Re: [PATCH] Improve checks in c_strlen (PR 87053)

[Jeff Law]

On 08/23/2018 03:27 AM, Bernd Edlinger wrote:
> On 08/22/18 18:28, Martin Sebor wrote:
>> On 08/22/2018 08:41 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>>
>>> This patch adds some more checks to c_getstr to fix PR middle-end/87053
>>> wrong code bug.
>>>
>>> Unfortunately this patch alone is not sufficient to fix the problem,
>>> but also the patch for PR 86714 that hardens c_getstr is necessary
>>> to prevent the wrong folding.
>>>
>>>
>>> Bootstrapped and reg-tested on top of my PR 86711/86714 patch.
>>> Is it OK for trunk?
>>
>> This case is also the subject of the patch I submitted back in
>> July for 86711/86714 and 86552.  With it, GCC avoid folding
>> the strlen call early and warns for the missing nul:
>>
>> warning: ‘__builtin_strlen’ argument missing terminating nul 
>> [-Wstringop-overflow=]
>>     if (__builtin_strlen (u.z) != 7)
>>     ^~~~
>>
>> The patch doesn't doesn't prevent all such strings from being
>> folded and it eventually lets fold_builtin_strlen() do its thing:
>>
>>    /* To avoid warning multiple times about unterminated
>>   arrays only warn if its length has been determined
>>   and is being folded to a constant.  */
>>    if (nonstr)
>>      warn_string_no_nul (loc, NULL_TREE, fndecl, nonstr);
>>
>>    return fold_convert_loc (loc, type, len);
>>
>> Handling this case is a matter of avoiding the folding here as
>> well and moving the warning later.
>>
>> Since my patch is still in the review queue and does much more
>> than just prevent folding of non-nul terminated arrays it should
>> be reviewed first.
>>
> 
> Hmmm, now you made me curious.
> 
> So I tried to install your patch (I did this on r263508
> since it does not apply to trunk, one thing I noted is
> that part 4 and part 3 seem to create 
> gcc/testsuite/gcc.dg/warn-strcpy-no-nul.c
> I did not check if they are identical or not).
> 
> So I tried the test case from this PR on the compiler built with your patch:
> 
> $ cat cat pr87053.c
> /* PR middle-end/87053 */
> 
> const union
> { struct {
>  char x[4];
>  char y[4];
>};
>struct {
>  char z[8];
>};
> } u = {{"1234", "567"}};
> 
> int main ()
> {
>if (__builtin_strlen (u.z) != 7)
>  __builtin_abort ();
> }
> $ gcc -S pr87053.c
> pr87053.c: In function 'main':
> pr87053.c:15:7: warning: '__builtin_strlen' argument missing terminating nul 
> [-Wstringop-overflow=]
> 15 |   if (__builtin_strlen (u.z) != 7)
> |   ^~~~
> pr87053.c:11:3: note: referenced argument declared here
> 11 | } u = {{"1234", "567"}};
> |   ^
> $ cat pr87053.s
>   .file   "pr87053.c"
>   .text
>   .globl  u
>   .section.rodata
>   .align 8
>   .type   u, @object
>   .size   u, 8
> u:
>   .ascii  "1234"
>   .string "567"
>   .text
>   .globl  main
>   .type   main, @function
> main:
> .LFB0:
>   .cfi_startproc
>   pushq   %rbp
>   .cfi_def_cfa_offset 16
>   .cfi_offset 6, -16
>   movq%rsp, %rbp
>   .cfi_def_cfa_register 6
>   callabort
>   .cfi_endproc
> .LFE0:
>   .size   main, .-main
>   .ident  "GCC: (GNU) 9.0.0 20180813 (experimental)"
>   .section.note.GNU-stack,"",@progbits
> 
> 
> So we get a warning, and still wrong code.
> 
> That is the reason why I think this patch of yours adds
> confusion by trying to fix everything in one step.
> 
> And I would like you to think of ways how to solve
> a problem step by step.
> 
> And at this time, sorry, we should restore correctness issues.
> And fix wrong-code issues.
> If possible without breaking existing warnings, yes.
> But no new warnings, sorry again.
Just a note, Martin's most fix for 86711/86714 fixes codegen issues
without breaking existing warnings or adding new warnings.  The new
warnings were broken out into follow-up patches.

jeff
> Bernd.
> 

Re: [PATCH] Improve checks in c_strlen (PR 87053)

[Jeff Law]

On 08/22/2018 10:28 AM, Martin Sebor wrote:
> On 08/22/2018 08:41 AM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> This patch adds some more checks to c_getstr to fix PR middle-end/87053
>> wrong code bug.
>>
>> Unfortunately this patch alone is not sufficient to fix the problem,
>> but also the patch for PR 86714 that hardens c_getstr is necessary
>> to prevent the wrong folding.
>>
>>
>> Bootstrapped and reg-tested on top of my PR 86711/86714 patch.
>> Is it OK for trunk?
> 
> This case is also the subject of the patch I submitted back in
> July for 86711/86714 and 86552.  With it, GCC avoid folding
> the strlen call early and warns for the missing nul:
> 
> warning: ‘__builtin_strlen’ argument missing terminating nul
> [-Wstringop-overflow=]
>    if (__builtin_strlen (u.z) != 7)
>    ^~~~
> 
> The patch doesn't doesn't prevent all such strings from being
> folded and it eventually lets fold_builtin_strlen() do its thing:
> 
>   /* To avoid warning multiple times about unterminated
>  arrays only warn if its length has been determined
>  and is being folded to a constant.  */
>   if (nonstr)
>     warn_string_no_nul (loc, NULL_TREE, fndecl, nonstr);
> 
>   return fold_convert_loc (loc, type, len);
> 
> Handling this case is a matter of avoiding the folding here as
> well and moving the warning later.
> 
> Since my patch is still in the review queue and does much more
> than just prevent folding of non-nul terminated arrays it should
> be reviewed first.
I think we need to address 86711/86714 first.  However, neither approach
to 86711/86714 (Bernd's or yours) is sufficient alone to fix this bug.
This patch can be layered on top of either approach to 86711/86714 to
fix 87053 (I've actually tested that).

So let's table this, hopefully for just a day or so.  It's getting late
and I've got more tests to run on the 86714/86711 patches for comparison
purposes and some loose ends I want to look at in Martin's patch.  I'd
hoped to be finished already, but wasn't able to move things as fast as
I hoped.

jeff

Re: [PATCH][Middle-end]patch for fixing PR 86519

[Jeff Law]

On 08/23/2018 10:13 AM, Qing Zhao wrote:
> 
>> On Aug 22, 2018, at 5:01 PM, Jeff Law  wrote:
>>
>> On 08/22/2018 11:05 AM, Qing Zhao wrote:
>>>
 On Aug 22, 2018, at 10:50 AM, Rainer Orth  
 wrote:

 Hi Qing,

> From the comments you put into PR86519, for SPARC, looks like that only
> 32-bit sparc has the problem.
> sparcv9 does NOT have the same issue.
>
> I was trying to find the string to represent 32-bit sparc target, but
> haven’t found it.
>
> my guess is:   sparc32*-*-*,  is this correct?

 no, certainly not.  You need to use something like sparc*-*-* && ilp32
 to catch the 32-bit multilib in both sparc-*-* and sparcv9-*-*
 configurations.  This is similar to { i?86-*-* x86_64-*-* } && ilp32 on 
 x86.
>>>
>>> thanks for the info.
>>>

 I'm still doubtful that enumerating target after target which all fail
 the original test for unrelated reasons is the way to go, especially
 given that there are others affected besides mips and sparc.
>>>
>>> I am not sure, either.
>>>
>>> however, given the available directives provided in testing suite, what’s 
>>> the better solution
>>> to this problem?
>> We could move the test into the i386 target specific test directory.
>> It'll still get good coverage that way and it'll be naturally restricted
>> to a target where we don't have to worry about the function name we're
>> scanning for showing up in undesirable contexts.
> 
> I will do this.  is it better to add it to both i386 and aarch64 target?
If we've got verification that it's working on aarch64, then adding it
to both is fine.

jeff
> 

Re: [patch, fortran] Fix PR 86837, wrong code regression in implied do loop in i/o

[Jerry DeLisle]

On 08/23/2018 01:12 PM, Thomas König wrote:

Hello world,

this patch fixes a regression by correctly checking that
the innner start, step or end values of an implied do
loop do not depend on an outer loop variable.

The check was actually done before, but gfc_check_dependency
wasn't finding all relevant cases.

Regression-tested. OK for trunk and 8.x?

Regards

 Thomas



Very OK Thomas.

Thanks for patch.

Jerry

Re: OpenRISC Port Submission

[David Edelsohn]

Stafford,

Thanks for rewriting and contributing the new OpenRISC port for GCC. I have
forwarded your request to the GCC Steering Committee to formally accept the
contribution.

The port still requires a technical review and approval from a GCC Global
Reviewer.  You mentioned Richard Henderson as co-author.  Has he reviewed
the entire port?  If Richard signs off on the port, approval could be
relatively quick.

Thanks, David

Re: [PATCH] treat -Wxxx-larger-than=HWI_MAX special (PR 86631)

[Martin Sebor]

On 08/23/2018 07:18 AM, Richard Biener wrote:

On Thu, Aug 23, 2018 at 12:20 AM Martin Sebor  wrote:


On 08/20/2018 06:14 AM, Richard Biener wrote:

On Thu, Jul 26, 2018 at 10:52 PM Martin Sebor  wrote:


On 07/26/2018 08:58 AM, Martin Sebor wrote:

On 07/26/2018 02:38 AM, Richard Biener wrote:

On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor  wrote:


On 07/25/2018 08:57 AM, Jakub Jelinek wrote:

On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:

I don't mean for the special value to be used except internally
for the defaults.  Otherwise, users wanting to override the default
will choose a value other than it.  I'm happy to document it in
the .opt file for internal users though.

-1 has the documented effect of disabling the warnings altogether
(-1 is SIZE_MAX) so while I agree that -1 looks better it doesn't
work.  (It would need more significant changes.)


The variable is signed, so -1 is not SIZE_MAX.  Even if -1 disables
it, you
could use e.g. -2 or other negative value for the other special case.


The -Wxxx-larger-than=N distinguish three ranges of argument
values (treated as unsigned):

   1.  [0, HOST_WIDE_INT_MAX)
   2.  HOST_WIDE_INT_MAX
   3.  [HOST_WIDE_INT_MAX + 1, Infinity)


But it doesn't make sense for those to be host dependent.


It isn't when the values are handled by each warning.  That's
also the point of this patch: to remove this (unintended)
dependency.


I think numerical user input should be limited to [0, ptrdiff_max]
and cases (1) and (2) should be simply merged, I see no value
in distinguishing them.  -Wxxx-larger-than should be aliased
to [0, ptrdiff_max], case (3) is achieved by -Wno-xxx-larger-than.


To be clear: this is also close to what this patch does.

The only wrinkle is that we don't know the value of PTRDIFF_MAX
either at the time the option initial value is set in the .opt
file or when the option is processed when it's specified either
on the command line or as an alias in the .opt file (as all
-Wno-xxx-larger-than options are).


But then why not make that special value accessible and handle
it as PTRDIFF_MAX when that is available (at users of the params)?

That is,

Index: gcc/calls.c
===
--- gcc/calls.c (revision 262951)
+++ gcc/calls.c (working copy)
@@ -1222,9 +1222,12 @@ alloc_max_size (void)
   if (alloc_object_size_limit)
 return alloc_object_size_limit;

-  alloc_object_size_limit
-= build_int_cst (size_type_node, warn_alloc_size_limit);
+  HOST_WIDE_INT limit = warn_alloc_size_limit;
+  if (limit == HOST_WIDE_INT_MAX)
+limit = tree_to_shwi (TYPE_MAX_VALUE (ptrdiff_type_node));

+  alloc_object_size_limit = build_int_cst (size_type_node, limit);
+
   return alloc_object_size_limit;
 }

use sth like

 if (warn_alloc_size_limit == -1)
   alloc_object_size_limit = fold_convert (size_type_node,
TYPE_MAX_VALUE (ptrdiff_type_node));
 else
   alloc_object_size_limit = size_int (warn_alloc_size_limit);

?  Also removing the need to have > int params values.


Not sure I understand this last part.  Remove the enhancement?
(We do need to handle option arguments in excess of INT_MAX.)


I see.



It's that HOST_WIDE_INT_MAX use that is problematic IMHO.  Why not use -1?


-1 is a valid/documented value of the argument of all these
options because it's treated as unsigned HWI:

   Warnings controlled by the option can be disabled either
   by specifying byte-size of ‘SIZE_MAX’

It has an intuitive meaning: warning for any size larger than
the maximum means not warning at all.  Treating -1 as special
instead of HOST_WIDE_INT_MAX would replace that meaning with
"warn on any size in excess of PTRDIFF_MAX."

A reasonable way to disable the warning is like so:

   gcc -Walloc-size-larger-than=$(getconf ULONG_MAX) ...

That would not work anymore.

Treating HOST_WIDE_INT_MAX as PTRDIFF_MAX is the natural choice
on LP64: they have the same value.  It's only less than perfectly
natural in ILP32 and even there it's not a problem in practice
because it's either far out of the range of valid values [0, 4GB]
(i.e., where HWI is a 64-bit long long), or it's also equal to
PTRDIFF_MAX (on hosts with no 64-bit type, if GCC even supports
any).

I'm not trying to be stubborn here but I just don't see why
you think that setting aside HOST_WIDE_INT_MAX is problematic.
Anything else is worse from a user-interface POV.  It makes
little difference inside GCC as long as we want to let users
choose to warn for allocation sizes over some value in
[PTRDIFF_MAX, SIZE_MAX] -- e.g., for malloc() over 3GB but
not for less.  There's also the -Walloca-size-larger-than=
case where PTRDIFF_MAX means only warn for known sizes over
than but not for unknown sizes.


Well I understand all of the above.  Alternatively you can omit
the initializer for the option and use

  if (!global_options_set.x_warn_alloc_size_limit)
warn_alloc_size_limit = PTRDIFF_MAX;


Using zero to mean unset would prevent the -larger-than 

OpenRISC Port Submission

[Stafford Horne]

Hello,

Since February this year I have been working on an OpenRISC clean room rewrite.

  
http://stffrdhrn.github.io/software/embedded/openrisc/2018/02/03/openrisc_gcc_rewrite.html

As per the article, the old port had issues with some of the owners signing over
FSF copyright.  To get around this I discussed options with the group and in the
end I opted for a clean room rewrite.

The new code base has been written by me and more recently Richard Henderson.  I
trust that both of us have our FSF GCC copyright's in place.

# Question

How should I go about submitting the port for review?  Should I split libgcc and
gcc into separate patches?  i.e. One patch mail for ChangeLog?  Or would you
prefer a single patch mail?  The patch size is around 150k.

Sorry, I understand its a big patch.

# Testing

We have been running the GCC testsuite with newlib and musl libc.  The results
are good.  See results published in a test build/release here:

 - https://github.com/stffrdhrn/gcc/releases/tag/or1k-9.0.0-20180730

# Early Review

If you are interested in reviewing online I have pushed:

 - https://github.com/stffrdhrn/gcc/commits/or1k-port-1

To build this requires some of the latest binutils patches submitted here:

 - https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01506.html
 - git tree: https://github.com/stffrdhrn/binutils-gdb/tree/or1k-6

-Stafford

Re: [Patch][GCC] Document and fix -r (partial linking)

[Joseph Myers]

On Thu, 23 Aug 2018, Iain Sandoe wrote:

> Joseph: As a side-comment, is there a reason that we don’t exclude 
> gomp/itm/fortran/gcov from the link for -nostdlib / -nodefaultlib?
> 
> If we are relying on the lib self-specs for this, then we’re not 
> succeeding since the one we build at the moment don’t include those 
> clauses.

Well, fortran/gfortranspec.c for example has

case OPT_nostdlib:
case OPT_nodefaultlibs:
case OPT_c:
case OPT_S:
case OPT_fsyntax_only:
case OPT_E:
  /* These options disable linking entirely or linking of the
 standard libraries.  */
  library = 0;
  break;

and only uses libgfortran.spec if (library).  So it's certainly meant to 
avoid linking with libgfortran or its dependencies if -nostdlib.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Make safe_iterator inline friends

[François Dumont]

On 22/08/2018 23:45, Jonathan Wakely wrote:

On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all my 
attempts to make them inline friends failed. I understand that an 
inline friend within a base class is not a very clean design.


Compiler error was:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:459: 
error: redefinition of 'bool __gnu_debug::operator==(const _Self&, 
const _OtherSelf&)'
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:452: 
note: 'bool __gnu_debug::operator==(const _Self&, const _Self&)' 
previously declared here
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:473: 
error: redefinition of 'bool __gnu_debug::operator!=(const _Self&, 
const _OtherSelf&)'
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:466: 
note: 'bool __gnu_debug::operator!=(const _Self&, const _Self&)' 
previously declared here


I don't know if it is a compiler issue


I don't think so. The error seems clear: when _Self and _OtherSelf are
the same type the friend declarations are the same function.


_Self and _OtherSelf and like the types defined in _Safe_iterator<_It, 
_Sq, random_access_interator_tag> in this patch. Depending on 
__conditional_type so definitely different.


In _Safe_iterator representing the container iterator type we have 
friend operators:


operator==(iterator, iterator);

operator==(iterator, const_iterator);

And in the one representing const_iterator:

operator==(const_iterator, const_iterator);

operator==(const_iterator, iterator);

but gcc do not see it this way.

I try again without the _Self and _OtherSelf types, using directly 
_Safe_iterator as it should and got:


/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h: 
In instantiation of 'class 
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iteratorstd::__cxx11::basic_string*, 
std::__cxx1998::vector, 
std::allocator > > >, 
std::__debug::vector >, 
std::forward_iterator_tag>':
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:489: 
required from 'class 
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iteratorstd::__cxx11::basic_string*, 
std::__cxx1998::vector, 
std::allocator > > >, 
std::__debug::vector >, 
std::bidirectional_iterator_tag>'
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:631: 
required from 'class 
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iteratorstd::__cxx11::basic_string*, 
std::__cxx1998::vector, 
std::allocator > > >, 
std::__debug::vector >, 
std::random_access_iterator_tag>'
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/util/testsuite_abi.cc:419: 
required from here
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:449: 
error: redefinition of 'templateclass _Cat> bool __gnu_debug::operator==(const 
__gnu_debug::_Safe_iterator<_IteL, _Seq, _Cat>&, const 
__gnu_debug::_Safe_iterator<_IteR, _Seq, _Cat>&)'
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:449: 
note: 'template bool 
__gnu_debug::operator==(const __gnu_debug::_Safe_iterator<_IteL, _Seq, 
_Cat>&, const __gnu_debug::_Safe_iterator<_IteR, _Seq, _Cat>&)' 
previously declared here


redefinition and previous declaration are targetting the exact same 
line. This is why I think it has something to do with the inheritance 
between the different iterator types.


But as I said it doesn't really matter for the patch. We can go with 
those 2 operators not inline friends.


So appart from that is it ok to commit ?

François

PATCH for c++/87068, missing diagnostic with fallthrough statement

[Marek Polacek]

The C++ standard says that [[fallthrough]]; at the end of a switch statement
is ill-formed: 

Currently we do check that the statement after a fallthrough statement is
a labeled statement, but we didn't warn if a fallthrough statement is at
the very end of a switch statement.  This patch adds this warning.

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

2018-08-23  Marek Polacek  

PR c++/87068
* gimplify.c (expand_FALLTHROUGH_r): If IFN_FALLTHROUGH was found
at the end of a seq, save its location to walk_stmt_info.
(expand_FALLTHROUGH): Warn if IFN_FALLTHROUGH is at the end of
a switch.

* c-c++-common/Wimplicit-fallthrough-37.c: New test.

diff --git gcc/gimplify.c gcc/gimplify.c
index e35137aec2c..04c15016f18 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -2231,7 +2231,7 @@ maybe_warn_implicit_fallthrough (gimple_seq seq)
 
 static tree
 expand_FALLTHROUGH_r (gimple_stmt_iterator *gsi_p, bool *handled_ops_p,
- struct walk_stmt_info *)
+ struct walk_stmt_info *wi)
 {
   gimple *stmt = gsi_stmt (*gsi_p);
 
@@ -2250,11 +2250,14 @@ expand_FALLTHROUGH_r (gimple_stmt_iterator *gsi_p, bool 
*handled_ops_p,
   if (gimple_call_internal_p (stmt, IFN_FALLTHROUGH))
{
  gsi_remove (gsi_p, true);
+ location_t loc = gimple_location (stmt);
  if (gsi_end_p (*gsi_p))
-   return integer_zero_node;
+   {
+ wi->info = 
+ return integer_zero_node;
+   }
 
  bool found = false;
- location_t loc = gimple_location (stmt);
 
  gimple_stmt_iterator gsi2 = *gsi_p;
  stmt = gsi_stmt (gsi2);
@@ -2317,6 +2320,14 @@ expand_FALLTHROUGH (gimple_seq *seq_p)
   struct walk_stmt_info wi;
   memset (, 0, sizeof (wi));
   walk_gimple_seq_mod (seq_p, expand_FALLTHROUGH_r, NULL, );
+  if (wi.callback_result == integer_zero_node)
+{
+  /* We've found [[fallthrough]]; at the end of a switch, which the C++
+standard says is ill-formed; see [dcl.attr.fallthrough].  */
+  location_t *loc = static_cast(wi.info);
+  warning_at (*loc, 0, "attribute % not preceding "
+ "a case label or default label");
+}
 }
 
 
diff --git gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c 
gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
index e69de29bb2d..644003af47d 100644
--- gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
+++ gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
@@ -0,0 +1,13 @@
+/* PR c++/87068 */
+/* { dg-do compile } */
+
+void
+f (int n)
+{
+  switch (n)
+{
+case 4:
+  ++n;
+  __attribute__((fallthrough)); /* { dg-warning "not preceding" } */
+}
+}

[patch, fortran] Fix PR 86837, wrong code regression in implied do loop in i/o

[Thomas König]

Hello world,

this patch fixes a regression by correctly checking that
the innner start, step or end values of an implied do
loop do not depend on an outer loop variable.

The check was actually done before, but gfc_check_dependency
wasn't finding all relevant cases.

Regression-tested. OK for trunk and 8.x?

Regards

Thomas

2018-08-23  Thomas Koenig  

PR fortran/86837
* frontend-passes.c (var_in_expr_callback): New function.
(var_in_expr): New function.
(traverse_io_block): Use var_in_expr instead of
gfc_check_dependency for checking if the variable depends on the
previous interators.

2018-08-23  Thomas Koenig  

PR fortran/86837
* gfortran.dg/implied_do_io_6.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 263752)
+++ frontend-passes.c	(Arbeitskopie)
@@ -1104,6 +1104,31 @@ convert_elseif (gfc_code **c, int *walk_subtrees A
   return 0;
 }
 
+/* Callback function to var_in_expr - return true if expr1 and
+   expr2 are identical variables. */
+static int
+var_in_expr_callback (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+		  void *data)
+{
+  gfc_expr *expr1 = (gfc_expr *) data;
+  gfc_expr *expr2 = *e;
+
+  if (expr2->expr_type != EXPR_VARIABLE)
+return 0;
+
+  return expr1->symtree->n.sym == expr2->symtree->n.sym;
+}
+
+/* Return true if expr1 is found in expr2. */
+
+static bool
+var_in_expr (gfc_expr *expr1, gfc_expr *expr2)
+{
+  gcc_assert (expr1->expr_type == EXPR_VARIABLE);
+
+  return gfc_expr_walker (, var_in_expr_callback, (void *) expr1);
+}
+
 struct do_stack
 {
   struct do_stack *prev;
@@ -1256,9 +1281,9 @@ traverse_io_block (gfc_code *code, bool *has_reach
 	  for (int j = i - 1; j < i; j++)
 	{
 	  if (iters[j]
-		  && (gfc_check_dependency (var, iters[j]->start, true)
-		  || gfc_check_dependency (var, iters[j]->end, true)
-		  || gfc_check_dependency (var, iters[j]->step, true)))
+		  && (var_in_expr (var, iters[j]->start)
+		  || var_in_expr (var, iters[j]->end)
+		  || var_in_expr (var, iters[j]->step)))
 		  return false;
 	}		  
 	}
! { dg-do  run }
! { dg-options "-ffrontend-optimize" }
! PR 86837 - this was mis-optimized by trying to turn this into an
! array I/O statement.
! Original test case by "Pascal".

Program read_loop

  implicit none

  integer :: i, j

  ! number of values per column
  integer, dimension(3) :: nvalues
  data nvalues / 1, 2, 4 /

  ! values in a 1D array
  real, dimension(7) :: one_d
  data one_d / 1,   11, 12,   21, 22, 23, 24 /

  ! where to store the data back
  real, dimension(4, 3) :: two_d

  ! 1 - write our 7 values in one block
  open(unit=10, file="loop.dta", form="unformatted")
  write(10) one_d
  close(unit=10)

  ! 2 - read them back in chosen cells of a 2D array
  two_d = -9
  open(unit=10, file="loop.dta", form="unformatted", status='old')
  read(10) ((two_d(i,j), i=1,nvalues(j)), j=1,3)
  close(unit=10, status='delete')

  ! 4 - print the whole array, just in case

  if (any(reshape(two_d,[12]) /= [1.,-9.,-9.,-9.,11.,12.,-9.,-9.,21.,22.,23.,24.])) call abort

end Program read_loop

[PATCH] Fix failure when -fno-rtti test is run in C++17 or later

[Jonathan Wakely]

* testsuite/util/testsuite_allocator.h (__gnu_test::memory_resource):
Only define when RTTI is enabled.

Tested x86_64-linux, committed to trunk.


commit b79c14098cd52633b680c7186f472028fec64f04
Author: Jonathan Wakely 
Date:   Thu Aug 23 20:25:36 2018 +0100

Fix failure when -fno-rtti test is run in C++17 or later

* testsuite/util/testsuite_allocator.h 
(__gnu_test::memory_resource):
Only define when RTTI is enabled.

diff --git a/libstdc++-v3/testsuite/util/testsuite_allocator.h 
b/libstdc++-v3/testsuite/util/testsuite_allocator.h
index 03679aad8dc..b0fecfb59a3 100644
--- a/libstdc++-v3/testsuite/util/testsuite_allocator.h
+++ b/libstdc++-v3/testsuite/util/testsuite_allocator.h
@@ -697,7 +697,8 @@ namespace __gnu_test
 };
 #endif // C++11
 
-#if __cplusplus >= 201703L && __cpp_aligned_new
+#if __cplusplus >= 201703L
+#if __cpp_aligned_new && __cpp_rtti
 // A concrete memory_resource, with error checking.
 class memory_resource : public std::pmr::memory_resource
 {
@@ -835,6 +836,7 @@ namespace __gnu_test
 
   allocation_lists* lists;
 };
+#endif // aligned-new && rtti
 
 // Set the default resource, and restore the previous one on destruction.
 struct default_resource_mgr
@@ -849,7 +851,7 @@ namespace __gnu_test
   std::pmr::memory_resource* prev;
 };
 
-#endif // C++17 && aligned-new
+#endif // C++17
 
 } // namespace __gnu_test
 

Re: [PATCH,FORTRAN] Remove OS dependency in definition of ASYNC_IO

[Thomas Koenig]

David,


The recent fix for Async I/O on systems without Gthread cond support added
an explicit test for _AIX.  This test is unnecessary because
__GTHREAD_HAS_COND is not defined on AIX.  Protecting the use of
__gthread_cond_t inside in the ASYNC_IO macro for the declaration of struct
adv_cond is sufficient.  This patch simplifies the macro definition.

Bootstrapped on powerpc-ibm-aix7.2.0.0

Okay?


OK.

Thanks for the patch!

Thomas

[PATCH,FORTRAN] Remove OS dependency in definition of ASYNC_IO

[David Edelsohn]

The recent fix for Async I/O on systems without Gthread cond support added
an explicit test for _AIX.  This test is unnecessary because
__GTHREAD_HAS_COND is not defined on AIX.  Protecting the use of
__gthread_cond_t inside in the ASYNC_IO macro for the declaration of struct
adv_cond is sufficient.  This patch simplifies the macro definition.

Bootstrapped on powerpc-ibm-aix7.2.0.0

Okay?

Thanks, David

* async.h (ASYNC_IO): Revert _AIX test.

Index: async.h
===
--- async.h (revision 263818)
+++ async.h (working copy)
@@ -29,7 +29,7 @@
__gthread_cond_t and __gthread_equal / __gthread_self.  Check
this.  */

-#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) &&
!defined(_AIX)
+#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X)
 #define ASYNC_IO 1
 #else
 #define ASYNC_IO 0

Fix typo "permutaion" in vect_grouped_store_supported.

[Prathamesh Kulkarni]

Committed as obvious in r263819.

Regards,
Prathamesh
2018-08-23  Prathamesh Kulkarni  

* tree-vect-data-refs.c (vect_grouped_store_supported): Fix typo
"permutaion".

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index d70d207c7d2..909728919c7 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -5154,7 +5154,7 @@ vect_grouped_store_supported (tree vectype, unsigned 
HOST_WIDE_INT count)
 
   if (dump_enabled_p ())
 dump_printf (MSG_MISSED_OPTIMIZATION,
-"permutaion op not supported by target.\n");
+"permutation op not supported by target.\n");
   return false;
 }
 

Re: Async I/O patch with compilation fix

[Thomas Koenig]

David,

I will take the "thank you for restoring bootstrap for AIX" as implied
in your e-mail.

Second, the patch that you applied is unacceptable.  ASYNC_IO already is 
set to zero for AIX.


There is a clear procedure for this something that you deem
"unacceptable": Submit a patch (for which I promise a fast
review) or, if you feel that the patch is simple and obvious,
commit it yourself and announce it to the fortran and gcc-patches
mailing list.

Thomas

[PATCH] C++: highlight bad argument in some users of print_z_candidates (more PR c++/85110)

[David Malcolm]

This is a followup to:

  "[PATCH] C++: underline param in print_conversion_rejection (more PR 
c++/85110)"
 https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01480.html

to highlight the pertinent argument in a unmatched function call
for which there is one candidate.

It updates the output from:

demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, const 
char*&, float&)'
5 |   return s4::member_1 (first, second, third);
  |^
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**, 
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |^~~~
demo.cc:1:56: note:   no known conversion for argument 2 from 'const char*' to 
'const char**'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |   ~^~~

to:

demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:31: error: no matching function for call to 's4::member_1(int&, const 
char*&, float&)'
5 |   return s4::member_1 (first, second, third);
  |   ^~
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**, 
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |^~~~
demo.cc:1:56: note:   no known conversion for argument 2 from 'const char*' to 
'const char**'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |   ~^~~

updating the location of the "error" to use that of the argument with
the mismatching type.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; adds a
further 33 PASS results to g++.sum.

OK for trunk?

gcc/cp/ChangeLog:
PR c++/85110
* call.c (struct conversion_info): Add "loc" field.
(arg_conversion_rejection): Add "loc" param, using it to
initialize the new field.
(bad_arg_conversion_rejection): Likewise.
(explicit_conversion_rejection): Initialize the new field to
UNKNOWN_LOCATION.
(template_conversion_rejection): Likewise.
(add_function_candidate): Pass on the argument location to the new
param of arg_conversion_rejection.
(add_conv_candidate): Likewise.
(build_builtin_candidate): Likewise.
(build_user_type_conversion_1): Likewise.
(get_location_for_arg_conversion): New function.
(get_location_for_unmatched_call): New function.
(build_new_method_call_1): Call get_location_for_unmatched_call
when reporting on unmatched functions, and use it for the error's
location.

gcc/testsuite/ChangeLog:
PR c++/85110
* g++.dg/diagnostic/param-type-mismatch-2.C: Update expected
results to underline the pertinent argument in the initial
error for unmatched calls in which there is a single candidate.
Add test coverage for an unmatched overloaded operator.
---
 gcc/cp/call.c  | 107 ++---
 .../g++.dg/diagnostic/param-type-mismatch-2.C  |  37 ++-
 2 files changed, 123 insertions(+), 21 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index ef445e0..3bc42f5 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -436,6 +436,8 @@ struct conversion_info {
   tree from;
   /* The type of the parameter.  */
   tree to_type;
+  /* The location of the argument.  */
+  location_t loc;
 };
   
 struct rejection_reason {
@@ -627,24 +629,28 @@ arity_rejection (tree first_arg, int expected, int actual)
 }
 
 static struct rejection_reason *
-arg_conversion_rejection (tree first_arg, int n_arg, tree from, tree to)
+arg_conversion_rejection (tree first_arg, int n_arg, tree from, tree to,
+ location_t loc)
 {
   struct rejection_reason *r = alloc_rejection (rr_arg_conversion);
   int adjust = first_arg != NULL_TREE;
   r->u.conversion.n_arg = n_arg - adjust;
   r->u.conversion.from = from;
   r->u.conversion.to_type = to;
+  r->u.conversion.loc = loc;
   return r;
 }
 
 static struct rejection_reason *
-bad_arg_conversion_rejection (tree first_arg, int n_arg, tree from, tree to)
+bad_arg_conversion_rejection (tree first_arg, int n_arg, tree from, tree to,
+ location_t loc)
 {
   struct rejection_reason *r = alloc_rejection (rr_bad_arg_conversion);
   int adjust = first_arg != NULL_TREE;
   r->u.bad_conversion.n_arg = n_arg - adjust;
   r->u.bad_conversion.from = from;
   r->u.bad_conversion.to_type = to;
+  r->u.bad_conversion.loc = loc;
   return r;
 }
 
@@ -655,6 +661,7 @@ explicit_conversion_rejection (tree from, tree to)
   r->u.conversion.n_arg = 0;
   r->u.conversion.from = from;
   r->u.conversion.to_type = to;
+  r->u.conversion.loc = UNKNOWN_LOCATION;
   return 

Re: [PATCH] Optimise sqrt reciprocal multiplications

[Kyrill Tkachov]

Hi Richard,

On 23/08/18 11:13, Richard Sandiford wrote:

Kyrill  Tkachov  writes:

Hi all,

This patch aims to optimise sequences involving uses of 1.0 / sqrt (a) under 
-freciprocal-math and -funsafe-math-optimizations.
In particular consider:

x = 1.0 / sqrt (a);
r1 = x * x;  // same as 1.0 / a
r2 = a * x; // same as sqrt (a)

If x, r1 and r2 are all used further on in the code, this can be transformed 
into:
tmp1 = 1.0 / a
tmp2 = sqrt (a)
tmp3 = tmp1 * tmp2
x = tmp3
r1 = tmp1
r2 = tmp2

Nice optimisation :-)  Someone who knows the pass better should review,
but:


Thanks for the review.


There seems to be an implicit assumption that this is a win even
when the r1 and r2 assignments are only conditionally executed.
That's probably true, but it might be worth saying explicitly.


I'll admit I had not considered that case.
I think it won't make a difference in practice, as the really expensive 
operations here
are the sqrt and the division and they are on the executed path in either case 
and them
becoming independent should be a benefit of its own.


+/* Return TRUE if USE_STMT is a multiplication of DEF by A.  */
+
+static inline bool
+is_mult_by (gimple *use_stmt, tree def, tree a)
+{
+  if (gimple_code (use_stmt) == GIMPLE_ASSIGN
+  && gimple_assign_rhs_code (use_stmt) == MULT_EXPR)
+{
+  tree op0 = gimple_assign_rhs1 (use_stmt);
+  tree op1 = gimple_assign_rhs2 (use_stmt);
+
+  return (op0 == def && op1 == a)
+ || (op0 == a && op1 == def);
+}
+  return 0;
+}

Seems like is_square_of could now be a light-weight wrapper around this.


Indeed, I've done the wrapping now.


@@ -652,6 +669,180 @@ execute_cse_reciprocals_1 (gimple_stmt_iterator *def_gsi, 
tree def)
occ_head = NULL;
  }
  
+/* Transform sequences like

+   x = 1.0 / sqrt (a);
+   r1 = x * x;
+   r2 = a * x;
+   into:
+   tmp1 = 1.0 / a;
+   tmp2 = sqrt (a);
+   tmp3 = tmp1 * tmp2;
+   x = tmp3;
+   r1 = tmp1;
+   r2 = tmp2;
+   depending on the uses of x, r1, r2.  This removes one multiplication and
+   allows the sqrt and division operations to execute in parallel.
+   DEF_GSI is the gsi of the initial division by sqrt that defines
+   DEF (x in the example abovs).  */
+
+static void
+optimize_recip_sqrt (gimple_stmt_iterator *def_gsi, tree def)
+{
+  use_operand_p use_p;
+  imm_use_iterator use_iter;
+  gimple *stmt = gsi_stmt (*def_gsi);
+  tree x = def;
+  tree orig_sqrt_ssa_name = gimple_assign_rhs2 (stmt);
+  tree div_rhs1 = gimple_assign_rhs1 (stmt);
+
+  if (TREE_CODE (orig_sqrt_ssa_name) != SSA_NAME
+  || TREE_CODE (div_rhs1) != REAL_CST
+  || !real_equal (_REAL_CST (div_rhs1), ))
+return;
+
+  gimple *sqrt_stmt = SSA_NAME_DEF_STMT (orig_sqrt_ssa_name);
+  if (!is_gimple_call (sqrt_stmt)
+  || !gimple_call_lhs (sqrt_stmt))
+return;
+
+  gcall *call = as_a  (sqrt_stmt);

Very minor, but:

   gcall *sqrt_stmt
 = dyn_cast  (SSA_NAME_DEF_STMT (orig_sqrt_ssa_name));
   if (!sqrt_stmt || !gimple_call_lhs (sqrt_stmt))
 return;

would avoid the need for the separate as_a<>, and would mean that
we only call gimple_call_* on gcalls.


Ok.


+  if (has_other_use)
+{
+  /* Using the two temporaries tmp1, tmp2 from above
+the original x is now:
+x = tmp1 * tmp2.  */
+  gcc_assert (mult_ssa_name);
+  gcc_assert (sqr_ssa_name);
+  gimple_stmt_iterator gsi2 = gsi_for_stmt (stmt);
+
+  tree new_ssa_name
+   = make_temp_ssa_name (TREE_TYPE (a), NULL, "recip_sqrt_transformed");
+  gimple *new_stmt
+   = gimple_build_assign (new_ssa_name, MULT_EXPR,
+  mult_ssa_name, sqr_ssa_name);
+  gsi_insert_before (, new_stmt, GSI_SAME_STMT);
+  gcc_assert (gsi_stmt (gsi2) == stmt);
+  gimple_assign_set_rhs_from_tree (, new_ssa_name);
+  fold_stmt ();
+  update_stmt (stmt);

In this case we're replacing the statement in its original position,
so there's no real need to use a temporary.  It seems better to
change the rhs_code, rhs1 and rhs2 of stmt in-place, with the same
lhs as before.


Yes, that's cleaner.


@@ -762,6 +953,23 @@ pass_cse_reciprocals::execute (function *fun)
if (optimize_bb_for_size_p (bb))
  continue;

Seems unnecessary to skip the new optimisation when optimising for size.
Like you say, it saves a multiplication overall.  Also:


Indeed.


+  if (flag_unsafe_math_optimizations)
+   {
+ for (gimple_stmt_iterator gsi = gsi_after_labels (bb);
+  !gsi_end_p (gsi);
+  gsi_next ())
+   {
+ gimple *stmt = gsi_stmt (gsi);
+
+ if (gimple_has_lhs (stmt)
+ && (def = SINGLE_SSA_TREE_OPERAND (stmt, SSA_OP_DEF)) != NULL
+ && FLOAT_TYPE_P (TREE_TYPE (def))
+ && TREE_CODE (def) == SSA_NAME
+ && is_gimple_assign (stmt)
+ && gimple_assign_rhs_code (stmt) == RDIV_EXPR)
+   optimize_recip_sqrt (, def);
+   }
+  

Re: [PATCH] fix typo 'exapnded' to 'expanded'

[Richard Sandiford]

Giuliano Augusto Faulin Belinassi  writes:
> There was a small typo in the current version of trunk, more precisely
> in genmatch.c and exp_unst.ads. This patch fixes it.
>
> Changelog:
>
> 2018-08-23  Giuliano Belinassi 
>
> * genmatch.c: Fix typo 'exapnded' to 'expanded'.
> * exp_unst.ads: Likewise.

Applied. thanks.

Richard

PS. gcc/ and gcc/ada/ have separate changelogs, so I used:

2018-08-23  Giuliano Belinassi  

gcc/
* genmatch.c (parser::parse_operation): Fix typo 'exapnded'
to 'expanded'.

gcc/ada/
* exp_unst.ads: Fix typo 'exapnded' to 'expanded'.

Re: C++ PATCH for c++/67012, c++/86942, detect invalid cases with function return type deduction

[Marek Polacek]

On Tue, Aug 21, 2018 at 11:59:06PM +1200, Jason Merrill wrote:
> On Fri, Aug 17, 2018 at 2:17 PM, Marek Polacek  wrote:
> > As I promised in ,
> > this patch fixes a couple of invalid cases we weren't detecting.  It's got
> > testcases from two PRs and another case I found out; they're intertwined so
> > I think it makes sense to fix them in one go.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2018-08-16  Marek Polacek  
> >
> > PR c++/86942
> > PR c++/67012
> > * decl.c (grokdeclarator): Disallow functions with trailing return
> > type with decltype(auto) as its type.  Also check the function if
> > it's inner declarator doesn't exist.
> >
> > * g++.dg/cpp0x/auto52.C: New test.
> > * g++.dg/cpp1y/auto-fn52.C: New test.
> > * g++.dg/cpp1y/auto-fn53.C: New test.
> > * g++.dg/cpp1y/auto-fn54.C: New test.
> >
> > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > index fa58bc4d2b3..8261f8e30e5 100644
> > --- gcc/cp/decl.c
> > +++ gcc/cp/decl.c
> > @@ -11238,7 +11238,10 @@ grokdeclarator (const cp_declarator *declarator,
> >
> > /* Handle a late-specified return type.  */
> > tree late_return_type = declarator->u.function.late_return_type;
> > -   if (funcdecl_p)
> > +   if (funcdecl_p
> > +   /* This is the case e.g. for
> > +  using T = auto () -> int.  */
> > +   || inner_declarator == NULL)
> 
> Hmm, checking funcdecl_p here seems just wrong; these errors should be
> the same regardless of whether this is declaring a function.  What
> breaks if we just remove this condition?  The deduction guide errors
> will need to be adjusted to handle the abstract declarator case, but
> that looks like the only spot that would need fixing.
 
That was my first idea but it breaks with pointers to functions and pointers
to member functions as in auto2.C:

auto (*fp)() = f;
where the declarators are: cdk_function -> cdk_pointer -> cdk_id
auto (A::*pmf)() = ::f;
where the declarators are: cdk_function -> cdk_ptrmem -> cdk_id

it complains that a function uses 'auto' type specifier without trailing return 
type

> >   {
> > if (tree auto_node = type_uses_auto (type))
> >   {
> > @@ -11270,6 +11273,18 @@ grokdeclarator (const cp_declarator *declarator,
> >name, type);
> > return error_mark_node;
> >   }
> > +   else if (is_auto (type)
> > +&& (TYPE_IDENTIFIER (type)
> > +== decltype_auto_identifier))
> 
> I think you want AUTO_IS_DECLTYPE here.

Ah, nice.

Marek

Re: [PATCH][Middle-end]patch for fixing PR 86519

[Qing Zhao]

> On Aug 22, 2018, at 5:01 PM, Jeff Law  wrote:
> 
> On 08/22/2018 11:05 AM, Qing Zhao wrote:
>> 
>>> On Aug 22, 2018, at 10:50 AM, Rainer Orth  
>>> wrote:
>>> 
>>> Hi Qing,
>>> 
 From the comments you put into PR86519, for SPARC, looks like that only
 32-bit sparc has the problem.
 sparcv9 does NOT have the same issue.
 
 I was trying to find the string to represent 32-bit sparc target, but
 haven’t found it.
 
 my guess is:   sparc32*-*-*,  is this correct?
>>> 
>>> no, certainly not.  You need to use something like sparc*-*-* && ilp32
>>> to catch the 32-bit multilib in both sparc-*-* and sparcv9-*-*
>>> configurations.  This is similar to { i?86-*-* x86_64-*-* } && ilp32 on x86.
>> 
>> thanks for the info.
>> 
>>> 
>>> I'm still doubtful that enumerating target after target which all fail
>>> the original test for unrelated reasons is the way to go, especially
>>> given that there are others affected besides mips and sparc.
>> 
>> I am not sure, either.
>> 
>> however, given the available directives provided in testing suite, what’s 
>> the better solution
>> to this problem?
> We could move the test into the i386 target specific test directory.
> It'll still get good coverage that way and it'll be naturally restricted
> to a target where we don't have to worry about the function name we're
> scanning for showing up in undesirable contexts.

I will do this.  is it better to add it to both i386 and aarch64 target?

Qing
> 
> Another approach might be to scan the RTL dumps.  But if there were a
> target that didn't have direct jumps and requires a hi+lo_sum style
> sequence to load a symbolic constant it would fail.
> 
> jeff

Re: PR libstdc++/68222 Hide safe iterator operators

[Jonathan Wakely]

On 23/08/18 15:29 +0100, Jonathan Wakely wrote:

On 23/08/18 08:51 +0100, Jonathan Wakely wrote:

On 21/08/18 22:18 +0200, François Dumont wrote:

On 21/08/2018 11:33, Jonathan Wakely wrote:

On 18/08/18 22:31 +0200, François Dumont wrote:
Here is the new proposal. It is indeed possible to keep 
_Safe_iterator and just add a _Category template parameter to 
it.


While this is still a large patch (obviously, because it's changing a
lot!) I think this version is much easier to understand, and doesn't
add a whole new class unnecessarily. Thanks for updating it.

I introduce a friend declaration to access container _Base 
nested typedef from the safe iterator.


I review the safe const_iterator constructor from safe 
iterator. I now check if we are in the a const_iterator 
context so that compilers don't even try to consider this 
constructor when we are in an iterator context.


Nice.

I adapted _Safe_local_iterator the same way to keep 
consistency with _Safe_iterator and because I find the new 
design cleaner. It also fixes the same problem I fixed on 
_Safe_iterator when checking it iterator has been initialized 
using _MutableIterator() rather than _Iterator().


I stop overloading __get_distance for safe iterators or safe 
local iterators, it was useless. I prefer to introduce similar 
functions as members. Same for __get_distance_from_begin or 
__get_distance_to_end, and I move code in safe_iterator.tcc.


Tested under Linux x86_64 debug mode.

Ok to commit ?


OK for trunk, thanks again.




Note that it also avoids to adapt the pretty printers scripts.

I'll commit it tomorrow once I'll have rework the ChangeLog entry. 
I'll also add the test case in PR 68222 adapted for the testsuite.


I'm not sure when it started, but I'm seeing a few failures in the
testsuite, with linker errors like this:

FAIL: 25_algorithms/sort/34636.cc (test for excess errors)
Excess errors:
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:614: undefined reference to `std::__debug::vector >* std::__niter_base >*, 
std::__cxx1998::vector >, std::allocator > > >, std::__debug::vector >, 
std::allocator > > > >(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >*, std::__cxx1998::vector >, std::allocator > > > >, std::__debug::vector >, std::allocator > > >, std::random_access_iterator_tag> const&)'
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:614: undefined reference to `std::__debug::vector >* std::__niter_base >*, 
std::__cxx1998::vector >, std::allocator > > >, std::__debug::vector >, 
std::allocator > > > >(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >*, std::__cxx1998::vector >, std::allocator > > > >, std::__debug::vector >, std::allocator > > >, std::random_access_iterator_tag> const&)'
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:614: undefined reference to `std::__debug::vector >* std::__niter_base >*, 
std::__cxx1998::vector >, std::allocator > > >, std::__debug::vector >, 
std::allocator > > > >(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >*, std::__cxx1998::vector >, std::allocator > > > >, std::__debug::vector >, std::allocator > > >, std::random_access_iterator_tag> const&)'
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:286: undefined reference to `std::__debug::vector >* std::__niter_base >*, 
std::__cxx1998::vector >, std::allocator > > >, std::__debug::vector >, 
std::allocator > > > >(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >*, std::__cxx1998::vector >, std::allocator > > > >, std::__debug::vector >, std::allocator > > >, std::random_access_iterator_tag> const&)'
collect2: error: ld returned 1 exit status

This happens when run like:

make check RUNTESTFLAGS="conformance.exp==25_algorithms/sort/*.cc 
--target_board=unix/-std=gnu++98/-D_GLIBCXX_USE_CXX11_ABI=0/-D_GLIBCXX_DEBUG"


Seems to be caused by r262349

  2018-07-03  François Dumont

  * include/bits/stl_algobase.h (__niter_wrap): New.
  (__copy_move_a2(_II, _II, _OI)): Use latter.
  (__copy_move_backward_a2(_BI1, _BI1, _BI2)): Likewise.
  (fill_n(_OI, _Size, const _Tp&)): Likewise.
  (equal(_II1, _II1, _II2)): Use __glibcxx_requires_can_increment.
  * include/debug/stl_iterator.h
  (std::__niter_base(const __gnu_cxx::_Safe_iterator<
  __gnu_cxx::__normal_iterator<>, _Sequence>&)): New declaration.
  * include/debug/vector (__niter_base(const __gnu_cxx::_Safe_iterator<
  __gnu_cxx::__normal_iterator<>, _Sequence>&)): New.


I think because include/debug/stl_iterator.h declares the __niter_base
overload unconditionally, but then include/debug/vector only defines
it for C++11 and later.


Fixed by this patch. Tested x86_64-linux, committed to trunk.



commit ef605abf0a3ae6ee05996f7e9bdef8bdc13e37df
Author: Jonathan Wakely 
Date:   Thu Aug 23 16:11:22 2018 

Re: [PATCH] print full STRING_CST in Gimple dumps (PR 87052)

[Martin Sebor]

On 08/23/2018 08:07 AM, Michael Matz wrote:

Hi,

On Thu, 23 Aug 2018, Richard Biener wrote:


Can you write a not \0 terminated string literal in C?


Yes: char a[2] = "12";


I thought they are fully defined in translation phase #1 ...


No, you can't write a string literal which is not zero terminated, because
in translation phase 7 a zero code is appended to all character sequences
resulting from string literals, which is then used to allocate and
initialize a static (wide) character array of just the right size,
including the zero code.

The above construct uses that static char[3] array from the string literal
to initialize a char[2] array (which is explicitely allowed), and _that_
one is not zero terminated.  But it's also no string literal.


Yes, you're right.  I misinterpreted Richard's question as
asking if one could construct an unterminated array of chars
using a string literal.

The distinction that I thought would be useful to capture in
Gimple is between "12" that initializes an array of two elements
(and where the nul doesn't fit) vs "12" that initializes one of
three elements (and where the nul does fit).  It's probably not
terribly important when the array type also appears in Gimple
like in the case above but there are (perhaps corner) cases
where it doesn't, as in the second one below:

  char a[2] = "12";
  char *p = (char[2]){ "12" };

which ends up represented as:

  char a[2];
  char * p;
  char D.1910[2];

  try
{
  a = "12";
  D.1910 = "12";
  p = 
}

Martin

Re: [PATCH] Fix tests that fail in C++98 mode

[Jonathan Wakely]

On 23/08/18 00:42 +0100, Jonathan Wakely wrote:

* testsuite/23_containers/deque/capacity/max_size.cc: Fix test for
C++98 mode.
* testsuite/23_containers/deque/modifiers/assign/1.cc: Likewise.
* testsuite/23_containers/list/modifiers/assign/1.cc: Likewise.
* testsuite/23_containers/vector/bool/modifiers/assign/1.cc: Likewise.
* testsuite/23_containers/vector/capacity/max_size.cc: Likewise.
* testsuite/23_containers/vector/modifiers/assign/1.cc: Likewise.


Two more fixes along the same lines.

Tested x86_64-linux, committed to trunk.


commit 132a337e0f59fa4a6fd2213418c6bb2e922ecf44
Author: Jonathan Wakely 
Date:   Thu Aug 23 14:17:36 2018 +0100

Fix C++98 tests to not use C++11 features.

* testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc:
Fix C++98 test to not use C++11 features.
* testsuite/25_algorithms/fill_n/2.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/25_algorithms/fill_n/2.cc b/libstdc++-v3/testsuite/25_algorithms/fill_n/2.cc
index 6e18032e1e6..fb951b5c175 100644
--- a/libstdc++-v3/testsuite/25_algorithms/fill_n/2.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/fill_n/2.cc
@@ -31,7 +31,7 @@ test01()
   ref.push_back(1);
   ref.push_back(2);
 
-  std::vector> vvect;
+  std::vector > vvect;
   vvect.push_back(std::vector());
   vvect.push_back(std::vector());
 
diff --git a/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc b/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc
index 84449d6dbd4..5da782a4550 100644
--- a/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc
@@ -31,8 +31,8 @@ bad_lower(int lhs, int rhs)
 
 void test01()
 {
-  int ins[] { 0, 1, 2, 3 };
-  int outs[] { 9, 9 };
+  int ins[] = { 0, 1, 2, 3 };
+  int outs[] = { 9, 9 };
   std::partial_sort_copy(ins, ins + 4, outs, outs + 2, bad_lower);
 }
 

Re: C++ PATCH for c++/87029, Implement -Wredundant-move

[Marek Polacek]

On Thu, Aug 23, 2018 at 10:44:30AM -0400, Marek Polacek wrote:
> +T
> +fn3 (const T t)
> +{
> +  // t is const: will decay into move.
> +  return t;
> +}
> +
> +T
> +fn4 (const T t)
> +{
> +  // t is const: will decay into move despite std::move, so it's redundant.
> +  return std::move (t); // { dg-warning "redundant move in return statement" 
> }
> +}

This should read "decay into copy".  We can't move from a const object.  
Consider
it fixed.

Marek

Re: VRP: make range_includes_zero_p handle value_ranges

[Aldy Hernandez]

On 08/23/2018 05:59 AM, Richard Biener wrote:

On Wed, Aug 22, 2018 at 11:31 AM Aldy Hernandez  wrote:




On 08/21/2018 05:46 AM, Richard Biener wrote:

On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez  wrote:



Finally, my apologies for including a tiny change to the
POINTER_PLUS_EXPR handling code as well.  It came about the same set of
auditing tests.


Bah, please split up things here ;)  I've done a related change there
yesterday...



It turns out we can handle POINTER_PLUS_EXPR(~[0,0], [X,Y]) without
bailing as VR_VARYING in extract_range_from_binary_expr_1.  In doing so,
I also noticed that ~[0,0] is not the only non-null.  We could also have
~[0,2] and still know that the pointer is not zero.  I have adjusted
range_is_nonnull accordingly.


But there are other consumers and it would have been better to
change range_includes_zero_p to do the natural thing (get a VR) and
then remove range_is_nonnull as redundant if possible.


Indeed.  Cleaning up range_includes_zero_p makes VRP and friends a lot
cleaner.  Thanks for the suggestion.

I lazily avoided cleaning up the division code affected in this patch
too much, since it's going to be superseded by my division changes in
the other patch.

OK pending tests?


-/* Return 1 if [MIN, MAX] includes the value zero, 0 if it does not
-   include the value zero, -2 if we cannot tell.  */
+/* Return 1 if *VR includes the value zero, 0 if it does not include
+   the value zero, or -2 if we cannot tell.  */

  int
-range_includes_zero_p (tree min, tree max)
+range_includes_zero_p (const value_range *vr)
  {
-  tree zero = build_int_cst (TREE_TYPE (min), 0);
-  return value_inside_range (zero, min, max);
+  if (vr->type == VR_UNDEFINED || vr->type == VR_VARYING)
+return -2;
+
+  tree zero = build_int_cst (TREE_TYPE (vr->min), 0);
+  if (vr->type == VR_RANGE)
+return value_inside_range (zero, vr->min, vr->max);
+  else
+return !value_inside_range (zero, vr->min, vr->max);
  }

please make it return a bool.  VR_VARYING means the range does
include zero.  For VR_UNDEFINED we could say it doesn't or we choose
to not possibly optimize and thus return true (just do that for now).
That's because VR_VARYING is [-INF, INF] and VR_UNDEFINED is
an empty range.


Done.



I suppose the -2 for we cannot tell was for the case of symbolic
ranges where again we can conservatively return true
(and your return !value_inside_range for VR_ANTI_RANGE botched
the tri-state return value anyways...).


Bah!  I sure botched up the anti range return.  That was the last 
bootstrap failure I was investigating.  You'd be amazed how many things 
mysteriously fail when things like ~[SYMBOL, SYMBOL] are assumed to be 
non-zero.


Thanks for spotting this.  Bootstrap is happy now :-P.



So, can you please rework that?


Sure can!

Attached.

gcc/

	* gimple-ssa-evrp-analyze.c (set_ssa_range_info): Pass value_range
	to range_includes_zero_p.  Do not special case VR_ANTI_RANGE.
	* tree-vrp.c (range_is_nonnull): Remove.
	(range_includes_zero_p): Accept value_range instead of min/max.
	(extract_range_from_binary_expr_1): Do not early bail on
	POINTER_PLUS_EXPR.
	Use range_includes_zero_p instead of range_is_nonnull.
	(extract_range_from_unary_expr): Use range_includes_zero_p instead
	of range_is_nonnull.
	(vrp_meet_1): Pass value_range to range_includes_zero_p.  Do not
	special case VR_ANTI_RANGE.
	(vrp_finalize): Same.
	* tree-vrp.h (range_includes_zero_p): Pass value_range as argument
	instead of min/max.
	(range_is_nonnull): Remove.
	* vr-values.c (vrp_stmt_computes_nonzero): Use
	range_includes_zero_p instead of range_is_nonnull.
	(extract_range_basic): Pass value_range to range_includes_zero_p
	instead of range_is_nonnull.

diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index b9dcf906ff7..e9afa80e191 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -119,12 +119,7 @@ evrp_range_analyzer::set_ssa_range_info (tree lhs, value_range *vr)
 			wi::to_wide (vr->max));
 }
   else if (POINTER_TYPE_P (TREE_TYPE (lhs))
-	   && ((vr->type == VR_RANGE
-		&& range_includes_zero_p (vr->min,
-	  vr->max) == 0)
-	   || (vr->type == VR_ANTI_RANGE
-		   && range_includes_zero_p (vr->min,
-	 vr->max) == 1)))
+	   && range_includes_zero_p (vr) == 0)
 set_ptr_nonnull (lhs);
 }
 
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 735b3646e81..84da2635624 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -502,17 +502,6 @@ vrp_bitmap_equal_p (const_bitmap b1, const_bitmap b2)
 	  && bitmap_equal_p (b1, b2)));
 }
 
-/* Return true if VR is ~[0, 0].  */
-
-bool
-range_is_nonnull (value_range *vr)
-{
-  return vr->type == VR_ANTI_RANGE
-	 && integer_zerop (vr->min)
-	 && integer_zerop (vr->max);
-}
-
-
 /* Return true if VR is [0, 0].  */
 
 static inline bool
@@ -880,14 +869,25 @@ value_ranges_intersect_p (value_range *vr0, value_range *vr1)
 }
 
 
-/* Return 1 if [MIN, MAX] includes the value zero, 0 if it does 

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

[Bernd Edlinger]

On 08/23/18 16:24, Jeff Law wrote:
>>
>> Yes, and which one was the earlier, more controversial patch from me?
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
> 
> 
> Which is the issue I'm working through right now :-)
> 

Okay, please note that a re-based patch is here:

https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01005.html

and if you want, you can split that patch in two parts:

first:
86711 fix:
2018-08-17  Bernd Edlinger  

 PR middle-end/86711
 * expr.c (string_constant): Don't return truncated string literals.

 * gcc.c-torture/execute/pr86711.c: New test.



and then:
86714 fix:
2018-08-17  Bernd Edlinger  

 PR middle-end/86714
 * fold-const.c (c_getstr): Fix function comment.  Remove unused third
 argument.  Fix range checks.
 * fold-const.h (c_getstr): Adjust protoype.

 * gcc.c-torture/execute/pr86714.c: New test.




Bernd.

Re: [PATCH] Print default options selection for -march,-mcpu and -mtune for aarch64 (PR driver/83193).

[Richard Earnshaw (lists)]

On 02/08/18 10:46, Martin Liška wrote:
> On 08/02/2018 11:39 AM, Richard Earnshaw (lists) wrote:
>> On 18/07/18 16:48, Martin Liška wrote:
>>> Hi.
>>>
>>> This is aarch64 fix for PR83193. It's about setting of default options
>>> so that --help=target -Q prints proper numbers:
>>>
>>> Now this is seen on my cross-compiler:
>>>
>>> --- /home/marxin/Downloads/options-2-before.txt 2018-07-18 
>>> 14:53:11.658146543 +0200
>>> +++ /home/marxin/Downloads/options-2.txt2018-07-18 14:52:30.113274284 
>>> +0200
>>> @@ -1,10 +1,10 @@
>>>  The following options are target specific:
>>>-mabi=ABIlp64
>>> -  -march=ARCH  
>>> +  -march=  armv8-a
>>
>> So we have
>>
>> -mabi=ABIlp64
>>
>> but
>>
>> -march=  armv8-a
>>^ blank
>>
>> Isn't that inconsistent?
> 
> It is probably, in this case I would remove 'ABI' from -mabi option. It's 
> explained bellow
> what are possible options:
> 
>   Known AArch64 ABIs (for use with the -mabi= option):
> ilp32 lp64
> 
> Similarly for:
>   -moverride=STRING   Power users only! Override CPU optimization 
> parameters.
>   -msve-vector-bits=N Set the number of bits in an SVE vector 
> register to N.
> 
> It's more common to  notation, there are some samples from --help=common:
> 
>   -fmax-errors=   Maximum number of errors to report.
>   -fmessage-length=   Limit diagnostics to  characters per 
> line.  0 suppresses line-wrapping.
>   -fira-region=[one|all|mixed] Set regions for IRA.
>   -fira-verbose=  Control IRA's level of diagnostic messages.
>   -flifetime-dse=<0,2>This option lacks documentation.
>   -fstack-limit-register= Trap if the stack goes past .
>   -fstack-limit-symbol= Trap if the stack goes past symbol .
> 
> Are you fine with the suggested approach?

Yes, those look sensible.

R.

> 
> Martin
> 
>>
>> R.
>>
>>>-mbig-endian [disabled]
>>>-mbionic [disabled]
>>>-mcmodel=small
>>> -  -mcpu=CPU
>>> +  -mcpu=   generic
>>>-mfix-cortex-a53-835769  [enabled]
>>>-mfix-cortex-a53-843419  [enabled]
>>>-mgeneral-regs-only  [disabled]
>>> @@ -19,7 +19,7 @@
>>>-msve-vector-bits=N  scalable
>>>-mtls-dialect=   desc
>>>-mtls-size=  24
>>> -  -mtune=CPU   
>>> +  -mtune=  generic
>>>-muclibc [disabled]
>>>
>>> May I please ask ARM folks to test the patch?
>>> Thanks,
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> 2018-07-18  Martin Liska  
>>>
>>> PR driver/83193
>>> * config/aarch64/aarch64.c (aarch64_override_options_internal):
>>> Set default values for x_aarch64_*_string strings.
>>> * config/aarch64/aarch64.opt: Remove --{march,mcpu,mtune}==
>>> prefix.
>>> ---
>>>  gcc/config/aarch64/aarch64.c   | 7 +++
>>>  gcc/config/aarch64/aarch64.opt | 6 +++---
>>>  2 files changed, 10 insertions(+), 3 deletions(-)
>>>
>>>
>>>
>>> 0001-Print-default-options-selection-for-march-mcpu-and-m.patch
>>>
>>>
>>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>>> index 6fa03e4b091..d48e6278efa 100644
>>> --- a/gcc/config/aarch64/aarch64.c
>>> +++ b/gcc/config/aarch64/aarch64.c
>>> @@ -10713,6 +10713,13 @@ aarch64_override_options_internal (struct 
>>> gcc_options *opts)
>>>&& opts->x_optimize >= 
>>> aarch64_tune_params.prefetch->default_opt_level)
>>>  opts->x_flag_prefetch_loop_arrays = 1;
>>>  
>>> +  if (opts->x_aarch64_arch_string == NULL)
>>> +opts->x_aarch64_arch_string = selected_arch->name;
>>> +  if (opts->x_aarch64_cpu_string == NULL)
>>> +opts->x_aarch64_cpu_string = selected_cpu->name;
>>> +  if (opts->x_aarch64_tune_string == NULL)
>>> +opts->x_aarch64_tune_string = selected_tune->name;
>>> +
>>>aarch64_override_options_after_change_1 (opts);
>>>  }
>>>  
>>> diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
>>> index 1426b45ff0f..7f0b65de37b 100644
>>> --- a/gcc/config/aarch64/aarch64.opt
>>> +++ b/gcc/config/aarch64/aarch64.opt
>>> @@ -117,15 +117,15 @@ Enum(aarch64_tls_size) String(48) Value(48)
>>>  
>>>  march=
>>>  Target RejectNegative ToLower Joined Var(aarch64_arch_string)
>>> --march=ARCHUse features of architecture ARCH.
>>> +Use features of architecture ARCH.
>>>  
>>>  mcpu=
>>>  Target RejectNegative ToLower Joined Var(aarch64_cpu_string)
>>> --mcpu=CPU  Use features of and optimize for CPU.
>>> +Use features of and optimize for CPU.
>>>  
>>>  mtune=
>>>  Target RejectNegative ToLower Joined Var(aarch64_tune_string)
>>> 

Re: Fix aarch64_evpc_tbl guard (PR 85910)

[Richard Earnshaw (lists)]

On 23/08/18 09:52, Richard Sandiford wrote:
> This patch fixes a typo in aarch64_expand_vec_perm_const_1 that I
> introduced as part of the SVE changes.  I don't know of any cases in
> which it has any practical effect, since we'll eventually try to use
> TBL as a variable permute instead.  Having the code is still an
> important part of defining the interface properly and so we shouldn't
> simply drop it.
> 
> Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
> Applied as obvious to trunk, but OK to backport to GCC 8?
> 

Yes.

R.

> Richard
> 
> 
> 2018-08-23  Richard Sandiford  
> 
> gcc/
>   PR target/85910
>   * config/aarch64/aarch64.c (aarch64_expand_vec_perm_const_1): Fix
>   aarch64_evpc_tbl guard.
> --
> 
> Index: gcc/config/aarch64/aarch64.c
> ===
> --- gcc/config/aarch64/aarch64.c  2018-08-23 09:47:55.0 +0100
> +++ gcc/config/aarch64/aarch64.c  2018-08-23 09:48:51.379223625 +0100
> @@ -15461,7 +15461,7 @@ aarch64_expand_vec_perm_const_1 (struct
>   return true;
>if (d->vec_flags == VEC_SVE_DATA)
>   return aarch64_evpc_sve_tbl (d);
> -  else if (d->vec_flags == VEC_SVE_DATA)
> +  else if (d->vec_flags == VEC_ADVSIMD)
>   return aarch64_evpc_tbl (d);
>  }
>return false;
> 

Re: C++ PATCH for c++/87029, Implement -Wredundant-move

[Marek Polacek]

On Thu, Aug 23, 2018 at 11:59:13PM +1200, Jason Merrill wrote:
> On Thu, Aug 23, 2018 at 12:12 PM, Marek Polacek  wrote:
> > +Wredundant-move
> > +C++ ObjC++ Var(warn_redundant_move) Warning LangEnabledBy(C++ ObjC++, Wall)
> > +Warn about redundant calls to std::move.
> 
> I don't think this belongs in -Wall, since the code is only redundant,
> not wrong.

Hmm, OK.

> > + /* Warn if the move is redundant.  It is redundant when we would
> > +do maybe-rvalue overload resolution even without std::move.  */
> > + else if (((VAR_P (arg) && !DECL_HAS_VALUE_EXPR_P (arg))
> > +   || TREE_CODE (arg) == PARM_DECL)
> > +  && DECL_CONTEXT (arg) == current_function_decl
> > +  && !TREE_STATIC (arg))
> 
> This condition should be shared with check_return_expr rather than copied.

Done.  I'm puzzled why I didn't do it before as I'd planned.

I've also dropped the fix-it hints as explained here:


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

2018-08-23  Marek Polacek  

PR c++/87029, Implement -Wredundant-move.
* c.opt (Wredundant-move): New option.

* typeck.c (treat_lvalue_as_rvalue_p): New function.
(maybe_warn_pessimizing_move): Call convert_from_reference.
Warn about redundant moves.

* doc/invoke.texi: Document -Wredundant-move.

* g++.dg/cpp0x/Wredundant-move1.C: New test.
* g++.dg/cpp0x/Wredundant-move2.C: New test.
* g++.dg/cpp0x/Wredundant-move3.C: New test.
* g++.dg/cpp0x/Wredundant-move4.C: New test.

diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index 76840dd77ad..31a2b972919 100644
--- gcc/c-family/c.opt
+++ gcc/c-family/c.opt
@@ -985,6 +985,10 @@ Wredundant-decls
 C ObjC C++ ObjC++ Var(warn_redundant_decls) Warning
 Warn about multiple declarations of the same object.
 
+Wredundant-move
+C++ ObjC++ Var(warn_redundant_move) Warning LangEnabledBy(C++ ObjC++,Wextra)
+Warn about redundant calls to std::move.
+
 Wregister
 C++ ObjC++ Var(warn_register) Warning
 Warn about uses of register storage specifier.
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 122d9dcd4b3..2d556faafc4 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -9178,6 +9178,19 @@ can_do_nrvo_p (tree retval, tree functype)
  && !TYPE_VOLATILE (TREE_TYPE (retval)));
 }
 
+/* Returns true if we should treat RETVAL, an expression being returned,
+   as if it were designated by an rvalue.  See [class.copy.elision].  */
+
+static bool
+treat_lvalue_as_rvalue_p (tree retval)
+{
+  return ((cxx_dialect != cxx98)
+ && ((VAR_P (retval) && !DECL_HAS_VALUE_EXPR_P (retval))
+ || TREE_CODE (retval) == PARM_DECL)
+ && DECL_CONTEXT (retval) == current_function_decl
+ && !TREE_STATIC (retval));
+}
+
 /* Warn about wrong usage of std::move in a return statement.  RETVAL
is the expression we are returning; FUNCTYPE is the type the function
is declared to return.  */
@@ -9185,7 +9198,7 @@ can_do_nrvo_p (tree retval, tree functype)
 static void
 maybe_warn_pessimizing_move (tree retval, tree functype)
 {
-  if (!warn_pessimizing_move)
+  if (!(warn_pessimizing_move || warn_redundant_move))
 return;
 
   /* C++98 doesn't know move.  */
@@ -9207,6 +9220,7 @@ maybe_warn_pessimizing_move (tree retval, tree functype)
  STRIP_NOPS (arg);
  if (TREE_CODE (arg) == ADDR_EXPR)
arg = TREE_OPERAND (arg, 0);
+ arg = convert_from_reference (arg);
  /* Warn if we could do copy elision were it not for the move.  */
  if (can_do_nrvo_p (arg, functype))
{
@@ -9216,6 +9230,15 @@ maybe_warn_pessimizing_move (tree retval, tree functype)
  "prevents copy elision"))
inform (location_of (retval), "remove % call");
}
+ /* Warn if the move is redundant.  It is redundant when we would
+do maybe-rvalue overload resolution even without std::move.  */
+ else if (treat_lvalue_as_rvalue_p (arg))
+   {
+ auto_diagnostic_group d;
+ if (warning_at (location_of (retval), OPT_Wredundant_move,
+ "redundant move in return statement"))
+   inform (location_of (retval), "remove % call");
+   }
}
 }
 }
@@ -9494,11 +9517,7 @@ check_return_expr (tree retval, bool *no_warning)
  Note that these conditions are similar to, but not as strict as,
 the conditions for the named return value optimization.  */
   bool converted = false;
-  if ((cxx_dialect != cxx98)
-  && ((VAR_P (retval) && !DECL_HAS_VALUE_EXPR_P (retval))
- || TREE_CODE (retval) == PARM_DECL)
- && DECL_CONTEXT (retval) == current_function_decl
- && !TREE_STATIC (retval)
+  if (treat_lvalue_as_rvalue_p (retval)
  /* This is only interesting for class type.  */

Re: [PATCH] Use more DECL_BUILT_IN_P macro.

[Martin Liška]

On 08/23/2018 03:58 PM, Richard Biener wrote:
> On Thu, Aug 23, 2018 at 3:30 PM Martin Liška  wrote:
>>
>> On 08/23/2018 01:58 PM, Richard Biener wrote:
>>> On Thu, Aug 23, 2018 at 12:46 PM Martin Liška  wrote:

 On 08/20/2018 10:34 AM, Richard Biener wrote:
> On Wed, Aug 15, 2018 at 2:52 PM Martin Liška  wrote:
>>
>> On 08/14/2018 06:02 PM, Martin Sebor wrote:
>>> On 08/14/2018 03:06 AM, Martin Liška wrote:
 Hi.

 The patch adds more usages of the new macro. I hope it improves
 readability of code.
>>>
>>> I think it does :)  I see that most invocations of it in your
>>> patch are with BUILT_IN_NORMAL as the second argument.  Is
>>> the argument implied by the last argument?  E.g., in
>>>
>>>   DECL_BUILT_IN_P (fndecl, BUILT_IN_NORMAL, BUILT_IN_VA_ARG_PACK)
>>>
>>> is there a way to determine that BUILT_IN_VA_ARG_PACK implies
>>> DECL_BUILT_IN_CLASS(fndecl), so that the second argument could
>>> be eliminated?  (Both to make the invocation less verbose and
>>> to avoid the mistake of using the macro with the wrong class.)
>>
>> If I see correctly not, there are separate enums:
>>
>> BUILT_IN_MD:
>>
>> enum ix86_builtins {
>>   IX86_BUILTIN_MASKMOVQ,
>>   IX86_BUILTIN_LDMXCSR,
>>   IX86_BUILTIN_STMXCSR,
>> ...
>> }
>>
>> BUILT_IN_NORMAL:
>> enum built_in_function {
>> BUILT_IN_NONE,
>> BUILT_IN_ACOS,
>> BUILT_IN_ACOSF,
>> ...
>> }
>>
>> So the enum values overlap and thus one needs the class.
>>
>>
>>>
>>> If not, adding DECL_NORMAL_BUILT_IN_P() would make it possible
>>> to omit it.
>>
>> But yes, this is nice idea, I'm sending V2 of the patch that I'm testing
>> right now.
>
> Ick, and now we have DECL_IS_BUILTIN, DECL_BUILT_IN, DECL_BUILT_IN_P
> and DECL_NORMAL_BUILT_IN_P ... (esp the first one is confusing).

 Agree.

>
> I think following what gimple.h does would be nicer which means using
> inline functions and overloading.
>
> decl_built_in_p (tree);
> decl_built_in_p (tree, enum built_in_class);
> decl_built_in_p (tree, enum built_in_function); /// implies 
> BUILT_IN_NORMAL

 Yes, that's easier to use!

>
> Can you rework things this way please?  (ok, for gimple those are not 
> inlines)

 Done in patch that can bootstrap and survives regression tests.
 Ready for trunk?
>>>
>>> +/* For a FUNCTION_DECL NODE, nonzero means a built in function of a
>>> +   standard library or more generally a built in function that is
>>> +   recognized by optimizers and expanders.
>>> +
>>> +   Note that it is different from the DECL_IS_BUILTIN accessor.  For
>>> +   instance, user declared prototypes of C library functions are not
>>> +   DECL_IS_BUILTIN but may be DECL_BUILT_IN.  */
>>> +
>>> +inline bool
>>> +decl_built_in_p (const_tree node)
>>> +{
>>> +  return (node != NULL_TREE
>>> + && TREE_CODE (node) == FUNCTION_DECL
>>>
>>> You document for a FUNCTION_DECL NODE but the check
>>> for FUNCTION_DECL anyway.  I realize doing all (possibly redundant)
>>> checks in decl_built_in_p is convenient at callers, but at least update
>>> docs accordingly?  In reality I somewhat prefer
>>
>> Yes, please let stay with version that does the checks. It can provide
>> more readable code like:
>>
>>/* If last argument is __builtin_va_arg_pack (), arguments to this
>>  function are not finalized yet.  Defer folding until they are.  */
>>if (n && TREE_CODE (argarray[n - 1]) == CALL_EXPR)
>> {
>>   tree fndecl2 = get_callee_fndecl (argarray[n - 1]);
>> - if (fndecl2
>> - && TREE_CODE (fndecl2) == FUNCTION_DECL
>> - && DECL_BUILT_IN_CLASS (fndecl2) == BUILT_IN_NORMAL
>> - && DECL_FUNCTION_CODE (fndecl2) == BUILT_IN_VA_ARG_PACK)
>> + if (decl_built_in_p (fndecl2, BUILT_IN_VA_ARG_PACK))
>> return NULL_TREE;
>> }
>>if (avoid_folding_inline_builtin (fndecl))
> 
> But here the TREE_CODE (fndecl2) == FUNCTION_DECL check is redundant
> (get_callee_fndecl always returns a FUNCTION_DECL).  So it would become
> 
>   if (fndecl2 && fndecl_built_in_p (fndecl2, BUILT_IN_VA_ARG_PACK))
> 
> which is IMHO good enough.

Ok, let's do it this way.

> 
>>>
>>> inline bool
>>> decl_built_in_p (const_tree node)
>>> {
>>>   return DECL_BUILT_IN_CLASS (node) != NOT_BUILT_IN;
>>> }
>>>
>>> and
>>>
>>> inline bool
>>> decl_built_in_p (const_tree node, built_in_class klass)
>>> {
>>>   return DECL_BUILT_IN_CLASS (node) == klass;
>>> }
>>>
>>> esp. since the built_in_class overload doesn't work for
>>> NOT_BUILT_IN for your variant.
>>
>> That's true. One should probably use DECL_BUILT_IN_CLASS (t1) != NOT_BUILT_IN
>> in this case.
>>
>>>
>>> And if we're at changing, maybe call the functions
>>> fndecl_built_in_p to make it 

Re: [PATCH] DWARF: Call set_indirect_string on DW_MACINFO_start_file

[H.J. Lu]

On Thu, Aug 23, 2018 at 5:56 AM, Richard Biener
 wrote:
> On Wed, Aug 22, 2018 at 9:36 PM H.J. Lu  wrote:
>>
>> Since -gsplit-dwarf -g3 will output filename as indirect string, call
>> set_indirect_string on DW_MACINFO_start_file for -gsplit-dwarf -g3.
>>
>> OK for trunk?
>
> Can you add a testcase?
>
>

Here is the updated patch with a testcase.  Before my fix:

/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -m32
-O2 -fno-var-tracking-assignments -gsplit-dwarf -g3 -march=skylake
-mrtm -mabm -S x.c
x.c:14:1: internal compiler error: in output_index_string, at dwarf2out.c:28780
14 | }
   | ^
0xb090e7 output_index_string(indirect_string_node**, unsigned int*)
/export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:28780
0xb09370 output_indirect_strings
/export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:28868
0xb0ed85 dwarf2out_finish
/export/gnu/import/git/sources/gcc/gcc/dwarf2out.c:31563
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

After:

/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -m32
-O2 -fno-var-tracking-assignments -gsplit-dwarf -g3 -march=skylake
-mrtm -mabm -S x.c

OK for trunk?

Thanks.

-- 
H.J.
From 65c84b66ff7027a90f2108053427a516575ba78b Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 22 Aug 2018 12:25:17 -0700
Subject: [PATCH] DWARF: Call set_indirect_string on DW_MACINFO_start_file

Since -gsplit-dwarf -g3 will output filename as indirect string, call
set_indirect_string on DW_MACINFO_start_file for -gsplit-dwarf -g3.

gcc/

	PR debug/79342
	* dwarf2out.c (save_macinfo_strings): Call set_indirect_string
	on DW_MACINFO_start_file for -gsplit-dwarf -g3

gcc/testsuite/

	PR debug/79342
	* gcc.dg/pr79342.: New test.
---
 gcc/dwarf2out.c|  6 ++
 gcc/testsuite/gcc.dg/pr79342.c | 18 ++
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr79342.c

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 91af4e8fc4e..77317ed2575 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -28287,6 +28287,12 @@ save_macinfo_strings (void)
 && (debug_str_section->common.flags & SECTION_MERGE) != 0)
   set_indirect_string (find_AT_string (ref->info));
 break;
+	  case DW_MACINFO_start_file:
+	/* -gsplit-dwarf -g3 will also output filename as indirect
+	   string.  */
+	if (!dwarf_split_debug_info)
+	  break;
+	/* Fall through. */
 	  case DW_MACRO_define_strp:
 	  case DW_MACRO_undef_strp:
 set_indirect_string (find_AT_string (ref->info));
diff --git a/gcc/testsuite/gcc.dg/pr79342.c b/gcc/testsuite/gcc.dg/pr79342.c
new file mode 100644
index 000..958de55d09b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr79342.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -gsplit-dwarf -g3" } */
+/* { dg-additional-options "-march=skylake -mrtm -mabm" { target x86_64-*-* i?86-*-* } } */
+
+int a;
+void b(void);
+
+void e(int *);
+int f(void);
+
+void 
+c(void)
+{
+  int d;
+  e();
+  if (f())
+b();
+}
-- 
2.17.1

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

[Jeff Law]

On 08/22/2018 11:40 PM, Bernd Edlinger wrote:
> On 08/23/18 01:36, Jeff Law wrote:
>> On 08/22/2018 05:22 PM, Bernd Edlinger wrote:
>>> On 08/23/18 00:50, Jeff Law wrote:
 On 08/22/2018 02:14 AM, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/22/18 09:26, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>
 On 08/21/18 10:59, Richard Biener wrote:
> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>
>> gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-expansion=0 
>> -fshort-wchar builtin-sprintf-warn-20.c
>> builtin-sprintf-warn-20.c: In function 'test':
>> builtin-sprintf-warn-20.c:19:39: warning: hex escape sequence out of 
>> range
>> 19 | ? (char*)L"\x4142\x4344" : (char*)L"\x41424344\x45464748";
>> |   
>> ^~~
>>
>> Hmm, this test might create some noise on short-wchar targets.
>>
>> I would prefer a warning here, about the wrong type of the parameter.
>> The buffer overflow is only a secondary thing.
>>
>> For constant objects like those, the GIMPLE type is still guaranteed 
>> to be reliable,
>> right?
>
> TREE_TYPE of tcc_declaration and tcc_constant trees should 
> more-or-less
> (minus qualifications not affecting semantics) be those set by
> frontends.
>

 and in this case:

 const union
 { struct {
 wchar_t x[4];
   };
   struct {
 char z[8];
   };
 } u = {{L"123"}};

 int test()
 {
   return __builtin_strlen(u.z);
 }


 string_constant works out the initializer for u.x
 which has a different type than u.z
>>>
>>> Yes.  That's because it uses ctor-for-folding and friends.  It's
>>> a question of the desired semantics of string_constant whether
>>> it should better return NULL_TREE in this case or whether the
>>> caller has to deal with type mismatches.
>>>
>>
>> Yes, absolutely.
>>
>> c_getstr needs to bail out if the string is not zero-terminated
>> within the limits given by the decl, or the string_cst-type or whatever
>> may help.
>>
>> Furthermore I also consider it possible that the byteoffset
>> is not a multiple of eltsize.  So fail in that case as well.
>>
>>
>> I am currently boot-strapping a patch for this (pr87053):
>> $ cat u.c
>> const union
>> { struct {
>>char x[4];
>>char y[4];
>>  };
>>  struct {
>>char z[8];
>>  };
>> } u = {{"1234", "567"}};
>>
>> int test()
>> {
>>  return __builtin_strlen(u.z);
>> }
>>
>> gets folded to 4.
>>
>> ... but unfortunately it will depend on my pr86714 fix which fixes
>> the mem_size parameter returned from string_constant.
>>
>> Frankly, in the moment I feel like I fell in a deep deep hole.   :-O
>
> /me too with > 100 mails in this and related threads unread ;)
>
> I thought Jeff applied the mem_size parameter thing but maybe it
> was something else.  *fetches coffee*  Ah, Jeff is still "working"
> on it.
 The patch that was applied adds a parameter to c_strlen to indicate how
 it should count (ie, bytes, 16bit wchars or 32bit wchars).

 There was one hunk that was dependent upon an earlier, more
 controversial, patch from Bernd which is still under discussion.  That
 hunk was twiddled to preserve the overall goal of Bernd's patch which
 added the how to count parameter without being dependent upon the older,
 more controversial patch.

>>>
>>> Which patch do you mean?
>> This one:
>>
>> Author: law 
>> Date:   Thu Aug 16 22:38:04 2018 +
>>
>>  * builtins.c (c_strlen): Add new parameter eltsize.  Use it
>>  for determining how to count the elements.
>>  * builtins.h (c_strlen): Adjust prototype.
>>  * expr.c (string_constant): Add new parameter mem_size.
>>  Set *mem_size appropriately.
>>  * expr.h (string_constant): Adjust protoype.
>>  * gimple-fold.c (get_range_strlen): Add new parameter eltsize.
>>  * gimple-fold.h (get_range_strlen): Adjust prototype.
>>  * gimple-ssa-sprintf.c (get_string_length): Add new
>> parameter eltsize.
>>  (format_string): Call get_string_length with eltsize.
>>
>>  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@263607
>> 138bc75d-0d04-0410-961f-82ee72b054a4
>>
> 
> Yes, and which one was the earlier, more controversial patch from me?

https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html


Which is 

[PATCH] C++: underline param in print_conversion_rejection (more PR c++/85110)

[David Malcolm]

Consider this bogus code (from g++.dg/diagnostic/param-type-mismatch-2.C):

struct s4 { static int member_1 (int one, const char **two, float three); };

int test_4 (int first, const char *second, float third)
{
  return s4::member_1 (first, second, third);
}

Before this patch, g++ emits:

demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, const 
char*&, float&)'
5 |   return s4::member_1 (first, second, third);
  |^
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**, 
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |^~~~
demo.cc:1:24: note:   no known conversion for argument 2 from 'const char*' to 
'const char**'

With this patch, it highlights the pertinent parameter in the
"no known conversion" note:

demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, const 
char*&, float&)'
5 |   return s4::member_1 (first, second, third);
  |^
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**, 
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |^~~~
demo.cc:1:56: note:   no known conversion for argument 2 from 'const char*' to 
'const char**'
1 | struct s4 { static int member_1 (int one, const char **two, float three); };
  |   ~^~~

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; adds
15 PASS results to g++.sum.

OK for trunk?

I'm working on a followup to highlight the pertinent argument
in the initial error diagnostic.

gcc/cp/ChangeLog:
PR c++/85110
* call.c (print_conversion_rejection): Add "fn" param and use it
for "no known conversion" messages to underline the pertinent
param.
(print_z_candidate): Supply "fn" to the new param above.

gcc/testsuite/ChangeLog:
PR c++/85110
* g++.dg/diagnostic/param-type-mismatch-2.C: Update expected
output to reflect underlining of pertinent parameter in decl
for "no known conversion" messages.
---
 gcc/cp/call.c  | 17 +--
 .../g++.dg/diagnostic/param-type-mismatch-2.C  | 25 +-
 2 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 626830c..ef445e0 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -3432,10 +3432,11 @@ equal_functions (tree fn1, tree fn2)
   return fn1 == fn2;
 }
 
-/* Print information about a candidate being rejected due to INFO.  */
+/* Print information about a candidate FN being rejected due to INFO.  */
 
 static void
-print_conversion_rejection (location_t loc, struct conversion_info *info)
+print_conversion_rejection (location_t loc, struct conversion_info *info,
+   tree fn)
 {
   tree from = info->from;
   if (!TYPE_P (from))
@@ -3466,8 +3467,12 @@ print_conversion_rejection (location_t loc, struct 
conversion_info *info)
 inform (loc, "  no known conversion from %qH to %qI",
from, info->to_type);
   else
-inform (loc, "  no known conversion for argument %d from %qH to %qI",
-   info->n_arg + 1, from, info->to_type);
+{
+  if (TREE_CODE (fn) == FUNCTION_DECL)
+   loc = get_fndecl_argument_location (fn, info->n_arg);
+  inform (loc, "  no known conversion for argument %d from %qH to %qI",
+ info->n_arg + 1, from, info->to_type);
+}
 }
 
 /* Print information about a candidate with WANT parameters and we found
@@ -3542,10 +3547,10 @@ print_z_candidate (location_t loc, const char *msgstr,
   r->u.arity.expected);
  break;
case rr_arg_conversion:
- print_conversion_rejection (cloc, >u.conversion);
+ print_conversion_rejection (cloc, >u.conversion, fn);
  break;
case rr_bad_arg_conversion:
- print_conversion_rejection (cloc, >u.bad_conversion);
+ print_conversion_rejection (cloc, >u.bad_conversion, fn);
  break;
case rr_explicit_conversion:
  inform (cloc, "  return type %qT of explicit conversion function "
diff --git a/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C 
b/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C
index 8cf2dab..4957f61 100644
--- a/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C
+++ b/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C
@@ -82,7 +82,10 @@ int test_4 (int first, const char *second, float third)
 ^~~~
  { dg-end-multiline-output "" } */
   // { dg-message "no known conversion for argument 2 from 'const char\\*' to 
'const char\\*\\*'" "" { target *-*-* } s4_member_1 }
-  // 

Re: C++ PATCH for c++/87029, Implement -Wredundant-move

[Marek Polacek]

On Thu, Aug 23, 2018 at 09:51:43AM -0400, David Malcolm wrote:
> On Wed, 2018-08-22 at 20:12 -0400, Marek Polacek wrote:
> > Now that we have -Wpessimizing-move implemented, it was fairly easy
> > to extend
> > it to -Wredundant-move, which warns about redundant calls to
> > std::move; it's
> > supposed to detect cases where the compiler is obliged to treat an
> > object as
> > if it were an rvalue, so calling std::move is pointless.  Since we
> > implement
> > Core Issue 1579, it warns in more situations than clang++.  I
> > described this
> > in more detail in the manual entry.
> > 
> > David, I've also tweaked the warning to use fix-it hints; the point
> > is to turn
> > 
> >   return std::move (x);
> > 
> > into
> > 
> >   return x;
> > 
> > I didn't fool around with looking for the locations of the parens;
> > I've used a
> > DECL_NAME hack instead.  I've verified it using -fdiagnostics-
> > generate-patch,
> > which produces e.g.:
> > 
> > @@ -27,7 +27,7 @@
> >  f ()
> >  {
> >T foo;
> > -  return std::move (foo);
> > +  return foo;
> >  }
> >  
> > g++.dg/diagnostic/move1.C tests the fix-it hints for -Wredundant-move 
> > and
> > -Wpessimizing-move.
> 
> Thanks (and ideally, we'd have a precanned way for DejaGnu to test that
> the fix-its hints work, and lead to code that resolves the diagnostics;
> I've toyed around with doing so, but it's fiddly, involving a second
> compile; ugh).
> 
> Regarding the fix-it hint code: I'm not convinced that it works in
> every possible scenario.
> 
> Consider:
> 
> (A):
> 
>   namespace ns {
>  int some_global;
>   };
> 
>   int fn ()
>   {
> return std::move (ns::some_global);
>   }
> 
> which I believe will generate this bogus suggestion:
> 
> return std::move (ns::some_global);
>~~^
>some_global
> 
> since IIRC, DECL_NAME doesn't contain any explicit namespace for the
> way the var was referred to.
> 
> (B):
> 
> #ifdef SOME_CONFIG_FLAG
> # define CONFIGURY_GLOBAL global_a
> #else
> # define CONFIGURY_GLOBAL global_b
> #endif
> 
>   int fn ()
>   {
>  return std::move (CONFIGURY_GLOBAL);
>   }
> 
> which presumably will erroneously strip out the macro in the fix-it
> hint:
> 
>  return std::move (CONFIGURY_GLOBAL);
> ~~^~
> global_a
> 
> rich_location will discard fix-it hints for locations that are in macro
> expansions to try to avoid problems like this, but (B)'s location will 
> be a non-macro location, I believe.

You're right; I realized that it would not handle e.g. parenthesized
expressions correctly, either.

> Hence my suggestion to, if possible, use the locations of the parens,
> so that the fix-it hint preserves the user's spelling of the variable.
>  
> But I appreciate that it might be unreasonably difficult to get at
> those locations.  Hence, I think the fix-it hint part of the patch is
> probably good enough as-is: I'd rather not let "perfect be the enemy of
> the good" here.

Indeed, my attempts at extracting the proper locations failed.  I went back
to good ol' inform for now as I no longer think that the DECL_NAME hack is
good enough.

Thanks for the help!

Marek

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

[Jeff Law]

On 08/23/2018 04:21 AM, Bernd Edlinger wrote:
> On 08/22/18 10:14, Richard Biener wrote:
>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/22/18 09:26, Richard Biener wrote:
 On Wed, 22 Aug 2018, Bernd Edlinger wrote:

> On 08/21/18 10:59, Richard Biener wrote:
>> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>>
>>> gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-expansion=0 
>>> -fshort-wchar builtin-sprintf-warn-20.c
>>> builtin-sprintf-warn-20.c: In function 'test':
>>> builtin-sprintf-warn-20.c:19:39: warning: hex escape sequence out of 
>>> range
>>> 19 | ? (char*)L"\x4142\x4344" : (char*)L"\x41424344\x45464748";
>>>|   ^~~
>>>
>>> Hmm, this test might create some noise on short-wchar targets.
>>>
>>> I would prefer a warning here, about the wrong type of the parameter.
>>> The buffer overflow is only a secondary thing.
>>>
>>> For constant objects like those, the GIMPLE type is still guaranteed to 
>>> be reliable,
>>> right?
>>
>> TREE_TYPE of tcc_declaration and tcc_constant trees should more-or-less
>> (minus qualifications not affecting semantics) be those set by
>> frontends.
>>
>
> and in this case:
>
> const union
> { struct {
>wchar_t x[4];
>  };
>  struct {
>char z[8];
>  };
> } u = {{L"123"}};
>
> int test()
> {
>  return __builtin_strlen(u.z);
> }
>
>
> string_constant works out the initializer for u.x
> which has a different type than u.z

 Yes.  That's because it uses ctor-for-folding and friends.  It's
 a question of the desired semantics of string_constant whether
 it should better return NULL_TREE in this case or whether the
 caller has to deal with type mismatches.

>>>
>>> Yes, absolutely.
>>>
>>> c_getstr needs to bail out if the string is not zero-terminated
>>> within the limits given by the decl, or the string_cst-type or whatever
>>> may help.
>>>
>>> Furthermore I also consider it possible that the byteoffset
>>> is not a multiple of eltsize.  So fail in that case as well.
>>>
>>>
>>> I am currently boot-strapping a patch for this (pr87053):
>>> $ cat u.c
>>> const union
>>> { struct {
>>>   char x[4];
>>>   char y[4];
>>> };
>>> struct {
>>>   char z[8];
>>> };
>>> } u = {{"1234", "567"}};
>>>
>>> int test()
>>> {
>>> return __builtin_strlen(u.z);
>>> }
>>>
>>> gets folded to 4.
>>>
>>> ... but unfortunately it will depend on my pr86714 fix which fixes
>>> the mem_size parameter returned from string_constant.
>>>
>>> Frankly, in the moment I feel like I fell in a deep deep hole.   :-O
>>
>> /me too with > 100 mails in this and related threads unread ;)
>>
>> I thought Jeff applied the mem_size parameter thing but maybe it
>> was something else.  *fetches coffee*  Ah, Jeff is still "working"
>> on it.
>>
> 
> The dependence is not because of the missing mem_size parameter,
> but because there is another place where strlen(c_getstr) is used,
> and my other patch fixes c_getstr to use mem_size and
> not return non-zero terminated strings.
> 
> But since Martin claims his patch is superior to mine we
> are stuck in this situation.
> 
> I think all uses of string_constant all over where mem_size
> is not used, are actually broken.  I should make mem_size
> a mandatory parameter.
I think Martin's patch to handle the problems with unterminated strings
is more complete and it provides infrastructure to allow for sensible
warnings WRT unterminated strings.

Where I'm having trouble with Martin's patch is convincing myself it's
right for wchar types.   I also want to side test it against your new
tests.  This is going to require me to twiddle Martin's patch for the
current trunk and likely twiddle at least a couple places that I think
need adjustment for wchars.

Your patch is simpler and easier to generally understand.  My concern is
that even if we installed your patch now we'd end up wanting something
similar to Martin's very soon.  I also want to side test yours against
Martin's new tests.  Side testing your patch is simpler.

Losing half my day Tuesday and half of Thursday to meetings isn't
helping.  Nor did the repeated power and internet drops yesterday.  I'm
not getting nearly as much work done as normal.

Jeff

Re: [PATCH] print full STRING_CST in Gimple dumps (PR 87052)

[Michael Matz]

Hi,

On Thu, 23 Aug 2018, Richard Biener wrote:

> > > Can you write a not \0 terminated string literal in C?
> >
> > Yes: char a[2] = "12";
> 
> I thought they are fully defined in translation phase #1 ...

No, you can't write a string literal which is not zero terminated, because 
in translation phase 7 a zero code is appended to all character sequences 
resulting from string literals, which is then used to allocate and 
initialize a static (wide) character array of just the right size, 
including the zero code.

The above construct uses that static char[3] array from the string literal 
to initialize a char[2] array (which is explicitely allowed), and _that_ 
one is not zero terminated.  But it's also no string literal.

(Of course, due to as-if the intermediate char[3] array won't usually be 
explicitely constructed.)


Ciao,
Michael.

Re: [PATCH] Use more DECL_BUILT_IN_P macro.

[Richard Biener]

On Thu, Aug 23, 2018 at 3:30 PM Martin Liška  wrote:
>
> On 08/23/2018 01:58 PM, Richard Biener wrote:
> > On Thu, Aug 23, 2018 at 12:46 PM Martin Liška  wrote:
> >>
> >> On 08/20/2018 10:34 AM, Richard Biener wrote:
> >>> On Wed, Aug 15, 2018 at 2:52 PM Martin Liška  wrote:
> 
>  On 08/14/2018 06:02 PM, Martin Sebor wrote:
> > On 08/14/2018 03:06 AM, Martin Liška wrote:
> >> Hi.
> >>
> >> The patch adds more usages of the new macro. I hope it improves
> >> readability of code.
> >
> > I think it does :)  I see that most invocations of it in your
> > patch are with BUILT_IN_NORMAL as the second argument.  Is
> > the argument implied by the last argument?  E.g., in
> >
> >   DECL_BUILT_IN_P (fndecl, BUILT_IN_NORMAL, BUILT_IN_VA_ARG_PACK)
> >
> > is there a way to determine that BUILT_IN_VA_ARG_PACK implies
> > DECL_BUILT_IN_CLASS(fndecl), so that the second argument could
> > be eliminated?  (Both to make the invocation less verbose and
> > to avoid the mistake of using the macro with the wrong class.)
> 
>  If I see correctly not, there are separate enums:
> 
>  BUILT_IN_MD:
> 
>  enum ix86_builtins {
>    IX86_BUILTIN_MASKMOVQ,
>    IX86_BUILTIN_LDMXCSR,
>    IX86_BUILTIN_STMXCSR,
>  ...
>  }
> 
>  BUILT_IN_NORMAL:
>  enum built_in_function {
>  BUILT_IN_NONE,
>  BUILT_IN_ACOS,
>  BUILT_IN_ACOSF,
>  ...
>  }
> 
>  So the enum values overlap and thus one needs the class.
> 
> 
> >
> > If not, adding DECL_NORMAL_BUILT_IN_P() would make it possible
> > to omit it.
> 
>  But yes, this is nice idea, I'm sending V2 of the patch that I'm testing
>  right now.
> >>>
> >>> Ick, and now we have DECL_IS_BUILTIN, DECL_BUILT_IN, DECL_BUILT_IN_P
> >>> and DECL_NORMAL_BUILT_IN_P ... (esp the first one is confusing).
> >>
> >> Agree.
> >>
> >>>
> >>> I think following what gimple.h does would be nicer which means using
> >>> inline functions and overloading.
> >>>
> >>> decl_built_in_p (tree);
> >>> decl_built_in_p (tree, enum built_in_class);
> >>> decl_built_in_p (tree, enum built_in_function); /// implies 
> >>> BUILT_IN_NORMAL
> >>
> >> Yes, that's easier to use!
> >>
> >>>
> >>> Can you rework things this way please?  (ok, for gimple those are not 
> >>> inlines)
> >>
> >> Done in patch that can bootstrap and survives regression tests.
> >> Ready for trunk?
> >
> > +/* For a FUNCTION_DECL NODE, nonzero means a built in function of a
> > +   standard library or more generally a built in function that is
> > +   recognized by optimizers and expanders.
> > +
> > +   Note that it is different from the DECL_IS_BUILTIN accessor.  For
> > +   instance, user declared prototypes of C library functions are not
> > +   DECL_IS_BUILTIN but may be DECL_BUILT_IN.  */
> > +
> > +inline bool
> > +decl_built_in_p (const_tree node)
> > +{
> > +  return (node != NULL_TREE
> > + && TREE_CODE (node) == FUNCTION_DECL
> >
> > You document for a FUNCTION_DECL NODE but the check
> > for FUNCTION_DECL anyway.  I realize doing all (possibly redundant)
> > checks in decl_built_in_p is convenient at callers, but at least update
> > docs accordingly?  In reality I somewhat prefer
>
> Yes, please let stay with version that does the checks. It can provide
> more readable code like:
>
>/* If last argument is __builtin_va_arg_pack (), arguments to this
>  function are not finalized yet.  Defer folding until they are.  */
>if (n && TREE_CODE (argarray[n - 1]) == CALL_EXPR)
> {
>   tree fndecl2 = get_callee_fndecl (argarray[n - 1]);
> - if (fndecl2
> - && TREE_CODE (fndecl2) == FUNCTION_DECL
> - && DECL_BUILT_IN_CLASS (fndecl2) == BUILT_IN_NORMAL
> - && DECL_FUNCTION_CODE (fndecl2) == BUILT_IN_VA_ARG_PACK)
> + if (decl_built_in_p (fndecl2, BUILT_IN_VA_ARG_PACK))
> return NULL_TREE;
> }
>if (avoid_folding_inline_builtin (fndecl))

But here the TREE_CODE (fndecl2) == FUNCTION_DECL check is redundant
(get_callee_fndecl always returns a FUNCTION_DECL).  So it would become

  if (fndecl2 && fndecl_built_in_p (fndecl2, BUILT_IN_VA_ARG_PACK))

which is IMHO good enough.

> >
> > inline bool
> > decl_built_in_p (const_tree node)
> > {
> >   return DECL_BUILT_IN_CLASS (node) != NOT_BUILT_IN;
> > }
> >
> > and
> >
> > inline bool
> > decl_built_in_p (const_tree node, built_in_class klass)
> > {
> >   return DECL_BUILT_IN_CLASS (node) == klass;
> > }
> >
> > esp. since the built_in_class overload doesn't work for
> > NOT_BUILT_IN for your variant.
>
> That's true. One should probably use DECL_BUILT_IN_CLASS (t1) != NOT_BUILT_IN
> in this case.
>
> >
> > And if we're at changing, maybe call the functions
> > fndecl_built_in_p to make it clear we're expecting FUNCTION_DECLs...
> >
> > +/* For a FUNCTION_DECL NODE, return true when a function is
> > +   

[PATCH] fix typo 'exapnded' to 'expanded'

[Giuliano Augusto Faulin Belinassi]

There was a small typo in the current version of trunk, more precisely
in genmatch.c and exp_unst.ads. This patch fixes it.

Changelog:

2018-08-23  Giuliano Belinassi 

* genmatch.c: Fix typo 'exapnded' to 'expanded'.
* exp_unst.ads: Likewise.

I don't think this requires a test case :P
Index: gcc/ada/exp_unst.ads
===
--- gcc/ada/exp_unst.ads	(revisão 263813)
+++ gcc/ada/exp_unst.ads	(cópia de trabalho)
@@ -477,7 +477,7 @@
--  subprograms exist. Similarly overloading would cause a naming issue.
 
--  In fact, the expanded code includes qualified names which eliminate this
-   --  problem. We omitted the qualification from the exapnded examples above
+   --  problem. We omitted the qualification from the expanded examples above
--  for simplicity. But to see this in action, consider this example:
 
--function Mnames return Boolean is
Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revisão 263813)
+++ gcc/genmatch.c	(cópia de trabalho)
@@ -4150,7 +4150,7 @@
   if (active_fors.length() == 0)
 	record_operlist (id_tok->src_loc, p);
   else
-	fatal_at (id_tok, "operator-list %s cannot be exapnded inside 'for'", id);
+	fatal_at (id_tok, "operator-list %s cannot be expanded inside 'for'", id);
 }
   return op;
 }

Re: C++ PATCH for c++/87029, Implement -Wredundant-move

[David Malcolm]

On Wed, 2018-08-22 at 20:12 -0400, Marek Polacek wrote:
> Now that we have -Wpessimizing-move implemented, it was fairly easy
> to extend
> it to -Wredundant-move, which warns about redundant calls to
> std::move; it's
> supposed to detect cases where the compiler is obliged to treat an
> object as
> if it were an rvalue, so calling std::move is pointless.  Since we
> implement
> Core Issue 1579, it warns in more situations than clang++.  I
> described this
> in more detail in the manual entry.
> 
> David, I've also tweaked the warning to use fix-it hints; the point
> is to turn
> 
>   return std::move (x);
> 
> into
> 
>   return x;
> 
> I didn't fool around with looking for the locations of the parens;
> I've used a
> DECL_NAME hack instead.  I've verified it using -fdiagnostics-
> generate-patch,
> which produces e.g.:
> 
> @@ -27,7 +27,7 @@
>  f ()
>  {
>T foo;
> -  return std::move (foo);
> +  return foo;
>  }
>  
> g++.dg/diagnostic/move1.C tests the fix-it hints for -Wredundant-move 
> and
> -Wpessimizing-move.

Thanks (and ideally, we'd have a precanned way for DejaGnu to test that
the fix-its hints work, and lead to code that resolves the diagnostics;
I've toyed around with doing so, but it's fiddly, involving a second
compile; ugh).

Regarding the fix-it hint code: I'm not convinced that it works in
every possible scenario.

Consider:

(A):

  namespace ns {
 int some_global;
  };

  int fn ()
  {
return std::move (ns::some_global);
  }

which I believe will generate this bogus suggestion:

return std::move (ns::some_global);
   ~~^
   some_global

since IIRC, DECL_NAME doesn't contain any explicit namespace for the
way the var was referred to.

(B):

#ifdef SOME_CONFIG_FLAG
# define CONFIGURY_GLOBAL global_a
#else
# define CONFIGURY_GLOBAL global_b
#endif

  int fn ()
  {
 return std::move (CONFIGURY_GLOBAL);
  }

which presumably will erroneously strip out the macro in the fix-it
hint:

 return std::move (CONFIGURY_GLOBAL);
~~^~
global_a

rich_location will discard fix-it hints for locations that are in macro
expansions to try to avoid problems like this, but (B)'s location will 
be a non-macro location, I believe.

Hence my suggestion to, if possible, use the locations of the parens,
so that the fix-it hint preserves the user's spelling of the variable.
 
But I appreciate that it might be unreasonably difficult to get at
those locations.  Hence, I think the fix-it hint part of the patch is
probably good enough as-is: I'd rather not let "perfect be the enemy of
the good" here.

Dave

> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2018-08-22  Marek Polacek  
> 
>   PR c++/87029, Implement -Wredundant-move.
>   * c.opt (Wredundant-move): New option.
> 
>   * typeck.c (maybe_warn_pessimizing_move): Call
> convert_from_reference.
>   Warn about redundant moves.  Use fix-it hints.
> 
>   * doc/invoke.texi: Document -Wredundant-move.
> 
>   * g++.dg/cpp0x/Wredundant-move1.C: New test.
>   * g++.dg/cpp0x/Wredundant-move2.C: New test.
>   * g++.dg/cpp0x/Wredundant-move3.C: New test.
>   * g++.dg/cpp0x/Wredundant-move4.C: New test.
>   * g++.dg/diagnostic/move1.C: New test.
> 
> diff --git gcc/c-family/c.opt gcc/c-family/c.opt
> index 76840dd77ad..a92be089b40 100644
> --- gcc/c-family/c.opt
> +++ gcc/c-family/c.opt
> @@ -985,6 +985,10 @@ Wredundant-decls
>  C ObjC C++ ObjC++ Var(warn_redundant_decls) Warning
>  Warn about multiple declarations of the same object.
>  
> +Wredundant-move
> +C++ ObjC++ Var(warn_redundant_move) Warning LangEnabledBy(C++
> ObjC++, Wall)
> +Warn about redundant calls to std::move.
> +
>  Wregister
>  C++ ObjC++ Var(warn_register) Warning
>  Warn about uses of register storage specifier.
> diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> index 122d9dcd4b3..3f0b263525e 100644
> --- gcc/cp/typeck.c
> +++ gcc/cp/typeck.c
> @@ -9185,7 +9185,7 @@ can_do_nrvo_p (tree retval, tree functype)
>  static void
>  maybe_warn_pessimizing_move (tree retval, tree functype)
>  {
> -  if (!warn_pessimizing_move)
> +  if (!(warn_pessimizing_move || warn_redundant_move))
>  return;
>  
>/* C++98 doesn't know move.  */
> @@ -9207,14 +9207,31 @@ maybe_warn_pessimizing_move (tree retval,
> tree functype)
> STRIP_NOPS (arg);
> if (TREE_CODE (arg) == ADDR_EXPR)
>   arg = TREE_OPERAND (arg, 0);
> +   arg = convert_from_reference (arg);
> /* Warn if we could do copy elision were it not for the
> move.  */
> if (can_do_nrvo_p (arg, functype))
>   {
> auto_diagnostic_group d;
> -   if (warning_at (location_of (retval),
> OPT_Wpessimizing_move,
> -   "moving a local object in a return
> statement "
> -   "prevents copy elision"))
> - inform (location_of (retval), "remove %
> call");
> +   

Re: VEC_DUPLICATE_EXPR options (was Re: [PATCH, RFC, rs6000] enable GIMPLE folding of vec_splat)

[Richard Biener]

On Sat, Aug 18, 2018 at 7:01 PM Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Tue, Aug 7, 2018 at 9:25 PM Will Schmidt  
> > wrote:
> >>
> >> Hi
> >> Enable GIMPLE folding of the vec_splat() intrinsic.
> >>
> >> For review.. feedback is expected. :-)
> >>
> >> I came up with the following after spending some time poking around
> >> at the tree_vec_extract() and vector_element() functions as seen
> >> in tree-vect-generic.c looking for insights.  Some of this seems a
> >> bit clunky to me yet, but this is functional as far as make-check
> >> can tell, and is as far as I can get without additional input.
> >>
> >> This uses the tree_vec_extract() function out of tree-vect-generic.c
> >> to retrieve the splat value, which is a BIT_FIELD_REF.   That function is
> >> made non-static as part of this change.
> >>
> >> In review of the .gimple output, this folding takes a sample testcase
> >> of
> >> vector bool int testb_0  (vector bool int x)
> >> {
> >>   return vec_splat (x, 0b0);
> >> }
> >> from:
> >> testb_0 (__vector __bool int x)
> >> {
> >>   __vector __bool intD.1486 D.2855;
> >>
> >>   _1 = VIEW_CONVERT_EXPR<__vector signed intD.1468>(xD.2778);
> >>   _2 = __builtin_altivec_vspltwD.1919 (_1, 0);
> >>   D.2855 = VIEW_CONVERT_EXPR<__vector __bool intD.1486>(_2);
> >>   return D.2855;
> >> }
> >> to:
> >>  testb_0 (__vector __bool int x)
> >> {
> >>   __vector __bool intD.1486 D.2855;
> >>
> >>   _1 = VIEW_CONVERT_EXPR<__vector signed intD.1468>(xD.2778);
> >>   D.2856 = BIT_FIELD_REF <_1, 32, 0>;
> >>   _2 = {D.2856, D.2856, D.2856, D.2856};
> >>   D.2855 = VIEW_CONVERT_EXPR<__vector __bool intD.1486>(_2);
> >>   return D.2855;
> >> }
> >>
> >>
> >> Testcases are being posted as a separate patch.
> >>
> >> OK for trunk?
> >
> > It certainly works, nowadays we have VEC_DUPLICATE_EXPR though
> > so you could simply do
> >
> >  _1 = VIEW_CONVERT_EXPR<__vector signed intD.1468>(xD.2778);
> >  D.2856 = BIT_FIELD_REF <_1, 32, 0>;
> >  D.2855 = VEC_DUPLICATE_EXPR <__vector __bool intD.1486> (D.2856);
> >
> > not sure what variant is better for followup optimizations and whether
> > we already fold that { D.2856, D.2856, D.2856, D.2856 }; to 
> > VEC_DUPLICATE_EXPR.
> >
> > Richard may know more.
>
> We only use VEC_DUPLICATE_EXPR for variable-length vectors.  I still owe
> you a GCC 9 update for:
>
>   https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01039.html
>
> (hadn't forgotten!)
>
> It's a diversion from the patch, sorry, but I think the main alternatives are:
>
> (1) Allow either operand of a VEC_PERM_EXPR to be a scalar
> --
>
> Handles VEC_DUPLICATE_EXPR  as:
> VEC_PERM_EXPR 
>
> Handles IFN_VEC_SHL_INSERT  as:
> VEC_PERM_EXPR 
> or: VEC_PERM_EXPR 
>
> Can also insert a single "a" at the beginning of a vector of "b":
> VEC_PERM_EXPR 
>
> Disdvantages:
>
> (a) It's still a bit limited.  E.g. it can't insert two scalars at
> the beginning of a vector of "b", which might be useful for SLP.
>
> (b) Either all targets would need to handle this case explicitly
> or something would need to massage the tree permute mask before
> the targets see it.  E.g.:
>
>VEC_PERM_EXPR 
> -> permute of { 0, n, n, ... } on two vector broadcast rtxes
>
> (c) There'd still be an inconsistency.  Either:
> (i) we'd only use VEC_PERM_EXPRs for variable-length vectors or
> (ii) we'd have to check before creating a CONSTRUCTOR whether
>  it should be represented as a VEC_PERM_EXPR instead.
>
> (2) Allow only the second operand of a VEC_PERM_EXPR to be a scalar
> ---
>
> Handles VEC_DUPLICATE_EXPR  as:
> VEC_PERM_EXPR <{ 0, ... }, a, { n, ... }>
>
> Handles IFN_VEC_SHL_INSERT  as:
> VEC_PERM_EXPR ;
>
> Advantages:
>
> - Avoids the need for target changes: the mask is the same if the scalar
>   is replaced by a vector.

Interesting idea ;)

> Disadvantages:
>
> - (a) still holds (and now we can't do a two-scalar permute).
>
> - (c) still holds.
>
> (3) Keep VEC_DUPLICATE_EXPR but use it for everything
> -
>
> Advantages:
>
> - The handling of duplicates becomes consistent across vector types.

I think this is definitely important - I don't like too much the idea of
having some stuff only used for the variable-size case.

> - There are no changes to VEC_PERM_EXPR or targets.
>
> - We can still replace IFN_VEC_SHL_INSERT with a VEC_PERM_EXPR,
>   as a separate change.
>
> Disadvantages:
>
> - (c) still holds.
>
> (d) Vector duplication stays a bit of a special case (which was the
> original problem).
>
> (4) Use the VECTOR_CST encoding for CONSTRUCTORs too
> 

Re: [PATCH] Use more DECL_BUILT_IN_P macro.

[Martin Liška]

On 08/23/2018 01:58 PM, Richard Biener wrote:
> On Thu, Aug 23, 2018 at 12:46 PM Martin Liška  wrote:
>>
>> On 08/20/2018 10:34 AM, Richard Biener wrote:
>>> On Wed, Aug 15, 2018 at 2:52 PM Martin Liška  wrote:

 On 08/14/2018 06:02 PM, Martin Sebor wrote:
> On 08/14/2018 03:06 AM, Martin Liška wrote:
>> Hi.
>>
>> The patch adds more usages of the new macro. I hope it improves
>> readability of code.
>
> I think it does :)  I see that most invocations of it in your
> patch are with BUILT_IN_NORMAL as the second argument.  Is
> the argument implied by the last argument?  E.g., in
>
>   DECL_BUILT_IN_P (fndecl, BUILT_IN_NORMAL, BUILT_IN_VA_ARG_PACK)
>
> is there a way to determine that BUILT_IN_VA_ARG_PACK implies
> DECL_BUILT_IN_CLASS(fndecl), so that the second argument could
> be eliminated?  (Both to make the invocation less verbose and
> to avoid the mistake of using the macro with the wrong class.)

 If I see correctly not, there are separate enums:

 BUILT_IN_MD:

 enum ix86_builtins {
   IX86_BUILTIN_MASKMOVQ,
   IX86_BUILTIN_LDMXCSR,
   IX86_BUILTIN_STMXCSR,
 ...
 }

 BUILT_IN_NORMAL:
 enum built_in_function {
 BUILT_IN_NONE,
 BUILT_IN_ACOS,
 BUILT_IN_ACOSF,
 ...
 }

 So the enum values overlap and thus one needs the class.


>
> If not, adding DECL_NORMAL_BUILT_IN_P() would make it possible
> to omit it.

 But yes, this is nice idea, I'm sending V2 of the patch that I'm testing
 right now.
>>>
>>> Ick, and now we have DECL_IS_BUILTIN, DECL_BUILT_IN, DECL_BUILT_IN_P
>>> and DECL_NORMAL_BUILT_IN_P ... (esp the first one is confusing).
>>
>> Agree.
>>
>>>
>>> I think following what gimple.h does would be nicer which means using
>>> inline functions and overloading.
>>>
>>> decl_built_in_p (tree);
>>> decl_built_in_p (tree, enum built_in_class);
>>> decl_built_in_p (tree, enum built_in_function); /// implies BUILT_IN_NORMAL
>>
>> Yes, that's easier to use!
>>
>>>
>>> Can you rework things this way please?  (ok, for gimple those are not 
>>> inlines)
>>
>> Done in patch that can bootstrap and survives regression tests.
>> Ready for trunk?
> 
> +/* For a FUNCTION_DECL NODE, nonzero means a built in function of a
> +   standard library or more generally a built in function that is
> +   recognized by optimizers and expanders.
> +
> +   Note that it is different from the DECL_IS_BUILTIN accessor.  For
> +   instance, user declared prototypes of C library functions are not
> +   DECL_IS_BUILTIN but may be DECL_BUILT_IN.  */
> +
> +inline bool
> +decl_built_in_p (const_tree node)
> +{
> +  return (node != NULL_TREE
> + && TREE_CODE (node) == FUNCTION_DECL
> 
> You document for a FUNCTION_DECL NODE but the check
> for FUNCTION_DECL anyway.  I realize doing all (possibly redundant)
> checks in decl_built_in_p is convenient at callers, but at least update
> docs accordingly?  In reality I somewhat prefer

Yes, please let stay with version that does the checks. It can provide
more readable code like:

   /* If last argument is __builtin_va_arg_pack (), arguments to this
 function are not finalized yet.  Defer folding until they are.  */
   if (n && TREE_CODE (argarray[n - 1]) == CALL_EXPR)
{
  tree fndecl2 = get_callee_fndecl (argarray[n - 1]);
- if (fndecl2
- && TREE_CODE (fndecl2) == FUNCTION_DECL
- && DECL_BUILT_IN_CLASS (fndecl2) == BUILT_IN_NORMAL
- && DECL_FUNCTION_CODE (fndecl2) == BUILT_IN_VA_ARG_PACK)
+ if (decl_built_in_p (fndecl2, BUILT_IN_VA_ARG_PACK))
return NULL_TREE;
}
   if (avoid_folding_inline_builtin (fndecl))

> 
> inline bool
> decl_built_in_p (const_tree node)
> {
>   return DECL_BUILT_IN_CLASS (node) != NOT_BUILT_IN;
> }
> 
> and
> 
> inline bool
> decl_built_in_p (const_tree node, built_in_class klass)
> {
>   return DECL_BUILT_IN_CLASS (node) == klass;
> }
> 
> esp. since the built_in_class overload doesn't work for
> NOT_BUILT_IN for your variant.

That's true. One should probably use DECL_BUILT_IN_CLASS (t1) != NOT_BUILT_IN
in this case.

> 
> And if we're at changing, maybe call the functions
> fndecl_built_in_p to make it clear we're expecting FUNCTION_DECLs...
> 
> +/* For a FUNCTION_DECL NODE, return true when a function is
> +   a built-in of class KLASS with name equal to NAME.  */
> +
> +inline bool
> +decl_built_in_p (const_tree node, int name,
> 
> why's that 'int' and not built_in_function?

Because we want to also call it for e.g. cp_built_in_function
enum types:

gcc/cp/cp-gimplify.c:2498:26: error: no matching function for call to 
‘decl_built_in_p(tree_node*&, cp_built_in_function, built_in_class)’

Note that:
gimple_call_builtin_p (const gimple *stmt, enum built_in_function code)

is only used for BUILT_IN_NORMAL, which decl_built_in_p should handle also FE 
and TARGET 

Re: [PATCH] Remove verify_no_unreachable_blocks

[Tom de Vries]

On 08/23/2018 02:06 PM, Richard Biener wrote:
> On Thu, 23 Aug 2018, Tom de Vries wrote:
> 
>> On 08/23/2018 01:18 PM, Richard Biener wrote:
>>> This removes verify_no_unreachable_blocks and implements checking
>>> for unreachable blocks in inverted_post_order_compute by simply
>>> looking if we reach a block without predecessors that is not the
>>> entry block.
>>>
>>
>> I think that doesn't detect unreachable cyles: say you have blocks A and
>> B, and A -> B -> A.
> 
> Ah, true.  Bah, I guess I can use some other flag in my pass.
> 
>>> This solves a problem I ran into when (ab-)using BB_REACHABLE
>>> in a pass and I got comparison failues because of -fchecking vs.
>>> -fno-checking.  It also should speed up checking builds.
>>>
>>> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>>>
>>> Tom, does this make sense?
>>>
>>
>> The intent of the check I added was to verify the assumption stated in
>> the comment. I don't know how serious it is if the assumption is violated.
> 
> I think if you have reverse-not-reachable blocks (infinite loops w/o
> fake exit edges) that are not reachable from entry it will ICE
> or loop infintely.
> 

Hmm, looking at the code a bit more, there's an infinite loop detection
mechanism, and I think the case I described above, would run into this
assert:
...
  if (has_unvisited_bb && stack.is_empty ())
{
  /* No blocks are reachable from EXIT at all.

 Find a dead-end from the ENTRY, and restart the
 iteration. */
  basic_block be
= dfs_find_deadend (ENTRY_BLOCK_PTR_FOR_FN (cfun));
  gcc_assert (be != NULL);
  bitmap_set_bit (visited, be->index);
  stack.quick_push (ei_start (be->preds));
}
...

So perhaps the code already verifies that there are no unreachable
blocks, and the comment needs to be updated to:
...
   This function requires that all blocks in the CFG are reachable

   from the ENTRY (but not necessarily from EXIT).  Otherwise, it ICEs.
...

Thanks,
- Tom

Re: RFA: Define vect_perm for variable-length SVE

[Richard Biener]

On Thu, Aug 23, 2018 at 11:15 AM Richard Sandiford
 wrote:
>
> Variable-length SVE now supports enough permutes to define vect_perm.
>
> The change to vect_perm_supported is currently a no-op because the
> function is only called with a count of 3.
>
> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu.  OK for the vect_perm_supported change?
> I think the rest is covered by the SVE maintainership.
OK

> Richard
>
>
> 2018-08-23  Richard Sandiford  
>
> gcc/testsuite/
> * lib/target-supports.exp (vect_perm_supported): Only return
> false for variable-length vectors if the permute size is not
> a power of 2.
> (check_effective_target_vect_perm)
> (check_effective_target_vect_perm_byte)
> (check_effective_target_vect_perm_short): Remove check for
> variable-length vectors.
> * gcc.dg/vect/slp-23.c: Add an XFAIL for variable-length SVE.
> * gcc.dg/vect/slp-perm-10.c: Likewise.
> * gcc.dg/vect/slp-perm-9.c: Add an XFAIL for variable-length vectors.
>
> Index: gcc/testsuite/lib/target-supports.exp
> ===
> --- gcc/testsuite/lib/target-supports.exp   2018-08-21 14:47:06.491178839 
> +0100
> +++ gcc/testsuite/lib/target-supports.exp   2018-08-23 10:09:45.296442485 
> +0100
> @@ -5758,8 +5758,7 @@ proc check_effective_target_vect_perm {
>  } else {
> set et_vect_perm_saved($et_index) 0
>  if { [is-effective-target arm_neon]
> -|| ([istarget aarch64*-*-*]
> -&& ![check_effective_target_vect_variable_length])
> +|| [istarget aarch64*-*-*]
>  || [istarget powerpc*-*-*]
>   || [istarget spu-*-*]
>  || [istarget i?86-*-*] || [istarget x86_64-*-*]
> @@ -5824,7 +5823,9 @@ proc check_effective_target_vect_perm {
>
>  proc vect_perm_supported { count element_bits } {
>  set vector_bits [lindex [available_vector_sizes] 0]
> -if { $vector_bits <= 0 } {
> +# The number of vectors has to be a power of 2 when permuting
> +# variable-length vectors.
> +if { $vector_bits <= 0 && ($count & -$count) != $count } {
> return 0
>  }
>  set vf [expr { $vector_bits / $element_bits }]
> @@ -5864,8 +5865,7 @@ proc check_effective_target_vect_perm_by
>  if { ([is-effective-target arm_neon]
>   && [is-effective-target arm_little_endian])
>  || ([istarget aarch64*-*-*]
> -&& [is-effective-target aarch64_little_endian]
> -&& ![check_effective_target_vect_variable_length])
> +&& [is-effective-target aarch64_little_endian])
>  || [istarget powerpc*-*-*]
>  || [istarget spu-*-*]
>  || ([istarget mips-*.*]
> @@ -5904,8 +5904,7 @@ proc check_effective_target_vect_perm_sh
>  if { ([is-effective-target arm_neon]
>   && [is-effective-target arm_little_endian])
>  || ([istarget aarch64*-*-*]
> -&& [is-effective-target aarch64_little_endian]
> -&& ![check_effective_target_vect_variable_length])
> +&& [is-effective-target aarch64_little_endian])
>  || [istarget powerpc*-*-*]
>  || [istarget spu-*-*]
>  || (([istarget i?86-*-*] || [istarget x86_64-*-*])
> Index: gcc/testsuite/gcc.dg/vect/slp-23.c
> ===
> --- gcc/testsuite/gcc.dg/vect/slp-23.c  2018-05-02 08:37:48.985604715 +0100
> +++ gcc/testsuite/gcc.dg/vect/slp-23.c  2018-08-23 10:09:45.296442485 +0100
> @@ -107,8 +107,8 @@ int main (void)
>
>  /* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { target 
> { vect_strided8 && { ! { vect_no_align} } } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target 
> { ! { vect_strided8 || vect_no_align } } } } } */
> -/* We fail to vectorize the second loop with variable-length SVE but
> -   fall back to 128-bit vectors, which does use SLP.  */
>  /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> { target { ! vect_perm } } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target vect_perm } } } */
> +/* SLP fails for the second loop with variable-length SVE because
> +   the load size is greater than the minimum vector size.  */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target vect_perm xfail { aarch64_sve && vect_variable_length } } } } */
>
> Index: gcc/testsuite/gcc.dg/vect/slp-perm-10.c
> ===
> --- gcc/testsuite/gcc.dg/vect/slp-perm-10.c 2016-11-11 17:07:36.516798781 
> +
> +++ gcc/testsuite/gcc.dg/vect/slp-perm-10.c 2018-08-23 10:09:45.296442485 
> +0100
> @@ -50,4 +50,6 @@ int main ()
>  }
>
>  /* { dg-final { 

Re: VRP: rewrite the division code (to handle corner cases including 0)

[Aldy Hernandez]

On 08/23/2018 08:51 AM, Richard Biener wrote:

On Tue, Aug 21, 2018 at 7:35 PM Aldy Hernandez  wrote:




On 08/21/2018 05:46 AM, Richard Biener wrote:

On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez  wrote:


Howdy!

In auditing the *_DIV_EXPR code I noticed that we were really botching
some divisions where the divisor included 0.

Particularly interesting was that we were botching something as simple
as dividing by [0,0].  We were also incorrectly calculating things like
[-2,-2] / [0, ], where we should have removed the 0 from the divisor.

Also, the symbolic special casing could be handled by just treating
symbolic ranges as [-MIN, +MAX] and letting the common code handle then.
Similarly for anti ranges, which actually never happen except for the
constant case, since they've been normalized earlier.


Note we also have "mixed" symbolic (anti-)ranges like [0, a].  I don't think
we handled those before but extract_range_to_wide_ints may be improved
to handle them.  Likewise ranges_from_anti_range, ~[0, a] -> [-INF,
-1] u [a+1, +INF]
though not sure if that helps any case in practice.


I have added comments for a future improvements.  Perhaps after the dust
settles...


Good ;)




All in all, it was much easier to normalize all the symbolic ranges and
treat everything generically by performing the division in two chunks...
the negative numbers and the (non-zero) positive numbers.  And finally,
unioning the results.  This makes everything much simpler to read with
minimal special casing.


Yeah, nice work.  Few comments:

+  TYPE_OVERFLOW_UNDEFINED (expr_type),
+  TYPE_OVERFLOW_WRAPS (expr_type),

we no longer have the third state !UNDEFINED && !WRAPS so I suggest
to eliminate one for the other (just pass TYPE_OVERFLOW_UNDEFINED).


I'm confused.  Then what shall I pass to
wide_int_range_multiplicative_op within wide_int_range_div?  Are you
expecting to pass overflow_undefined to both the overflow_undefined and
overflow_wraps arguments in multiplicative_op?  Or are you saying I
should get rid of overflow_wraps in both wide_int_range_div and
wide_int_range_multiplicative_op (plus all other users of
w_i_r_multiplicative_op)?


Yes, overflow_wraps == !overflow_undefined (well, OK, not exactly - there's
also TYPE_OVERFLOW_TRAPS, but not for pointers).

Let's sort this out as a followup.  It somewhat felt odd / inconsistent.


Ok, I'm drowning myself in changes here.  I've put this on my short-term 
todo list, and will revisit once the dust settles-- hopefully in a week.




I think the wide-int routines want to know whether the operation may
overflow or not and if it may then it simply assumes wrapping behavior.
When overflow is undefined or if it traps the overflow isn't observed
in the result ...





+  /* If we're definitely dividing by zero, there's nothing to do.  */
+  if (wide_int_range_zero_p (divisor_min, divisor_max, prec))
+return false;

I know we didn't do this before but for x / 0 we should compute UNDEFINED
as range.  With the current interfacing this special case would require handling
in the non-wide-int caller.


I've added the following, since I'm unsure whether we should return
undefined or varying for non_call_exceptions.  What do you think?

/* Special case explicit division by zero as undefined.  */
if (range_is_null ())
 {
   /* However, we must not eliminate a division by zero if
  flag_non_call_exceptions.  */
   if (cfun->can_throw_non_call_exceptions)
 set_value_range_to_varying (vr);
   else
 set_value_range_to_undefined (vr);
   return;
 }


... which means even for non-call-exceptions the actual _result_ of
a division by zero is UNDEFINED.  When an exception is thrown
we're just not reaching any consumer of the result.




Finally, my apologies for including a tiny change to the
POINTER_PLUS_EXPR handling code as well.  It came about the same set of
auditing tests.


Bah, please split up things here ;)  I've done a related change there
yesterday...


Ughh... Will do.  I figured someone would complain ;-).


;)

The patch is OK unchanged or with the division-by-zero changed to
VR_UNDEFINED unconditionally (you can also do/test that as followup,
but make sure to enable Ada for testing).


Likewise.  I've added this to my list, and will revisit shortly.

Ada?  What's that?  Is that what I test right before I merge a branch 
with tons of changes into mainline? *hides in shame*


I'm committing as is.  Thanks.
Aldy

Re: [PATCH] treat -Wxxx-larger-than=HWI_MAX special (PR 86631)

[Richard Biener]

On Thu, Aug 23, 2018 at 12:20 AM Martin Sebor  wrote:
>
> On 08/20/2018 06:14 AM, Richard Biener wrote:
> > On Thu, Jul 26, 2018 at 10:52 PM Martin Sebor  wrote:
> >>
> >> On 07/26/2018 08:58 AM, Martin Sebor wrote:
> >>> On 07/26/2018 02:38 AM, Richard Biener wrote:
>  On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor  wrote:
> >
> > On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
> >> On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
> >>> I don't mean for the special value to be used except internally
> >>> for the defaults.  Otherwise, users wanting to override the default
> >>> will choose a value other than it.  I'm happy to document it in
> >>> the .opt file for internal users though.
> >>>
> >>> -1 has the documented effect of disabling the warnings altogether
> >>> (-1 is SIZE_MAX) so while I agree that -1 looks better it doesn't
> >>> work.  (It would need more significant changes.)
> >>
> >> The variable is signed, so -1 is not SIZE_MAX.  Even if -1 disables
> >> it, you
> >> could use e.g. -2 or other negative value for the other special case.
> >
> > The -Wxxx-larger-than=N distinguish three ranges of argument
> > values (treated as unsigned):
> >
> >1.  [0, HOST_WIDE_INT_MAX)
> >2.  HOST_WIDE_INT_MAX
> >3.  [HOST_WIDE_INT_MAX + 1, Infinity)
> 
>  But it doesn't make sense for those to be host dependent.
> >>>
> >>> It isn't when the values are handled by each warning.  That's
> >>> also the point of this patch: to remove this (unintended)
> >>> dependency.
> >>>
>  I think numerical user input should be limited to [0, ptrdiff_max]
>  and cases (1) and (2) should be simply merged, I see no value
>  in distinguishing them.  -Wxxx-larger-than should be aliased
>  to [0, ptrdiff_max], case (3) is achieved by -Wno-xxx-larger-than.
> >>
> >> To be clear: this is also close to what this patch does.
> >>
> >> The only wrinkle is that we don't know the value of PTRDIFF_MAX
> >> either at the time the option initial value is set in the .opt
> >> file or when the option is processed when it's specified either
> >> on the command line or as an alias in the .opt file (as all
> >> -Wno-xxx-larger-than options are).
> >
> > But then why not make that special value accessible and handle
> > it as PTRDIFF_MAX when that is available (at users of the params)?
> >
> > That is,
> >
> > Index: gcc/calls.c
> > ===
> > --- gcc/calls.c (revision 262951)
> > +++ gcc/calls.c (working copy)
> > @@ -1222,9 +1222,12 @@ alloc_max_size (void)
> >if (alloc_object_size_limit)
> >  return alloc_object_size_limit;
> >
> > -  alloc_object_size_limit
> > -= build_int_cst (size_type_node, warn_alloc_size_limit);
> > +  HOST_WIDE_INT limit = warn_alloc_size_limit;
> > +  if (limit == HOST_WIDE_INT_MAX)
> > +limit = tree_to_shwi (TYPE_MAX_VALUE (ptrdiff_type_node));
> >
> > +  alloc_object_size_limit = build_int_cst (size_type_node, limit);
> > +
> >return alloc_object_size_limit;
> >  }
> >
> > use sth like
> >
> >  if (warn_alloc_size_limit == -1)
> >alloc_object_size_limit = fold_convert (size_type_node,
> > TYPE_MAX_VALUE (ptrdiff_type_node));
> >  else
> >alloc_object_size_limit = size_int (warn_alloc_size_limit);
> >
> > ?  Also removing the need to have > int params values.
>
> Not sure I understand this last part.  Remove the enhancement?
> (We do need to handle option arguments in excess of INT_MAX.)

I see.

> >
> > It's that HOST_WIDE_INT_MAX use that is problematic IMHO.  Why not use -1?
>
> -1 is a valid/documented value of the argument of all these
> options because it's treated as unsigned HWI:
>
>Warnings controlled by the option can be disabled either
>by specifying byte-size of ‘SIZE_MAX’
>
> It has an intuitive meaning: warning for any size larger than
> the maximum means not warning at all.  Treating -1 as special
> instead of HOST_WIDE_INT_MAX would replace that meaning with
> "warn on any size in excess of PTRDIFF_MAX."
>
> A reasonable way to disable the warning is like so:
>
>gcc -Walloc-size-larger-than=$(getconf ULONG_MAX) ...
>
> That would not work anymore.
>
> Treating HOST_WIDE_INT_MAX as PTRDIFF_MAX is the natural choice
> on LP64: they have the same value.  It's only less than perfectly
> natural in ILP32 and even there it's not a problem in practice
> because it's either far out of the range of valid values [0, 4GB]
> (i.e., where HWI is a 64-bit long long), or it's also equal to
> PTRDIFF_MAX (on hosts with no 64-bit type, if GCC even supports
> any).
>
> I'm not trying to be stubborn here but I just don't see why
> you think that setting aside HOST_WIDE_INT_MAX is problematic.
> Anything else is worse from a user-interface POV.  It makes
> little difference inside GCC as long as we want to let users
> choose to warn for allocation sizes over some value in
> 

Re: [PATCH] DWARF: Call set_indirect_string on DW_MACINFO_start_file

[Richard Biener]

On Wed, Aug 22, 2018 at 9:36 PM H.J. Lu  wrote:
>
> Since -gsplit-dwarf -g3 will output filename as indirect string, call
> set_indirect_string on DW_MACINFO_start_file for -gsplit-dwarf -g3.
>
> OK for trunk?

Can you add a testcase?

Richard.

> H.J.
> --
> PR debug/79342
> * dwarf2out.c (save_macinfo_strings): Call set_indirect_string
> on DW_MACINFO_start_file for -gsplit-dwarf -g3
> ---
>  gcc/dwarf2out.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index edf1ac35896..6ae0a4d66b4 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -28280,6 +28280,12 @@ save_macinfo_strings (void)
>  && (debug_str_section->common.flags & SECTION_MERGE) != 0)
>set_indirect_string (find_AT_string (ref->info));
>  break;
> + case DW_MACINFO_start_file:
> +   /* -gsplit-dwarf -g3 will also output filename as indirect
> +  string.  */
> +   if (!dwarf_split_debug_info)
> + break;
> +   /* Fall through. */
>   case DW_MACRO_define_strp:
>   case DW_MACRO_undef_strp:
>  set_indirect_string (find_AT_string (ref->info));
> --
> 2.17.1
>

Re: [PATCH] print full STRING_CST in Gimple dumps (PR 87052)

[Richard Biener]

On Wed, Aug 22, 2018 at 5:05 PM Martin Sebor  wrote:
>
> On 08/22/2018 06:48 AM, Richard Biener wrote:
> > On Wed, Aug 22, 2018 at 4:56 AM Martin Sebor  wrote:
> >>
> >> In the discussion of the fallout from the enhancement for pr71625
> >> it was pointed out that STRING_CSts in Gimple dumps extend only
> >> to the first nul and don't include any subsequent characters,
> >> and that this makes the dumps harder to read and might give rise
> >> to the question whether the code is correct.
> >>
> >> In the attached patch I enhance the pretty_print_string() function
> >> to print the full contents of a STRING_CST, including any embedded
> >> nuls to make the dumps clearer.  I got rid of the single digit
> >> escapes like '\1' since they make the string look ambiguous.
> >> If TREE_STRING_LENGTH (node) is guaranteed to be non-zero these
> >> days the test for it being so may be redundant but I figured it's
> >> better to be safe than sorry.
> >>
> >> A further enhancement might be to also distinguish the type of
> >> the STRING_CST.
> >
> > And somehow indicate whether it is \0 terminated (just thinking of
> > the GIMPLE FE and how it parses string literals simply by relying
> > on libcpp).
> >
> > Can you write a not \0 terminated string literal in C?
>
> Yes: char a[2] = "12";

I thought they are fully defined in translation phase #1 ...

> I briefly considered making the terminating nul visible when
> there was one but there's at least one test that scans GIMPLE
> for the expected string and it failed so I didn't pursue this
> idea further.

Yes, I think it would just confuse people at the moment.  I thought
of somehow marking non-terminated literals, like  "12"[nt] or so ...
or by using an alternate quote "12' (eh).

Anyway, not too important I guess if you for a moment exclude
the -fdump-XXX-gimple and re-parsing with the GIMPLE FE case.

Richard.

> The tests can certainly be changed to look for the new pattern
> if we should decide to make a change here.  I'm not sure what
> would be best.  Printing "12\x00" for an ordinary nul-terminated
> literal looks like there might be an extra nul after the first
> one.  Leaving it out doesn't distinguish it from the unterminated
> array.  Using the braced-list notation (i.e.,  a = { '1', '2' }
> for unterminated arrays doesn't capture the fact that it's
> represented as STRING_CST).
>
> I'm open to suggestions.
>
> Martin

Re: Async I/O patch with compilation fix

[David Edelsohn]

Thomas,

Once the plural.c file has been re-generated incorrectly using the local
Yacc, it must be deleted and checked out again.  Did you pull it fresh from
the repository in your AIX tree after the incorrect checkout?

Thanks, David


On Wed, Aug 22, 2018 at 5:30 PM Thomas Koenig  wrote:

> Hi David,
>
> > This patch broke bootstrap on AIX again.  This is completely
> unacceptable.
>
> Again, sorry for the breakage.
>
> I faced quite some challenges trying to get bootstrap to
> work on gcc119. Despite quite a few e-mails (plus hints in a PR)
> that I received, none of the hints for bootstrap I got actually got
> it to work. I finally gave up after four or five different failures,
> and the patch was committed because every test
> that _could_ be run did show no failure.
>
> Had we received instructions that work for bootstrapping on AIX,
> we would have tested the patch there.
>
> If it were possible to add instructions that do work for AIX
> bootstrapping to the compile farm wiki, that would be great.
>
> If you (or somebody else who has the requisite AIX fu) could test
> patches that are known to be difficult, that would also be
> great.
>
> As long as we have no other solution, it is probably best to #ifdef out
> AIX any additional pthread-related functionality for libgfortran that
> might be coming along. That can always be integrated later, if somebody
> can re-implement POSIX condition variables for libgfortran from what
> AIX provides.
>
> Let's talk about how to proceed at the GNU cauldron, over a beer.
> Both Nicolas and I will be there.
>
> In the meantime, I have committed the following patch (r263788) as
> obvious after regression-testing on Linux both with ASYNC_IO set
> to 1 and to 0.  Let me know how that works out.
>
> 2018-08-22  Thomas Koenig  
>
> * async.h: Set ASYNC_IO to zero if _AIX is defined.
> (struct adv_cond): If ASYNC_IO is zero, the struct has no members.
> (async_unit): If ASYNC_IO is zero, remove unneeded members.
>
> 2018-08-22  Thomas Koenig  
>
> * gfortran.texi: Mention that asynchronous I/O does
> not work on systems which lack condition variables, such
> as AIX.
>
> Regards
>
> Thomas
>

Re: VRP: rewrite the division code (to handle corner cases including 0)

[Richard Biener]

On Tue, Aug 21, 2018 at 7:35 PM Aldy Hernandez  wrote:
>
>
>
> On 08/21/2018 05:46 AM, Richard Biener wrote:
> > On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez  wrote:
> >>
> >> Howdy!
> >>
> >> In auditing the *_DIV_EXPR code I noticed that we were really botching
> >> some divisions where the divisor included 0.
> >>
> >> Particularly interesting was that we were botching something as simple
> >> as dividing by [0,0].  We were also incorrectly calculating things like
> >> [-2,-2] / [0, ], where we should have removed the 0 from the divisor.
> >>
> >> Also, the symbolic special casing could be handled by just treating
> >> symbolic ranges as [-MIN, +MAX] and letting the common code handle then.
> >>Similarly for anti ranges, which actually never happen except for the
> >> constant case, since they've been normalized earlier.
> >
> > Note we also have "mixed" symbolic (anti-)ranges like [0, a].  I don't think
> > we handled those before but extract_range_to_wide_ints may be improved
> > to handle them.  Likewise ranges_from_anti_range, ~[0, a] -> [-INF,
> > -1] u [a+1, +INF]
> > though not sure if that helps any case in practice.
>
> I have added comments for a future improvements.  Perhaps after the dust
> settles...

Good ;)

> >
> >> All in all, it was much easier to normalize all the symbolic ranges and
> >> treat everything generically by performing the division in two chunks...
> >> the negative numbers and the (non-zero) positive numbers.  And finally,
> >> unioning the results.  This makes everything much simpler to read with
> >> minimal special casing.
> >
> > Yeah, nice work.  Few comments:
> >
> > +  TYPE_OVERFLOW_UNDEFINED (expr_type),
> > +  TYPE_OVERFLOW_WRAPS (expr_type),
> >
> > we no longer have the third state !UNDEFINED && !WRAPS so I suggest
> > to eliminate one for the other (just pass TYPE_OVERFLOW_UNDEFINED).
>
> I'm confused.  Then what shall I pass to
> wide_int_range_multiplicative_op within wide_int_range_div?  Are you
> expecting to pass overflow_undefined to both the overflow_undefined and
> overflow_wraps arguments in multiplicative_op?  Or are you saying I
> should get rid of overflow_wraps in both wide_int_range_div and
> wide_int_range_multiplicative_op (plus all other users of
> w_i_r_multiplicative_op)?

Yes, overflow_wraps == !overflow_undefined (well, OK, not exactly - there's
also TYPE_OVERFLOW_TRAPS, but not for pointers).

Let's sort this out as a followup.  It somewhat felt odd / inconsistent.

I think the wide-int routines want to know whether the operation may
overflow or not and if it may then it simply assumes wrapping behavior.
When overflow is undefined or if it traps the overflow isn't observed
in the result ...

>
> >
> > +  /* If we're definitely dividing by zero, there's nothing to do.  */
> > +  if (wide_int_range_zero_p (divisor_min, divisor_max, prec))
> > +return false;
> >
> > I know we didn't do this before but for x / 0 we should compute UNDEFINED
> > as range.  With the current interfacing this special case would require 
> > handling
> > in the non-wide-int caller.
>
> I've added the following, since I'm unsure whether we should return
> undefined or varying for non_call_exceptions.  What do you think?
>
>/* Special case explicit division by zero as undefined.  */
>if (range_is_null ())
> {
>   /* However, we must not eliminate a division by zero if
>  flag_non_call_exceptions.  */
>   if (cfun->can_throw_non_call_exceptions)
> set_value_range_to_varying (vr);
>   else
> set_value_range_to_undefined (vr);
>   return;
> }

... which means even for non-call-exceptions the actual _result_ of
a division by zero is UNDEFINED.  When an exception is thrown
we're just not reaching any consumer of the result.

> >
> >> Finally, my apologies for including a tiny change to the
> >> POINTER_PLUS_EXPR handling code as well.  It came about the same set of
> >> auditing tests.
> >
> > Bah, please split up things here ;)  I've done a related change there
> > yesterday...
>
> Ughh... Will do.  I figured someone would complain ;-).

;)

The patch is OK unchanged or with the division-by-zero changed to
VR_UNDEFINED unconditionally (you can also do/test that as followup,
but make sure to enable Ada for testing).

Thanks,
Richard.

> Aldy
>
> >
> >>
> >> It turns out we can handle POINTER_PLUS_EXPR(~[0,0], [X,Y]) without
> >> bailing as VR_VARYING in extract_range_from_binary_expr_1.  In doing so,
> >> I also noticed that ~[0,0] is not the only non-null.  We could also have
> >> ~[0,2] and still know that the pointer is not zero.  I have adjusted
> >> range_is_nonnull accordingly.
> >
> > But there are other consumers and it would have been better to
> > change range_includes_zero_p to do the natural thing (get a VR) and
> > then remove range_is_nonnull as redundant if possible.
> >
> >>
> >> (Yes, we 

Re: [PATCH][GCC][AARCH64] use "arch_enabled" attribute for aarch64.

[Richard Earnshaw (lists)]

On 23/08/18 08:23, Matthew Malcomson wrote:
> Hello,
> 
> arm.md has some attributes "arch" and "arch_enabled" to aid enabling and
> disabling insn alternatives based on the architecture being targeted.
> This patch introduces a similar attribute in the aarch64 backend.
> The new attribute will be used to enable a new alternative for the 
> atomic_store
> insn in a future patch, but is an atomic change in itself.
> 
> The new attribute has values "any", "fp", "fp16", "simd", and "sve".
> These attribute values have been taken from the pre-existing attributes "fp",
> "fp16", "simd", and "sve".
> The standalone "fp" attribute has been reintroduced in terms of the "arch"
> attribute as it's needed for the xgene1.md scheduling file -- the use in this
> file can't be changed to check for `(eq_attr "arch" "fp")` as the file is
> reused by the arm.md machine description whose 'arch' attribute doesn't have 
> an
> 'fp' value.
> 
> 
> Full bootstrap and regression test done on aarch64.
> 
> Ok for trunk?
> I don't have commit rights, so could someone commit it if accepted.
> 

Committed.


Thanks,
R.

> 
> gcc/ChangeLog:
> 
> 2018-08-23  Matthew Malcomson  
> 
>   * config/aarch64/aarch64.md (arches): New enum.
>   (arch): New enum attr.
>   (arch_enabled): New attr.
>   (enabled): Now uses arch_enabled only.
>   (simd, sve, fp16): Removed attribute.
>   (fp): Attr now defined in terms of 'arch'.
>   (*mov_aarch64, *movsi_aarch64, *movdi_aarch64, *movti_aarch64,
>   *movhf_aarch64, 2,
>   3,
>   3): Merge 'fp' and 'simd'
>   attributes into 'arch'. 
>   (*movsf_aarch64, *movdf_aarch64, *movtf_aarch64, *add3_aarch64,
>   subdi3, neg2, 3, one_cmpl2,
>   *_one_cmpl3, *xor_one_cmpl3,
>   *aarch64_ashl_sisd_or_int_3, *aarch64_lshr_sisd_or_int_3,
>   *aarch64_ashr_sisd_or_int_3, *aarch64_sisd_ushl): Convert use of
>   'simd' attribute into 'arch'. 
>   (load_pair_sw_, load_pair_dw_,
>   store_pair_sw_, store_pair_dw_):
>   Convert use of 'fp' attribute to 'arch'. 
>   * config/aarch64/aarch64-simd.md (move_lo_quad_internal_,
>   move_lo_quad_internal_): (different modes) Merge 'fp' and 'simd'
>   into 'arch'.
>   (move_lo_quad_internal_be_, move_lo_quad_internal_be_):
>   (different modes) Merge 'fp' and 'simd' into 'arch'.
>   (*aarch64_combinez, *aarch64_combinez_be): Merge 'fp' and
>   'simd' into 'arch'.
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> 5591c7b5a6bd7783c2b227add3e5a89d1a188f69..bea1c14e8ddabc4175be10790cd839c3a3852dab
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -1352,9 +1352,8 @@
> fmov\\t%d0, %1
> dup\\t%d0, %1"
>[(set_attr "type" "neon_dup,f_mcr,neon_dup")
> -   (set_attr "simd" "yes,*,yes")
> -   (set_attr "fp" "*,yes,*")
> -   (set_attr "length" "4")]
> +   (set_attr "length" "4")
> +   (set_attr "arch" "simd,fp,simd")]
>  )
>  
>  (define_insn "move_lo_quad_internal_"
> @@ -1368,9 +1367,8 @@
> fmov\\t%d0, %1
> dup\\t%d0, %1"
>[(set_attr "type" "neon_dup,f_mcr,neon_dup")
> -   (set_attr "simd" "yes,*,yes")
> -   (set_attr "fp" "*,yes,*")
> -   (set_attr "length" "4")]
> +   (set_attr "length" "4")
> +   (set_attr "arch" "simd,fp,simd")]
>  )
>  
>  (define_insn "move_lo_quad_internal_be_"
> @@ -1384,9 +1382,8 @@
> fmov\\t%d0, %1
> dup\\t%d0, %1"
>[(set_attr "type" "neon_dup,f_mcr,neon_dup")
> -   (set_attr "simd" "yes,*,yes")
> -   (set_attr "fp" "*,yes,*")
> -   (set_attr "length" "4")]
> +   (set_attr "length" "4")
> +   (set_attr "arch" "simd,fp,simd")]
>  )
>  
>  (define_insn "move_lo_quad_internal_be_"
> @@ -1400,9 +1397,8 @@
> fmov\\t%d0, %1
> dup\\t%d0, %1"
>[(set_attr "type" "neon_dup,f_mcr,neon_dup")
> -   (set_attr "simd" "yes,*,yes")
> -   (set_attr "fp" "*,yes,*")
> -   (set_attr "length" "4")]
> +   (set_attr "length" "4")
> +   (set_attr "arch" "simd,fp,simd")]
>  )
>  
>  (define_expand "move_lo_quad_"
> @@ -3114,8 +3110,7 @@
> fmov\t%d0, %1
> ldr\\t%d0, %1"
>[(set_attr "type" "neon_move, neon_from_gp, neon_load1_1reg")
> -   (set_attr "simd" "yes,*,yes")
> -   (set_attr "fp" "*,yes,*")]
> +   (set_attr "arch" "simd,fp,simd")]
>  )
>  
>  (define_insn "*aarch64_combinez_be"
> @@ -3129,8 +3124,7 @@
> fmov\t%d0, %1
> ldr\\t%d0, %1"
>[(set_attr "type" "neon_move, neon_from_gp, neon_load1_1reg")
> -   (set_attr "simd" "yes,*,yes")
> -   (set_attr "fp" "*,yes,*")]
> +   (set_attr "arch" "simd,fp,simd")]
>  )
>  
>  (define_expand "aarch64_combine"
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> 955bf1814b92d2bbf72d46bb2050998385174200..52ad814aafa8645342342cc6d67084af57e4b343
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ 

[PATCH] Do not read gcda files multiple times (PR gcov-profile/87069).

[Martin Liška]

Hi.

This is simple fix of situation when a source file is passed
on command line multiple times.

I'm planning to install that if no objection. Survives regression tests
of gcov.exp.

Martin

gcc/ChangeLog:

2018-08-23  Martin Liska  

PR gcov-profile/87069
* gcov.c (process_file): Record files already processed
and warn about a file being processed multiple times.
---
 gcc/gcov.c | 15 +++
 1 file changed, 15 insertions(+)


diff --git a/gcc/gcov.c b/gcc/gcov.c
index 43dfc9a4b2c..ff4020c713e 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -408,6 +408,10 @@ static vector sources;
 /* Mapping of file names to sources */
 static vector names;
 
+/* Record all processed files in order to warn about
+   a file being read multiple times.  */
+static vector processed_files;
+
 /* This holds data summary information.  */
 
 static unsigned object_runs;
@@ -1146,6 +1150,17 @@ static void
 process_file (const char *file_name)
 {
   create_file_names (file_name);
+
+  for (unsigned i = 0; i < processed_files.size (); i++)
+if (strcmp (da_file_name, processed_files[i]) == 0)
+  {
+	fnotice (stderr, "'%s' file is already processed\n",
+		 file_name);
+	return;
+  }
+
+  processed_files.push_back (xstrdup (da_file_name));
+
   read_graph_file ();
   read_count_file ();
 }

Do not stream TYPE_STUB_DECL

[Jan Hubicka]

Hi,
this patch removes streaming of TYPE_STUB_DECL. The sanity checking part depends
on the coverage change but I may just drop it (though I think it is useful as
a sanity check that things are consistend within the middle-end).

lto-bootstrapped/regtested x86_64-linux, OK?

Honza

* ipa-utils.h (polymorphic_type_binfo_p,
type_in_anonymous_namespace_p): Expect free lang data to remove
TYPE_STUB_DECL after producing mangled names for types with linkage.
* lto-stramer-out.c (DFS::DFS_write_tree_body, hash_tree):
Do not walk TYPE_STUB_DECL; sanity check it is NULL.
* tree-streamer-in.c (lto_input_ts_type_common_tree_pointers):
Do not stream TYPE_STUB_DECL.
* tree-streamer-out.c (write_ts_type_common_tree_pointers): Likewise.
* tree.c (free_lang_data_in_type): Always clear TYPE_STUB_DECL.
Index: ipa-utils.h
===
--- ipa-utils.h (revision 263696)
+++ ipa-utils.h (working copy)
@@ -179,22 +179,24 @@ polymorphic_type_binfo_p (const_tree bin
 inline bool
 type_with_linkage_p (const_tree t)
 {
-  if (!TYPE_NAME (t) || TREE_CODE (TYPE_NAME (t)) != TYPE_DECL
-  || !TYPE_STUB_DECL (t))
+  if (!TYPE_NAME (t) || TREE_CODE (TYPE_NAME (t)) != TYPE_DECL)
+return false;
+
+  /* To support -fno-lto-odr-type-merigng recognize types with vtables
+ to have linkage.  */
+  if (RECORD_OR_UNION_TYPE_P (t)
+  && TYPE_BINFO (t) && BINFO_VTABLE (TYPE_BINFO (t)))
+return true;
+
+  /* After free_lang_data was run and -flto-odr-type-merging we can recongize
+ types with linkage by presence of mangled name.  */
+  if (DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (t)))
+return true;
+
+  /* If free lang data was not run check if indeed the type looks like C++
+ type with linkage.  */
+  if (in_lto_p || !TYPE_STUB_DECL (t))
 return false;
-  /* In LTO do not get confused by non-C++ produced types or types built
- with -fno-lto-odr-type-merigng.  */
-  if (in_lto_p)
-{
-  /* To support -fno-lto-odr-type-merigng recognize types with vtables
- to have linkage.  */
-  if (RECORD_OR_UNION_TYPE_P (t)
- && TYPE_BINFO (t) && BINFO_VTABLE (TYPE_BINFO (t)))
-return true;
-  /* With -flto-odr-type-merging C++ FE specify mangled names
-for all types with the linkage.  */
-  return DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (t));
-}
 
   if (!RECORD_OR_UNION_TYPE_P (t) && TREE_CODE (t) != ENUMERAL_TYPE)
 return false;
@@ -214,18 +216,16 @@ type_in_anonymous_namespace_p (const_tre
 {
   gcc_checking_assert (type_with_linkage_p (t));
 
-  if (!TREE_PUBLIC (TYPE_STUB_DECL (t)))
-{
-  /* C++ FE uses magic  as assembler names of anonymous types.
-verify that this match with type_in_anonymous_namespace_p.  */
-  gcc_checking_assert (!in_lto_p
-  || !DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (t))
-  || !strcmp ("",
-  IDENTIFIER_POINTER
-  (DECL_ASSEMBLER_NAME (TYPE_NAME (t);
-  return true;
-}
-  return false;
+  /* free_lang_data clears TYPE_STUB_DECL but sets assembler name to
+ ""  */
+  if (DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (t)))
+return !strcmp ("",
+   IDENTIFIER_POINTER
+   (DECL_ASSEMBLER_NAME (TYPE_NAME (t;
+  else if (!TYPE_STUB_DECL (t))
+return false;
+  else
+return !TREE_PUBLIC (TYPE_STUB_DECL (t));
 }
 
 /* Return true of T is type with One Definition Rule info attached. 
Index: lto-streamer-out.c
===
--- lto-streamer-out.c  (revision 263696)
+++ lto-streamer-out.c  (working copy)
@@ -857,7 +857,7 @@ DFS::DFS_write_tree_body (struct output_
   DFS_follow_tree_edge (TYPE_CONTEXT (expr));
   /* TYPE_CANONICAL is re-computed during type merging, so no need
 to follow it here.  */
-  DFS_follow_tree_edge (TYPE_STUB_DECL (expr));
+  gcc_checking_assert (TYPE_STUB_DECL (expr) == NULL);
 }
 
   if (CODE_CONTAINS_STRUCT (code, TS_TYPE_NON_COMMON))
@@ -1270,7 +1270,6 @@ hash_tree (struct streamer_tree_cache_d
;
   else
visit (TYPE_CONTEXT (t));
-  visit (TYPE_STUB_DECL (t));
 }
 
   if (CODE_CONTAINS_STRUCT (code, TS_TYPE_NON_COMMON))
Index: tree-streamer-in.c
===
--- tree-streamer-in.c  (revision 263696)
+++ tree-streamer-in.c  (working copy)
@@ -820,7 +820,6 @@ lto_input_ts_type_common_tree_pointers (
   TYPE_CONTEXT (expr) = stream_read_tree (ib, data_in);
   /* TYPE_CANONICAL gets re-computed during type merging.  */
   TYPE_CANONICAL (expr) = NULL_TREE;
-  TYPE_STUB_DECL (expr) = stream_read_tree (ib, data_in);
 }
 
 /* Read all pointer fields in the TS_TYPE_NON_COMMON structure of EXPR
Index: tree-streamer-out.c

Re: Walk pointer_to and reference_to chain in free_lang_data

[Jan Hubicka]

> On Thu, 23 Aug 2018, Jan Hubicka wrote:
> 
> > Hi
> > this patch takes care of gcov.  There are two oddities. First that gcov uses
> > langhook to produce new records while asan gets around with make_node.
> > I think both are middle-end types and in the direction of separating 
> > front-ends
> > and middle-ends better the langhooks are not desirable.
> > 
> > The TYPE_STUB_DECL is produced by finish_builtin_struct.  This is function 
> > used
> > just few times but I am not sure if we don't want debug info on some of the
> > builtins, so I have added extra parameter.
> > 
> > config/darwin.c:  finish_builtin_struct (cfstring_type_node, 
> > "__builtin_CFString",
> > config/i386/i386.c:  finish_builtin_struct (type, "__processor_model", 
> > field_chain, NULL_TREE);
> > coverage.c:  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, 
> > NULL_TREE, true);
> > coverage.c:  finish_builtin_struct (type, "__gcov_fn_info", fields, 
> > NULL_TREE, true);
> > coverage.c:  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE, 
> > true);
> > cp/decl.c:  finish_builtin_struct (t, "__ptrmemfunc_type", fields, 
> > ptr_type_node);
> > cp/rtti.c:  finish_builtin_struct (pseudo_type, pseudo_name, fields, 
> > NULL_TREE);
> > hsa-brig.c:  finish_builtin_struct (variable_info_type, 
> > "__hsa_variable_info", id_f2,
> > hsa-brig.c:  finish_builtin_struct (kernel_info_type, "__hsa_kernel_info", 
> > id_f5,
> > hsa-brig.c:  finish_builtin_struct (hsa_image_desc_type, 
> > "__hsa_image_desc", id_f5,
> > hsa-gen.c:  finish_builtin_struct (*hsa_kernel_dispatch_type, 
> > "__hsa_kernel_dispatch",
> > objc/objc-act.c:  /* NB: The finish_builtin_struct() routine expects 
> > FIELD_DECLs in
> > objc/objc-act.c:  finish_builtin_struct (type, "__builtin_ObjCString",
> > omp-expand.c:  finish_builtin_struct 
> > (grid_attr_trees->kernel_launch_attributes_type,
> > stor-layout.c:finish_builtin_struct (tree type, const char *name, tree 
> > fields,
> > stor-layout.h:extern void finish_builtin_struct (tree, const char *, tree, 
> > tree,
> > 
> > Perhaps we could make them all to just use identifier_node
> > but I am honestly not sure :)
> 
> Given finish_builtin_struct uses BUILTINS_LOCATION for the TYPE_DECL
> and dwarf2out.c does
> 
> case TYPE_DECL:
>   /* Don't emit stubs for types unless they are needed by other DIEs.  
> */
>   if (TYPE_DECL_SUPPRESS_DEBUG (decl))
> return;
> 
>   /* Don't bother trying to generate any DIEs to represent any of the
>  normal built-in types for the language we are compiling.  */
>   if (DECL_IS_BUILTIN (decl))
> return;
> 
> making them just all IDENTIFIER_NODE is fine I think.  At least for
> the debuginfo part it shouldn't make any difference ...

OK, that is a good observation :) I will re-test variant of patch doing
identifier pointers.   I am bit concerned about the C++/objc use that may later 
use the type produced with the assumtion that it looks like C++/objc type :)

Honza

Re: Async I/O patch with compilation fix

[David Edelsohn]

Thomas,

After your complaint about bootstrap on gcc119, I tried it again.  My
bootstrap worked correctly.  I used exactly the public instructions.
Others have been able to bootstrap on gcc119.  The problem is local to
you.  Does your environment have any special variables?

You can see the bootstrap in /scratch/dje/GCC

Second, the patch that you applied is unacceptable.  ASYNC_IO already is
set to zero for AIX.  I refuse to accept this patch as correct or complete.

Third, the problem from the beginning has been __gthread_cond_t.  The
earlier patch had

struct adv_cond
{
  int pending;
  __gthread_mutex_t lock;
  __gthread_cond_t signal;
};

with __gthread_cond_t clearly not protected by #if ASYNC_IO.  This is
visible by inspection.  Without a bootstrap, this patch should have been
visually checked that all uses of __gthread_cond_t were protected.

Similarly one can test this / confirm this on any system by setting
ASYNC_IO to 0 and ensuring that __gthread_cond_t is not declared.  This
simply is sloppy work.

Please fix this correctly.  The current kludge is not acceptable.

Thanks, David

On Wed, Aug 22, 2018 at 5:30 PM Thomas Koenig  wrote:

> Hi David,
>
> > This patch broke bootstrap on AIX again.  This is completely
> unacceptable.
>
> Again, sorry for the breakage.
>
> I faced quite some challenges trying to get bootstrap to
> work on gcc119. Despite quite a few e-mails (plus hints in a PR)
> that I received, none of the hints for bootstrap I got actually got
> it to work. I finally gave up after four or five different failures,
> and the patch was committed because every test
> that _could_ be run did show no failure.
>
> Had we received instructions that work for bootstrapping on AIX,
> we would have tested the patch there.
>
> If it were possible to add instructions that do work for AIX
> bootstrapping to the compile farm wiki, that would be great.
>
> If you (or somebody else who has the requisite AIX fu) could test
> patches that are known to be difficult, that would also be
> great.
>
> As long as we have no other solution, it is probably best to #ifdef out
> AIX any additional pthread-related functionality for libgfortran that
> might be coming along. That can always be integrated later, if somebody
> can re-implement POSIX condition variables for libgfortran from what
> AIX provides.
>
> Let's talk about how to proceed at the GNU cauldron, over a beer.
> Both Nicolas and I will be there.
>
> In the meantime, I have committed the following patch (r263788) as
> obvious after regression-testing on Linux both with ASYNC_IO set
> to 1 and to 0.  Let me know how that works out.
>
> 2018-08-22  Thomas Koenig  
>
> * async.h: Set ASYNC_IO to zero if _AIX is defined.
> (struct adv_cond): If ASYNC_IO is zero, the struct has no members.
> (async_unit): If ASYNC_IO is zero, remove unneeded members.
>
> 2018-08-22  Thomas Koenig  
>
> * gfortran.texi: Mention that asynchronous I/O does
> not work on systems which lack condition variables, such
> as AIX.
>
> Regards
>
> Thomas
>

Re: Walk pointer_to and reference_to chain in free_lang_data

[Richard Biener]

On Thu, 23 Aug 2018, Jan Hubicka wrote:

> Hi
> this patch takes care of gcov.  There are two oddities. First that gcov uses
> langhook to produce new records while asan gets around with make_node.
> I think both are middle-end types and in the direction of separating 
> front-ends
> and middle-ends better the langhooks are not desirable.
> 
> The TYPE_STUB_DECL is produced by finish_builtin_struct.  This is function 
> used
> just few times but I am not sure if we don't want debug info on some of the
> builtins, so I have added extra parameter.
> 
> config/darwin.c:  finish_builtin_struct (cfstring_type_node, 
> "__builtin_CFString",
> config/i386/i386.c:  finish_builtin_struct (type, "__processor_model", 
> field_chain, NULL_TREE);
> coverage.c:  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, 
> NULL_TREE, true);
> coverage.c:  finish_builtin_struct (type, "__gcov_fn_info", fields, 
> NULL_TREE, true);
> coverage.c:  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE, 
> true);
> cp/decl.c:  finish_builtin_struct (t, "__ptrmemfunc_type", fields, 
> ptr_type_node);
> cp/rtti.c:  finish_builtin_struct (pseudo_type, pseudo_name, fields, 
> NULL_TREE);
> hsa-brig.c:  finish_builtin_struct (variable_info_type, 
> "__hsa_variable_info", id_f2,
> hsa-brig.c:  finish_builtin_struct (kernel_info_type, "__hsa_kernel_info", 
> id_f5,
> hsa-brig.c:  finish_builtin_struct (hsa_image_desc_type, "__hsa_image_desc", 
> id_f5,
> hsa-gen.c:  finish_builtin_struct (*hsa_kernel_dispatch_type, 
> "__hsa_kernel_dispatch",
> objc/objc-act.c:  /* NB: The finish_builtin_struct() routine expects 
> FIELD_DECLs in
> objc/objc-act.c:  finish_builtin_struct (type, "__builtin_ObjCString",
> omp-expand.c:  finish_builtin_struct 
> (grid_attr_trees->kernel_launch_attributes_type,
> stor-layout.c:finish_builtin_struct (tree type, const char *name, tree fields,
> stor-layout.h:extern void finish_builtin_struct (tree, const char *, tree, 
> tree,
> 
> Perhaps we could make them all to just use identifier_node
> but I am honestly not sure :)

Given finish_builtin_struct uses BUILTINS_LOCATION for the TYPE_DECL
and dwarf2out.c does

case TYPE_DECL:
  /* Don't emit stubs for types unless they are needed by other DIEs.  
*/
  if (TYPE_DECL_SUPPRESS_DEBUG (decl))
return;

  /* Don't bother trying to generate any DIEs to represent any of the
 normal built-in types for the language we are compiling.  */
  if (DECL_IS_BUILTIN (decl))
return;

making them just all IDENTIFIER_NODE is fine I think.  At least for
the debuginfo part it shouldn't make any difference ...

Richard.

> Bootstrapped/regtested x86_64-linux, OK?
> 
> Honza
> 
>   * coverage.c (build_fn_info_type, build_info, coverage_obj_init):
>   Use make_node to build record type and pass true to
>   finish_builtin_struct.
>   * stor-layout.c (finish_record_layout): Add nodebug parameter.
>   * stor-layout.h (finish_builtin_struct): Likewise.
> Index: coverage.c
> ===
> --- coverage.c(revision 263696)
> +++ coverage.c(working copy)
> @@ -780,7 +780,7 @@ build_var (tree fn_decl, tree type, int
>  static void
>  build_fn_info_type (tree type, unsigned counters, tree gcov_info_type)
>  {
> -  tree ctr_info = lang_hooks.types.make_type (RECORD_TYPE);
> +  tree ctr_info = make_node (RECORD_TYPE);
>tree field, fields;
>tree array_type;
>  
> @@ -797,7 +797,7 @@ build_fn_info_type (tree type, unsigned
>DECL_CHAIN (field) = fields;
>fields = field;
>
> -  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, NULL_TREE);
> +  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, NULL_TREE, 
> true);
>  
>/* key */
>field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
> @@ -831,7 +831,7 @@ build_fn_info_type (tree type, unsigned
>DECL_CHAIN (field) = fields;
>fields = field;
>  
> -  finish_builtin_struct (type, "__gcov_fn_info", fields, NULL_TREE);
> +  finish_builtin_struct (type, "__gcov_fn_info", fields, NULL_TREE, true);
>  }
>  
>  /* Returns a CONSTRUCTOR for a gcov_fn_info.  DATA is
> @@ -963,7 +963,7 @@ build_info_type (tree type, tree fn_info
>DECL_CHAIN (field) = fields;
>fields = field;
>  
> -  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE);
> +  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE, true);
>  }
>  
>  /* Returns a CONSTRUCTOR for the gcov_info object.  INFO_TYPE is the
> @@ -1020,8 +1020,6 @@ build_info (tree info_type, tree fn_ary)
> get_identifier (ctr_merge_functions[ix]),
> TREE_TYPE (merge_fn_type));
> DECL_EXTERNAL (merge_fn) = 1;
> -   TREE_PUBLIC (merge_fn) = 1;
> -   DECL_ARTIFICIAL (merge_fn) = 1;
> TREE_NOTHROW (merge_fn) = 1;
> /* Initialize assembler name so we can stream out. */
> 

Re: [PATCH] Fix recent bug in canonicalize_comparison (PR87026)

[Richard Biener]

On Thu, Aug 23, 2018 at 2:05 PM Segher Boessenkool
 wrote:
>
> The new code testing which way a comparison is best expressed creates
> a pseudoregister (by hand) and creates some insns with that.  Such
> insns will no longer recog() when pseudo-registers are no longer
> aloowed (after reload).  But we have an ifcvt pass after reload (ce3).
>
> This patch simply returns if we cannot create pseudos.
>
> Tested on powerpc64-linux {-m32,-m64}.  Is this okay for trunk?

OK.

>
> Segher
>
>
> 2018-08-23  Segher Boessenkool  
>
> PR rtl-optimization/87026
> * expmed.c (canonicalize_comparison): If we can no longer create
> pseudoregisters, don't.
>
> ---
>  gcc/expmed.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/gcc/expmed.c b/gcc/expmed.c
> index e281930..0922029 100644
> --- a/gcc/expmed.c
> +++ b/gcc/expmed.c
> @@ -6243,6 +6243,10 @@ canonicalize_comparison (machine_mode mode, enum 
> rtx_code *code, rtx *imm)
>if (overflow)
>  return;
>
> +  /* The following creates a pseudo; if we cannot do that, bail out.  */
> +  if (!can_create_pseudo_p ())
> +return;
> +
>rtx reg = gen_rtx_REG (mode, LAST_VIRTUAL_REGISTER + 1);
>rtx new_imm = immed_wide_int_const (imm_modif, mode);
>
> --
> 1.8.3.1
>

Re: Walk pointer_to and reference_to chain in free_lang_data

[Jan Hubicka]

Hi
this patch takes care of gcov.  There are two oddities. First that gcov uses
langhook to produce new records while asan gets around with make_node.
I think both are middle-end types and in the direction of separating front-ends
and middle-ends better the langhooks are not desirable.

The TYPE_STUB_DECL is produced by finish_builtin_struct.  This is function used
just few times but I am not sure if we don't want debug info on some of the
builtins, so I have added extra parameter.

config/darwin.c:  finish_builtin_struct (cfstring_type_node, 
"__builtin_CFString",
config/i386/i386.c:  finish_builtin_struct (type, "__processor_model", 
field_chain, NULL_TREE);
coverage.c:  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, 
NULL_TREE, true);
coverage.c:  finish_builtin_struct (type, "__gcov_fn_info", fields, NULL_TREE, 
true);
coverage.c:  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE, 
true);
cp/decl.c:  finish_builtin_struct (t, "__ptrmemfunc_type", fields, 
ptr_type_node);
cp/rtti.c:  finish_builtin_struct (pseudo_type, pseudo_name, fields, NULL_TREE);
hsa-brig.c:  finish_builtin_struct (variable_info_type, "__hsa_variable_info", 
id_f2,
hsa-brig.c:  finish_builtin_struct (kernel_info_type, "__hsa_kernel_info", 
id_f5,
hsa-brig.c:  finish_builtin_struct (hsa_image_desc_type, "__hsa_image_desc", 
id_f5,
hsa-gen.c:  finish_builtin_struct (*hsa_kernel_dispatch_type, 
"__hsa_kernel_dispatch",
objc/objc-act.c:  /* NB: The finish_builtin_struct() routine expects 
FIELD_DECLs in
objc/objc-act.c:  finish_builtin_struct (type, "__builtin_ObjCString",
omp-expand.c:  finish_builtin_struct 
(grid_attr_trees->kernel_launch_attributes_type,
stor-layout.c:finish_builtin_struct (tree type, const char *name, tree fields,
stor-layout.h:extern void finish_builtin_struct (tree, const char *, tree, tree,

Perhaps we could make them all to just use identifier_node
but I am honestly not sure :)

Bootstrapped/regtested x86_64-linux, OK?

Honza

* coverage.c (build_fn_info_type, build_info, coverage_obj_init):
Use make_node to build record type and pass true to
finish_builtin_struct.
* stor-layout.c (finish_record_layout): Add nodebug parameter.
* stor-layout.h (finish_builtin_struct): Likewise.
Index: coverage.c
===
--- coverage.c  (revision 263696)
+++ coverage.c  (working copy)
@@ -780,7 +780,7 @@ build_var (tree fn_decl, tree type, int
 static void
 build_fn_info_type (tree type, unsigned counters, tree gcov_info_type)
 {
-  tree ctr_info = lang_hooks.types.make_type (RECORD_TYPE);
+  tree ctr_info = make_node (RECORD_TYPE);
   tree field, fields;
   tree array_type;
 
@@ -797,7 +797,7 @@ build_fn_info_type (tree type, unsigned
   DECL_CHAIN (field) = fields;
   fields = field;
   
-  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, NULL_TREE);
+  finish_builtin_struct (ctr_info, "__gcov_ctr_info", fields, NULL_TREE, true);
 
   /* key */
   field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
@@ -831,7 +831,7 @@ build_fn_info_type (tree type, unsigned
   DECL_CHAIN (field) = fields;
   fields = field;
 
-  finish_builtin_struct (type, "__gcov_fn_info", fields, NULL_TREE);
+  finish_builtin_struct (type, "__gcov_fn_info", fields, NULL_TREE, true);
 }
 
 /* Returns a CONSTRUCTOR for a gcov_fn_info.  DATA is
@@ -963,7 +963,7 @@ build_info_type (tree type, tree fn_info
   DECL_CHAIN (field) = fields;
   fields = field;
 
-  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE);
+  finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE, true);
 }
 
 /* Returns a CONSTRUCTOR for the gcov_info object.  INFO_TYPE is the
@@ -1020,8 +1020,6 @@ build_info (tree info_type, tree fn_ary)
  get_identifier (ctr_merge_functions[ix]),
  TREE_TYPE (merge_fn_type));
  DECL_EXTERNAL (merge_fn) = 1;
- TREE_PUBLIC (merge_fn) = 1;
- DECL_ARTIFICIAL (merge_fn) = 1;
  TREE_NOTHROW (merge_fn) = 1;
  /* Initialize assembler name so we can stream out. */
  DECL_ASSEMBLER_NAME (merge_fn);
@@ -1140,10 +1138,10 @@ coverage_obj_init (void)
   n_counters++;
   
   /* Build the info and fn_info types.  These are mutually recursive.  */
-  gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
-  gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
+  gcov_info_type = make_node (RECORD_TYPE);
+  gcov_fn_info_type = make_node (RECORD_TYPE);
   build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
-  gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
+  gcov_info_type = make_node (RECORD_TYPE);
   gcov_fn_info_ptr_type = build_pointer_type
 (build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
   build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
Index: stor-layout.c

Re: Walk pointer_to and reference_to chain in free_lang_data

[Richard Biener]

On Thu, 23 Aug 2018, Jan Hubicka wrote:

> > >   tree type_decl = build_decl (input_location, TYPE_DECL, 
> > >   
> > >get_identifier ("__asan_global"), ret);
> > >   
> > >   DECL_IGNORED_P (type_decl) = 1; 
> > >   
> > >   DECL_ARTIFICIAL (type_decl) = 1;
> > >   
> > >   TYPE_FIELDS (ret) = fields[0];  
> > >   
> > >   TYPE_NAME (ret) = type_decl;
> > >   
> > >   TYPE_STUB_DECL (ret) = type_decl;   
> > >   
> > > 
> > > It seems to me that setting TYPE_NAME to identifier node would be easier.
> > 
> > Yeah.  I probably added the DECL_INGORED_P to most of those so indeed
> > type_decls are somewhat pointless.
> 
> OK, I have tried to remove them and it passes bootstrap/regtest x86-64.
> Looks sane?

OK.

Richard.

> Honza
> 
>   * asan.c (asan_global_struct): Turn TYPE_NAME into identifier.
>   (ubsan_get_type_descriptor_type,
>   ubsan_get_source_location_type,
>   ubsan_create_data): Likewise.
> Index: asan.c
> ===
> --- asan.c(revision 263696)
> +++ asan.c(working copy)
> @@ -2515,13 +2515,8 @@ asan_global_struct (void)
>if (i)
>   DECL_CHAIN (fields[i - 1]) = fields[i];
>  }
> -  tree type_decl = build_decl (input_location, TYPE_DECL,
> -get_identifier ("__asan_global"), ret);
> -  DECL_IGNORED_P (type_decl) = 1;
> -  DECL_ARTIFICIAL (type_decl) = 1;
>TYPE_FIELDS (ret) = fields[0];
> -  TYPE_NAME (ret) = type_decl;
> -  TYPE_STUB_DECL (ret) = type_decl;
> +  TYPE_NAME (ret) = get_identifier ("__asan_global");
>layout_type (ret);
>return ret;
>  }
> Index: ubsan.c
> ===
> --- ubsan.c   (revision 263696)
> +++ ubsan.c   (working copy)
> @@ -221,14 +221,8 @@ ubsan_get_type_descriptor_type (void)
>if (i)
>   DECL_CHAIN (fields[i - 1]) = fields[i];
>  }
> -  tree type_decl = build_decl (input_location, TYPE_DECL,
> -get_identifier ("__ubsan_type_descriptor"),
> -ret);
> -  DECL_IGNORED_P (type_decl) = 1;
> -  DECL_ARTIFICIAL (type_decl) = 1;
>TYPE_FIELDS (ret) = fields[0];
> -  TYPE_NAME (ret) = type_decl;
> -  TYPE_STUB_DECL (ret) = type_decl;
> +  TYPE_NAME (ret) = get_identifier ("__ubsan_type_descriptor");
>layout_type (ret);
>ubsan_type_descriptor_type = ret;
>return ret;
> @@ -269,14 +263,8 @@ ubsan_get_source_location_type (void)
>if (i)
>   DECL_CHAIN (fields[i - 1]) = fields[i];
>  }
> -  tree type_decl = build_decl (input_location, TYPE_DECL,
> -get_identifier ("__ubsan_source_location"),
> -ret);
> -  DECL_IGNORED_P (type_decl) = 1;
> -  DECL_ARTIFICIAL (type_decl) = 1;
>TYPE_FIELDS (ret) = fields[0];
> -  TYPE_NAME (ret) = type_decl;
> -  TYPE_STUB_DECL (ret) = type_decl;
> +  TYPE_NAME (ret) = get_identifier ("__ubsan_source_location");
>layout_type (ret);
>ubsan_source_location_type = ret;
>return ret;
> @@ -586,13 +574,8 @@ ubsan_create_data (const char *name, int
>  }
>va_end (args);
>  
> -  tree type_decl = build_decl (input_location, TYPE_DECL,
> -get_identifier (name), ret);
> -  DECL_IGNORED_P (type_decl) = 1;
> -  DECL_ARTIFICIAL (type_decl) = 1;
>TYPE_FIELDS (ret) = fields[0];
> -  TYPE_NAME (ret) = type_decl;
> -  TYPE_STUB_DECL (ret) = type_decl;
> +  TYPE_NAME (ret) = get_identifier (name);
>layout_type (ret);
>  
>/* Now, fill in the type.  */
> 
> 

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

Re: [PATCH] Remove verify_no_unreachable_blocks

[Richard Biener]

On Thu, 23 Aug 2018, Tom de Vries wrote:

> On 08/23/2018 01:18 PM, Richard Biener wrote:
> > This removes verify_no_unreachable_blocks and implements checking
> > for unreachable blocks in inverted_post_order_compute by simply
> > looking if we reach a block without predecessors that is not the
> > entry block.
> > 
> 
> I think that doesn't detect unreachable cyles: say you have blocks A and
> B, and A -> B -> A.

Ah, true.  Bah, I guess I can use some other flag in my pass.

> > This solves a problem I ran into when (ab-)using BB_REACHABLE
> > in a pass and I got comparison failues because of -fchecking vs.
> > -fno-checking.  It also should speed up checking builds.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > 
> > Tom, does this make sense?
> > 
> 
> The intent of the check I added was to verify the assumption stated in
> the comment. I don't know how serious it is if the assumption is violated.

I think if you have reverse-not-reachable blocks (infinite loops w/o
fake exit edges) that are not reachable from entry it will ICE
or loop infintely.

Richard.

> Thanks,
> - Tom
> 
> > Thanks,
> > Richard.
> > 
> > 2018-08-23  Richard Biener  
> > 
> > * cfganal.h (verify_no_unreachable_blocks): Remove.
> > * cfganal.c (verify_no_unreachable_blocks): Likewise.
> > (inverted_post_order_compute): Do not call verify_no_unreachable_blocks
> > instead assert when we reach a block without predecessor that is not
> > the entry block.
> > 
> > diff --git a/gcc/cfganal.c b/gcc/cfganal.c
> > index 3b80758e8f2..baf9f0562f9 100644
> > --- a/gcc/cfganal.c
> > +++ b/gcc/cfganal.c
> > @@ -186,18 +186,6 @@ find_unreachable_blocks (void)
> >free (worklist);
> >  }
> >  
> > -/* Verify that there are no unreachable blocks in the current function.  */
> > -
> > -void
> > -verify_no_unreachable_blocks (void)
> > -{
> > -  find_unreachable_blocks ();
> > -
> > -  basic_block bb;
> > -  FOR_EACH_BB_FN (bb, cfun)
> > -gcc_assert ((bb->flags & BB_REACHABLE) != 0);
> > -}
> > -
> >  
> >  /* Functions to access an edge list with a vector representation.
> > Enough data is kept such that given an index number, the
> > @@ -800,9 +788,6 @@ inverted_post_order_compute (vec *post_order,
> >basic_block bb;
> >post_order->reserve_exact (n_basic_blocks_for_fn (cfun));
> >  
> > -  if (flag_checking)
> > -verify_no_unreachable_blocks ();
> > -
> >/* Allocate stack for back-tracking up CFG.  */
> >auto_vec stack (n_basic_blocks_for_fn (cfun) + 1);
> >  
> > @@ -866,7 +851,10 @@ inverted_post_order_compute (vec *post_order,
> > time, check its predecessors.  */
> > stack.quick_push (ei_start (pred->preds));
> >else
> > -   post_order->quick_push (pred->index);
> > +   {
> > + gcc_assert (pred->index == ENTRY_BLOCK);
> > + post_order->quick_push (pred->index);
> > +   }
> >  }
> >else
> >  {
> > diff --git a/gcc/cfganal.h b/gcc/cfganal.h
> > index 122c665f7f6..ac3fe8f4617 100644
> > --- a/gcc/cfganal.h
> > +++ b/gcc/cfganal.h
> > @@ -50,7 +50,6 @@ private:
> >  
> >  extern bool mark_dfs_back_edges (void);
> >  extern void find_unreachable_blocks (void);
> > -extern void verify_no_unreachable_blocks (void);
> >  struct edge_list * create_edge_list (void);
> >  void free_edge_list (struct edge_list *);
> >  void print_edge_list (FILE *, struct edge_list *);
> > 
> 
> 

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

[PATCH] Fix recent bug in canonicalize_comparison (PR87026)

[Segher Boessenkool]

The new code testing which way a comparison is best expressed creates
a pseudoregister (by hand) and creates some insns with that.  Such
insns will no longer recog() when pseudo-registers are no longer
aloowed (after reload).  But we have an ifcvt pass after reload (ce3).

This patch simply returns if we cannot create pseudos.

Tested on powerpc64-linux {-m32,-m64}.  Is this okay for trunk?


Segher


2018-08-23  Segher Boessenkool  

PR rtl-optimization/87026
* expmed.c (canonicalize_comparison): If we can no longer create
pseudoregisters, don't.

---
 gcc/expmed.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/expmed.c b/gcc/expmed.c
index e281930..0922029 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -6243,6 +6243,10 @@ canonicalize_comparison (machine_mode mode, enum 
rtx_code *code, rtx *imm)
   if (overflow)
 return;
 
+  /* The following creates a pseudo; if we cannot do that, bail out.  */
+  if (!can_create_pseudo_p ())
+return;
+
   rtx reg = gen_rtx_REG (mode, LAST_VIRTUAL_REGISTER + 1);
   rtx new_imm = immed_wide_int_const (imm_modif, mode);
 
-- 
1.8.3.1

Re: Walk pointer_to and reference_to chain in free_lang_data

[Jan Hubicka]

> >   tree type_decl = build_decl (input_location, TYPE_DECL,   
> > 
> >get_identifier ("__asan_global"), ret);  
> > 
> >   DECL_IGNORED_P (type_decl) = 1;   
> > 
> >   DECL_ARTIFICIAL (type_decl) = 1;  
> > 
> >   TYPE_FIELDS (ret) = fields[0];
> > 
> >   TYPE_NAME (ret) = type_decl;  
> > 
> >   TYPE_STUB_DECL (ret) = type_decl; 
> > 
> > 
> > It seems to me that setting TYPE_NAME to identifier node would be easier.
> 
> Yeah.  I probably added the DECL_INGORED_P to most of those so indeed
> type_decls are somewhat pointless.

OK, I have tried to remove them and it passes bootstrap/regtest x86-64.
Looks sane?

Honza

* asan.c (asan_global_struct): Turn TYPE_NAME into identifier.
(ubsan_get_type_descriptor_type,
ubsan_get_source_location_type,
ubsan_create_data): Likewise.
Index: asan.c
===
--- asan.c  (revision 263696)
+++ asan.c  (working copy)
@@ -2515,13 +2515,8 @@ asan_global_struct (void)
   if (i)
DECL_CHAIN (fields[i - 1]) = fields[i];
 }
-  tree type_decl = build_decl (input_location, TYPE_DECL,
-  get_identifier ("__asan_global"), ret);
-  DECL_IGNORED_P (type_decl) = 1;
-  DECL_ARTIFICIAL (type_decl) = 1;
   TYPE_FIELDS (ret) = fields[0];
-  TYPE_NAME (ret) = type_decl;
-  TYPE_STUB_DECL (ret) = type_decl;
+  TYPE_NAME (ret) = get_identifier ("__asan_global");
   layout_type (ret);
   return ret;
 }
Index: ubsan.c
===
--- ubsan.c (revision 263696)
+++ ubsan.c (working copy)
@@ -221,14 +221,8 @@ ubsan_get_type_descriptor_type (void)
   if (i)
DECL_CHAIN (fields[i - 1]) = fields[i];
 }
-  tree type_decl = build_decl (input_location, TYPE_DECL,
-  get_identifier ("__ubsan_type_descriptor"),
-  ret);
-  DECL_IGNORED_P (type_decl) = 1;
-  DECL_ARTIFICIAL (type_decl) = 1;
   TYPE_FIELDS (ret) = fields[0];
-  TYPE_NAME (ret) = type_decl;
-  TYPE_STUB_DECL (ret) = type_decl;
+  TYPE_NAME (ret) = get_identifier ("__ubsan_type_descriptor");
   layout_type (ret);
   ubsan_type_descriptor_type = ret;
   return ret;
@@ -269,14 +263,8 @@ ubsan_get_source_location_type (void)
   if (i)
DECL_CHAIN (fields[i - 1]) = fields[i];
 }
-  tree type_decl = build_decl (input_location, TYPE_DECL,
-  get_identifier ("__ubsan_source_location"),
-  ret);
-  DECL_IGNORED_P (type_decl) = 1;
-  DECL_ARTIFICIAL (type_decl) = 1;
   TYPE_FIELDS (ret) = fields[0];
-  TYPE_NAME (ret) = type_decl;
-  TYPE_STUB_DECL (ret) = type_decl;
+  TYPE_NAME (ret) = get_identifier ("__ubsan_source_location");
   layout_type (ret);
   ubsan_source_location_type = ret;
   return ret;
@@ -586,13 +574,8 @@ ubsan_create_data (const char *name, int
 }
   va_end (args);
 
-  tree type_decl = build_decl (input_location, TYPE_DECL,
-  get_identifier (name), ret);
-  DECL_IGNORED_P (type_decl) = 1;
-  DECL_ARTIFICIAL (type_decl) = 1;
   TYPE_FIELDS (ret) = fields[0];
-  TYPE_NAME (ret) = type_decl;
-  TYPE_STUB_DECL (ret) = type_decl;
+  TYPE_NAME (ret) = get_identifier (name);
   layout_type (ret);
 
   /* Now, fill in the type.  */

Re: C++ PATCH for c++/87029, Implement -Wredundant-move

[Jason Merrill]

On Thu, Aug 23, 2018 at 12:12 PM, Marek Polacek  wrote:
> Now that we have -Wpessimizing-move implemented, it was fairly easy to extend
> it to -Wredundant-move, which warns about redundant calls to std::move; it's
> supposed to detect cases where the compiler is obliged to treat an object as
> if it were an rvalue, so calling std::move is pointless.  Since we implement
> Core Issue 1579, it warns in more situations than clang++.  I described this
> in more detail in the manual entry.
>
> David, I've also tweaked the warning to use fix-it hints; the point is to turn
>
>   return std::move (x);
>
> into
>
>   return x;
>
> I didn't fool around with looking for the locations of the parens; I've used a
> DECL_NAME hack instead.  I've verified it using -fdiagnostics-generate-patch,
> which produces e.g.:
>
> @@ -27,7 +27,7 @@
>  f ()
>  {
>T foo;
> -  return std::move (foo);
> +  return foo;
>  }
>
> g++.dg/diagnostic/move1.C tests the fix-it hints for -Wredundant-move and
> -Wpessimizing-move.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-08-22  Marek Polacek  
>
> PR c++/87029, Implement -Wredundant-move.
> * c.opt (Wredundant-move): New option.
>
> * typeck.c (maybe_warn_pessimizing_move): Call convert_from_reference.
> Warn about redundant moves.  Use fix-it hints.
>
> * doc/invoke.texi: Document -Wredundant-move.
>
> * g++.dg/cpp0x/Wredundant-move1.C: New test.
> * g++.dg/cpp0x/Wredundant-move2.C: New test.
> * g++.dg/cpp0x/Wredundant-move3.C: New test.
> * g++.dg/cpp0x/Wredundant-move4.C: New test.
> * g++.dg/diagnostic/move1.C: New test.
>
> diff --git gcc/c-family/c.opt gcc/c-family/c.opt
> index 76840dd77ad..a92be089b40 100644
> --- gcc/c-family/c.opt
> +++ gcc/c-family/c.opt
> @@ -985,6 +985,10 @@ Wredundant-decls
>  C ObjC C++ ObjC++ Var(warn_redundant_decls) Warning
>  Warn about multiple declarations of the same object.
>
> +Wredundant-move
> +C++ ObjC++ Var(warn_redundant_move) Warning LangEnabledBy(C++ ObjC++, Wall)
> +Warn about redundant calls to std::move.

I don't think this belongs in -Wall, since the code is only redundant,
not wrong.

>  Wregister
>  C++ ObjC++ Var(warn_register) Warning
>  Warn about uses of register storage specifier.
> diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> index 122d9dcd4b3..3f0b263525e 100644
> --- gcc/cp/typeck.c
> +++ gcc/cp/typeck.c
> @@ -9185,7 +9185,7 @@ can_do_nrvo_p (tree retval, tree functype)
>  static void
>  maybe_warn_pessimizing_move (tree retval, tree functype)
>  {
> -  if (!warn_pessimizing_move)
> +  if (!(warn_pessimizing_move || warn_redundant_move))
>  return;
>
>/* C++98 doesn't know move.  */
> @@ -9207,14 +9207,31 @@ maybe_warn_pessimizing_move (tree retval, tree 
> functype)
>   STRIP_NOPS (arg);
>   if (TREE_CODE (arg) == ADDR_EXPR)
> arg = TREE_OPERAND (arg, 0);
> + arg = convert_from_reference (arg);
>   /* Warn if we could do copy elision were it not for the move.  */
>   if (can_do_nrvo_p (arg, functype))
> {
>   auto_diagnostic_group d;
> - if (warning_at (location_of (retval), OPT_Wpessimizing_move,
> - "moving a local object in a return statement "
> - "prevents copy elision"))
> -   inform (location_of (retval), "remove % call");
> + gcc_rich_location richloc (location_of (retval));
> + tree name = DECL_NAME (arg);
> + richloc.add_fixit_replace (IDENTIFIER_POINTER (name));
> + warning_at (, OPT_Wpessimizing_move,
> + "moving a local object in a return statement "
> + "prevents copy elision");
> +   }
> + /* Warn if the move is redundant.  It is redundant when we would
> +do maybe-rvalue overload resolution even without std::move.  */
> + else if (((VAR_P (arg) && !DECL_HAS_VALUE_EXPR_P (arg))
> +   || TREE_CODE (arg) == PARM_DECL)
> +  && DECL_CONTEXT (arg) == current_function_decl
> +  && !TREE_STATIC (arg))

This condition should be shared with check_return_expr rather than copied.

> +   {
> + auto_diagnostic_group d;
> + gcc_rich_location richloc (location_of (retval));
> + tree name = DECL_NAME (arg);
> + richloc.add_fixit_replace (IDENTIFIER_POINTER (name));
> + warning_at (, OPT_Wredundant_move,
> + "redundant move in return statement");
> }
> }
>  }
> diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
> index e4148297a87..341499f49b7 100644
> --- gcc/doc/invoke.texi
> +++ gcc/doc/invoke.texi
> @@ -231,7 +231,7 @@ in the following sections.
>  -Wdelete-non-virtual-dtor -Wdeprecated-copy  -Wliteral-suffix @gol
>  -Wmultiple-inheritance @gol
>  -Wnamespaces  

Re: [PATCH] Use more DECL_BUILT_IN_P macro.

[Richard Biener]

On Thu, Aug 23, 2018 at 12:46 PM Martin Liška  wrote:
>
> On 08/20/2018 10:34 AM, Richard Biener wrote:
> > On Wed, Aug 15, 2018 at 2:52 PM Martin Liška  wrote:
> >>
> >> On 08/14/2018 06:02 PM, Martin Sebor wrote:
> >>> On 08/14/2018 03:06 AM, Martin Liška wrote:
>  Hi.
> 
>  The patch adds more usages of the new macro. I hope it improves
>  readability of code.
> >>>
> >>> I think it does :)  I see that most invocations of it in your
> >>> patch are with BUILT_IN_NORMAL as the second argument.  Is
> >>> the argument implied by the last argument?  E.g., in
> >>>
> >>>   DECL_BUILT_IN_P (fndecl, BUILT_IN_NORMAL, BUILT_IN_VA_ARG_PACK)
> >>>
> >>> is there a way to determine that BUILT_IN_VA_ARG_PACK implies
> >>> DECL_BUILT_IN_CLASS(fndecl), so that the second argument could
> >>> be eliminated?  (Both to make the invocation less verbose and
> >>> to avoid the mistake of using the macro with the wrong class.)
> >>
> >> If I see correctly not, there are separate enums:
> >>
> >> BUILT_IN_MD:
> >>
> >> enum ix86_builtins {
> >>   IX86_BUILTIN_MASKMOVQ,
> >>   IX86_BUILTIN_LDMXCSR,
> >>   IX86_BUILTIN_STMXCSR,
> >> ...
> >> }
> >>
> >> BUILT_IN_NORMAL:
> >> enum built_in_function {
> >> BUILT_IN_NONE,
> >> BUILT_IN_ACOS,
> >> BUILT_IN_ACOSF,
> >> ...
> >> }
> >>
> >> So the enum values overlap and thus one needs the class.
> >>
> >>
> >>>
> >>> If not, adding DECL_NORMAL_BUILT_IN_P() would make it possible
> >>> to omit it.
> >>
> >> But yes, this is nice idea, I'm sending V2 of the patch that I'm testing
> >> right now.
> >
> > Ick, and now we have DECL_IS_BUILTIN, DECL_BUILT_IN, DECL_BUILT_IN_P
> > and DECL_NORMAL_BUILT_IN_P ... (esp the first one is confusing).
>
> Agree.
>
> >
> > I think following what gimple.h does would be nicer which means using
> > inline functions and overloading.
> >
> > decl_built_in_p (tree);
> > decl_built_in_p (tree, enum built_in_class);
> > decl_built_in_p (tree, enum built_in_function); /// implies BUILT_IN_NORMAL
>
> Yes, that's easier to use!
>
> >
> > Can you rework things this way please?  (ok, for gimple those are not 
> > inlines)
>
> Done in patch that can bootstrap and survives regression tests.
> Ready for trunk?

+/* For a FUNCTION_DECL NODE, nonzero means a built in function of a
+   standard library or more generally a built in function that is
+   recognized by optimizers and expanders.
+
+   Note that it is different from the DECL_IS_BUILTIN accessor.  For
+   instance, user declared prototypes of C library functions are not
+   DECL_IS_BUILTIN but may be DECL_BUILT_IN.  */
+
+inline bool
+decl_built_in_p (const_tree node)
+{
+  return (node != NULL_TREE
+ && TREE_CODE (node) == FUNCTION_DECL

You document for a FUNCTION_DECL NODE but the check
for FUNCTION_DECL anyway.  I realize doing all (possibly redundant)
checks in decl_built_in_p is convenient at callers, but at least update
docs accordingly?  In reality I somewhat prefer

inline bool
decl_built_in_p (const_tree node)
{
  return DECL_BUILT_IN_CLASS (node) != NOT_BUILT_IN;
}

and

inline bool
decl_built_in_p (const_tree node, built_in_class klass)
{
  return DECL_BUILT_IN_CLASS (node) == klass;
}

esp. since the built_in_class overload doesn't work for
NOT_BUILT_IN for your variant.

And if we're at changing, maybe call the functions
fndecl_built_in_p to make it clear we're expecting FUNCTION_DECLs...

+/* For a FUNCTION_DECL NODE, return true when a function is
+   a built-in of class KLASS with name equal to NAME.  */
+
+inline bool
+decl_built_in_p (const_tree node, int name,

why's that 'int' and not built_in_function?

+built_in_class klass = BUILT_IN_NORMAL)

This deviates from the gimple.h routines as well (also builtin vs. built_in, but
built_in is better).

+{
+  return (decl_built_in_p (node, klass) && DECL_FUNCTION_CODE (node) == name);
+}


> Martin
>
> >
> > Thanks,
> > Richard.
> >
> >> Martin
> >>
> >>>
> >>> Martin
> >>>
> 
>  Patch can bootstrap on ppc64le-redhat-linux and survives regression 
>  tests.
> 
>  Ready to be installed?
>  Martin
> 
>  gcc/ChangeLog:
> 
>  2018-08-10  Martin Liska  
> 
>  * tree.h (DECL_BUILT_IN_P): Add also check
>  for TREE_CODE (NODE) == FUNCTION_DECL.
>  * builtins.c (fold_call_expr): Use DECL_BUILT_IN_P macro.
>  (fold_builtin_call_array): Likewise.
>  * cgraph.c (cgraph_update_edges_for_call_stmt_node): Likewise.
>  (cgraph_edge::verify_corresponds_to_fndecl): Likewise.
>  (cgraph_node::verify_node): Likewise.
>  * cgraphclones.c (cgraph_node::create_clone): Likewise.
>  * dse.c (scan_insn): Likewise.
>  * fold-const.c (fold_binary_loc): Likewise.
>  * gimple-pretty-print.c (dump_gimple_call): Likewise.
>  * gimple.c (gimple_call_builtin_p): Likewise.
>  * gimplify.c (gimplify_call_expr): Likewise.
>  (gimple_boolify): Likewise.
>  

Re: Allow target to emit LTO early debug to a separate LTO file.

[Iain Sandoe]

> On 23 Aug 2018, at 12:37, Richard Biener  wrote:
> 
> On Thu, Aug 23, 2018 at 1:19 PM Tom de Vries  wrote:
>> 
>> On 08/22/2018 10:09 PM, Iain Sandoe wrote:
>>> Hi Tom, Richi,
>>> 
>>> This is something I was experimenting with to try and solve platform 
>>> problems with early debug.
>>> 
>>> Not a “finished patch”
>> 
>> Hmm, not a building patch either.
>> 
>>> (I’ve removed the Darwin back-end parts) but would like your comments on 
>>> the central idea.
>>> 
>>> This is to switch to the alternate LTO file (this process already exists 
>>> for the actual LTO output)
>> 
>> It took me a while to realize that you're talking about darwin here,
>> specifically the lto_start/end hooks.
>> 
>>> before the early debug is started and switch back to the regular output 
>>> file after.  Therefore both the LTO early debug and the LTO streamed data 
>>> end up in a separate file (this can be concatenated as we do now, 
>>> guaranteeing that it appears after any referenced symbols, or could be 
>>> handled in “some other way” if that was a useful solution).
>>> 
>>> Now the second part of this delays the output of the .file directives until 
>>> the “regular” output of the asm (it could be that this could be simplified 
>>> now there there’s a start/end function pair).
>>> 
>>> The idea is that the main output text is identical with/without the early 
>>> debug (and, in fact, it’s broken without this change - since the .file 
>>> directives would end up in the separate LTO stream).
>>> 
>>> thoughts?
>>> Iain
>>> 
>> 
>> I found it hard to understand the above with something concrete to look
>> at. So I've written attach patch (targeted for my regular x86_64 linux
>> development platform) that adds comments in the assembly when
>> transitioning from one generation phase to another.
>> 
>> So, the effect of the patch on vla-1.c -flto -g is:
>> ...
>> $ diff -I '\.section' -I '\.byte' -u 1 2
>> --- 1   2018-08-23 12:24:37.426659159 +0200
>> +++ 2   2018-08-23 12:26:46.886658665 +0200
>> @@ -1,6 +1,6 @@
>>.file   "vla-1.c"
>> +# LTO_START
>> # DWARF2OUT_EARLY_FINISH START
>> -   .file 1
>> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
>>.section.gnu.debuglto_.debug_info,"e",@progbits
>> .Ldebug_info0:
>>.hidden vla_1.c.1d3f9cc3
>> @@ -330,15 +330,8 @@
>>.byte   0
>>.byte   0
>>.byte   0x1
>> -   .ascii
>> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/gual"
>> -   .ascii  "ity"
>>.byte   0
>>.byte   0
>> -   .string "vla-1.c"
>> -   .uleb128 0x1
>> -   .uleb128 0
>> -   .uleb128 0
>> -   .byte   0
>> .LELTP0:
>> .LELT0:
>>.section.gnu.debuglto_.debug_str,"eMS",@progbits,1
>> @@ -358,8 +351,9 @@
>>.string
>> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
>>.text
>> # DWARF2OUT_EARLY_FINISH END
>> +# LTO_END
>> # LTO_START
>> -   .section.gnu.lto_.profile.b9a985e7cc2d09b4,"e",@progbits
>> +   .section.gnu.lto_.profile.922c9ad53427823c,"e",@progbits
>>.string "x\234\343\004b\006"
>>.string ""
>>.string "V"
>> @@ -635,6 +629,7 @@
>>.type   bar, @function
>> bar:
>> .LFB0:
>> +   .file 1
>> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
>>.loc 1 7 1
>>.cfi_startproc
>> .LVL0:
>> ...
>> 
>> So, emitting the dwarf2 .file ALAP looks ok to me, and I think that can
>> be a separate patch. I wonder though if you really need a separate state
>> variable delay_emit_file to track this, and if you can't use
>> early_dwarf/early_dwarf_finished.
>> 
>> As for adding lto_start/end around dwarf2out_early_finish, the lto_start
>> hook is defined as:
>> ...
>> Output to asm_out_file any text which the assembler expects to find at
>> the start of an LTO section.
>> ...
>> 
>> Looking at the current implementation of this hook, adding this new call
>> pair shouldn't hurt, but perhaps we want to clarify in the documentation
>> that the "LTO section" can also be a debug LTO section?
> 
> I think we should adjust the documentation since they now called multiple
> times, bracketing LTO section output.  So targets implementing the hook
> would need to take care of keeping track of whether it's the first call
> to lto_begin.

Thanks for looking at this, apologies my question was phrased badly
 (I was trying to make sure that it was conceptually sound, i.e that the
FAT portion of the asm output could be handled distinctly from the LTO).

It seemed to make sense, since the LTO stuff can stand alone.

This is still experimental; it’s not clear if it will provide a mechanism to 
solve the problems, but your suggestions are noted and I’ll incorporate
in my next update.

thanks
Iain

Re: [PATCH] Remove verify_no_unreachable_blocks

[Tom de Vries]

On 08/23/2018 01:18 PM, Richard Biener wrote:
> This removes verify_no_unreachable_blocks and implements checking
> for unreachable blocks in inverted_post_order_compute by simply
> looking if we reach a block without predecessors that is not the
> entry block.
> 

I think that doesn't detect unreachable cyles: say you have blocks A and
B, and A -> B -> A.

> This solves a problem I ran into when (ab-)using BB_REACHABLE
> in a pass and I got comparison failues because of -fchecking vs.
> -fno-checking.  It also should speed up checking builds.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> Tom, does this make sense?
> 

The intent of the check I added was to verify the assumption stated in
the comment. I don't know how serious it is if the assumption is violated.

Thanks,
- Tom

> Thanks,
> Richard.
> 
> 2018-08-23  Richard Biener  
> 
>   * cfganal.h (verify_no_unreachable_blocks): Remove.
>   * cfganal.c (verify_no_unreachable_blocks): Likewise.
>   (inverted_post_order_compute): Do not call verify_no_unreachable_blocks
>   instead assert when we reach a block without predecessor that is not
>   the entry block.
> 
> diff --git a/gcc/cfganal.c b/gcc/cfganal.c
> index 3b80758e8f2..baf9f0562f9 100644
> --- a/gcc/cfganal.c
> +++ b/gcc/cfganal.c
> @@ -186,18 +186,6 @@ find_unreachable_blocks (void)
>free (worklist);
>  }
>  
> -/* Verify that there are no unreachable blocks in the current function.  */
> -
> -void
> -verify_no_unreachable_blocks (void)
> -{
> -  find_unreachable_blocks ();
> -
> -  basic_block bb;
> -  FOR_EACH_BB_FN (bb, cfun)
> -gcc_assert ((bb->flags & BB_REACHABLE) != 0);
> -}
> -
>  
>  /* Functions to access an edge list with a vector representation.
> Enough data is kept such that given an index number, the
> @@ -800,9 +788,6 @@ inverted_post_order_compute (vec *post_order,
>basic_block bb;
>post_order->reserve_exact (n_basic_blocks_for_fn (cfun));
>  
> -  if (flag_checking)
> -verify_no_unreachable_blocks ();
> -
>/* Allocate stack for back-tracking up CFG.  */
>auto_vec stack (n_basic_blocks_for_fn (cfun) + 1);
>  
> @@ -866,7 +851,10 @@ inverted_post_order_compute (vec *post_order,
> time, check its predecessors.  */
>   stack.quick_push (ei_start (pred->preds));
>else
> - post_order->quick_push (pred->index);
> + {
> +   gcc_assert (pred->index == ENTRY_BLOCK);
> +   post_order->quick_push (pred->index);
> + }
>  }
>else
>  {
> diff --git a/gcc/cfganal.h b/gcc/cfganal.h
> index 122c665f7f6..ac3fe8f4617 100644
> --- a/gcc/cfganal.h
> +++ b/gcc/cfganal.h
> @@ -50,7 +50,6 @@ private:
>  
>  extern bool mark_dfs_back_edges (void);
>  extern void find_unreachable_blocks (void);
> -extern void verify_no_unreachable_blocks (void);
>  struct edge_list * create_edge_list (void);
>  void free_edge_list (struct edge_list *);
>  void print_edge_list (FILE *, struct edge_list *);
> 

Re: [PATCH] Remove verify_no_unreachable_blocks

[Richard Biener]

On Thu, 23 Aug 2018, Steven Bosscher wrote:

> On Thu, Aug 23, 2018 at 1:18 PM Richard Biener <> wrote:
> > -/* Verify that there are no unreachable blocks in the current function.  */
> > -
> > -void
> > -verify_no_unreachable_blocks (void)
> > -{
> > -  find_unreachable_blocks ();
> > -
> > -  basic_block bb;
> > -  FOR_EACH_BB_FN (bb, cfun)
> > -gcc_assert ((bb->flags & BB_REACHABLE) != 0);
> 
> Alternatively, just clear BB_REACHABLE here?

That doesn't help me of course since I need BB_REACHABLE to be
preserved ;)

>   FOR_EACH_BB_FN (bb, cfun)
> {
>   gcc_assert ((bb->flags & BB_REACHABLE) != 0);
>   bb->flags &= ~BB_REACHABLE;
> }
> 
> The function is quite useful for debugging, I wouldn't remove it.

I certainly can keep it (unused).

Richard.

Re: Allow target to emit LTO early debug to a separate LTO file.

[Richard Biener]

On Thu, Aug 23, 2018 at 1:19 PM Tom de Vries  wrote:
>
> On 08/22/2018 10:09 PM, Iain Sandoe wrote:
> > Hi Tom, Richi,
> >
> > This is something I was experimenting with to try and solve platform 
> > problems with early debug.
> >
> > Not a “finished patch”
>
> Hmm, not a building patch either.
>
> > (I’ve removed the Darwin back-end parts) but would like your comments on 
> > the central idea.
> >
> > This is to switch to the alternate LTO file (this process already exists 
> > for the actual LTO output)
>
> It took me a while to realize that you're talking about darwin here,
> specifically the lto_start/end hooks.
>
> > before the early debug is started and switch back to the regular output 
> > file after.  Therefore both the LTO early debug and the LTO streamed data 
> > end up in a separate file (this can be concatenated as we do now, 
> > guaranteeing that it appears after any referenced symbols, or could be 
> > handled in “some other way” if that was a useful solution).
> >
> > Now the second part of this delays the output of the .file directives until 
> > the “regular” output of the asm (it could be that this could be simplified 
> > now there there’s a start/end function pair).
> >
> > The idea is that the main output text is identical with/without the early 
> > debug (and, in fact, it’s broken without this change - since the .file 
> > directives would end up in the separate LTO stream).
> >
> > thoughts?
> > Iain
> >
>
> I found it hard to understand the above with something concrete to look
> at. So I've written attach patch (targeted for my regular x86_64 linux
> development platform) that adds comments in the assembly when
> transitioning from one generation phase to another.
>
> So, the effect of the patch on vla-1.c -flto -g is:
> ...
> $ diff -I '\.section' -I '\.byte' -u 1 2
> --- 1   2018-08-23 12:24:37.426659159 +0200
> +++ 2   2018-08-23 12:26:46.886658665 +0200
> @@ -1,6 +1,6 @@
> .file   "vla-1.c"
> +# LTO_START
>  # DWARF2OUT_EARLY_FINISH START
> -   .file 1
> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
> .section.gnu.debuglto_.debug_info,"e",@progbits
>  .Ldebug_info0:
> .hidden vla_1.c.1d3f9cc3
> @@ -330,15 +330,8 @@
> .byte   0
> .byte   0
> .byte   0x1
> -   .ascii
> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/gual"
> -   .ascii  "ity"
> .byte   0
> .byte   0
> -   .string "vla-1.c"
> -   .uleb128 0x1
> -   .uleb128 0
> -   .uleb128 0
> -   .byte   0
>  .LELTP0:
>  .LELT0:
> .section.gnu.debuglto_.debug_str,"eMS",@progbits,1
> @@ -358,8 +351,9 @@
> .string
> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
> .text
>  # DWARF2OUT_EARLY_FINISH END
> +# LTO_END
>  # LTO_START
> -   .section.gnu.lto_.profile.b9a985e7cc2d09b4,"e",@progbits
> +   .section.gnu.lto_.profile.922c9ad53427823c,"e",@progbits
> .string "x\234\343\004b\006"
> .string ""
> .string "V"
> @@ -635,6 +629,7 @@
> .type   bar, @function
>  bar:
>  .LFB0:
> +   .file 1
> "/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
> .loc 1 7 1
> .cfi_startproc
>  .LVL0:
> ...
>
> So, emitting the dwarf2 .file ALAP looks ok to me, and I think that can
> be a separate patch. I wonder though if you really need a separate state
> variable delay_emit_file to track this, and if you can't use
> early_dwarf/early_dwarf_finished.
>
> As for adding lto_start/end around dwarf2out_early_finish, the lto_start
> hook is defined as:
> ...
> Output to asm_out_file any text which the assembler expects to find at
> the start of an LTO section.
> ...
>
> Looking at the current implementation of this hook, adding this new call
> pair shouldn't hurt, but perhaps we want to clarify in the documentation
> that the "LTO section" can also be a debug LTO section?

I think we should adjust the documentation since they now called multiple
times, bracketing LTO section output.  So targets implementing the hook
would need to take care of keeping track of whether it's the first call
to lto_begin.

Richard.

>
> Thanks,
> - Tom

Re: [PATCH] Remove verify_no_unreachable_blocks

[Steven Bosscher]

On Thu, Aug 23, 2018 at 1:18 PM Richard Biener <> wrote:
> -/* Verify that there are no unreachable blocks in the current function.  */
> -
> -void
> -verify_no_unreachable_blocks (void)
> -{
> -  find_unreachable_blocks ();
> -
> -  basic_block bb;
> -  FOR_EACH_BB_FN (bb, cfun)
> -gcc_assert ((bb->flags & BB_REACHABLE) != 0);

Alternatively, just clear BB_REACHABLE here?

  FOR_EACH_BB_FN (bb, cfun)
{
  gcc_assert ((bb->flags & BB_REACHABLE) != 0);
  bb->flags &= ~BB_REACHABLE;
}

The function is quite useful for debugging, I wouldn't remove it.

Ciao!
Steven

Re: [PATCH] Skip tests that depend on the cxx11 std::string

[Jonathan Wakely]

On 23/08/18 11:52 +0100, Jonathan Wakely wrote:

On 23/08/18 10:03 +0100, Jonathan Wakely wrote:

On 23/08/18 09:24 +0100, Jonathan Wakely wrote:

--- a/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
@@ -17,6 +17,7 @@
//

// { dg-do run { target c++11 } }
+// { dg-require-effective-target cxx11-abi }


Actually I shouldn't have added it here. It only depends on the new
string when compiled with _GLIBCXX_DEBUG, and that should be fixed in
__gnu_debug::string not by skipping the test.


Like so.


And one more tweak, for C++98 mode.

Tested x86_64-linux, committed to trunk.


commit e2fdd7cb9553a4430d04089db0849737a88bddee
Author: Jonathan Wakely 
Date:   Thu Aug 23 12:20:55 2018 +0100

Fix C++11-ism in C++98 member function

* include/debug/string (insert(__const_iterator, _InIter, _InIter)):
[!_GLIBCXX_USE_CXX11_ABI]: Replace use of C++11-only cbegin() with
begin(), for C++98 compatibility.

diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index d330bfd5a3f..ca190fa6528 100644
--- a/libstdc++-v3/include/debug/string
+++ b/libstdc++-v3/include/debug/string
@@ -642,7 +642,7 @@ namespace __gnu_debug
 	  else
 	__res = _Base::insert(__p.base(), __first, __last);
 #else
-	  const size_type __offset = __p.base() - _Base::cbegin();
+	  const size_type __offset = __p.base() - _Base::begin();
 	  _Base::insert(__p.base(), __first, __last);
 	  __res = _Base::begin() + __offset;
 #endif

Re: patch to bug #86829

[Giuliano Augusto Faulin Belinassi]

>
> Ah, a runtime test.  That'd be sufficient.  The cost when we can't do
> the transformation is relatively small, but the gains when we can are huge.

Thank you. I will update the patch and send it again :-)

On Wed, Aug 22, 2018 at 7:05 PM, Jeff Law  wrote:
> On 08/22/2018 06:02 AM, Richard Biener wrote:
>> On Tue, Aug 21, 2018 at 11:27 PM Jeff Law  wrote:
>>>
>>> On 08/21/2018 02:08 PM, Giuliano Augusto Faulin Belinassi wrote:
> Just as an example, compare the results for
> x = 0x1.fp1023

 Thank you for your answer and the counterexample. :-)

> If we had useful range info on floats we might conditionalize such
> transforms appropriately.  Or we can enable it on floats and do
> the sqrt (x*x + 1) in double.

 I think I managed to find a bound were the transformation can be done
 without overflow harm, however I don't know about rounding problems,
 however

 Suppose we are handling double precision floats for now. The function
 x/sqrt(1 + x*x) approaches 1 when x is big enough. How big must be x
 for the function be 1?

 Since sqrt(1 + x*x) > x when x > 1, then we must find a value to x
 that x/sqrt(1 + x*x) < eps, where eps is the biggest double smaller
 than 1. Such eps must be around 1 - 2^-53 in ieee double because the
 mantissa has 52 bits. Solving for x yields that x must be somewhat
 bigger than 6.7e7, so let's take 1e8. Therefore if abs(x) > 1e8, it is
 enough to return copysign(1, x). Notice that this arguments is also
 valid for x = +-inf (if target supports that) because sin(atan(+-inf))
 = +-1, and it can be extended to other floating point formats.The
 following test code illustrates my point:
 https://pastebin.com/M4G4neLQ

 This might still be faster than calculating sin(atan(x)) explicitly.

 Please let me know if this is unfeasible. :-)
>>> The problem is our VRP implementation doesn't handle any floating point
>>> types at this time.   If we had range information for FP types, then
>>> this kind of analysis is precisely what we'd need to do the
>>> transformation regardless of -ffast-math.
>>
>> I think his idea was to emit a runtime test?  You'd have to use a
>> COND_EXPR and evaluate both arms at the same time because
>> match.pd doesn't allow you to create control flow.
>>
>> Note the rounding issue is also real given for large x you strip
>> away lower mantissa bits when computing x*x.
> Ah, a runtime test.  That'd be sufficient.  The cost when we can't do
> the transformation is relatively small, but the gains when we can are huge.
>
> Jeff

Re: Allow target to emit LTO early debug to a separate LTO file.

[Tom de Vries]

On 08/22/2018 10:09 PM, Iain Sandoe wrote:
> Hi Tom, Richi,
> 
> This is something I was experimenting with to try and solve platform problems 
> with early debug.
> 
> Not a “finished patch” 

Hmm, not a building patch either.

> (I’ve removed the Darwin back-end parts) but would like your comments on the 
> central idea.
> 
> This is to switch to the alternate LTO file (this process already exists for 
> the actual LTO output)

It took me a while to realize that you're talking about darwin here,
specifically the lto_start/end hooks.

> before the early debug is started and switch back to the regular output file 
> after.  Therefore both the LTO early debug and the LTO streamed data end up 
> in a separate file (this can be concatenated as we do now, guaranteeing that 
> it appears after any referenced symbols, or could be handled in “some other 
> way” if that was a useful solution).
> 
> Now the second part of this delays the output of the .file directives until 
> the “regular” output of the asm (it could be that this could be simplified 
> now there there’s a start/end function pair).
> 
> The idea is that the main output text is identical with/without the early 
> debug (and, in fact, it’s broken without this change - since the .file 
> directives would end up in the separate LTO stream).
> 
> thoughts?
> Iain
> 

I found it hard to understand the above with something concrete to look
at. So I've written attach patch (targeted for my regular x86_64 linux
development platform) that adds comments in the assembly when
transitioning from one generation phase to another.

So, the effect of the patch on vla-1.c -flto -g is:
...
$ diff -I '\.section' -I '\.byte' -u 1 2
--- 1   2018-08-23 12:24:37.426659159 +0200
+++ 2   2018-08-23 12:26:46.886658665 +0200
@@ -1,6 +1,6 @@
.file   "vla-1.c"
+# LTO_START
 # DWARF2OUT_EARLY_FINISH START
-   .file 1
"/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
.section.gnu.debuglto_.debug_info,"e",@progbits
 .Ldebug_info0:
.hidden vla_1.c.1d3f9cc3
@@ -330,15 +330,8 @@
.byte   0
.byte   0
.byte   0x1
-   .ascii
"/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/gual"
-   .ascii  "ity"
.byte   0
.byte   0
-   .string "vla-1.c"
-   .uleb128 0x1
-   .uleb128 0
-   .uleb128 0
-   .byte   0
 .LELTP0:
 .LELT0:
.section.gnu.debuglto_.debug_str,"eMS",@progbits,1
@@ -358,8 +351,9 @@
.string
"/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
.text
 # DWARF2OUT_EARLY_FINISH END
+# LTO_END
 # LTO_START
-   .section.gnu.lto_.profile.b9a985e7cc2d09b4,"e",@progbits
+   .section.gnu.lto_.profile.922c9ad53427823c,"e",@progbits
.string "x\234\343\004b\006"
.string ""
.string "V"
@@ -635,6 +629,7 @@
.type   bar, @function
 bar:
 .LFB0:
+   .file 1
"/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c"
.loc 1 7 1
.cfi_startproc
 .LVL0:
...

So, emitting the dwarf2 .file ALAP looks ok to me, and I think that can
be a separate patch. I wonder though if you really need a separate state
variable delay_emit_file to track this, and if you can't use
early_dwarf/early_dwarf_finished.

As for adding lto_start/end around dwarf2out_early_finish, the lto_start
hook is defined as:
...
Output to asm_out_file any text which the assembler expects to find at
the start of an LTO section.
...

Looking at the current implementation of this hook, adding this new call
pair shouldn't hurt, but perhaps we want to clarify in the documentation
that the "LTO section" can also be a debug LTO section?

Thanks,
- Tom
Add comments in .s file describing generation phases

---
 gcc/dwarf2out.c | 13 -
 gcc/hooks.c | 15 +++
 gcc/hooks.h |  2 ++
 gcc/target.def  |  4 ++--
 4 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index fb71ff349fa..334f9a3a901 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -31114,6 +31114,7 @@ reset_dies (dw_die_ref die)
 static void
 dwarf2out_finish (const char *filename)
 {
+  fprintf (asm_out_file, "%s DWARF2OUT_FINISH START\n", ASM_COMMENT_START);
   comdat_type_node *ctnode;
   dw_die_ref main_comp_unit_die;
   unsigned char checksum[16];
@@ -31565,6 +31566,7 @@ dwarf2out_finish (const char *filename)
   symview_upper_bound = 0;
   if (zero_view_p)
 bitmap_clear (zero_view_p);
+  fprintf (asm_out_file, "%s DWARF2OUT_FINISH END\n", ASM_COMMENT_START);
 }
 
 /* Returns a hash value for X (which really is a variable_value_struct).  */
@@ -31845,6 +31847,8 @@ note_variable_value (dw_die_ref die)
 static void
 dwarf2out_early_finish (const char *filename)
 {
+  fprintf (asm_out_file, "%s DWARF2OUT_EARLY_FINISH START\n",
+	   ASM_COMMENT_START);
   set_early_dwarf s;
   char dl_section_ref[MAX_ARTIFICIAL_LABEL_BYTES];
 
@@ -31899,6 

[PATCH] Remove verify_no_unreachable_blocks

[Richard Biener]

This removes verify_no_unreachable_blocks and implements checking
for unreachable blocks in inverted_post_order_compute by simply
looking if we reach a block without predecessors that is not the
entry block.

This solves a problem I ran into when (ab-)using BB_REACHABLE
in a pass and I got comparison failues because of -fchecking vs.
-fno-checking.  It also should speed up checking builds.

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

Tom, does this make sense?

Thanks,
Richard.

2018-08-23  Richard Biener  

* cfganal.h (verify_no_unreachable_blocks): Remove.
* cfganal.c (verify_no_unreachable_blocks): Likewise.
(inverted_post_order_compute): Do not call verify_no_unreachable_blocks
instead assert when we reach a block without predecessor that is not
the entry block.

diff --git a/gcc/cfganal.c b/gcc/cfganal.c
index 3b80758e8f2..baf9f0562f9 100644
--- a/gcc/cfganal.c
+++ b/gcc/cfganal.c
@@ -186,18 +186,6 @@ find_unreachable_blocks (void)
   free (worklist);
 }
 
-/* Verify that there are no unreachable blocks in the current function.  */
-
-void
-verify_no_unreachable_blocks (void)
-{
-  find_unreachable_blocks ();
-
-  basic_block bb;
-  FOR_EACH_BB_FN (bb, cfun)
-gcc_assert ((bb->flags & BB_REACHABLE) != 0);
-}
-
 
 /* Functions to access an edge list with a vector representation.
Enough data is kept such that given an index number, the
@@ -800,9 +788,6 @@ inverted_post_order_compute (vec *post_order,
   basic_block bb;
   post_order->reserve_exact (n_basic_blocks_for_fn (cfun));
 
-  if (flag_checking)
-verify_no_unreachable_blocks ();
-
   /* Allocate stack for back-tracking up CFG.  */
   auto_vec stack (n_basic_blocks_for_fn (cfun) + 1);
 
@@ -866,7 +851,10 @@ inverted_post_order_compute (vec *post_order,
time, check its predecessors.  */
stack.quick_push (ei_start (pred->preds));
   else
-   post_order->quick_push (pred->index);
+   {
+ gcc_assert (pred->index == ENTRY_BLOCK);
+ post_order->quick_push (pred->index);
+   }
 }
   else
 {
diff --git a/gcc/cfganal.h b/gcc/cfganal.h
index 122c665f7f6..ac3fe8f4617 100644
--- a/gcc/cfganal.h
+++ b/gcc/cfganal.h
@@ -50,7 +50,6 @@ private:
 
 extern bool mark_dfs_back_edges (void);
 extern void find_unreachable_blocks (void);
-extern void verify_no_unreachable_blocks (void);
 struct edge_list * create_edge_list (void);
 void free_edge_list (struct edge_list *);
 void print_edge_list (FILE *, struct edge_list *);

Re: Allow target to emit LTO early debug to a separate LTO file.

[Richard Biener]

On Wed, Aug 22, 2018 at 10:09 PM Iain Sandoe  wrote:
>
> Hi Tom, Richi,
>
> This is something I was experimenting with to try and solve platform problems 
> with early debug.
>
> Not a “finished patch” (I’ve removed the Darwin back-end parts) but would 
> like your comments on the central idea.
>
> This is to switch to the alternate LTO file (this process already exists for 
> the actual LTO output) before the early debug is started and switch back to 
> the regular output file after.  Therefore both the LTO early debug and the 
> LTO streamed data end up in a separate file (this can be concatenated as we 
> do now, guaranteeing that it appears after any referenced symbols, or could 
> be handled in “some other way” if that was a useful solution).
>
> Now the second part of this delays the output of the .file directives until 
> the “regular” output of the asm (it could be that this could be simplified 
> now there there’s a start/end function pair).
>
> The idea is that the main output text is identical with/without the early 
> debug (and, in fact, it’s broken without this change - since the .file 
> directives would end up in the separate LTO stream).
>
> thoughts?

Hmm, I wonder how we build the file table for the LTO early debug
when output_asm_line_debug_info () is true.  I guess that's
completely broken right now?  But IIRC I verified it "works" ...

Re-checking it looks like for early LTO debug we're not relying
on the assembler somehow but for the FAT part we do.

Otherwise the patch makes sense for those targets that need
to use that separate temporary file thing.

Note I think it would be cleaner to stick that lto_start/end around
the block actually emitting the debug info in dwarf2out_early_finish.

I'd also initialize delay_emit_file to true and only clear it in
dwarf2out_early_finish.  Or clear it in dwarf2out_finish only?

Richard.

> Iain
>
>
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index ec490d75bd..1a7db6c353 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -2777,11 +2777,14 @@ symbol_table::finalize_compilation_unit (void)
>FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (cnode)
> (*debug_hooks->early_global_decl) (cnode->decl);
>
> + targetm.asm_out.lto_start ();
>/* Clean up anything that needs cleaning up after initial debug
>  generation.  */
>debuginfo_early_start ();
>(*debug_hooks->early_finish) (main_input_filename);
> +
>debuginfo_early_stop ();
> +  targetm.asm_out.lto_end ();
>  }
>
>/* Finally drive the pass manager.  */
>
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 74a5926524..5f166b7f42 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -3600,6 +3600,9 @@ static GTY(()) unsigned int poc_label_num;
>  /* The last file entry emitted by maybe_emit_file().  */
>  static GTY(()) struct dwarf_file_data * last_emitted_file;
>
> +/* Don't emit the .file directives for early debug.  */
> +static bool delay_emit_file = false;
> +
>  /* Number of internal labels generated by gen_internal_sym().  */
>  static GTY(()) int label_num;
>
> @@ -26939,7 +26942,7 @@ lookup_filename (const char *file_name)
>  static int
>  maybe_emit_file (struct dwarf_file_data * fd)
>  {
> -  if (! fd->emitted_number)
> +  if (! fd->emitted_number && ! delay_emit_file)
>  {
>if (last_emitted_file)
> fd->emitted_number = last_emitted_file->emitted_number + 1;
> @@ -31866,6 +31869,7 @@ dwarf2out_early_finish (const char *filename)
>set_early_dwarf s;
>char dl_section_ref[MAX_ARTIFICIAL_LABEL_BYTES];
>
> +  delay_emit_file = true;
>/* PCH might result in DW_AT_producer string being restored from the
>   header compilation, so always fill it with empty string initially
>   and overwrite only here.  */
> @@ -31917,6 +31921,7 @@ dwarf2out_early_finish (const char *filename)
>   fprintf (dump_file, "LTO EARLY DWARF for %s\n", filename);
>   print_die (comp_unit_die (), dump_file);
> }
> +  delay_emit_file = false;
>return;
>  }
>
> @@ -32006,7 +32011,11 @@ dwarf2out_early_finish (const char *filename)
>  copy_lto_debug_sections operation of the simple object support in
>  libiberty is not implemented for them yet.  */
>|| TARGET_PECOFF || TARGET_COFF)
> -return;
> +  || TARGET_PECOFF)
> +{
> +  delay_emit_file = false;
> +  return;
> +}
>
>/* Now as we are going to output for LTO initialize sections and labels
>   to the LTO variants.  We don't need a random-seed postfix as other
> @@ -32128,6 +32137,8 @@ dwarf2out_early_finish (const char *filename)
> output_indirect_string> (form);
>  }
>
> +  delay_emit_file = false;
> +
>/* Switch back to the text section.  */
>switch_to_section (text_section);
>  }
> --
> 2.17.1
>
>
>

Re: [PATCH] Print default options selection for -march,-mcpu and -mtune for aarch64 (PR driver/83193).

[Martin Liška]

PING^1

On 08/02/2018 11:46 AM, Martin Liška wrote:
> On 08/02/2018 11:39 AM, Richard Earnshaw (lists) wrote:
>> On 18/07/18 16:48, Martin Liška wrote:
>>> Hi.
>>>
>>> This is aarch64 fix for PR83193. It's about setting of default options
>>> so that --help=target -Q prints proper numbers:
>>>
>>> Now this is seen on my cross-compiler:
>>>
>>> --- /home/marxin/Downloads/options-2-before.txt 2018-07-18 
>>> 14:53:11.658146543 +0200
>>> +++ /home/marxin/Downloads/options-2.txt2018-07-18 14:52:30.113274284 
>>> +0200
>>> @@ -1,10 +1,10 @@
>>>  The following options are target specific:
>>>-mabi=ABIlp64
>>> -  -march=ARCH  
>>> +  -march=  armv8-a
>>
>> So we have
>>
>> -mabi=ABIlp64
>>
>> but
>>
>> -march=  armv8-a
>>^ blank
>>
>> Isn't that inconsistent?
> 
> It is probably, in this case I would remove 'ABI' from -mabi option. It's 
> explained bellow
> what are possible options:
> 
>   Known AArch64 ABIs (for use with the -mabi= option):
> ilp32 lp64
> 
> Similarly for:
>   -moverride=STRING   Power users only! Override CPU optimization 
> parameters.
>   -msve-vector-bits=N Set the number of bits in an SVE vector 
> register to N.
> 
> It's more common to  notation, there are some samples from --help=common:
> 
>   -fmax-errors=   Maximum number of errors to report.
>   -fmessage-length=   Limit diagnostics to  characters per 
> line.  0 suppresses line-wrapping.
>   -fira-region=[one|all|mixed] Set regions for IRA.
>   -fira-verbose=  Control IRA's level of diagnostic messages.
>   -flifetime-dse=<0,2>This option lacks documentation.
>   -fstack-limit-register= Trap if the stack goes past .
>   -fstack-limit-symbol= Trap if the stack goes past symbol .
> 
> Are you fine with the suggested approach?
> 
> Martin
> 
>>
>> R.
>>
>>>-mbig-endian [disabled]
>>>-mbionic [disabled]
>>>-mcmodel=small
>>> -  -mcpu=CPU
>>> +  -mcpu=   generic
>>>-mfix-cortex-a53-835769  [enabled]
>>>-mfix-cortex-a53-843419  [enabled]
>>>-mgeneral-regs-only  [disabled]
>>> @@ -19,7 +19,7 @@
>>>-msve-vector-bits=N  scalable
>>>-mtls-dialect=   desc
>>>-mtls-size=  24
>>> -  -mtune=CPU   
>>> +  -mtune=  generic
>>>-muclibc [disabled]
>>>
>>> May I please ask ARM folks to test the patch?
>>> Thanks,
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> 2018-07-18  Martin Liska  
>>>
>>> PR driver/83193
>>> * config/aarch64/aarch64.c (aarch64_override_options_internal):
>>> Set default values for x_aarch64_*_string strings.
>>> * config/aarch64/aarch64.opt: Remove --{march,mcpu,mtune}==
>>> prefix.
>>> ---
>>>  gcc/config/aarch64/aarch64.c   | 7 +++
>>>  gcc/config/aarch64/aarch64.opt | 6 +++---
>>>  2 files changed, 10 insertions(+), 3 deletions(-)
>>>
>>>
>>>
>>> 0001-Print-default-options-selection-for-march-mcpu-and-m.patch
>>>
>>>
>>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>>> index 6fa03e4b091..d48e6278efa 100644
>>> --- a/gcc/config/aarch64/aarch64.c
>>> +++ b/gcc/config/aarch64/aarch64.c
>>> @@ -10713,6 +10713,13 @@ aarch64_override_options_internal (struct 
>>> gcc_options *opts)
>>>&& opts->x_optimize >= 
>>> aarch64_tune_params.prefetch->default_opt_level)
>>>  opts->x_flag_prefetch_loop_arrays = 1;
>>>  
>>> +  if (opts->x_aarch64_arch_string == NULL)
>>> +opts->x_aarch64_arch_string = selected_arch->name;
>>> +  if (opts->x_aarch64_cpu_string == NULL)
>>> +opts->x_aarch64_cpu_string = selected_cpu->name;
>>> +  if (opts->x_aarch64_tune_string == NULL)
>>> +opts->x_aarch64_tune_string = selected_tune->name;
>>> +
>>>aarch64_override_options_after_change_1 (opts);
>>>  }
>>>  
>>> diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
>>> index 1426b45ff0f..7f0b65de37b 100644
>>> --- a/gcc/config/aarch64/aarch64.opt
>>> +++ b/gcc/config/aarch64/aarch64.opt
>>> @@ -117,15 +117,15 @@ Enum(aarch64_tls_size) String(48) Value(48)
>>>  
>>>  march=
>>>  Target RejectNegative ToLower Joined Var(aarch64_arch_string)
>>> --march=ARCHUse features of architecture ARCH.
>>> +Use features of architecture ARCH.
>>>  
>>>  mcpu=
>>>  Target RejectNegative ToLower Joined Var(aarch64_cpu_string)
>>> --mcpu=CPU  Use features of and optimize for CPU.
>>> +Use features of and optimize for CPU.
>>>  
>>>  mtune=
>>>  Target RejectNegative ToLower Joined Var(aarch64_tune_string)
>>> --mtune=CPU Optimize 

Re: [PATCH] Provide extension hint for aarch64 target (PR driver/83193).

[Martin Liška]

PING^2

On 08/01/2018 03:56 PM, Martin Liška wrote:
> PING^1
> 
> On 07/18/2018 05:49 PM, Martin Liška wrote:
>> Hi.
>>
>> This patch improves aarch64 feature modifier hints.
>>
>> May I please ask ARM folks to test the patch?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-07-18  Martin Liska  
>>
>> PR driver/83193
>>  * common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
>> Set invalid_extension when there's any.
>>  (aarch64_get_all_extension_candidates): New function.
>>  (aarch64_rewrite_selected_cpu): Pass NULL as new argument.
>>  * config/aarch64/aarch64-protos.h 
>> (aarch64_get_all_extension_candidates):
>> Declare new function.
>>  * config/aarch64/aarch64.c (aarch64_parse_arch): Record
>> invalid_feature.
>>  (aarch64_parse_cpu): Likewise.
>>  (aarch64_print_hint_for_feature_modifier): New.
>>  (aarch64_validate_mcpu): Record invalid feature modifier
>> and print hint for it.
>>  (aarch64_validate_march): Likewise.
>>  (aarch64_handle_attr_arch): Likewise.
>>  (aarch64_handle_attr_cpu): Likewise.
>>  (aarch64_handle_attr_isa_flags): Likewise.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-07-18  Martin Liska  
>>
>> PR driver/83193
>>  * gcc.target/aarch64/spellcheck_7.c: New test.
>>  * gcc.target/aarch64/spellcheck_8.c: New test.
>> ---
>>  gcc/common/config/aarch64/aarch64-common.c| 20 +-
>>  gcc/config/aarch64/aarch64-protos.h   |  4 +-
>>  gcc/config/aarch64/aarch64.c  | 67 +++
>>  .../gcc.target/aarch64/spellcheck_7.c | 11 +++
>>  .../gcc.target/aarch64/spellcheck_8.c | 12 
>>  5 files changed, 97 insertions(+), 17 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_7.c
>>  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_8.c
>>
>>
> 

Re: [PATCH] Skip tests that depend on the cxx11 std::string

[Jonathan Wakely]

On 23/08/18 10:03 +0100, Jonathan Wakely wrote:

On 23/08/18 09:24 +0100, Jonathan Wakely wrote:

--- a/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
@@ -17,6 +17,7 @@
//

// { dg-do run { target c++11 } }
+// { dg-require-effective-target cxx11-abi }


Actually I shouldn't have added it here. It only depends on the new
string when compiled with _GLIBCXX_DEBUG, and that should be fixed in
__gnu_debug::string not by skipping the test.


Like so.

Tested x86_64-linux, committed to trunk.


commit eaf0a58cf22a0164001560efc5f7f966bf8ac6ca
Author: Jonathan Wakely 
Date:   Thu Aug 23 11:26:05 2018 +0100

Fix testsuite failures for __gnu_debug::string with old ABI

The __gnu_debug string (mostly) implements the C++11 API, but when it
wraps the old COW string many of the member functions in the base class
have the wrong parameter types or return types. This makes the
__gnu_debug::string type adapt itself to the base class API. This
actually makes the debug string slightly more conforming than the
underlying string type when using the old ABI.

* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::__const_iterator): Change access to protected.
[!_GLIBCXX_USE_CXX11_ABI] (basic_string::__const_iterator): Define
as typedef for iterator.
* include/debug/string (__const_iterator): Use typedef from base.
(insert(const_iterator, _CharT))
(replace(const_iterator, const_iterator, const basic_string&))
(replace(const_iterator, const_iterator, const _CharT*, size_type))
(replace(const_iterator, const_iterator, const CharT*))
(replace(const_iterator, const_iterator, size_type, _CharT))
(replace(const_iterator, const_iterator, _InputIter, _InputIter))
(replace(const_iterator, const_iterator, initializer_list<_CharT>)):
Change const_iterator parameters to __const_iterator.
(insert(iterator, size_type, _CharT)): Add C++98 overload.
(insert(const_iterator, _InputIterator, _InputIterator)): Change
const_iterator parameter to __const_iterator.
[!_GLIBCXX_USE_CXX11_ABI]: Add workaround for incorrect return type
of base's member function.
(insert(const_iterator, size_type, _CharT)) [!_GLIBCXX_USE_CXX11_ABI]:
Likewise.
(insert(const_iterator, initializer_list<_CharT>))
[!_GLIBCXX_USE_CXX11_ABI]: Likewise.
* testsuite/21_strings/basic_string/init-list.cc: Remove effective
target directive.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index c9463989ddc..ba94b51f616 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -100,7 +100,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   ///  Value returned by various member functions when they fail.
   static const size_type	npos = static_cast(-1);
 
-private:
+protected:
   // type used for positions in insert, erase etc.
 #if __cplusplus < 201103L
   typedef iterator __const_iterator;
@@ -108,6 +108,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   typedef const_iterator __const_iterator;
 #endif
 
+private:
 #if __cplusplus > 201402L
   // A helper type for avoiding boiler-plate.
   typedef basic_string_view<_CharT, _Traits> __sv_type;
@@ -3119,6 +3120,10 @@ _GLIBCXX_END_NAMESPACE_CXX11
   typedef std::reverse_iterator	const_reverse_iterator;
   typedef std::reverse_iterator		reverse_iterator;
 
+protected:
+  // type used for positions in insert, erase etc.
+  typedef iterator __const_iterator;
+
 private:
   // _Rep: string representation
   //   Invariants:
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index 1883cac2fbb..d330bfd5a3f 100644
--- a/libstdc++-v3/include/debug/string
+++ b/libstdc++-v3/include/debug/string
@@ -97,6 +97,10 @@ namespace __gnu_debug
   template
 	friend class ::__gnu_debug::_Safe_iterator;
 
+  // type used for positions in insert, erase etc.
+  typedef __gnu_debug::_Safe_iterator<
+	typename _Base::__const_iterator, basic_string> __const_iterator;
+
 public:
   // types:
   typedef _Traits	traits_type;
@@ -589,7 +593,7 @@ namespace __gnu_debug
   }
 
   iterator
-  insert(const_iterator __p, _CharT __c)
+  insert(__const_iterator __p, _CharT __c)
   {
 	__glibcxx_check_insert(__p);
 	typename _Base::iterator __res = _Base::insert(__p.base(), __c);
@@ -597,29 +601,51 @@ namespace __gnu_debug
 	return iterator(__res, this);
   }
 
+#if __cplusplus >= 201103L
   iterator
   insert(const_iterator __p, size_type __n, _CharT __c)
   {
 	__glibcxx_check_insert(__p);
+#if _GLIBCXX_USE_CXX11_ABI
 	

Re: [PATCH] Use more DECL_BUILT_IN_P macro.

[Martin Liška]

On 08/20/2018 10:34 AM, Richard Biener wrote:
> On Wed, Aug 15, 2018 at 2:52 PM Martin Liška  wrote:
>>
>> On 08/14/2018 06:02 PM, Martin Sebor wrote:
>>> On 08/14/2018 03:06 AM, Martin Liška wrote:
 Hi.

 The patch adds more usages of the new macro. I hope it improves
 readability of code.
>>>
>>> I think it does :)  I see that most invocations of it in your
>>> patch are with BUILT_IN_NORMAL as the second argument.  Is
>>> the argument implied by the last argument?  E.g., in
>>>
>>>   DECL_BUILT_IN_P (fndecl, BUILT_IN_NORMAL, BUILT_IN_VA_ARG_PACK)
>>>
>>> is there a way to determine that BUILT_IN_VA_ARG_PACK implies
>>> DECL_BUILT_IN_CLASS(fndecl), so that the second argument could
>>> be eliminated?  (Both to make the invocation less verbose and
>>> to avoid the mistake of using the macro with the wrong class.)
>>
>> If I see correctly not, there are separate enums:
>>
>> BUILT_IN_MD:
>>
>> enum ix86_builtins {
>>   IX86_BUILTIN_MASKMOVQ,
>>   IX86_BUILTIN_LDMXCSR,
>>   IX86_BUILTIN_STMXCSR,
>> ...
>> }
>>
>> BUILT_IN_NORMAL:
>> enum built_in_function {
>> BUILT_IN_NONE,
>> BUILT_IN_ACOS,
>> BUILT_IN_ACOSF,
>> ...
>> }
>>
>> So the enum values overlap and thus one needs the class.
>>
>>
>>>
>>> If not, adding DECL_NORMAL_BUILT_IN_P() would make it possible
>>> to omit it.
>>
>> But yes, this is nice idea, I'm sending V2 of the patch that I'm testing
>> right now.
> 
> Ick, and now we have DECL_IS_BUILTIN, DECL_BUILT_IN, DECL_BUILT_IN_P
> and DECL_NORMAL_BUILT_IN_P ... (esp the first one is confusing).

Agree.

> 
> I think following what gimple.h does would be nicer which means using
> inline functions and overloading.
> 
> decl_built_in_p (tree);
> decl_built_in_p (tree, enum built_in_class);
> decl_built_in_p (tree, enum built_in_function); /// implies BUILT_IN_NORMAL

Yes, that's easier to use!

> 
> Can you rework things this way please?  (ok, for gimple those are not inlines)

Done in patch that can bootstrap and survives regression tests.
Ready for trunk?

Martin 

> 
> Thanks,
> Richard.
> 
>> Martin
>>
>>>
>>> Martin
>>>

 Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

 Ready to be installed?
 Martin

 gcc/ChangeLog:

 2018-08-10  Martin Liska  

 * tree.h (DECL_BUILT_IN_P): Add also check
 for TREE_CODE (NODE) == FUNCTION_DECL.
 * builtins.c (fold_call_expr): Use DECL_BUILT_IN_P macro.
 (fold_builtin_call_array): Likewise.
 * cgraph.c (cgraph_update_edges_for_call_stmt_node): Likewise.
 (cgraph_edge::verify_corresponds_to_fndecl): Likewise.
 (cgraph_node::verify_node): Likewise.
 * cgraphclones.c (cgraph_node::create_clone): Likewise.
 * dse.c (scan_insn): Likewise.
 * fold-const.c (fold_binary_loc): Likewise.
 * gimple-pretty-print.c (dump_gimple_call): Likewise.
 * gimple.c (gimple_call_builtin_p): Likewise.
 * gimplify.c (gimplify_call_expr): Likewise.
 (gimple_boolify): Likewise.
 (gimplify_modify_expr): Likewise.
 * ipa-fnsummary.c (compute_fn_summary): Likewise.
 * omp-low.c (setjmp_or_longjmp_p): Likewise.
 * trans-mem.c (is_tm_irrevocable): Likewise.
 (is_tm_abort): Likewise.
 * tree-cfg.c (stmt_can_terminate_bb_p): Likewise.
 * tree-inline.c (copy_bb): Likewise.
 * tree-sra.c (scan_function): Likewise.
 * tree-ssa-ccp.c (optimize_stack_restore): Likewise.
 (pass_fold_builtins::execute): Likewise.
 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Likewise.
 * tree-ssa-loop-im.c (stmt_cost): Likewise.
 * tree-stdarg.c (optimize_va_list_gpr_fpr_size): Likewise.

 gcc/c/ChangeLog:

 2018-08-10  Martin Liska  

 * c-parser.c (c_parser_postfix_expression_after_primary):
 Use DECL_BUILT_IN_P macro.

 gcc/cp/ChangeLog:

 2018-08-10  Martin Liska  

 * constexpr.c (constexpr_fn_retval): Use DECL_BUILT_IN_P macro.
 (cxx_eval_builtin_function_call): Likewise.
 * cp-gimplify.c (cp_gimplify_expr): Likewise.
 (cp_fold): Likewise.
 * semantics.c (finish_call_expr): Likewise.
 * tree.c (builtin_valid_in_constant_expr_p): Likewise.
 ---
  gcc/builtins.c| 10 ++
  gcc/c/c-parser.c  |  9 +++--
  gcc/cgraph.c  | 13 ++---
  gcc/cgraphclones.c|  4 ++--
  gcc/cp/constexpr.c| 12 +---
  gcc/cp/cp-gimplify.c  | 12 
  gcc/cp/semantics.c|  4 +---
  gcc/cp/tree.c |  5 ++---
  gcc/dse.c |  5 ++---
  gcc/fold-const.c  |  4 +---
  gcc/gimple-pretty-print.c |  4 +---
  gcc/gimple.c  |  3 +--
  gcc/gimplify.c| 14 --
  gcc/ipa-fnsummary.c   |  8 
  gcc/omp-low.c  

Re: [PATCH][RFC] Add gimple-cfg.h.

[Martin Liška]

On 08/21/2018 03:55 PM, Richard Biener wrote:
> On Tue, Aug 21, 2018 at 2:58 PM Martin Liška  wrote:
>>
>> Hi.
>>
>> I'm considering adding couple of new gimple-related functions that
>> are related to gswitch statement.
>>
>> Is it a good idea?
> 
> Just add them to tree-cfg.h?  That's what should be really called
> gimple-cfg.h these days...

Yes, done in the patch. I actually added 2 more functions:

extern basic_block gimple_switch_bb (gswitch *gs, unsigned index);
extern basic_block gimple_switch_default_bb (gswitch *gs);

and I clean up the implementation. Apart from that I noticed
label_to_block_fn can be removed as all callers use cfun as argument.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
> 
> Richard.
> 
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-08-06  Martin Liska  
>>
>> * gimple-cfg.h: New file.
>> * ipa-fnsummary.c (set_switch_stmt_execution_predicate):
>> Use gimple_switch_edge (and gimple_switch_default_edge).
>> * tree-switch-conversion.c (switch_conversion::collect): Likewise.
>> (switch_decision_tree::compute_cases_per_edge): Likewise.
>> (switch_decision_tree::analyze_switch_statement): Likewise.
>> (switch_decision_tree::try_switch_expansion): Likewise.
>> ---
>>  gcc/gimple-cfg.h | 44 
>>  gcc/ipa-fnsummary.c  |  7 +++---
>>  gcc/tree-switch-conversion.c | 38 ---
>>  3 files changed, 62 insertions(+), 27 deletions(-)
>>  create mode 100644 gcc/gimple-cfg.h
>>
>>

>From e59865447c1f19988bc0c6db05d8d4ba78d6785e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 3 Aug 2018 14:54:32 +0200
Subject: [PATCH] Add new gswitch related functions into tree-cfg.c.

gcc/ChangeLog:

2018-08-23  Martin Liska  

	* cfgexpand.c (expand_asm_stmt): Use label_to_block
instead of label_to_block_fn.
	* hsa-gen.c (gen_hsa_insns_for_switch_stmt): Use new
function gimple_switch_default_bb.
	(convert_switch_statements): Use cfun directly and
use label_to_block.
	(expand_builtins): Use cfun directly.
	* ipa-fnsummary.c (set_switch_stmt_execution_predicate):
Use new function gimple_switch_edge.
	* stmt.c (label_to_block_fn): Remove declaration.
	(expand_case): Use label_to_block.
	* tree-cfg.c (make_gimple_switch_edges): Use new
function gimple_switch_bb.
	(label_to_block_fn): Remove.
	(label_to_block): Replace implementation done
in label_to_block_fn.
	(group_case_labels_stmt): Use gimple_switch_default_bb.
	(gimple_verify_flow_info): Use gimple_switch_bb.
	(gimple_switch_bb): New.
	(gimple_switch_default_bb): Likewise.
	(gimple_switch_edge): Likewise.
	(gimple_switch_default_edge): Likewise.
	* tree-cfg.h (label_to_block_fn): Remove.
	(label_to_block): Make proper extern symbol.
	(gimple_switch_bb): New.
	(gimple_switch_default_bb): Likewise.
	(gimple_switch_edge): Likewise.
	(gimple_switch_default_edge): Likewise.
	* tree-cfgcleanup.c (convert_single_case_switch):
Use gimple_switch_default_bb.
	* tree-switch-conversion.c (switch_conversion::collect):
Use gimple_switch_default_edge and gimple_switch_edge
functions.
	(switch_conversion::check_final_bb): Use gimple_switch_bb.
	(switch_decision_tree::compute_cases_per_edge):
Use gimple_switch_edge.
	(switch_decision_tree::analyze_switch_statement): Do not
use label_to_block_fn.
	(switch_decision_tree::try_switch_expansion): Use
gimple_switch_default_edge.
---
 gcc/cfgexpand.c  |  2 +-
 gcc/hsa-gen.c| 21 +-
 gcc/ipa-fnsummary.c  |  2 +-
 gcc/stmt.c   |  4 +--
 gcc/tree-cfg.c   | 54 
 gcc/tree-cfg.h   |  8 --
 gcc/tree-cfgcleanup.c|  5 ++--
 gcc/tree-switch-conversion.c | 40 +-
 8 files changed, 74 insertions(+), 62 deletions(-)

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 3c5b30b79f8..156a529d730 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -3239,7 +3239,7 @@ expand_asm_stmt (gasm *stmt)
 	 may insert further instructions into the same basic block after
 	 asm goto and if we don't do this, insertion of instructions on
 	 the fallthru edge might misbehave.  See PR58670.  */
-	  if (fallthru_bb && label_to_block_fn (cfun, label) == fallthru_bb)
+	  if (fallthru_bb && label_to_block (label) == fallthru_bb)
 	{
 	  if (fallthru_label == NULL_RTX)
 	fallthru_label = gen_label_rtx ();
diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index 6595bedac82..39bd42e4522 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -3475,7 +3475,6 @@ gen_hsa_insns_for_switch_stmt (gswitch *s, hsa_bb *hbb)
   e->flags &= ~EDGE_FALLTHRU;
   e->flags |= EDGE_TRUE_VALUE;
 
-  function *func = DECL_STRUCT_FUNCTION (current_function_decl);
   tree index_tree = gimple_switch_index (s);
   tree lowest = 

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

[Bernd Edlinger]

On 08/22/18 10:14, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> 
>> On 08/22/18 09:26, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>
 On 08/21/18 10:59, Richard Biener wrote:
> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>
>> gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-expansion=0 
>> -fshort-wchar builtin-sprintf-warn-20.c
>> builtin-sprintf-warn-20.c: In function 'test':
>> builtin-sprintf-warn-20.c:19:39: warning: hex escape sequence out of 
>> range
>> 19 | ? (char*)L"\x4142\x4344" : (char*)L"\x41424344\x45464748";
>>|   ^~~
>>
>> Hmm, this test might create some noise on short-wchar targets.
>>
>> I would prefer a warning here, about the wrong type of the parameter.
>> The buffer overflow is only a secondary thing.
>>
>> For constant objects like those, the GIMPLE type is still guaranteed to 
>> be reliable,
>> right?
>
> TREE_TYPE of tcc_declaration and tcc_constant trees should more-or-less
> (minus qualifications not affecting semantics) be those set by
> frontends.
>

 and in this case:

 const union
 { struct {
wchar_t x[4];
  };
  struct {
char z[8];
  };
 } u = {{L"123"}};

 int test()
 {
  return __builtin_strlen(u.z);
 }


 string_constant works out the initializer for u.x
 which has a different type than u.z
>>>
>>> Yes.  That's because it uses ctor-for-folding and friends.  It's
>>> a question of the desired semantics of string_constant whether
>>> it should better return NULL_TREE in this case or whether the
>>> caller has to deal with type mismatches.
>>>
>>
>> Yes, absolutely.
>>
>> c_getstr needs to bail out if the string is not zero-terminated
>> within the limits given by the decl, or the string_cst-type or whatever
>> may help.
>>
>> Furthermore I also consider it possible that the byteoffset
>> is not a multiple of eltsize.  So fail in that case as well.
>>
>>
>> I am currently boot-strapping a patch for this (pr87053):
>> $ cat u.c
>> const union
>> { struct {
>>   char x[4];
>>   char y[4];
>> };
>> struct {
>>   char z[8];
>> };
>> } u = {{"1234", "567"}};
>>
>> int test()
>> {
>> return __builtin_strlen(u.z);
>> }
>>
>> gets folded to 4.
>>
>> ... but unfortunately it will depend on my pr86714 fix which fixes
>> the mem_size parameter returned from string_constant.
>>
>> Frankly, in the moment I feel like I fell in a deep deep hole.   :-O
> 
> /me too with > 100 mails in this and related threads unread ;)
> 
> I thought Jeff applied the mem_size parameter thing but maybe it
> was something else.  *fetches coffee*  Ah, Jeff is still "working"
> on it.
> 

The dependence is not because of the missing mem_size parameter,
but because there is another place where strlen(c_getstr) is used,
and my other patch fixes c_getstr to use mem_size and
not return non-zero terminated strings.

But since Martin claims his patch is superior to mine we
are stuck in this situation.

I think all uses of string_constant all over where mem_size
is not used, are actually broken.  I should make mem_size
a mandatory parameter.


Bernd.

Re: [PATCH] Optimise sqrt reciprocal multiplications

[Richard Sandiford]

Kyrill  Tkachov  writes:
> Hi all,
>
> This patch aims to optimise sequences involving uses of 1.0 / sqrt (a) under 
> -freciprocal-math and -funsafe-math-optimizations.
> In particular consider:
>
> x = 1.0 / sqrt (a);
> r1 = x * x;  // same as 1.0 / a
> r2 = a * x; // same as sqrt (a)
>
> If x, r1 and r2 are all used further on in the code, this can be transformed 
> into:
> tmp1 = 1.0 / a
> tmp2 = sqrt (a)
> tmp3 = tmp1 * tmp2
> x = tmp3
> r1 = tmp1
> r2 = tmp2

Nice optimisation :-)  Someone who knows the pass better should review,
but:

There seems to be an implicit assumption that this is a win even
when the r1 and r2 assignments are only conditionally executed.
That's probably true, but it might be worth saying explicitly.

> +/* Return TRUE if USE_STMT is a multiplication of DEF by A.  */
> +
> +static inline bool
> +is_mult_by (gimple *use_stmt, tree def, tree a)
> +{
> +  if (gimple_code (use_stmt) == GIMPLE_ASSIGN
> +  && gimple_assign_rhs_code (use_stmt) == MULT_EXPR)
> +{
> +  tree op0 = gimple_assign_rhs1 (use_stmt);
> +  tree op1 = gimple_assign_rhs2 (use_stmt);
> +
> +  return (op0 == def && op1 == a)
> +   || (op0 == a && op1 == def);
> +}
> +  return 0;
> +}

Seems like is_square_of could now be a light-weight wrapper around this.

> @@ -652,6 +669,180 @@ execute_cse_reciprocals_1 (gimple_stmt_iterator 
> *def_gsi, tree def)
>occ_head = NULL;
>  }
>  
> +/* Transform sequences like
> +   x = 1.0 / sqrt (a);
> +   r1 = x * x;
> +   r2 = a * x;
> +   into:
> +   tmp1 = 1.0 / a;
> +   tmp2 = sqrt (a);
> +   tmp3 = tmp1 * tmp2;
> +   x = tmp3;
> +   r1 = tmp1;
> +   r2 = tmp2;
> +   depending on the uses of x, r1, r2.  This removes one multiplication and
> +   allows the sqrt and division operations to execute in parallel.
> +   DEF_GSI is the gsi of the initial division by sqrt that defines
> +   DEF (x in the example abovs).  */
> +
> +static void
> +optimize_recip_sqrt (gimple_stmt_iterator *def_gsi, tree def)
> +{
> +  use_operand_p use_p;
> +  imm_use_iterator use_iter;
> +  gimple *stmt = gsi_stmt (*def_gsi);
> +  tree x = def;
> +  tree orig_sqrt_ssa_name = gimple_assign_rhs2 (stmt);
> +  tree div_rhs1 = gimple_assign_rhs1 (stmt);
> +
> +  if (TREE_CODE (orig_sqrt_ssa_name) != SSA_NAME
> +  || TREE_CODE (div_rhs1) != REAL_CST
> +  || !real_equal (_REAL_CST (div_rhs1), ))
> +return;
> +
> +  gimple *sqrt_stmt = SSA_NAME_DEF_STMT (orig_sqrt_ssa_name);
> +  if (!is_gimple_call (sqrt_stmt)
> +  || !gimple_call_lhs (sqrt_stmt))
> +return;
> +
> +  gcall *call = as_a  (sqrt_stmt);

Very minor, but:

  gcall *sqrt_stmt
= dyn_cast  (SSA_NAME_DEF_STMT (orig_sqrt_ssa_name));
  if (!sqrt_stmt || !gimple_call_lhs (sqrt_stmt))
return;

would avoid the need for the separate as_a<>, and would mean that
we only call gimple_call_* on gcalls.

> +  if (has_other_use)
> +{
> +  /* Using the two temporaries tmp1, tmp2 from above
> +  the original x is now:
> +  x = tmp1 * tmp2.  */
> +  gcc_assert (mult_ssa_name);
> +  gcc_assert (sqr_ssa_name);
> +  gimple_stmt_iterator gsi2 = gsi_for_stmt (stmt);
> +
> +  tree new_ssa_name
> + = make_temp_ssa_name (TREE_TYPE (a), NULL, "recip_sqrt_transformed");
> +  gimple *new_stmt
> + = gimple_build_assign (new_ssa_name, MULT_EXPR,
> +mult_ssa_name, sqr_ssa_name);
> +  gsi_insert_before (, new_stmt, GSI_SAME_STMT);
> +  gcc_assert (gsi_stmt (gsi2) == stmt);
> +  gimple_assign_set_rhs_from_tree (, new_ssa_name);
> +  fold_stmt ();
> +  update_stmt (stmt);

In this case we're replacing the statement in its original position,
so there's no real need to use a temporary.  It seems better to 
change the rhs_code, rhs1 and rhs2 of stmt in-place, with the same
lhs as before.

> @@ -762,6 +953,23 @@ pass_cse_reciprocals::execute (function *fun)
>if (optimize_bb_for_size_p (bb))
>  continue;

Seems unnecessary to skip the new optimisation when optimising for size.
Like you say, it saves a multiplication overall.  Also:

> +  if (flag_unsafe_math_optimizations)
> + {
> +   for (gimple_stmt_iterator gsi = gsi_after_labels (bb);
> +!gsi_end_p (gsi);
> +gsi_next ())
> + {
> +   gimple *stmt = gsi_stmt (gsi);
> +
> +   if (gimple_has_lhs (stmt)
> +   && (def = SINGLE_SSA_TREE_OPERAND (stmt, SSA_OP_DEF)) != NULL
> +   && FLOAT_TYPE_P (TREE_TYPE (def))
> +   && TREE_CODE (def) == SSA_NAME
> +   && is_gimple_assign (stmt)
> +   && gimple_assign_rhs_code (stmt) == RDIV_EXPR)
> + optimize_recip_sqrt (, def);
> + }
> + }

It looks like this could safely be done in one of the existing walks
(e.g. the execute_cse_reciprocals_1 one, if we do this when optimising
for size).

Thanks,
Richard

Re: VRP: make range_includes_zero_p handle value_ranges

[Richard Biener]

On Wed, Aug 22, 2018 at 11:31 AM Aldy Hernandez  wrote:
>
>
>
> On 08/21/2018 05:46 AM, Richard Biener wrote:
> > On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez  wrote:
>
> >> Finally, my apologies for including a tiny change to the
> >> POINTER_PLUS_EXPR handling code as well.  It came about the same set of
> >> auditing tests.
> >
> > Bah, please split up things here ;)  I've done a related change there
> > yesterday...
> >
> >>
> >> It turns out we can handle POINTER_PLUS_EXPR(~[0,0], [X,Y]) without
> >> bailing as VR_VARYING in extract_range_from_binary_expr_1.  In doing so,
> >> I also noticed that ~[0,0] is not the only non-null.  We could also have
> >> ~[0,2] and still know that the pointer is not zero.  I have adjusted
> >> range_is_nonnull accordingly.
> >
> > But there are other consumers and it would have been better to
> > change range_includes_zero_p to do the natural thing (get a VR) and
> > then remove range_is_nonnull as redundant if possible.
>
> Indeed.  Cleaning up range_includes_zero_p makes VRP and friends a lot
> cleaner.  Thanks for the suggestion.
>
> I lazily avoided cleaning up the division code affected in this patch
> too much, since it's going to be superseded by my division changes in
> the other patch.
>
> OK pending tests?

-/* Return 1 if [MIN, MAX] includes the value zero, 0 if it does not
-   include the value zero, -2 if we cannot tell.  */
+/* Return 1 if *VR includes the value zero, 0 if it does not include
+   the value zero, or -2 if we cannot tell.  */

 int
-range_includes_zero_p (tree min, tree max)
+range_includes_zero_p (const value_range *vr)
 {
-  tree zero = build_int_cst (TREE_TYPE (min), 0);
-  return value_inside_range (zero, min, max);
+  if (vr->type == VR_UNDEFINED || vr->type == VR_VARYING)
+return -2;
+
+  tree zero = build_int_cst (TREE_TYPE (vr->min), 0);
+  if (vr->type == VR_RANGE)
+return value_inside_range (zero, vr->min, vr->max);
+  else
+return !value_inside_range (zero, vr->min, vr->max);
 }

please make it return a bool.  VR_VARYING means the range does
include zero.  For VR_UNDEFINED we could say it doesn't or we choose
to not possibly optimize and thus return true (just do that for now).
That's because VR_VARYING is [-INF, INF] and VR_UNDEFINED is
an empty range.

I suppose the -2 for we cannot tell was for the case of symbolic
ranges where again we can conservatively return true
(and your return !value_inside_range for VR_ANTI_RANGE botched
the tri-state return value anyways...).

So, can you please rework that?

Thanks,
Richard.

> Aldy

PR target/86951 arm - Handle speculation barriers on pre-armv7 CPUs

[Richard Earnshaw (lists)]

The AArch32 instruction sets prior to Armv7 do not define the ISB and
DSB instructions that are needed to form a speculation barrier.  While I
do not know of any instances of cores based on those instruction sets
being vulnerable to speculative side channel attacks it is possible to
run code built for those ISAs on more recent hardware where they would
become vulnerable.

This patch works around this by using a library call added to libgcc.
That code can then take any platform-specific actions necessary to
ensure safety.

For the moment I've only handled two cases: the library code being built
for armv7 or later anyway and running on Linux.

On Linux we can handle this by calling the kernel function that will
flush a small amount of cache. Such a sequence ends with a ISB+DSB
sequence if running on an Armv7 or later CPU.

gcc:

PR target/86951
* config/arm/arm-protos.h (arm_emit_speculation_barrier): New
prototype.
* config/arm/arm.c (speculation_barrier_libfunc): New static
variable.
(arm_init_libfuncs): Initialize it.
(arm_emit_speculation_barrier): New function.
* config/arm/arm.md (speculation_barrier): Call
arm_emit_speculation_barrier for architectures that do not have
DSB or ISB.
(speculation_barrier_insn): Only match on Armv7 or later.

libgcc:

PR target/86951
* config/arm/lib1funcs.asm (speculation_barrier): New function.
* config/arm/t-arm (LIB1ASMFUNCS): Add it to list of functions
to build.

Bootstrapped and reg-tested and also tested by bootstrapping for ARMv5e
(on an ARMv7-a board).  Applied to trunk.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 8537262..0dfb3ac 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -56,6 +56,8 @@ extern void arm_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update
 extern rtx arm_simd_vect_par_cnst_half (machine_mode mode, bool high);
 extern bool arm_simd_check_vect_par_cnst_half_p (rtx op, machine_mode mode,
 		 bool high);
+extern void arm_emit_speculation_barrier_function (void);
+
 #ifdef RTX_CODE
 extern void arm_gen_unlikely_cbranch (enum rtx_code, machine_mode cc_mode,
   rtx label_ref);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f5eece4..0efac9d 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2466,8 +2466,9 @@ arm_set_fixed_conv_libfunc (convert_optab optable, machine_mode to,
   set_conv_libfunc (optable, to, from, buffer);
 }
 
-/* Set up library functions unique to ARM.  */
+static GTY(()) rtx speculation_barrier_libfunc;
 
+/* Set up library functions unique to ARM.  */
 static void
 arm_init_libfuncs (void)
 {
@@ -2753,6 +2754,8 @@ arm_init_libfuncs (void)
 
   if (TARGET_AAPCS_BASED)
 synchronize_libfunc = init_one_libfunc ("__sync_synchronize");
+
+  speculation_barrier_libfunc = init_one_libfunc ("__speculation_barrier");
 }
 
 /* On AAPCS systems, this is the "struct __va_list".  */
@@ -31528,6 +31531,16 @@ arm_constant_alignment (const_tree exp, HOST_WIDE_INT align)
   return align;
 }
 
+/* Emit a speculation barrier on target architectures that do not have
+   DSB/ISB directly.  Such systems probably don't need a barrier
+   themselves, but if the code is ever run on a later architecture, it
+   might become a problem.  */
+void
+arm_emit_speculation_barrier_function ()
+{
+  emit_library_call (speculation_barrier_libfunc, LCT_NORMAL, VOIDmode);
+}
+
 #if CHECKING_P
 namespace selftest {
 
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index ca2a2f5..270b8e4 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -12016,10 +12016,16 @@ (define_expand "speculation_barrier"
   [(unspec_volatile [(const_int 0)] VUNSPEC_SPECULATION_BARRIER)]
   "TARGET_EITHER"
   "
-/* Don't emit anything for Thumb1 and suppress the warning from the
-   generic expansion.  */
-if (!TARGET_32BIT)
-   DONE;
+  /* For thumb1 (except Armv8 derivatives), and for pre-Armv7 we don't
+ have a usable barrier (and probably don't need one in practice).
+ But to be safe if such code is run on later architectures, call a
+ helper function in libgcc that will do the thing for the active
+ system.  */
+  if (!(arm_arch7 || arm_arch8))
+{
+  arm_emit_speculation_barrier_function ();
+  DONE;
+}
   "
 )
 
@@ -12027,7 +12033,7 @@ (define_expand "speculation_barrier"
 ;; tracking.
 (define_insn "*speculation_barrier_insn"
   [(unspec_volatile [(const_int 0)] VUNSPEC_SPECULATION_BARRIER)]
-  "TARGET_32BIT"
+  "arm_arch7 || arm_arch8"
   "isb\;dsb\\tsy"
   [(set_attr "type" "block")
(set_attr "length" "8")]
diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
index b9919aa..ff06d50 100644
--- a/libgcc/config/arm/lib1funcs.S
+++ b/libgcc/config/arm/lib1funcs.S
@@ -1533,6 +1533,50 @@ LSYM(Lover12):
 #error "This is only for ARM EABI GNU/Linux"
 

[PATCH] Fix PR87024

[Richard Biener]

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

Richard.

2018-08-23  Richard Biener  

PR middle-end/87024
* tree-inline.c (copy_bb): Drop unused __builtin_va_arg_pack_len
calls.

* gcc.dg/pr87024.c: New testcase.

diff --git a/gcc/testsuite/gcc.dg/pr87024.c b/gcc/testsuite/gcc.dg/pr87024.c
new file mode 100644
index 000..a8a58aafc26
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr87024.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fno-tree-dce" } */
+
+static inline void __attribute__((always_inline))
+mp ()
+{
+  (void) __builtin_va_arg_pack_len ();
+}
+
+void
+ui (void)
+{
+  mp ();
+}
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 2b6bb5c0e31..ef615cc347e 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1951,7 +1951,13 @@ copy_bb (copy_body_data *id, basic_block bb,
  for (p = DECL_ARGUMENTS (id->src_fn); p; p = DECL_CHAIN (p))
nargs--;
 
- if (!gimple_call_va_arg_pack_p (id->call_stmt))
+ if (!gimple_call_lhs (stmt))
+   {
+ /* Drop unused calls.  */
+ gsi_remove (_gsi, false);
+ continue;
+   }
+ else if (!gimple_call_va_arg_pack_p (id->call_stmt))
{
  count = build_int_cst (integer_type_node, nargs);
  new_stmt = gimple_build_assign (gimple_call_lhs (stmt), 
count);

Re: [PATCH] Improve checks in c_strlen (PR 87053)

[Bernd Edlinger]

On 08/22/18 18:28, Martin Sebor wrote:
> On 08/22/2018 08:41 AM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> This patch adds some more checks to c_getstr to fix PR middle-end/87053
>> wrong code bug.
>>
>> Unfortunately this patch alone is not sufficient to fix the problem,
>> but also the patch for PR 86714 that hardens c_getstr is necessary
>> to prevent the wrong folding.
>>
>>
>> Bootstrapped and reg-tested on top of my PR 86711/86714 patch.
>> Is it OK for trunk?
> 
> This case is also the subject of the patch I submitted back in
> July for 86711/86714 and 86552.  With it, GCC avoid folding
> the strlen call early and warns for the missing nul:
> 
> warning: ‘__builtin_strlen’ argument missing terminating nul 
> [-Wstringop-overflow=]
>     if (__builtin_strlen (u.z) != 7)
>     ^~~~
> 
> The patch doesn't doesn't prevent all such strings from being
> folded and it eventually lets fold_builtin_strlen() do its thing:
> 
>    /* To avoid warning multiple times about unterminated
>   arrays only warn if its length has been determined
>   and is being folded to a constant.  */
>    if (nonstr)
>      warn_string_no_nul (loc, NULL_TREE, fndecl, nonstr);
> 
>    return fold_convert_loc (loc, type, len);
> 
> Handling this case is a matter of avoiding the folding here as
> well and moving the warning later.
> 
> Since my patch is still in the review queue and does much more
> than just prevent folding of non-nul terminated arrays it should
> be reviewed first.
> 

Hmmm, now you made me curious.

So I tried to install your patch (I did this on r263508
since it does not apply to trunk, one thing I noted is
that part 4 and part 3 seem to create gcc/testsuite/gcc.dg/warn-strcpy-no-nul.c
I did not check if they are identical or not).

So I tried the test case from this PR on the compiler built with your patch:

$ cat cat pr87053.c
/* PR middle-end/87053 */

const union
{ struct {
 char x[4];
 char y[4];
   };
   struct {
 char z[8];
   };
} u = {{"1234", "567"}};

int main ()
{
   if (__builtin_strlen (u.z) != 7)
 __builtin_abort ();
}
$ gcc -S pr87053.c
pr87053.c: In function 'main':
pr87053.c:15:7: warning: '__builtin_strlen' argument missing terminating nul 
[-Wstringop-overflow=]
15 |   if (__builtin_strlen (u.z) != 7)
|   ^~~~
pr87053.c:11:3: note: referenced argument declared here
11 | } u = {{"1234", "567"}};
|   ^
$ cat pr87053.s
.file   "pr87053.c"
.text
.globl  u
.section.rodata
.align 8
.type   u, @object
.size   u, 8
u:
.ascii  "1234"
.string "567"
.text
.globl  main
.type   main, @function
main:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
callabort
.cfi_endproc
.LFE0:
.size   main, .-main
.ident  "GCC: (GNU) 9.0.0 20180813 (experimental)"
.section.note.GNU-stack,"",@progbits


So we get a warning, and still wrong code.

That is the reason why I think this patch of yours adds
confusion by trying to fix everything in one step.

And I would like you to think of ways how to solve
a problem step by step.

And at this time, sorry, we should restore correctness issues.
And fix wrong-code issues.
If possible without breaking existing warnings, yes.
But no new warnings, sorry again.


Bernd.

RFA: Define vect_perm for variable-length SVE

[Richard Sandiford]

Variable-length SVE now supports enough permutes to define vect_perm.

The change to vect_perm_supported is currently a no-op because the
function is only called with a count of 3.

Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu.  OK for the vect_perm_supported change?
I think the rest is covered by the SVE maintainership.

Richard


2018-08-23  Richard Sandiford  

gcc/testsuite/
* lib/target-supports.exp (vect_perm_supported): Only return
false for variable-length vectors if the permute size is not
a power of 2.
(check_effective_target_vect_perm)
(check_effective_target_vect_perm_byte)
(check_effective_target_vect_perm_short): Remove check for
variable-length vectors.
* gcc.dg/vect/slp-23.c: Add an XFAIL for variable-length SVE.
* gcc.dg/vect/slp-perm-10.c: Likewise.
* gcc.dg/vect/slp-perm-9.c: Add an XFAIL for variable-length vectors.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   2018-08-21 14:47:06.491178839 
+0100
+++ gcc/testsuite/lib/target-supports.exp   2018-08-23 10:09:45.296442485 
+0100
@@ -5758,8 +5758,7 @@ proc check_effective_target_vect_perm {
 } else {
set et_vect_perm_saved($et_index) 0
 if { [is-effective-target arm_neon]
-|| ([istarget aarch64*-*-*]
-&& ![check_effective_target_vect_variable_length])
+|| [istarget aarch64*-*-*]
 || [istarget powerpc*-*-*]
  || [istarget spu-*-*]
 || [istarget i?86-*-*] || [istarget x86_64-*-*]
@@ -5824,7 +5823,9 @@ proc check_effective_target_vect_perm {
 
 proc vect_perm_supported { count element_bits } {
 set vector_bits [lindex [available_vector_sizes] 0]
-if { $vector_bits <= 0 } {
+# The number of vectors has to be a power of 2 when permuting
+# variable-length vectors.
+if { $vector_bits <= 0 && ($count & -$count) != $count } {
return 0
 }
 set vf [expr { $vector_bits / $element_bits }]
@@ -5864,8 +5865,7 @@ proc check_effective_target_vect_perm_by
 if { ([is-effective-target arm_neon]
  && [is-effective-target arm_little_endian])
 || ([istarget aarch64*-*-*]
-&& [is-effective-target aarch64_little_endian]
-&& ![check_effective_target_vect_variable_length])
+&& [is-effective-target aarch64_little_endian])
 || [istarget powerpc*-*-*]
 || [istarget spu-*-*]
 || ([istarget mips-*.*]
@@ -5904,8 +5904,7 @@ proc check_effective_target_vect_perm_sh
 if { ([is-effective-target arm_neon]
  && [is-effective-target arm_little_endian])
 || ([istarget aarch64*-*-*]
-&& [is-effective-target aarch64_little_endian]
-&& ![check_effective_target_vect_variable_length])
+&& [is-effective-target aarch64_little_endian])
 || [istarget powerpc*-*-*]
 || [istarget spu-*-*]
 || (([istarget i?86-*-*] || [istarget x86_64-*-*])
Index: gcc/testsuite/gcc.dg/vect/slp-23.c
===
--- gcc/testsuite/gcc.dg/vect/slp-23.c  2018-05-02 08:37:48.985604715 +0100
+++ gcc/testsuite/gcc.dg/vect/slp-23.c  2018-08-23 10:09:45.296442485 +0100
@@ -107,8 +107,8 @@ int main (void)
 
 /* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { target { 
vect_strided8 && { ! { vect_no_align} } } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { 
! { vect_strided8 || vect_no_align } } } } } */
-/* We fail to vectorize the second loop with variable-length SVE but
-   fall back to 128-bit vectors, which does use SLP.  */
 /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" { 
target { ! vect_perm } } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" { 
target vect_perm } } } */
+/* SLP fails for the second loop with variable-length SVE because
+   the load size is greater than the minimum vector size.  */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" { 
target vect_perm xfail { aarch64_sve && vect_variable_length } } } } */
   
Index: gcc/testsuite/gcc.dg/vect/slp-perm-10.c
===
--- gcc/testsuite/gcc.dg/vect/slp-perm-10.c 2016-11-11 17:07:36.516798781 
+
+++ gcc/testsuite/gcc.dg/vect/slp-perm-10.c 2018-08-23 10:09:45.296442485 
+0100
@@ -50,4 +50,6 @@ int main ()
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target 
vect_perm } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" { 
target vect_perm } } } */
+/* SLP fails for variable-length SVE because the load size is greater
+   

Avoid is_constant calls in vectorizable_bswap

[Richard Sandiford]

The "new" VEC_PERM_EXPR handling makes it easy to support bswap
for variable-length vectors.

Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu.  OK to install?

Richard


2018-08-23  Richard Sandiford  

gcc/
* tree-vect-stmts.c (vectorizable_bswap): Handle variable-length
vectors.

gcc/testsuite/
* gcc.target/aarch64/sve/bswap_1.c: New test.
* gcc.target/aarch64/sve/bswap_2.c: Likewise.
* gcc.target/aarch64/sve/bswap_3.c: Likewise.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   2018-08-23 09:59:35.245682525 +0100
+++ gcc/tree-vect-stmts.c   2018-08-23 10:07:30.233601466 +0100
@@ -2961,13 +2961,10 @@ vectorizable_bswap (stmt_vec_info stmt_i
   vec_info *vinfo = stmt_info->vinfo;
   loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
   unsigned ncopies;
-  unsigned HOST_WIDE_INT nunits, num_bytes;
 
   op = gimple_call_arg (stmt, 0);
   vectype = STMT_VINFO_VECTYPE (stmt_info);
-
-  if (!TYPE_VECTOR_SUBPARTS (vectype).is_constant ())
-return false;
+  poly_uint64 nunits = TYPE_VECTOR_SUBPARTS (vectype);
 
   /* Multiple types in SLP are handled by creating the appropriate number of
  vectorized stmts for each SLP node.  Hence, NCOPIES is always 1 in
@@ -2983,11 +2980,11 @@ vectorizable_bswap (stmt_vec_info stmt_i
   if (! char_vectype)
 return false;
 
-  if (!TYPE_VECTOR_SUBPARTS (char_vectype).is_constant (_bytes))
+  poly_uint64 num_bytes = TYPE_VECTOR_SUBPARTS (char_vectype);
+  unsigned word_bytes;
+  if (!constant_multiple_p (num_bytes, nunits, _bytes))
 return false;
 
-  unsigned word_bytes = num_bytes / nunits;
-
   /* The encoding uses one stepped pattern for each byte in the word.  */
   vec_perm_builder elts (num_bytes, word_bytes, 3);
   for (unsigned i = 0; i < 3; ++i)
Index: gcc/testsuite/gcc.target/aarch64/sve/bswap_1.c
===
--- /dev/null   2018-07-26 10:26:13.137955424 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/bswap_1.c  2018-08-23 
10:07:30.233601466 +0100
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+#include 
+
+void
+f (uint16_t *a, uint16_t *b)
+{
+  for (int i = 0; i < 100; ++i)
+a[i] = __builtin_bswap16 (b[i]);
+}
+
+/* { dg-final { scan-assembler-times {\trevb\tz[0-9]+\.h, p[0-7]/m, 
z[0-9]+\.h\n} 1 { xfail aarch64_big_endian } } } */
Index: gcc/testsuite/gcc.target/aarch64/sve/bswap_2.c
===
--- /dev/null   2018-07-26 10:26:13.137955424 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/bswap_2.c  2018-08-23 
10:07:30.233601466 +0100
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+#include 
+
+void
+f (uint32_t *a, uint32_t *b)
+{
+  for (int i = 0; i < 100; ++i)
+a[i] = __builtin_bswap32 (b[i]);
+}
+
+/* { dg-final { scan-assembler-times {\trevb\tz[0-9]+\.s, p[0-7]/m, 
z[0-9]+\.s\n} 1 { xfail aarch64_big_endian } } } */
Index: gcc/testsuite/gcc.target/aarch64/sve/bswap_3.c
===
--- /dev/null   2018-07-26 10:26:13.137955424 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/bswap_3.c  2018-08-23 
10:07:30.233601466 +0100
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+#include 
+
+void
+f (uint64_t *a, uint64_t *b)
+{
+  for (int i = 0; i < 100; ++i)
+a[i] = __builtin_bswap64 (b[i]);
+}
+
+/* { dg-final { scan-assembler-times {\trevb\tz[0-9]+\.d, p[0-7]/m, 
z[0-9]+\.d\n} 1 { xfail aarch64_big_endian } } } */

Handle SLP permutations for variable-length vectors

[Richard Sandiford]

The SLP code currently punts for all variable-length permutes.
This patch makes it handle the easy case of N->N permutes in which
the number of vector lanes is a multiple of N.  Every permute then
uses the same mask, and that mask repeats (with a stride) every
N elements.

The patch uses the same path for constant-length vectors,
since it should be slightly cheaper in terms of compile time.

Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu.  OK to install?

Richard


2018-08-23  Richard Sandiford  

gcc/
* tree-vect-slp.c (vect_transform_slp_perm_load): Separate out
the case in which the permute needs only a single element and
repeats for every vector of the result.  Extend that case to
handle variable-length vectors.
* tree-vect-stmts.c (vectorizable_load): Update accordingly.

gcc/testsuite/
* gcc.target/aarch64/sve/slp_perm_1.c: New test.
* gcc.target/aarch64/sve/slp_perm_2.c: Likewise.
* gcc.target/aarch64/sve/slp_perm_3.c: Likewise.
* gcc.target/aarch64/sve/slp_perm_4.c: Likewise.
* gcc.target/aarch64/sve/slp_perm_5.c: Likewise.
* gcc.target/aarch64/sve/slp_perm_6.c: Likewise.
* gcc.target/aarch64/sve/slp_perm_7.c: Likewise.

Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c 2018-08-21 14:47:08.339163256 +0100
--- gcc/tree-vect-slp.c 2018-08-23 09:59:35.245682525 +0100
*** vect_transform_slp_perm_load (slp_tree n
*** 3606,3618 
  {
stmt_vec_info stmt_info = SLP_TREE_SCALAR_STMTS (node)[0];
vec_info *vinfo = stmt_info->vinfo;
-   tree mask_element_type = NULL_TREE, mask_type;
int vec_index = 0;
tree vectype = STMT_VINFO_VECTYPE (stmt_info);
!   int group_size = SLP_INSTANCE_GROUP_SIZE (slp_node_instance);
unsigned int mask_element;
machine_mode mode;
-   unsigned HOST_WIDE_INT nunits, const_vf;
  
if (!STMT_VINFO_GROUPED_ACCESS (stmt_info))
  return false;
--- 3606,3616 
  {
stmt_vec_info stmt_info = SLP_TREE_SCALAR_STMTS (node)[0];
vec_info *vinfo = stmt_info->vinfo;
int vec_index = 0;
tree vectype = STMT_VINFO_VECTYPE (stmt_info);
!   unsigned int group_size = SLP_INSTANCE_GROUP_SIZE (slp_node_instance);
unsigned int mask_element;
machine_mode mode;
  
if (!STMT_VINFO_GROUPED_ACCESS (stmt_info))
  return false;
*** vect_transform_slp_perm_load (slp_tree n
*** 3620,3641 
stmt_info = DR_GROUP_FIRST_ELEMENT (stmt_info);
  
mode = TYPE_MODE (vectype);
! 
!   /* At the moment, all permutations are represented using per-element
!  indices, so we can't cope with variable vector lengths or
!  vectorization factors.  */
!   if (!TYPE_VECTOR_SUBPARTS (vectype).is_constant ()
!   || !vf.is_constant (_vf))
! return false;
! 
!   /* The generic VEC_PERM_EXPR code always uses an integral type of the
!  same size as the vector element being permuted.  */
!   mask_element_type = lang_hooks.types.type_for_mode
! (int_mode_for_mode (TYPE_MODE (TREE_TYPE (vectype))).require (), 1);
!   mask_type = get_vectype_for_scalar_type (mask_element_type);
!   vec_perm_builder mask (nunits, nunits, 1);
!   mask.quick_grow (nunits);
!   vec_perm_indices indices;
  
/* Initialize the vect stmts of NODE to properly insert the generated
   stmts later.  */
--- 3618,3624 
stmt_info = DR_GROUP_FIRST_ELEMENT (stmt_info);
  
mode = TYPE_MODE (vectype);
!   poly_uint64 nunits = TYPE_VECTOR_SUBPARTS (vectype);
  
/* Initialize the vect stmts of NODE to properly insert the generated
   stmts later.  */
*** vect_transform_slp_perm_load (slp_tree n
*** 3669,3682 
bool noop_p = true;
*n_perms = 0;
  
!   for (unsigned int j = 0; j < const_vf; j++)
  {
!   for (int k = 0; k < group_size; k++)
{
! unsigned int i = (SLP_TREE_LOAD_PERMUTATION (node)[k]
!   + j * DR_GROUP_SIZE (stmt_info));
! vec_index = i / nunits;
! mask_element = i % nunits;
  if (vec_index == first_vec_index
  || first_vec_index == -1)
{
--- 3652,3704 
bool noop_p = true;
*n_perms = 0;
  
!   vec_perm_builder mask;
!   unsigned int nelts_to_build;
!   unsigned int nvectors_per_build;
!   bool repeating_p = (group_size == DR_GROUP_SIZE (stmt_info)
! && multiple_p (nunits, group_size));
!   if (repeating_p)
! {
!   /* A single vector contains a whole number of copies of the node, so:
!(a) all permutes can use the same mask; and
!(b) the permutes only need a single vector input.  */
!   mask.new_vector (nunits, group_size, 3);
!   nelts_to_build = mask.encoded_nelts ();
!   nvectors_per_build = SLP_TREE_VEC_STMTS (node).length ();
! }
!   else
! {
!   /* We need to construct a separate mask for each vector statement.  */
! 

Re: [PATCH] Skip tests that depend on the cxx11 std::string

[Jonathan Wakely]

On 23/08/18 09:24 +0100, Jonathan Wakely wrote:

--- a/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
@@ -17,6 +17,7 @@
//

// { dg-do run { target c++11 } }
+// { dg-require-effective-target cxx11-abi }


Actually I shouldn't have added it here. It only depends on the new
string when compiled with _GLIBCXX_DEBUG, and that should be fixed in
__gnu_debug::string not by skipping the test.

[AArch64] Improve SVE handling of single-vector permutes

[Richard Sandiford]

aarch64_vectorize_vec_perm_const was failing to set one_vector_p
if the permute had only a single input.  This in turn was hiding
a problem in the SVE TBL handling: it accepted single-vector
variable-length permutes, but sent them through the general
two-vector aarch64_expand_sve_vec_perm, which is only set up
to handle constant-length permutes.

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied to trunk, counting the aarch64_vectorize_vec_perm_const change
as obvious.  Might be worth backporting to GCC 8 at some point.

Richard


2018-08-23  Richard Sandiford  

gcc/
* config/aarch64/aarch64.c (aarch64_evpc_sve_tbl): Fix handling
of single-vector TBLs.
(aarch64_vectorize_vec_perm_const): Set one_vector_p when only
one input is given.

gcc/testsuite/
* gcc.dg/vect/no-vfa-vect-depend-2.c: Remove XFAIL.
* gcc.dg/vect/no-vfa-vect-depend-3.c: Likewise.
* gcc.dg/vect/pr65947-13.c: Update for vect_fold_extract_last.
* gcc.dg/vect/pr80631-2.c: Likewise.

Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c2018-08-23 09:49:50.426715321 +0100
+++ gcc/config/aarch64/aarch64.c2018-08-23 09:53:58.416580848 +0100
@@ -15423,7 +15423,10 @@ aarch64_evpc_sve_tbl (struct expand_vec_
 
   machine_mode sel_mode = mode_for_int_vector (d->vmode).require ();
   rtx sel = vec_perm_indices_to_rtx (sel_mode, d->perm);
-  aarch64_expand_sve_vec_perm (d->target, d->op0, d->op1, sel);
+  if (d->one_vector_p)
+emit_unspec2 (d->target, UNSPEC_TBL, d->op0, force_reg (sel_mode, sel));
+  else
+aarch64_expand_sve_vec_perm (d->target, d->op0, d->op1, sel);
   return true;
 }
 
@@ -15476,7 +15479,8 @@ aarch64_vectorize_vec_perm_const (machin
   struct expand_vec_perm_d d;
 
   /* Check whether the mask can be applied to a single vector.  */
-  if (op0 && rtx_equal_p (op0, op1))
+  if (sel.ninputs () == 1
+  || (op0 && rtx_equal_p (op0, op1)))
 d.one_vector_p = true;
   else if (sel.all_from_input_p (0))
 {
Index: gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c
===
--- gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c2018-05-02 
08:37:48.981604753 +0100
+++ gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c2018-08-23 
09:53:58.416580848 +0100
@@ -51,7 +51,4 @@ int main (void)
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" {xfail { 
vect_no_align && { ! vect_hw_misalign } } } } } */
-/* Requires reverse for variable-length SVE, which is implemented for
-   by a later patch.  Until then we report it twice, once for SVE and
-   once for 128-bit Advanced SIMD.  */
-/* { dg-final { scan-tree-dump-times "dependence distance negative" 1 "vect" { 
xfail { aarch64_sve && vect_variable_length } } } } */
+/* { dg-final { scan-tree-dump-times "dependence distance negative" 1 "vect" } 
} */
Index: gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-3.c
===
--- gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-3.c2018-05-02 
08:37:49.021604375 +0100
+++ gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-3.c2018-08-23 
09:53:58.416580848 +0100
@@ -183,7 +183,4 @@ int main ()
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 4 "vect" {xfail { 
vect_no_align && { ! vect_hw_misalign } } } } } */
-/* f4 requires reverse for SVE, which is implemented by a later patch.
-   Until then we report it twice, once for SVE and once for 128-bit
-   Advanced SIMD.  */
-/* { dg-final { scan-tree-dump-times "dependence distance negative" 4 "vect" { 
xfail { aarch64_sve && vect_variable_length } } } } */
+/* { dg-final { scan-tree-dump-times "dependence distance negative" 4 "vect" } 
} */
Index: gcc/testsuite/gcc.dg/vect/pr65947-13.c
===
--- gcc/testsuite/gcc.dg/vect/pr65947-13.c  2018-05-02 08:37:49.041604185 
+0100
+++ gcc/testsuite/gcc.dg/vect/pr65947-13.c  2018-08-23 09:53:58.416580848 
+0100
@@ -41,4 +41,5 @@ main (void)
 }
 
 /* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 2 "vect" } } */
-/* { dg-final { scan-tree-dump-times "condition expression based on integer 
induction." 4 "vect" } } */
+/* { dg-final { scan-tree-dump-times "condition expression based on integer 
induction." 4 "vect" { xfail vect_fold_extract_last } } } */
+/* { dg-final { scan-tree-dump-times "optimizing condition reduction with 
FOLD_EXTRACT_LAST" 4 "vect" { target vect_fold_extract_last } } } */
Index: gcc/testsuite/gcc.dg/vect/pr80631-2.c
===
--- gcc/testsuite/gcc.dg/vect/pr80631-2.c   2018-05-02 08:37:48.977604791 
+0100
+++ gcc/testsuite/gcc.dg/vect/pr80631-2.c   2018-08-23 09:53:58.416580848 
+0100
@@ -72,4 +72,5 @@ main ()
 }
 
 /* { dg-final { scan-tree-dump-times 

Fix aarch64_evpc_tbl guard (PR 85910)

[Richard Sandiford]

This patch fixes a typo in aarch64_expand_vec_perm_const_1 that I
introduced as part of the SVE changes.  I don't know of any cases in
which it has any practical effect, since we'll eventually try to use
TBL as a variable permute instead.  Having the code is still an
important part of defining the interface properly and so we shouldn't
simply drop it.

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as obvious to trunk, but OK to backport to GCC 8?

Richard


2018-08-23  Richard Sandiford  

gcc/
PR target/85910
* config/aarch64/aarch64.c (aarch64_expand_vec_perm_const_1): Fix
aarch64_evpc_tbl guard.
--

Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c2018-08-23 09:47:55.0 +0100
+++ gcc/config/aarch64/aarch64.c2018-08-23 09:48:51.379223625 +0100
@@ -15461,7 +15461,7 @@ aarch64_expand_vec_perm_const_1 (struct
return true;
   if (d->vec_flags == VEC_SVE_DATA)
return aarch64_evpc_sve_tbl (d);
-  else if (d->vec_flags == VEC_SVE_DATA)
+  else if (d->vec_flags == VEC_ADVSIMD)
return aarch64_evpc_tbl (d);
 }
   return false;

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

[Bernd Edlinger]

On 08/23/18 00:50, Jeff Law wrote:
> On 08/22/2018 02:14 AM, Richard Biener wrote:
>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/22/18 09:26, Richard Biener wrote:
 On Wed, 22 Aug 2018, Bernd Edlinger wrote:

> On 08/21/18 10:59, Richard Biener wrote:
>> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>>
>>> gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-expansion=0 
>>> -fshort-wchar builtin-sprintf-warn-20.c
>>> builtin-sprintf-warn-20.c: In function 'test':
>>> builtin-sprintf-warn-20.c:19:39: warning: hex escape sequence out of 
>>> range
>>> 19 | ? (char*)L"\x4142\x4344" : (char*)L"\x41424344\x45464748";
>>>|   ^~~
>>>
>>> Hmm, this test might create some noise on short-wchar targets.
>>>
>>> I would prefer a warning here, about the wrong type of the parameter.
>>> The buffer overflow is only a secondary thing.
>>>
>>> For constant objects like those, the GIMPLE type is still guaranteed to 
>>> be reliable,
>>> right?
>>
>> TREE_TYPE of tcc_declaration and tcc_constant trees should more-or-less
>> (minus qualifications not affecting semantics) be those set by
>> frontends.
>>
>
> and in this case:
>
> const union
> { struct {
>wchar_t x[4];
>  };
>  struct {
>char z[8];
>  };
> } u = {{L"123"}};
>
> int test()
> {
>  return __builtin_strlen(u.z);
> }
>
>
> string_constant works out the initializer for u.x
> which has a different type than u.z

 Yes.  That's because it uses ctor-for-folding and friends.  It's
 a question of the desired semantics of string_constant whether
 it should better return NULL_TREE in this case or whether the
 caller has to deal with type mismatches.

>>>
>>> Yes, absolutely.
>>>
>>> c_getstr needs to bail out if the string is not zero-terminated
>>> within the limits given by the decl, or the string_cst-type or whatever
>>> may help.
>>>
>>> Furthermore I also consider it possible that the byteoffset
>>> is not a multiple of eltsize.  So fail in that case as well.
>>>
>>>
>>> I am currently boot-strapping a patch for this (pr87053):
>>> $ cat u.c
>>> const union
>>> { struct {
>>>   char x[4];
>>>   char y[4];
>>> };
>>> struct {
>>>   char z[8];
>>> };
>>> } u = {{"1234", "567"}};
>>>
>>> int test()
>>> {
>>> return __builtin_strlen(u.z);
>>> }
>>>
>>> gets folded to 4.
>>>
>>> ... but unfortunately it will depend on my pr86714 fix which fixes
>>> the mem_size parameter returned from string_constant.
>>>
>>> Frankly, in the moment I feel like I fell in a deep deep hole.   :-O
>>
>> /me too with > 100 mails in this and related threads unread ;)
>>
>> I thought Jeff applied the mem_size parameter thing but maybe it
>> was something else.  *fetches coffee*  Ah, Jeff is still "working"
>> on it.
> The patch that was applied adds a parameter to c_strlen to indicate how
> it should count (ie, bytes, 16bit wchars or 32bit wchars).
> 
> There was one hunk that was dependent upon an earlier, more
> controversial, patch from Bernd which is still under discussion.  That
> hunk was twiddled to preserve the overall goal of Bernd's patch which
> added the how to count parameter without being dependent upon the older,
> more controversial patch.
> 
> It's all confusing and it'd actually help if folks stopped issuing
> updated patches which try to handle more cases or which touch on the
> areas of code already being looked at.  Otherwise the patches just get
> more tangled and we're more likely to end up with developers getting
> more entrenched in a particular approach.
> 

Sorry, Jeff.

Actually I would not do all that work in my spare time, if I would not
really feel the need to help (in the end also help myself of course,
since I have basically a need of a working GCC to get my paid work done).

Unfortunately all those issues are somehow connected via
the unspecified semantical differences between STRING_CST
used for literals and used for initializers, but without working
on those patches I would not have found that out.


Bernd.

[PATCH] Skip tests that depend on the cxx11 std::string

[Jonathan Wakely]

* testsuite/21_strings/basic_string/init-list.cc:
Require cxx11-abi.
* testsuite/experimental/polymorphic_allocator/pmr_typedefs_match.cc:
Likewise.
* testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc:
Likewise.

Tested x86_64-linux, committed to trunk.


commit e164ee9c052794eb0beb84e1d4bf4ef60ed08daa
Author: Jonathan Wakely 
Date:   Thu Aug 23 09:22:25 2018 +0100

Skip tests that depend on the cxx11 std::string

* testsuite/21_strings/basic_string/init-list.cc:
Require cxx11-abi.
* 
testsuite/experimental/polymorphic_allocator/pmr_typedefs_match.cc:
Likewise.
* 
testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc:
Likewise.

diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
index aa7754821b9..20a392c40fc 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/init-list.cc
@@ -17,6 +17,7 @@
 //
 
 // { dg-do run { target c++11 } }
+// { dg-require-effective-target cxx11-abi }
 
 #include 
 
diff --git 
a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_match.cc
 
b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_match.cc
index c237f1e9de9..8f5f8513403 100644
--- 
a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_match.cc
+++ 
b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_match.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do compile { target c++14 } }
+// { dg-require-effective-target cxx11-abi }
 
 #include 
 
diff --git 
a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc
 
b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc
index 3cf8c94cfb1..ed53ce1a89b 100644
--- 
a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc
+++ 
b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do compile { target c++14 } }
+// { dg-require-effective-target cxx11-abi }
 
 #include 
 

[PATCH] Remove C++14-isms from C++11 tests

[Jonathan Wakely]

* testsuite/20_util/reference_wrapper/lwg2993.cc: Fix C++11 test to
not use C++14 feature.
* testsuite/23_containers/list/68222_neg.cc: Likewise.

Tested x86_64-linux, committed to trunk.

commit 7125051d44c2f4e52641658b7a35a26379f2db17
Author: Jonathan Wakely 
Date:   Thu Aug 23 09:23:16 2018 +0100

Remove C++14-isms from C++11 tests

* testsuite/20_util/reference_wrapper/lwg2993.cc: Fix C++11 test to
not use C++14 feature.
* testsuite/23_containers/list/68222_neg.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/lwg2993.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/lwg2993.cc
index 0a339486ef8..fa7cc728abe 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/lwg2993.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/lwg2993.cc
@@ -51,5 +51,5 @@ test02()
 
   // error: no member 'type' because the conditional
   // expression is ill-formed
-  using t = std::common_type_t, int>;
+  using t = typename std::common_type, int>::type;
 }
diff --git a/libstdc++-v3/testsuite/23_containers/list/68222_neg.cc 
b/libstdc++-v3/testsuite/23_containers/list/68222_neg.cc
index d969b6a9c52..cd33762e01a 100644
--- a/libstdc++-v3/testsuite/23_containers/list/68222_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/list/68222_neg.cc
@@ -26,10 +26,10 @@ test01()
   const std::list nums = { 1, 2, 3, 4 };
 
   // Grab the iterator type.
-  using list_itr_type = decltype( std::cbegin( nums ) );
+  using list_itr_type = decltype( std::begin( nums ) );
 
   // Confirm cend returns the same type.
-  static_assert( std::is_same< decltype( std::cend( nums ) ), list_itr_type 
>::value, "" );
+  static_assert( std::is_same< decltype( std::end( nums ) ), list_itr_type 
>::value, "" );
 
   // The list's iterator type provides a well-formed non-member operator-() 
with valid return type (long int)
   using substraction_type

Re: [Patch][GCC] Document and fix -r (partial linking)

[Iain Sandoe]

> On 20 Aug 2018, at 23:38, Joseph Myers  wrote:
> 
> On Fri, 3 Aug 2018, Allan Sandfeld Jensen wrote:
> 
>>> I think you're changing the wrong place for this.  If you want -r to be
>>> usable with GCC without using -nostdlib (which is an interesting
>>> question), you actually need to change LINK_COMMAND_SPEC (also sometimes
>>> overridden for targets) to handle -r more like -nostdlib -nostartfiles.
>>> 
>> Okay, so like this?
> 
> Could you confirm if this has passed a bootstrap and testsuite run, with 
> no testsuite regressions compared to GCC without the patch applied?  I 
> think it looks mostly OK (modulo ChangeLog rewrites and a missing second 
> space after '.' in the manual change) but I'd like to make sure it's 
> passed the usual testing before preparing it for commit.

I have bootstrapped the Darwin part (several times now), I’d say it’s “correct 
by
examination” and that if there’s test-suite fallout, that indicates a latent 
problem.
(I don’t think there is - but the Darwin test output is rather noisy at the 
moment).

But I think gcc/gcc.c patch is incomplete, since it doesn’t account for the
 VTABLE_VERIFICATION_SPEC, SANITIZER_EARLY_SPEC, SANITIZER_SPEC.
 
How have you determined that the patch is doing what you expect?

(it might be nice if there was some specific testsuite entry than makes sure 
this is
 working so that if people make a mistake in the future, it gets caught).

===

Joseph: As a side-comment, is there a reason that we don’t exclude 
gomp/itm/fortran/gcov
from the link for -nostdlib / -nodefaultlib?

If we are relying on the lib self-specs for this, then we’re not succeeding 
since the
one we build at the moment don’t include those clauses.

thanks
Iain

[PATCH][GCC][AARCH64] use "arch_enabled" attribute for aarch64.

[Matthew Malcomson]

Hello,

arm.md has some attributes "arch" and "arch_enabled" to aid enabling and
disabling insn alternatives based on the architecture being targeted.
This patch introduces a similar attribute in the aarch64 backend.
The new attribute will be used to enable a new alternative for the atomic_store
insn in a future patch, but is an atomic change in itself.

The new attribute has values "any", "fp", "fp16", "simd", and "sve".
These attribute values have been taken from the pre-existing attributes "fp",
"fp16", "simd", and "sve".
The standalone "fp" attribute has been reintroduced in terms of the "arch"
attribute as it's needed for the xgene1.md scheduling file -- the use in this
file can't be changed to check for `(eq_attr "arch" "fp")` as the file is
reused by the arm.md machine description whose 'arch' attribute doesn't have an
'fp' value.


Full bootstrap and regression test done on aarch64.

Ok for trunk?
I don't have commit rights, so could someone commit it if accepted.


gcc/ChangeLog:

2018-08-23  Matthew Malcomson  

* config/aarch64/aarch64.md (arches): New enum.
(arch): New enum attr.
(arch_enabled): New attr.
(enabled): Now uses arch_enabled only.
(simd, sve, fp16): Removed attribute.
(fp): Attr now defined in terms of 'arch'.
(*mov_aarch64, *movsi_aarch64, *movdi_aarch64, *movti_aarch64,
*movhf_aarch64, 2,
3,
3): Merge 'fp' and 'simd'
attributes into 'arch'. 
(*movsf_aarch64, *movdf_aarch64, *movtf_aarch64, *add3_aarch64,
subdi3, neg2, 3, one_cmpl2,
*_one_cmpl3, *xor_one_cmpl3,
*aarch64_ashl_sisd_or_int_3, *aarch64_lshr_sisd_or_int_3,
*aarch64_ashr_sisd_or_int_3, *aarch64_sisd_ushl): Convert use of
'simd' attribute into 'arch'. 
(load_pair_sw_, load_pair_dw_,
store_pair_sw_, store_pair_dw_):
Convert use of 'fp' attribute to 'arch'. 
* config/aarch64/aarch64-simd.md (move_lo_quad_internal_,
move_lo_quad_internal_): (different modes) Merge 'fp' and 'simd'
into 'arch'.
(move_lo_quad_internal_be_, move_lo_quad_internal_be_):
(different modes) Merge 'fp' and 'simd' into 'arch'.
(*aarch64_combinez, *aarch64_combinez_be): Merge 'fp' and
'simd' into 'arch'.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 
5591c7b5a6bd7783c2b227add3e5a89d1a188f69..bea1c14e8ddabc4175be10790cd839c3a3852dab
 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -1352,9 +1352,8 @@
fmov\\t%d0, %1
dup\\t%d0, %1"
   [(set_attr "type" "neon_dup,f_mcr,neon_dup")
-   (set_attr "simd" "yes,*,yes")
-   (set_attr "fp" "*,yes,*")
-   (set_attr "length" "4")]
+   (set_attr "length" "4")
+   (set_attr "arch" "simd,fp,simd")]
 )
 
 (define_insn "move_lo_quad_internal_"
@@ -1368,9 +1367,8 @@
fmov\\t%d0, %1
dup\\t%d0, %1"
   [(set_attr "type" "neon_dup,f_mcr,neon_dup")
-   (set_attr "simd" "yes,*,yes")
-   (set_attr "fp" "*,yes,*")
-   (set_attr "length" "4")]
+   (set_attr "length" "4")
+   (set_attr "arch" "simd,fp,simd")]
 )
 
 (define_insn "move_lo_quad_internal_be_"
@@ -1384,9 +1382,8 @@
fmov\\t%d0, %1
dup\\t%d0, %1"
   [(set_attr "type" "neon_dup,f_mcr,neon_dup")
-   (set_attr "simd" "yes,*,yes")
-   (set_attr "fp" "*,yes,*")
-   (set_attr "length" "4")]
+   (set_attr "length" "4")
+   (set_attr "arch" "simd,fp,simd")]
 )
 
 (define_insn "move_lo_quad_internal_be_"
@@ -1400,9 +1397,8 @@
fmov\\t%d0, %1
dup\\t%d0, %1"
   [(set_attr "type" "neon_dup,f_mcr,neon_dup")
-   (set_attr "simd" "yes,*,yes")
-   (set_attr "fp" "*,yes,*")
-   (set_attr "length" "4")]
+   (set_attr "length" "4")
+   (set_attr "arch" "simd,fp,simd")]
 )
 
 (define_expand "move_lo_quad_"
@@ -3114,8 +3110,7 @@
fmov\t%d0, %1
ldr\\t%d0, %1"
   [(set_attr "type" "neon_move, neon_from_gp, neon_load1_1reg")
-   (set_attr "simd" "yes,*,yes")
-   (set_attr "fp" "*,yes,*")]
+   (set_attr "arch" "simd,fp,simd")]
 )
 
 (define_insn "*aarch64_combinez_be"
@@ -3129,8 +3124,7 @@
fmov\t%d0, %1
ldr\\t%d0, %1"
   [(set_attr "type" "neon_move, neon_from_gp, neon_load1_1reg")
-   (set_attr "simd" "yes,*,yes")
-   (set_attr "fp" "*,yes,*")]
+   (set_attr "arch" "simd,fp,simd")]
 )
 
 (define_expand "aarch64_combine"
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 
955bf1814b92d2bbf72d46bb2050998385174200..52ad814aafa8645342342cc6d67084af57e4b343
 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -237,41 +237,51 @@
 ;; FP or SIMD registers then the pattern predicate should include TARGET_FLOAT
 ;; or TARGET_SIMD.
 
-;; Attribute that specifies whether or not the instruction touches fp
-;; registers.  When this is set to yes for an alternative, that alternative
-;; will be disabled when !TARGET_FLOAT.