Re: [PATCH/RFC] Add "User Experience Guidelines" to gccint.texi

[Sandra Loosemore]

On 10/12/2018 09:43 AM, David Malcolm wrote:

Here's a proposed "User Experience Guidelines" section for our
internals manual

It's a mixture of proposed policy, together with notes on how to
implement the recommendations.

Thoughts?


I think this documentation will be very helpful.  I'll leave other 
people who've worked on this aspect of the code to comment on the 
content, but a few markup/copy-editing things I noticed while skimming 
the patch:


- Can you please not use double-quote markup around so many words and 
phrases?  If there's a technical term, use @dfn{} at the first use where 
you define it (and probably also an @cindex entry), and no markup on 
subsequent uses.  In most other cases it seemed like the quotes would 
just be distracting from the flow of the text.


- I don't think "end-user" should be hyphenated when used as a noun, 
although as an adjective phrase like "end-user experience" etc is fine.


- Remember to use @noindent when continuing a sentence or paragraph 
broken up by a code example.


I'll take a deeper dive on the next iteration of the patch.

-Sandra

Re: [doc PATCH] mention interaction with noinline in flatten

[Sandra Loosemore]

On 10/11/2018 02:58 PM, Martin Sebor wrote:

While writing tests for attribute flatten I wasn't 100% sure
from reading the manual if it would respect attribute noinline
or if it would override it.  Turns out it's the former so
the attached patch mentions it in the manual.  Unless there
are objections I will commit the change tomorrow.


I've been behind on doc patch review, but for the record, this is fine 
with me.


-Sandra

Re: [PATCH, doc] describe mode checking for doloop_end pattern

[Sandra Loosemore]

On 10/11/2018 09:20 AM, Paul Koning wrote:

Since the code that uses the doloop_end pattern does not check the operand mode 
as given in the pattern, the pattern itself may need to do this, and that was 
not documented.  This patch adds that information.  It also updates the example 
to reflect this.

Ok for trunk?


I have no comments on the technical correctness of this patch, but one 
nit-picky thing that caught my eye



Index: doc/md.texi
===
--- doc/md.texi (revision 265042)
+++ doc/md.texi (working copy)
@@ -7619,7 +7619,23 @@ simplified) from the PDP-11 target:
  
  @smallexample

  @group
-(define_insn "doloop_end"
+(define_expand "doloop_end"
+  [(parallel [(set (pc)
+   (if_then_else
+(ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")


I wonder if the above code line is too long and might overflow the right 
margin.  Did you try to generate a PDF and look at it?  Just to be safe, 
you might try to reformat this example to have less indentation.


Otherwise it looks OK to me.

-Sandra

Re: [ARM/FDPIC v3 01/21] [ARM] FDPIC: Add -mfdpic option support

[Sandra Loosemore]

On 10/12/2018 03:52 AM, Richard Earnshaw (lists) wrote:

On 11/10/18 14:34, Christophe Lyon wrote:

2018-XX-XX  Christophe Lyon  
Mickaël Guêné  

gcc/
* config/arm/arm.opt: Add -mfdpic option.
* doc/invoke.texi: Add documentation for -mfdpic.


This is OK (once the rest of the series is approved).


The documentation looks fine to me too.

-Sandra

Re: [PATCH 3/6] [ARC] Add BI/BIH instruction support.

[Sandra Loosemore]

On 10/10/2018 02:00 AM, Claudiu Zissulescu wrote:

Use BI/BIH instruction to implement casesi pattern. Only ARC V2.


Very minor nit in the documentation part of this patch:


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 802cc642453..454587310c8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -650,7 +650,7 @@ Objective-C and Objective-C++ Dialects}.
  -mmixed-code  -mq-class  -mRcq  -mRcw  -msize-level=@var{level} @gol
  -mtune=@var{cpu}  -mmultcost=@var{num} @gol
  -munalign-prob-threshold=@var{probability}  -mmpy-option=@var{multo} @gol
--mdiv-rem  -mcode-density  -mll64  -mfpu=@var{fpu} -mrf16}
+-mdiv-rem  -mcode-density  -mll64  -mfpu=@var{fpu} -mrf16 -mbranch-index}
  
  @emph{ARM Options}

  @gccoptlist{-mapcs-frame  -mno-apcs-frame @gol


Please consistently use 2 spaces between options listed on the same line 
in these option summary tables.  It makes the output a little easier to 
read.


-Sandra

Re: [PATCH] add simple attribute introspection

[Eric Gallager]

On 10/13/18, Martin Sebor  wrote:
> Attached is an updated/enhanced patch with many more tests
> and the suggested documentation tweak.  It also restores
> the handling of empty attributes that the first revision
> inadvertently removed from the C parser.
>
> The tests are much more comprehensive now but still not
> exhaustive.  I have added warning for the mode attribute
> that cannot be supported.  Enumerator attributes aren't
> detected in C because they are folded to constants before
> they reach the built-in, and label attributes aren't handled
> yet either in C or in C++.  Supporting those will take a minor
> enhancement.  I haven only added handful of test cases for
> x86_64 target attributes,  The built-in is not exercised
> for any other target yet.  I don't expect any surprises
> there.  Either it will work or (where the attributes aren't
> hanging off a node) it will return false.  Supporting those
> will have to wait until the later (I think the best way is
> to add a callback to struct attribute_spec to let each back
> end query a node for the properties unique to such attributes
> analogously to attribute vector_size).
>
> I haven't done any work on supporting templates.  I would
> like to but I don't expect to be able to get it done before
> stage 1 is over (I have another feature I need to finish,
> the one that prompted this work to begin with).  I think
> the new built-in is quite useful even without template
> support.
>
> I've kept the name __builtin_has_attribute: it is close to
> the __has_attribute macro, and I think that's fine because
> the built-in's purpose is very close to that of the macro.

If you're going to keep the name, could you at least explain the
difference between the two in the documentation?

>
> Martin
>
> On 10/11/2018 08:54 AM, Martin Sebor wrote:
>> On 10/11/2018 06:04 AM, Joseph Myers wrote:
>>> On Thu, 11 Oct 2018, Martin Sebor wrote:
>>>
 The attached patch introduces a built-in function called
 __builtin_has_attribute that makes some of this possible.
 See the documentation and tests for details.
>>>
>>> I see nothing in the documentation about handling of equivalent forms of
>>> an attribute - for example, specifying __aligned__ in the attribute but
>>> aligned in __builtin_has_attribute, or vice versa.  I'd expect that to
>>> be
>>> documented to work (both of those should return true), with associated
>>> tests.  (And likewise the semantics should allow for a format attribute
>>> using printf in one place and __printf__ in the other, for example, or
>>> the
>>> same constant argument represented with different expressions.)
>>
>> Yes, it occurred to me belatedly that I should add a test for those
>> as well.  I can also mention it in the documentation, although I'd
>> have thought it would be implicit in how attributes work in general.
>> (Or are there some differences between the underscored forms and
>> the one without it)?
>>
>>>
>>> What are the semantics of __builtin_has_attribute for attributes that
>>> can't be tested for?  (E.g. the mode attribute, which ends up
>>> resulting in
>>> some existing type with the required mode being used, so there's nothing
>>> to indicate the attribute was originally used to declare things.)
>>
>> With a few exceptions (like aligned) the built-in returns false
>> for attributes that aren't attached to a node.  I haven't exercised
>> nearly all the attributes yet, and this one could very well be among
>> those that aren't and perhaps can't be handled.  I suspect some
>> target attributes might be in the same group.  If there's no way
>> to tell it should probably be documented as a limitation of
>> the function, maybe also under the attribute itself that can't
>> be detected.  Alternatively, the built-in return type could be
>> changed to a tri-state: "don't know," false, true.  Can you
>> think of a better solution?
>>
>> Martin
>
>

Re: [PATCH] add simple attribute introspection

[Jeff Law]

On 10/13/18 6:19 PM, Martin Sebor wrote:
> Attached is an updated/enhanced patch with many more tests
> and the suggested documentation tweak.  It also restores
> the handling of empty attributes that the first revision
> inadvertently removed from the C parser.
> 
> The tests are much more comprehensive now but still not
> exhaustive.  I have added warning for the mode attribute
> that cannot be supported.  Enumerator attributes aren't
> detected in C because they are folded to constants before
> they reach the built-in, and label attributes aren't handled
> yet either in C or in C++.  Supporting those will take a minor
> enhancement.  I haven only added handful of test cases for
> x86_64 target attributes,  The built-in is not exercised
> for any other target yet.  I don't expect any surprises
> there.  Either it will work or (where the attributes aren't
> hanging off a node) it will return false.  Supporting those
> will have to wait until the later (I think the best way is
> to add a callback to struct attribute_spec to let each back
> end query a node for the properties unique to such attributes
> analogously to attribute vector_size).
> 
> I haven't done any work on supporting templates.  I would
> like to but I don't expect to be able to get it done before
> stage 1 is over (I have another feature I need to finish,
> the one that prompted this work to begin with).  I think
> the new built-in is quite useful even without template
> support.
> 
> I've kept the name __builtin_has_attribute: it is close to
> the __has_attribute macro, and I think that's fine because
> the built-in's purpose is very close to that of the macro.
> 
> Martin
> 
> 
> 
> gcc-builtin-has-attribute.diff
> 
> gcc/c/ChangeLog:
> 
>   * c-parser.c (c_parser_has_attribute_expression): New function.
>   (c_parser_attribute): New function.
>   (c_parser_attributes): Move code into c_parser_attribute.
>   (c_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION.
> 
> gcc/c-family/ChangeLog:
> 
>   * c-attribs.c (type_for_vector_size): New function.
>   (type_valid_for_vector_size): Same.
>   (handle_vector_size_attribute): Move code to the functions above
>   and call them.
>   (validate_attribute, has_attribute): New functions.
>   * c-common.h (has_attribute): Declare.
>   (rid): Add RID_HAS_ATTRIBUTE_EXPRESSION.
>   * c-common.c (c_common_resword): Same.
> 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (cp_check_const_attributes): Declare.
>   * decl2.c (cp_check_const_attributes): Declare extern.
>   * parser.c (cp_parser_has_attribute_expression): New function.
>   (cp_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION.
>   (cp_parser_gnu_attribute_list): Add argument.
> 
> gcc/ChangeLog:
> 
>   * doc/extend.texi (Other Builtins): Add __builtin_has_attribute.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/builtin-has-attribute-2.c: New test.
>   * c-c++-common/builtin-has-attribute-3.c: New test.
>   * c-c++-common/builtin-has-attribute-4.c: New test.
>   * c-c++-common/builtin-has-attribute.c: New test.
>   * gcc.dg/builtin-has-attribute.c: New test.
>   * gcc/testsuite/gcc.target/i386/builtin-has-attribute.c: New test.
> 
Generally looks OK except for a nit mentioned below.  I don't mind
iterating a bit on the details here over time.  Give Jason a few days to
chime in on the C++ side.

> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 8ffb0cd..dcf4747 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -2649,8 +2649,9 @@ explicit @code{externally_visible} attributes are still 
> necessary.
>  @cindex @code{flatten} function attribute
>  Generally, inlining into a function is limited.  For a function marked with
>  this attribute, every call inside this function is inlined, if possible.
> -Whether the function itself is considered for inlining depends on its size 
> and
> -the current inlining parameters.
> +Functions declared with attribute @code{noinline} and similar are not
> +inlined.  Whether the function itself is considered for inlining depends
> +on its size and the current inlining parameters.
Guessing this was from another doc patch that I think has already been
approved :-)


> @@ -11726,6 +11728,33 @@ check its compatibility with @var{size}.
>  
>  @end deftypefn
>  
> +@deftypefn {Built-in Function} bool __builtin_has_attribute 
> (@var{type-or-expression}, @var{attribute})
> +The @code{__builtin_has_attribute} function evaluates to an integer constant
> +expression equal to @code{true} if the symbol or type referenced by
> +the @var{type-or-expression} argument has been declared with
> +the @var{attribute} referenced by the second argument.  Neither argument
> +is valuated.  The @var{type-or-expression} argument is subject to the same
s/valuated/evaluated/ ?

New Spanish PO file for 'gcc' (version 8.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/gcc/es.po

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

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[PATCH] Fix regression in std::random_device default constructor

[Jonathan Wakely]

When the default constructor was split out into a separate function (in
r261522) I accidentally  made it call _M_init("mt19937") instead of
_M_init_pretr1("mt19937"). That means it will always throw an exception,
because "mt19937" isn't a valid token accepted by the _M_init function.
Restore the original behaviour by calling _M_init_pretr1("mt19937").

* include/bits/random.h (random_device) [!_GLIBCXX_USE_DEV_RANDOM]:
Fix default constructor to call correct function.

Tested x86_64-w64-ming32, committed to trunk.

commit 17aac41d36d894e96b816ae97f5942871e65b254
Author: Jonathan Wakely 
Date:   Tue Oct 16 23:34:23 2018 +0100

Fix regression in std::random_device default constructor

When the default constructor was split out into a separate function (in
r261522) I accidentally  made it call _M_init("mt19937") instead of
_M_init_pretr1("mt19937"). That means it will always throw an exception,
because "mt19937" isn't a valid token accepted by the _M_init function.
Restore the original behaviour by calling _M_init_pretr1("mt19937").

* include/bits/random.h (random_device) [!_GLIBCXX_USE_DEV_RANDOM]:
Fix default constructor to call correct function.

diff --git a/libstdc++-v3/include/bits/random.h 
b/libstdc++-v3/include/bits/random.h
index 5e994aa8836..e02a185e3f0 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -1611,7 +1611,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 ~random_device()
 { _M_fini(); }
 #else
-random_device() { _M_init("mt19937"); }
+random_device() { _M_init_pretr1("mt19937"); }
 
 explicit
 random_device(const std::string& __token)

Re: [PATCH] Switch conversion: support any ax + b transformation (PR tree-optimization/84436).

[Jeff Law]

On 10/11/18 6:56 AM, Martin Liška wrote:
> Hi.
> 
> As seen in the PR, switch conversion can do better when we return equal 
> numbers
> based on index value. I implemented more than that, more precisely I support 
> all linear
> transformation based on index value. It's the same what clang is capable of.
> 
> Patch survives testing on x86_64-linux-gnu. I added various tests that should
> benefit of the transformation.
> 
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-10-11  Martin Liska  
> 
>   PR tree-optimization/84436
>   * tree-switch-conversion.c (switch_conversion::contains_same_values_p):
>   Remove.
>   (switch_conversion::contains_linear_function_p): New.
>   (switch_conversion::build_one_array): Support linear
>   transformation on input.
>   * tree-switch-conversion.h (struct switch_conversion): Add
>   contains_linear_function_p declaration.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-10-11  Martin Liska  
> 
>   PR tree-optimization/84436
>   * gcc.dg/tree-ssa/pr84436-1.c: New test.
>   * gcc.dg/tree-ssa/pr84436-2.c: New test.
>   * gcc.dg/tree-ssa/pr84436-3.c: New test.
>   * gcc.dg/tree-ssa/pr84436-4.c: New test.
>   * gcc.dg/tree-ssa/pr84436-5.c: New test.
> ---
> 
> 
> 
> diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
> index 64169a6cd3d..8f34ab45cb9 100644
> --- a/gcc/tree-switch-conversion.c
> +++ b/gcc/tree-switch-conversion.c
> @@ -439,25 +439,63 @@ switch_conversion::build_constructors ()
>  }
>  }
>  
> -/* If all values in the constructor vector are the same, return the value.
> -   Otherwise return NULL_TREE.  Not supposed to be called for empty
> -   vectors.  */
> +/* If all values in the constructor vector are products of a linear function
> +   a * x + b, then return true.  When true, COEFF_A and COEFF_B and
> +   coefficients of the linear function.  Note that equal values are special
> +   case of a linear function with a and b equal to zero.  */
>  
> -tree
> -switch_conversion::contains_same_values_p (vec *vec)
> +bool
> +switch_conversion::contains_linear_function_p (vec 
> *vec,
> +wide_int *coeff_a,
> +wide_int *coeff_b)
>  {
>unsigned int i;
> -  tree prev = NULL_TREE;
>constructor_elt *elt;
>  
> +  gcc_assert (vec->length () >= 2);
> +
> +  /* Let's try to find any linear function a.x + y that can apply to
> + given values. 'a' can be calculated as follows:
> +
> + a = (y2 - y1) / (x2 - x1) where x2 - x1 = 1 (consecutive case indices)
> + a = y2 - y1
> +
> + and
> +
> + b = y2 - a * x2
> +
> +  */
> +
> +  tree elt0 = (*vec)[0].value;
> +  tree elt1 = (*vec)[1].value;
> +
> +  if (TREE_CODE (elt0) != INTEGER_CST || TREE_CODE (elt1) != INTEGER_CST)
> +return false;
> +
> +  wide_int range_min = wi::to_wide (fold_convert (TREE_TYPE (elt0),
> +   m_range_min));
> +  wide_int y1 = wi::to_wide (elt0);
> +  wide_int y2 = wi::to_wide (elt1);
> +  wide_int a = y2 - y1;
> +  wide_int b = y2 - a * (range_min + 1);
> +
> +  /* Verify that all values fulfill the linear function.  */
>FOR_EACH_VEC_SAFE_ELT (vec, i, elt)
>  {
> -  if (!prev)
> - prev = elt->value;
> -  else if (!operand_equal_p (elt->value, prev, OEP_ONLY_CONST))
> - return NULL_TREE;
> +  if (TREE_CODE (elt->value) != INTEGER_CST)
> + return false;
> +
> +  wide_int value = wi::to_wide (elt->value);
> +  if (a * range_min + b != value)
> + return false;
ISTM that if we overflow the ax + b, then we're not going to be equal to
value here, right?  I think Jakub and at least someone else was
concerned about that possibility.

Assuming overflow isn't a problem, this is OK.

jeff

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Jeff Law]

On 10/8/18 5:22 PM, Martin Sebor wrote:
> Attached is an updated patch with the INTEGRAL_TYPE_P test added
> to detect constant non-integer arguments like (void*)0, and with
> quoting made unconditional.  I also removed the pretty printer
> business to avoid the "value%s" format, and modified the manual
> to clarify when each of the attributes are applicable and what
> their meaningful argument values are.
> 
> On 10/07/2018 04:38 PM, Martin Sebor wrote:
>> While still testing an enhancement in the area of attributes
>> I ran across bugs and inconsistencies in how different handlers
>> deal with positional arguments.  The bugs are either an ICE due
>> to the handlers not consistently converting positional arguments
>> to constants (i.e., CONST_DEL to INTEGER_CST in C++) for which
>> downstream code is unprepared (PR 87541), or errors for valid
>> code (PR 87542), or failing to diagnose invalid arguments.
>> The other inconsistencies are simply in responding to the same
>> invalid condition differently for different attributes .
>>
>> The attached patch introduces a new function to do validate
>> positional arguments in a uniform way and replaces the existing
>> handling with it.
>>
>> As a consequence of the handling being made consistent a number
>> of tests needed adjusting. In addition, some invalid arguments
>> that were previously rejected with a hard error are diagnosed
>> with just a warning (invalid argument values in attribute format),
>> and in one other instance what previously triggered a warning is
>> now accepted without one (attribute alloc_size on a function
>> without a prototype).  I'd be up tightening things up if that's
>> preferable as long it's done consistently.
>>
>> Tested on x86_64-linux.
>>
>> Martin
>>
>> PS It would be nice to have a general policy for how to respond
>> to invalid attribute arguments (warning or error).  Even better,
>> it would be ideal to move the validation from the front-ends and
>> back-ends into the middle-end.  I.e., describe attribute arguments
>> in more detail in struct attribute_spec and have decl_attributes
>> validate nut just the number of arguments but also their types
>> and, when appropriate, expected values.
> 
> 
> gcc-87541.diff
> 
> PR c++/87541 - ICE using a constant decl as an attribute alloc_size argument
> PR c++/87542 - bogus error on attribute format with a named constant argument
> 
> gcc/ChangeLog:
> 
>   PR c++/87541
>   PR c++/87542
>   * tree.c (type_argument_type): New function.
>   * tree.h (type_argument_type): Declare it.
>   * gcc/doc/extend.texi (alloc_align): Update and clarify.
>   (alloc_size, nonnull, sentinel): Same.
> 
> gcc/c-family/ChangeLog:
> 
>   PR c++/87541
>   PR c++/87542
>   * c-attribs.c (positional_argument): New function.
>   (handle_alloc_size_attribute): Use it and simplify.
>   (handle_alloc_align_attribute): Same.
>   (handle_assume_aligned_attribute): Same.
>   (handle_nonnull_attribute): Same.
>   * c-common.c (check_function_arguments): Pass fntype to
>   check_function_format.
>   * c-common.h (check_function_format): Add an argument.
>   (PosArgFlags, positional_argument): Declare new type and function.
>   * c-format.c (decode_format_attr): Add arguments.
>   (check_format_string, get_constant): Same.
>   (convert_format_name_to_system_name): Adjust.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/87541
>   PR c++/87542
>   * g++.dg/ext/attr-alloc_size.C: New test.
>   * c-c++-common/pr71574.c: Adjust diagnostics.
>   * c-c++-common/attributes-1.c: Same.
>   * gcc.dg/attr-alloc_align-2.c: Same.
>   * gcc.dg/attr-alloc_align-4.c: New test.
>   * gcc.dg/attr-alloc_size-2.c: Adjust diagnostics.
>   * gcc.dg/attr-alloc_size.c: Same.
>   * gcc.dg/attr-assume_aligned-4.c: New test.
>   * gcc.dg/format/attr-3.c: Adjust diagnostics.
>   * gcc.dg/nonnull-2.c: Same.
>   * obj-c++.dg/attributes/method-format-1.mm: Same.
>   * obj-c++.dg/attributes/method-nonnull-1.mm: Same.
>   * objc.dg/attributes/method-format-1.m: same.
>   * objc.dg/attributes/method-nonnull-1.m: Same.



> Index: gcc/c-family/c-common.c
> @@ -1322,6 +1323,18 @@ extern int tm_attr_to_mask (tree);
>  extern tree tm_mask_to_attr (int);
>  extern tree find_tm_attribute (tree);
>  
> +/* A bitmap of flags to positional_argument.  */
> +enum PosArgFlags {
> +  /* Consider positional attribute argument value zero valid.  */
> +  posarg_zero = 1,
> +  /* Consider positional attribute argument value valid if it refers
> + to the ellipsis (i.e., beyond the last typed argument).  */
> +  posarg_ellipsis = 2
> +};
> +
> +extern tree positional_argument (const_tree, const_tree, tree, tree_code,
> +  int = 0, int = PosArgFlags ());
> +
>  extern enum flt_eval_method
>  excess_precision_mode_join (enum flt_eval_method, enum flt_eval_method);
No camel case.  Make the enum type lowe

Re: [PATCH 3/6] [ARC] Add BI/BIH instruction support.

[Andrew Burgess]

* Claudiu Zissulescu  [2018-10-10 11:00:13 +0300]:

> Use BI/BIH instruction to implement casesi pattern. Only ARC V2.

This removes the compact-casesi as an option for earlier ARC, right?
Was there a reason why that had to be done?

> 
> gcc/
> 2018-03-21  Claudiu Zissulescu  
> 
>   * config/arc/arc.c (arc_override_options): Remove
>   TARGET_COMPACT_CASESI.
>   * config/arc/arc.h (ASM_OUTPUT_ADDR_DIFF_ELT): Update.
>   (CASE_VECTOR_MODE): Likewise.
>   (CASE_VECTOR_PC_RELATIVE): Likewise.
>   (CASE_VECTOR_SHORTEN_MODE): Likewise.
>   (CASE_VECTOR_SHORTEN_MODE1): Delete.
>   (ADDR_VEC_ALIGN): Update.
>   (ASM_OUTPUT_CASE_LABEL): Undefine.
>   (ASM_OUTPUT_BEFORE_CASE_LABEL): Undefine.
>   (TARGET_BI_BIH): Define.
>   (DEFAULT_BRANCH_INDEX): Likewise.
>   * config/arc/arc.md (casesi): Rework to accept BI/BIH
>   instructions, remove compact_casesi use case.
>   (casesi_compact_jump): Remove.
>   (casesi_dispatch): New pattern.
>   * config/arc/arc.opt: Add mbranch-index option. Deprecate
>   compact_casesi option.
>   * doc/invoke.texi: Document mbranch-index option.

I guess if you feel that dropping compact-casesi support for earlier
targets is appropriate, then that's fine.  There's some formatting
issues I point out below.  But otherwise seems reasonable.

Thanks,
Andrew

> 
> gcc/testsuite
> Claudiu Zissulescu  
> 
>   * gcc.target/arc/jumptable.c: New test.
> ---
>  gcc/config/arc/arc.c |  19 --
>  gcc/config/arc/arc.h | 106 ++-
>  gcc/config/arc/arc.md| 218 +++
>  gcc/config/arc/arc.opt   |   6 +-
>  gcc/doc/invoke.texi  |   9 +-
>  gcc/testsuite/gcc.target/arc/jumptable.c |  34 
>  6 files changed, 171 insertions(+), 221 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arc/jumptable.c
> 
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 56f566795ff..18dd0de6af7 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -1291,33 +1291,14 @@ arc_override_options (void)
>if (arc_size_opt_level == 3)
>  optimize_size = 1;
>  
> -  /* Compact casesi is not a valid option for ARCv2 family.  */
> -  if (TARGET_V2)
> -{
> -  if (TARGET_COMPACT_CASESI)
> - {
> -   warning (OPT_mcompact_casesi,
> -"compact-casesi is not applicable to ARCv2");
> -   TARGET_COMPACT_CASESI = 0;
> - }
> -}
> -  else if (optimize_size == 1
> -&& !global_options_set.x_TARGET_COMPACT_CASESI)
> -TARGET_COMPACT_CASESI = 1;
> -
>if (flag_pic)
>  target_flags |= MASK_NO_SDATA_SET;
>  
>if (flag_no_common == 255)
>  flag_no_common = !TARGET_NO_SDATA_SET;
>  
> -  /* TARGET_COMPACT_CASESI needs the "q" register class.  */
>if (TARGET_MIXED_CODE)
>  TARGET_Q_CLASS = 1;
> -  if (!TARGET_Q_CLASS)
> -TARGET_COMPACT_CASESI = 0;
> -  if (TARGET_COMPACT_CASESI)
> -TARGET_CASE_VECTOR_PC_RELATIVE = 1;
>  
>/* Check for small data option */
>if (!global_options_set.x_g_switch_value && !TARGET_NO_SDATA_SET)
> diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
> index dd78a6bbbd1..cb48b85d6e7 100644
> --- a/gcc/config/arc/arc.h
> +++ b/gcc/config/arc/arc.h
> @@ -1264,25 +1264,39 @@ do {  
> \
>  } while (0)
>  
>  /* This is how to output an element of a case-vector that is relative.  */
> -#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \
> -do { \
> -  char label[30];\
> -  ASM_GENERATE_INTERNAL_LABEL (label, "L", VALUE);   \
> -  switch (GET_MODE (BODY))   \
> -{\
> -case E_QImode: fprintf (FILE, "\t.byte "); break;\
> -case E_HImode: fprintf (FILE, "\t.hword "); break;   \
> -case E_SImode: fprintf (FILE, "\t.word "); break;\
> -default: gcc_unreachable (); \
> -}\
> -  assemble_name (FILE, label);   \
> -  fprintf (FILE, "-");   \
> -  ASM_GENERATE_INTERNAL_LABEL (label, "L", REL); \
> -  assemble_name (FILE, label);   \
> -  if (TARGET_COMPACT_CASESI) \
> -fprintf (FILE, " + %d", 4 + arc_get_unalign ()); \
> -  fprintf(FILE, "\n");  \
> -} while (0)
> +#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \
> +  do {   \
> +char label[30];  \
> +ASM_GENERATE_INTERNAL_LABEL (label, "L", VALUE); \
> +if (!TARGET_BI_BIH)  \
> +  {   

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Joseph Myers]

On Tue, 16 Oct 2018, Richard Sandiford wrote:

> > as Joseph pointed out, there are some related discussions
> > on the WG14 reflector. How a about moving the discussion
> > there?
> 
> The idea was to get a feel for what would be acceptable to GCC
> maintainers.  When Arm presented an extension of P0214 to support SVE
> at the last C++ committee meeting, using this sizeless type extension
> as a possible way of providing the underlying vector types, the feeling
> seemed to be that it wouldn't be considered unless it had already been
> proven in compilers.

But as shown in the related discussions, there are other possible features 
that might also involve non-VLA types whose size is not a compile-time 
constant.  And so it's necessary to work with the people interested in 
those features in order to clarify what the underlying concepts ought to 
look like to support different such features.

> I think it is for some poople though.  If the vectors don't decay to
> pointers, they're moe akin to a VLA wrapped in a structure rather than
> a stand-alone VLA.  There is a GNU extension for that, e.g.:
> 
>   int
>   f (int n)
>   {
> struct s {
>   int x[n];
> } foo;
> return sizeof (foo.x);
>   }
> 
> But even though clang supports VLAs (of course), it rejects the
> above with:
> 
>   error: fields must have a constant size: 'variable length array in 
> structure' extension will never be supported
> 
> This gives a strong impression that wrapping a VLA type like this
> is a bridge too far for some :-)  The message makes it clear that's
> a case of "don't even bother asking".

What are the clang concerns about VLAs in structs that are the reason for 
not supporting them?  How do the sizeless structs with sizeless members in 
your proposal avoid those concerns about the definition of VLAs in 
structs?

> The problem isn't so much that the size is only known at runtime,
> but that the size isn't necessarily invariant, and the size of an
> object doesn't carry the size information with it.
> 
> This means you can't tell what size a given object is, even at runtime.

How then is e.g. passing a pointer to such a struct (containing such 
unknown-size members) to another function supposed to work?  Or is there 
something in your proposed standard text edits that would disallow passing 
such a pointer, or disallow using "->" with it to access members?

> All you can tell is what size the object would be if you created it
> from scratch.  E.g.:
> 
>   svint8_t *ptr;  // pointer to variable-length vector type
> 
>   void thread1 (void)
>   {
> svint8_t local;
> *ptr = &local;
> ...run for a long time...
>   }
> 
>   void thread2 (void)
>   {
> ... sizeof (*ptr); ...;
>   }
> 
> If thread1 and thread2 have different vector lengths, thread2 has no way
> of knowing what size *ptr is.
> 
> Of course, thread2 can't validly use *ptr if it has wider vectors than
> thread1, but if we resort to saying "undefined behavior" for the above,
> then it becomes difficult to define when the size actually is defined.

What in your standard text edits serves to make that undefined?  
Generally, what in those edits serves to say when conversions involving 
such types, or pointers thereto, or accesses through compatible types in 
different places, are or are not defined?

In standard C, for example, we have for VLAs 6.7.6.2#6, "If the two array 
types are used in a context which requires them to be compatible, it is 
undefined behavior if the two size specifiers evaluate to unequal 
values.".  What is the analogue of this for sizeless types?  Since unlike 
VLAs you're allowing these types, and sizeless structs containing them, to 
be passed by value, assigned, etc., you need something like that to 
determine whether assignment, conditional expression, function argument 
passing, function return, access via a pointer, etc., are valid.

Can these types be used with _Atomic?  I don't see anything to say they 
can't.

Can these types be passed to variadic functions and named in va_arg?  
Again, I don't see anything to say they can't.

Can you have file-scope, and so static-storage-duration, compound literals 
with these types?  You're allowing compound literals with these types, and 
what you have disallowing objects with these types with non-automatic 
storage duration seems to be specific to the case of "an identifier for an 
object".

I don't see any change proposed to 6.2.6.1#2 corresponding to what you say 
elsewhere about discontiguous representations of sizeless structures.

> But do you have any feel for whether this would ever be acceptable
> in C++?  One of the main requirements for this was that it needs
> to work in both C and C++, with the same ABI representation.
> I thought VLAs were added to an early draft of C++14 and then
> removed before it was published.  They weren't added back for C++17,
> and I'd seen other proposals about classes having a "sizeof field"
> instead (i.e. the type would carry th

Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

[Jeff Law]

On 10/4/18 9:51 AM, Martin Sebor wrote:
> On 10/04/2018 08:58 AM, Jeff Law wrote:
>> On 8/27/18 9:42 AM, Richard Biener wrote:
>>> On Mon, Aug 27, 2018 at 5:32 PM Jeff Law  wrote:

 On 08/27/2018 02:29 AM, Richard Biener wrote:
> On Sun, Aug 26, 2018 at 7:26 AM Jeff Law  wrote:
>>
>> On 08/24/2018 09:58 AM, Martin Sebor wrote:
>>> The warning suppression for -Wstringop-truncation looks for
>>> the next statement after a truncating strncpy to see if it
>>> adds a terminating nul.  This only works when the next
>>> statement can be reached using the Gimple statement iterator
>>> which isn't until after gimplification.  As a result, strncpy
>>> calls that truncate their constant argument that are being
>>> folded to memcpy this early get diagnosed even if they are
>>> followed by the nul assignment:
>>>
>>>   const char s[] = "12345";
>>>   char d[3];
>>>
>>>   void f (void)
>>>   {
>>>     strncpy (d, s, sizeof d - 1);   // -Wstringop-truncation
>>>     d[sizeof d - 1] = 0;
>>>   }
>>>
>>> To avoid the warning I propose to defer folding strncpy to
>>> memcpy until the pointer to the basic block the strnpy call
>>> is in can be used to try to reach the next statement (this
>>> happens as early as ccp1).  I'm aware of the preference to
>>> fold things early but in the case of strncpy (a relatively
>>> rarely used function that is often misused), getting
>>> the warning right while folding a bit later but still fairly
>>> early on seems like a reasonable compromise.  I fear that
>>> otherwise, the false positives will drive users to adopt
>>> other unsafe solutions (like memcpy) where these kinds of
>>> bugs cannot be as readily detected.
>>>
>>> Tested on x86_64-linux.
>>>
>>> Martin
>>>
>>> PS There still are outstanding cases where the warning can
>>> be avoided.  I xfailed them in the test for now but will
>>> still try to get them to work for GCC 9.
>>>
>>> gcc-87028.diff
>>>
>>>
>>> PR tree-optimization/87028 - false positive -Wstringop-truncation
>>> strncpy with global variable source string
>>> gcc/ChangeLog:
>>>
>>>   PR tree-optimization/87028
>>>   * gimple-fold.c (gimple_fold_builtin_strncpy): Avoid
>>> folding when
>>>   statement doesn't belong to a basic block.
>>>   * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Handle
>>> MEM_REF on
>>>   the left hand side of assignment.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>>   PR tree-optimization/87028
>>>   * c-c++-common/Wstringop-truncation.c: Remove xfails.
>>>   * gcc.dg/Wstringop-truncation-5.c: New test.
>>>
>>> diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
>>> index 07341eb..284c2fb 100644
>>> --- a/gcc/gimple-fold.c
>>> +++ b/gcc/gimple-fold.c
>>> @@ -1702,6 +1702,11 @@ gimple_fold_builtin_strncpy
>>> (gimple_stmt_iterator *gsi,
>>>    if (tree_int_cst_lt (ssize, len))
>>>  return false;
>>>
>>> +  /* Defer warning (and folding) until the next statement in the
>>> basic
>>> + block is reachable.  */
>>> +  if (!gimple_bb (stmt))
>>> +    return false;
>> I think you want cfun->cfg as the test here.  They should be
>> equivalent
>> in practice.
>
> Please do not add 'cfun' references.  Note that the next stmt is
> also accessible
> when there is no CFG.  I guess the issue is that we fold this during
> gimplification where the next stmt is not yet "there" (but still in
> GENERIC)?
 That was my assumption.  I almost suggested peeking at gsi_next and
 avoiding in that case.
>>>
>>> So I'd rather add guards to maybe_fold_stmt in the gimplifier then.
>> So I think the concern with adding the guards to maybe_fold_stmt is the
>> possibility of further fallout.
>>
>> I guess they could be written to target this case specifically to
>> minimize fallout, but that feels like we're doing the same thing
>> (band-aid) just in a different place.
>>
>>
>>
>>>
>
> We generally do not want to have unfolded stmts in the IL when we
> can avoid that
> which is why we fold most stmts during gimplification.  We also do
> that because
> we now do less folding on GENERIC.
 But an unfolded call in the IL should always be safe and we've got
 plenty of opportunities to fold it later.
>>>
>>> Well - we do.  The very first one is forwprop though which means
>>> we'll miss to
>>> re-write some memcpy parts into SSA:
>>>
>>>   NEXT_PASS (pass_ccp, false /* nonzero_p */);
>>>   /* After CCP we rewrite no longer addressed locals into SSA
>>>  form if possible.  */
>>>   NEXT_PASS (pass_forwprop);
>>>
>>> likewise early object-size will be confused by memcpy calls that just
>>> exist
>>> to avoid TBAA issues (another of 

Re: [C++ Patch, obvious] PR 84705 ("[6/7/8/9 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390")

[Paolo Carlini]

Hi,

On 16/10/18 22:49, Jason Merrill wrote:

On Tue, Oct 16, 2018 at 2:39 PM Paolo Carlini  wrote:

the main issue is already fixed in trunk - we don't ICE anymore - but I
noticed that for ill-formed code like:

  int i = static_cast(i);

we emit a duplicate diagnostic about the incomplete type d, easy to
avoid by returning error_mark_node from
perform_direct_initialization_if_possible when build_special_member_call
returns it. I think this latter tweak qualifies as obvious, per a
comment made by Jason a while ago...

Yes, but in this case it might be better to handle it in
build_cplus_new, to also cover other uses of that function.


Ok... Then, I'm finishing testing the below. Thanks!

Paolo.



Index: cp/tree.c
===
--- cp/tree.c   (revision 265200)
+++ cp/tree.c   (working copy)
@@ -646,6 +646,9 @@ build_cplus_new (tree type, tree init, tsubst_flag
   tree rval = build_aggr_init_expr (type, init);
   tree slot;
 
+  if (init == error_mark_node)
+return error_mark_node;
+
   if (!complete_type_or_maybe_complain (type, init, complain))
 return error_mark_node;
 
Index: testsuite/g++.dg/cpp0x/pr84705.C
===
--- testsuite/g++.dg/cpp0x/pr84705.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr84705.C(working copy)
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+int a[]{a};  // { dg-error "invalid conversion" }
+
+template
+struct b {
+  __attribute__((c([] {
+struct {
+  int a = static_cast(a);  // { dg-error "invalid use of 
incomplete type" }
+} e;
+  })));
+};

Re: [Patch, Fortran] PR67125 - ALLOCATE with source-expr lbounds/ubound off by one

[Tobias Burnus]

Hi Paul,

thanks for the review; committed as Rev. 265212.

Using your check in gfc_array_allocate won't work as already early in 
gfc_trans_allocate everything is converted to a descriptor – likewise, 
checking "expr3" wouldn't work either.


I was pondering whether to check it elsewhere in gfc_trans_allocate, but 
I think it wouldn't be straight forward either and, hence, I left it as is.


After looking at the current code of the function, I decided to check 
CLASS – and decided to add those additional experiments to the test case 
– see attachment (committed as Rev. 265215).



Tobias

Paul Richard Thomas wrote:

Hi Tobias,

Your patch is OK for trunk and, I would suggest 8-branch.

As a matter of curiosity, why did you not use the condition:
if (!(expr3_desc && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (expr3_desc)))  ?

Your solution is fine, though.

Cheers

Paul

On Fri, 12 Oct 2018 at 12:29, Tobias Burnus
 wrote:

Hello all,

"When an ALLOCATE statement is executed for an array with no
  allocate-shape-spec-list, the bounds of source-expr determine
  the bounds of the array." (F2018, 9.7.1.2 (6))

That seems to work fine for arrays which have an array descriptor.
However, as the current code shows, it fails for array constructors
where the lbound is zero instead of the expected one.

It turns out (PR67125) that functions results which don't use array
descriptors have the same problem as do stack/static allocated
array variables (PR87580).

I am not sure that my check for array descriptors is the best but
it seems to work and fixes the problem.

OK for the trunk?
Build and regtested on x86-64-linux.

Tobias

Re: [PATCH/RFC] Add "User Experience Guidelines" to gccint.texi

[Jeff Law]

On 10/12/18 9:43 AM, David Malcolm wrote:
> Here's a proposed "User Experience Guidelines" section for our
> internals manual
> 
> It's a mixture of proposed policy, together with notes on how to
> implement the recommendations.
> 
> Thoughts?
> 
> gcc/ChangeLog:
>   * Makefile.in (TEXI_GCCINT_FILES): Add ux.texi.
>   * doc/gccint.texi: Include ux.texi and use it in top-level menu.
>   * doc/ux.texi: New file.
I'll ACK with the explicit caveat that we may need to adjust the coding
conventions (those are usually a wonderful discussion unto themselves).
 We shouldn't consider these written in stone at this time.

I'll also note that the guidelines are a reasonable direction, they do
not necessarily reflect current state everywhere.

jeff

Re: [C++ Patch, obvious] PR 84705 ("[6/7/8/9 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390")

[Jason Merrill]

On Tue, Oct 16, 2018 at 2:39 PM Paolo Carlini  wrote:
> the main issue is already fixed in trunk - we don't ICE anymore - but I
> noticed that for ill-formed code like:
>
>  int i = static_cast(i);
>
> we emit a duplicate diagnostic about the incomplete type d, easy to
> avoid by returning error_mark_node from
> perform_direct_initialization_if_possible when build_special_member_call
> returns it. I think this latter tweak qualifies as obvious, per a
> comment made by Jason a while ago...

Yes, but in this case it might be better to handle it in
build_cplus_new, to also cover other uses of that function.

Jason

Re: [Patch, fortran] PR56386 - [F03] ICE with ASSOCIATE construct and an derived type array component

[Tobias Burnus]

Paul Richard Thomas wrote:


This is a semi-obvious patch that fixes no fewer than five PRs: 56386,
58906, 77385, 80260 & 82077. The last two are marked as 7/8/9
regressions and so, although I haven't tested it yet, I suppose that
the others must be too. Thanks to Dominique for picking up the other
four PRs that are fixed by this patch.

Bootstrapped and regtested on FC28/x86_64 - OK for trunk, then 7- and
8-branches?


OK – but it is really only semi-obvious.

Tobias


2018-10-16  Paul Thomas  

 PR fortran/56386
 PR fortran/58906
 PR fortran/77385
 PR fortran/80260
 PR fortran/82077
 * resolve.c (resolve_variable): Fix up expressions with array
 associate names, where the parser did not detect that this is
 array and there was no array part_ref in the expression.

2018-10-16  Paul Thomas  

 PR fortran/56386
 PR fortran/58906
 PR fortran/77385
 * gfortran.dg/associate_44.f90 : New test.

 PR fortran/80260
 * gfortran.dg/select_type_45.f90 : New test.

 PR fortran/82077
 * gfortran.dg/select_type_46.f90 : New test.

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Jeff Law]

On 10/12/18 8:36 AM, Giuliano Augusto Faulin Belinassi wrote:
> Hello.
> I don't think there is a need for overflow handling here because
> the argument is bound by the argument of the sqrt function :-)
Yea, I guess you're right.  The domain of arctanh is -1 to 1, so I guess
we're safe there.  Except for the case where  the input is -1 or 1 in
which case I think you just set the output to +- INF as appropriate.

Hmm, do we have problems as we get close to -1 or 1 where the outputs of
the two forms might diverge?

Jeff

Re: [PATCH] v2: Run selftests for C++ as well as C

[Jeff Law]

On 10/13/18 7:12 AM, David Malcolm wrote:
> On Fri, 2018-10-12 at 14:17 -0400, David Malcolm wrote:
>> On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote:
>>> [re this thread "ToT build failure?":
>>>   https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
>>>
>>> On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote:
 On Thu, Jul 06, 2017 at 01:45:42PM -0400, David Malcolm wrote:
> Given that the previous status quo of the selftests was to
> require
> the
> C frontend, I committed the attached patch (as r250036), under
> the
> "obvious" rule, retaining the ability to optionally run the
> selftests
> within the C++ frontend.

 You should do something similar for how we make check etc.:
 CHECK_TARGETS = @check_languages@

 check: $(CHECK_TARGETS)

 and then each Make-lang.in defining its check- goal.
 So similarly to that s-selftest-c++ should be in cp/Make-lang.in
 and based on the configured languages should include the s-
 selftest-
 
 dependencies.

Jakub
>>>
>>> Thanks.
>>>
>>> I attemped the above, but it required each Make-lang.in to define
>>> a check- goal, but there are only two that make sense to run
>>> (those that set LANG_HOOKS_RUN_LANG_SELFTESTS: C and C++).
>>>
>>> Rather than add one to every Make-lang.in, I borrowing the "append"
>>> approach used by "lang_checks", so that only the Make-lang.in files
>>> that opt-in to having selftests need to do anything, appending
>>> their s-selftest- to lang_selftests.
>>>
>>> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>>> I manually verified that the self-tests were run 6 times: C and
>>> C++,
>>> for each of the three stages (each run taking well under a second).
>>>
>>> OK for trunk?
>>
>> Sorry; I failed to properly check the case Steve ran into back in
>> July,
>> and my patch doesn't handle it (all of the Make-lang.in files are
>> included, regardless of configuration, via LANG_MAKEFRAGS).
>>
>> I'm working on an updated patch.
>>
>> Dave
> 
> Here's an updated version; sorry for the earlier noise.
> 
> This one follows the approach you suggested, adding a SELFTEST_TARGETS
> built from a configure-supplied selftest_languages.  Each Make-lang.in
> defines a selftest-LANG, which becomes a dependency of "selftest".
> Almost all of the selftest-LANG are empty, apart from those for c and c++.
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> As before, I manually verified that the self-tests were run 6 times: c and
> c++, for each of the three stages (each run taking well under a second).
> This time I also verified that it builds successfully without c++ (via:
> "--enable-languages=c --disable-bootstrap"), for which it just ran the
> c selftests.
> 
> OK for trunk?
> 
> gcc/ChangeLog:
>   * Makefile.in (SELFTEST_TARGETS): New.
>   (selftest) Change from s-selftest-c to $(SELFTEST_TARGETS).
>   (C_SELFTEST_FLAGS, C_SELFTEST_DEPS, s-selftest-c, selftest-c-gdb)
>   (selftest-gdb, selftest-c-valgrind, selftest-valgrind): Move to
>   c/Make-lang.in.
>   (CPP_SELFTEST_FLAGS, CPP_SELFTEST_DEPS, s-selftest-c++)
>   (selftest-c++-gdb, selftest-c++-valgrind): Move to
>   cp/Make-lang.in.
>   * configure: Regenerate.
>   * configure.ac (selftest_languages): New.
> 
> gcc/brig/ChangeLog:
>   * Make-lang.in (selftest-brig): New.
> 
> gcc/c/ChangeLog:
>   * Make-lang.in (selftest-c): New.
>   (C_SELFTEST_FLAGS, C_SELFTEST_DEPS, s-selftest-c, selftest-c-gdb)
>   (selftest-gdb, selftest-c-valgrind, selftest-valgrind): Move here
>   from gcc/Makefile.in.
> 
> gcc/cp/ChangeLog:
>   * Make-lang.in (selftest-c++): New.
>   (CPP_SELFTEST_FLAGS, CPP_SELFTEST_DEPS, s-selftest-c++)
>   (selftest-c++-gdb, selftest-c++-valgrind): Move here from
>   gcc/Makefile.in.
> 
> gcc/fortran/ChangeLog:
>   * Make-lang.in (selftest-fortran): New.
> 
> gcc/go/ChangeLog:
>   * Make-lang.in (selftest-go): New.
> 
> gcc/jit/ChangeLog:
>   * Make-lang.in (selftest-jit): New.
> 
> gcc/lto/ChangeLog:
>   * Make-lang.in (selftest-lto): New.
> 
> gcc/objc/ChangeLog:
>   * Make-lang.in (selftest-objc): New.
> 
> gcc/objcp/ChangeLog:
>   * Make-lang.in (selftest-obj-c++): New.
> ---
OK.
jeff

Re: [RFC PATCH] libgcc: apply LIB2FUNCS_EXCLUDE logic to LIB2FUNCS_ST

[Jeff Law]

On 10/15/18 1:36 AM, Rasmus Villemoes wrote:
> One target file (config/c6x/t-elf) lists _printf and _gcc_bcmp in
> LIB2FUNCS_EXCLUDE, but that does not have any effect, since those are
> not filtered away from LIB2FUNCS_ST. Another option is to do as in
> config/rl78/t-rl78, which explicitly sets LIB2FUNCS_ST
> 
> # Remove __gcc_bcmp from LIB2FUNCS_ST
> LIB2FUNCS_ST = _eprintf
> 
> but honouring LIB2FUNCS_EXCLUDE also for LIB2FUNCS_ST seems more
> natural.
> 
> ==changelog==
> 
> libgcc/
> 
>   * Makefile.in: Filter out LIB2FUNCS_EXCLUDE from LIB2FUNCS_ST.
OK.  But please write the ChangeLog entry like

* Makefile.in (LIB2FUNCS_ST): Filter out LIB2FUNCS_EXCLUDE.

Jeff

C++: is there a good way to check for a valid no-op conversion?

[David Malcolm]

I've been extending -fopt-info to cover inlining, and I added a %S
format code to dump_printf which accepts a symtab_node *.

Unfortunately, -Wformat doesn't like the fact that I'm passing in a
subclass pointer (cgraph_node *), e.g.:

ipa-inline.c: In function ‘unsigned int early_inliner(function*)’:
ipa-inline.c:2769:21: error: format ‘%S’ expects argument of type 
‘symtab_node*’,
but argument 3 has type ‘cgraph_node*’ [-Werror=format=]
2769 |"Flattening %S\n", node);
 |~^ 
 | | |
 | | cgraph_node*
 | symtab_node*

I could fix this by changing my format converter so that explicitly
takes a cgraph_node *, but I wondered if it would be better to instead
teach -Wformat to accept non-virtual subclass pointers, so that %S can
handle symtab_node * and its two subclasses.

Does this sound sane, and is there a conversion function I can call for
this case?  cp_convert_to_pointer seemed the closest match.

Thanks
Dave

[v3 PATCH] PR libstdc++/87619

[Ville Voutilainen]

Simple, short, and sweet, just a thinko.

2018-10-16  Ville Voutilainen  

PR libstdc++/87619
* include/std/variant (__select_index): Fix an off-by-one.
* testsuite/20_util/variant/87619.cc: New.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 2d86a70..55b6440 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -362,7 +362,7 @@ namespace __variant
 
   template 
   using __select_index =
-typename __select_int::_Select_int_base::type::value_type;
 
diff --git a/libstdc++-v3/testsuite/20_util/variant/87619.cc b/libstdc++-v3/testsuite/20_util/variant/87619.cc
new file mode 100644
index 000..a8db6b8
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/variant/87619.cc
@@ -0,0 +1,46 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17" }
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+
+
+template
+struct S {
+};
+
+template 
+void f_impl(std::index_sequence)
+{
+	using V = std::variant...>;
+	static_assert(sizeof(V) == 2);
+}
+
+template 
+void f()
+{
+	f_impl(std::make_index_sequence{});
+}
+
+int main()
+{
+	f<254>();
+	f<255>();
+}

[PATCH v5 08/10] testsuite: Mark that PRU has one-cycle jumps

[Dimitar Dimitrov]

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* gcc.dg/tree-ssa/20040204-1.c: XFAIL on pru.
* gcc.dg/tree-ssa/reassoc-33.c: Ditto.
* gcc.dg/tree-ssa/reassoc-34.c: Ditto.
* gcc.dg/tree-ssa/reassoc-35.c: Ditto.
* gcc.dg/tree-ssa/reassoc-36.c: Ditto.
* gcc.dg/tree-ssa/ssa-thread-14.c: Ditto.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c
index a1237cf839b..06b83029fd3 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c
@@ -33,4 +33,4 @@ void test55 (int x, int y)
that the && should be emitted (based on BRANCH_COST).  Fix this
by teaching dom to look through && and register all components
as true.  */
-/* { dg-final { scan-tree-dump-times "link_error" 0 "optimized" { xfail { ! 
"alpha*-*-* arm*-*-* aarch64*-*-* powerpc*-*-* cris-*-* crisv32-*-* hppa*-*-* 
i?86-*-* mmix-*-* mips*-*-* m68k*-*-* moxie-*-* nds32*-*-* s390*-*-* sh*-*-* 
sparc*-*-* spu-*-* visium-*-* x86_64-*-* riscv*-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "link_error" 0 "optimized" { xfail { ! 
"alpha*-*-* arm*-*-* aarch64*-*-* powerpc*-*-* cris-*-* crisv32-*-* hppa*-*-* 
i?86-*-* mmix-*-* mips*-*-* m68k*-*-* moxie-*-* nds32*-*-* s390*-*-* sh*-*-* 
sparc*-*-* spu-*-* visium-*-* x86_64-*-* riscv*-*-* pru*-*-*" } } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c 
b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c
index 5572df4ae24..5e1cd1a6fa7 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-*"} } } */
+/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-* pru*-*-*"} } } */
 
 /* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
 /* { dg-additional-options "-mbranch-cost=2" { target branch_cost } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c 
b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c
index 9b45f1cd9be..a59df6a7244 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-*"} } } */
+/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-* pru*-*-*"} } } */
 
 /* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
 /* { dg-additional-options "-mbranch-cost=2" { target branch_cost } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c 
b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c
index 9ee3abca04e..21239372709 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-*"} } } */
+/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-* pru*-*-*"} } } */
 
 /* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
 /* { dg-additional-options "-mbranch-cost=2" { target branch_cost } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c 
b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c
index ac3a04291b7..f8eb0954ae7 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-*"} } } */
+/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-* 
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-* 
hppa*-*-* nios2*-*-* pru*-*-*"} } } */
 
 /* { dg-options "-O2 -fno-inline -fdump-tree-reassoc1-details" } */
 /* { dg-additional-options "-mbranch-cost=2" { target branch_cost } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c
index f12fb07e604..71e

[PATCH v5 09/10] testsuite: Mark that PRU uses all function pointer bits

[Dimitar Dimitrov]

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* g++.old-deja/g++.abi/ptrmem.C: Add PRU to list.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C 
b/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C
index 341735879c5..bda7960d8a2 100644
--- a/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C
+++ b/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C
@@ -7,7 +7,7 @@
function.  However, some platforms use all bits to encode a
function pointer.  Such platforms use the lowest bit of the delta,
that is shifted left by one bit.  */
-#if defined __MN10300__ || defined __SH5__ || defined __arm__ || defined 
__thumb__ || defined __mips__ || defined __aarch64__
+#if defined __MN10300__ || defined __SH5__ || defined __arm__ || defined 
__thumb__ || defined __mips__ || defined __aarch64__ || defined __PRU__
 #define ADJUST_PTRFN(func, virt) ((void (*)())(func))
 #define ADJUST_DELTA(delta, virt) (((delta) << 1) + !!(virt))
 #else
-- 
2.11.0

[PATCH v5 10/10] testsuite: Mark testsuite that PRU has different calling convention

[Dimitar Dimitrov]

For variadic functions, the last named and all anonymous arguments
are passed on stack. Regular functions pass arguments in registers.

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* gcc.dg/builtin-apply2.c: Skip for PRU.
* gcc.dg/torture/stackalign/builtin-apply-2.c: Ditto.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/builtin-apply2.c | 2 +-
 gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-2.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/builtin-apply2.c 
b/gcc/testsuite/gcc.dg/builtin-apply2.c
index 3768caa5d5a..6ede0f3054b 100644
--- a/gcc/testsuite/gcc.dg/builtin-apply2.c
+++ b/gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,7 +1,7 @@
 /* { dg-do run } */
 /* { dg-require-effective-target untyped_assembly } */
 /* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args 
in registers." { "avr-*-* nds32*-*-*" } } */
-/* { dg-skip-if "Variadic funcs use different argument passing from normal 
funcs." { "riscv*-*-*" } } */
+/* { dg-skip-if "Variadic funcs use different argument passing from normal 
funcs." { "riscv*-*-* pru-*-*" } } */
 /* { dg-skip-if "Variadic funcs use Base AAPCS.  Normal funcs use VFP 
variant." { arm*-*-* && arm_hf_eabi } } */
 
 /* PR target/12503 */
diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-2.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-2.c
index d033010dc7c..8b6e693c0f2 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-2.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-2.c
@@ -9,7 +9,7 @@
 /* arm_hf_eabi: Variadic funcs use Base AAPCS.  Normal funcs use VFP variant.
avr: Variadic funcs don't pass arguments in registers, while normal funcs
 do.  */
-/* { dg-skip-if "Variadic funcs use different argument passing from normal 
funcs" { arm_hf_eabi || { avr-*-* riscv*-*-* } } } */
+/* { dg-skip-if "Variadic funcs use different argument passing from normal 
funcs" { arm_hf_eabi || { avr-*-* riscv*-*-* pru-*-* } } } */
 /* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args 
in registers." { nds32*-*-* } } */
 /* { dg-require-effective-target untyped_assembly } */

-- 
2.11.0

[PATCH v5 06/10] testsuite: Remove PRU from test cases requiring hosted environment

[Dimitar Dimitrov]

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* gcc.c-torture/execute/20101011-1.c: Define DO_TEST to 0 for PRU.
* gcc.dg/20020312-2.c: No PIC register for PRU.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.c-torture/execute/20101011-1.c | 3 +++
 gcc/testsuite/gcc.dg/20020312-2.c| 2 ++
 2 files changed, 5 insertions(+)

diff --git a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c 
b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
index 8261b796a47..aa06dbfb73a 100644
--- a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
@@ -100,6 +100,9 @@ __aeabi_idiv0 (int return_value)
 #elif defined (__moxie__)
   /* Not all moxie configurations may raise exceptions.  */
 # define DO_TEST 0
+#elif defined (__pru__)
+/* There isn't even a signal function.  */
+# define DO_TEST 0
 #else
 # define DO_TEST 1
 #endif
diff --git a/gcc/testsuite/gcc.dg/20020312-2.c 
b/gcc/testsuite/gcc.dg/20020312-2.c
index 1a8afd81506..133862f3421 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -117,6 +117,8 @@ extern void abort (void);
 # if defined (__CK807__) || defined (__CK810__)
 #   define PIC_REG  "r28"
 # endif
+#elif defined(__PRU__)
+/* No pic register.  */
 #else
 # error "Modify the test for your target."
 #endif
-- 
2.11.0

[PATCH v5 07/10] testsuite: Define PRU stack usage

[Dimitar Dimitrov]

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* gcc.dg/stack-usage-1.c: Define PRU stack usage.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/stack-usage-1.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/stack-usage-1.c 
b/gcc/testsuite/gcc.dg/stack-usage-1.c
index e6440142e1d..b2642228808 100644
--- a/gcc/testsuite/gcc.dg/stack-usage-1.c
+++ b/gcc/testsuite/gcc.dg/stack-usage-1.c
@@ -93,6 +93,8 @@
 #  define SIZE 254
 #elif defined (__nios2__)
 #  define SIZE 252
+#elif defined (__PRU__)
+#  define SIZE 252
 #elif defined (__v850__)
 #define SIZE 260
 #elif defined (__mn10300__)
-- 
2.11.0

[PATCH v5 03/10] testsuite: Add PRU tests

[Dimitar Dimitrov]

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* gcc.target/pru/abi-arg-struct.c: New test.
* gcc.target/pru/ashiftrt.c: New test.
* gcc.target/pru/builtins-1.c: New test.
* gcc.target/pru/builtins-error.c: New test.
* gcc.target/pru/clearbit.c: New test.
* gcc.target/pru/loop-asm.c: New test.
* gcc.target/pru/loop-dowhile.c: New test.
* gcc.target/pru/loop-hi-1.c: New test.
* gcc.target/pru/loop-hi-2.c: New test.
* gcc.target/pru/loop-qi-1.c: New test.
* gcc.target/pru/loop-qi-2.c: New test.
* gcc.target/pru/loop-short-1.c: New test.
* gcc.target/pru/loop-short-2.c: New test.
* gcc.target/pru/loop-si-1.c: New test.
* gcc.target/pru/loop-si-2.c: New test.
* gcc.target/pru/loop-u8_pcrel_overflow.c: New test.
* gcc.target/pru/loop-ubyte-1.c: New test.
* gcc.target/pru/loop-ubyte-2.c: New test.
* gcc.target/pru/lra-framepointer-fragmentation-1.c: New test.
* gcc.target/pru/lra-framepointer-fragmentation-2.c: New test.
* gcc.target/pru/mabi-ti-1.c: New test.
* gcc.target/pru/mabi-ti-2.c: New test.
* gcc.target/pru/mabi-ti-3.c: New test.
* gcc.target/pru/mabi-ti-4.c: New test.
* gcc.target/pru/mabi-ti-5.c: New test.
* gcc.target/pru/mabi-ti-6.c: New test.
* gcc.target/pru/mabi-ti-7.c: New test.
* gcc.target/pru/pr64366.c: New test.
* gcc.target/pru/pragma-ctable_entry.c: New test.
* gcc.target/pru/pru.exp: New file.
* gcc.target/pru/qbbc-1.c: New test.
* gcc.target/pru/qbbc-2.c: New test.
* gcc.target/pru/qbbc-3.c: New test.
* gcc.target/pru/qbbs-1.c: New test.
* gcc.target/pru/qbbs-2.c: New test.
* gcc.target/pru/setbit.c: New test.
* gcc.target/pru/zero_extend-and-hisi.c: New test.
* gcc.target/pru/zero_extend-and-qihi.c: New test.
* gcc.target/pru/zero_extend-and-qisi.c: New test.
* gcc.target/pru/zero_extend-hisi.c: New test.
* gcc.target/pru/zero_extend-qihi.c: New test.
* gcc.target/pru/zero_extend-qisi.c: New test.
* lib/target-supports.exp: Add PRU to feature filters.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.target/pru/abi-arg-struct.c  | 164 +
 gcc/testsuite/gcc.target/pru/ashiftrt.c|  13 ++
 gcc/testsuite/gcc.target/pru/builtins-1.c  |  12 ++
 gcc/testsuite/gcc.target/pru/builtins-error.c  |   6 +
 gcc/testsuite/gcc.target/pru/clearbit.c|  13 ++
 gcc/testsuite/gcc.target/pru/loop-asm.c|  19 +++
 gcc/testsuite/gcc.target/pru/loop-dowhile.c|  45 ++
 gcc/testsuite/gcc.target/pru/loop-hi-1.c   |  38 +
 gcc/testsuite/gcc.target/pru/loop-hi-2.c   |  17 +++
 gcc/testsuite/gcc.target/pru/loop-qi-1.c   |  38 +
 gcc/testsuite/gcc.target/pru/loop-qi-2.c   |  17 +++
 gcc/testsuite/gcc.target/pru/loop-short-1.c|  53 +++
 gcc/testsuite/gcc.target/pru/loop-short-2.c|  21 +++
 gcc/testsuite/gcc.target/pru/loop-si-1.c   |  41 ++
 gcc/testsuite/gcc.target/pru/loop-si-2.c   |  20 +++
 .../gcc.target/pru/loop-u8_pcrel_overflow.c|  42 ++
 gcc/testsuite/gcc.target/pru/loop-ubyte-1.c|  30 
 gcc/testsuite/gcc.target/pru/loop-ubyte-2.c|  18 +++
 .../pru/lra-framepointer-fragmentation-1.c |  33 +
 .../pru/lra-framepointer-fragmentation-2.c |  61 
 gcc/testsuite/gcc.target/pru/mabi-ti-1.c   |  10 ++
 gcc/testsuite/gcc.target/pru/mabi-ti-2.c   |  15 ++
 gcc/testsuite/gcc.target/pru/mabi-ti-3.c   |  12 ++
 gcc/testsuite/gcc.target/pru/mabi-ti-4.c   |  14 ++
 gcc/testsuite/gcc.target/pru/mabi-ti-5.c   |  33 +
 gcc/testsuite/gcc.target/pru/mabi-ti-6.c   |  12 ++
 gcc/testsuite/gcc.target/pru/mabi-ti-7.c   |  21 +++
 gcc/testsuite/gcc.target/pru/pr64366.c | 128 
 gcc/testsuite/gcc.target/pru/pragma-ctable_entry.c |  22 +++
 gcc/testsuite/gcc.target/pru/pru.exp   |  41 ++
 gcc/testsuite/gcc.target/pru/qbbc-1.c  |  29 
 gcc/testsuite/gcc.target/pru/qbbc-2.c  |  15 ++
 gcc/testsuite/gcc.target/pru/qbbc-3.c  |  15 ++
 gcc/testsuite/gcc.target/pru/qbbs-1.c  |  29 
 gcc/testsuite/gcc.target/pru/qbbs-2.c  |  15 ++
 gcc/testsuite/gcc.target/pru/setbit.c  |  13 ++
 .../gcc.target/pru/zero_extend-and-hisi.c  |  16 ++
 .../gcc.target/pru/zero_extend-and-qihi.c  |  16 ++
 .../gcc.target/pru/zero_extend-and-qisi.c  |  16 ++
 gcc/testsuite/gcc.target/pru/zero_extend-hisi.c|  43 ++
 gcc/testsuite/gcc.target/pru/zero_extend-qihi.c|  43 ++
 gcc/testsuite/gcc.target/pru/zero_extend-qisi.c|  43 ++
 gcc/testsuite/lib/target-supports.exp 

[PATCH v5 05/10] testsuite: Add check for unsupported TI ABI PRU features to testsuite

[Dimitar Dimitrov]

Not all C language features are supported when -mabi=ti option is
used for PRU target.

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* lib/gcc-dg.exp: Filter unsupported features in PRU's TI ABI mode.
* lib/target-utils.exp: Ditto.
* lib/target-supports.exp (check_effective_target_function_pointers,
check_effective_target_large_return_values): New.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/lib/gcc-dg.exp  | 11 +++
 gcc/testsuite/lib/target-supports.exp | 26 ++
 gcc/testsuite/lib/target-utils.exp|  8 
 3 files changed, 45 insertions(+)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 59c10016014..3287184c0bb 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -407,6 +407,17 @@ proc gcc-dg-prune { system text } {
return "::unsupported::memory full"
 }
 
+if { [string match "*error: function pointers not supported*" $text]
+ && ![check_effective_target_function_pointers] } {
+   # The format here is important.  See dg.exp.
+   return "::unsupported::funcptr"
+}
+if { [string match "*error: large return values not supported*" $text]
+ && ![check_effective_target_large_return_values] } {
+   # The format here is important.  See dg.exp.
+   return "::unsupported::large return values"
+}
+
 return $text
 }
 
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 13e32377885..6e475df0922 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2602,6 +2602,32 @@ proc check_effective_target_ptr32plus { } {
 }]
 }
 
+# Return 1 if target supports function pointers, 0 otherwise.
+
+proc check_effective_target_function_pointers { } {
+if { [istarget pru-*-*] } {
+   return [check_no_compiler_messages func_ptr_avail assembly {
+   #ifdef __PRU_EABI_GNU__
+   #error unsupported
+   #endif
+   }]
+}
+return 1
+}
+
+# Return 1 if target supports arbitrarily large return values, 0 otherwise.
+
+proc check_effective_target_large_return_values { } {
+if { [istarget pru-*-*] } {
+   return [check_no_compiler_messages func_ptr_avail assembly {
+   #ifdef __PRU_EABI_GNU__
+   #error unsupported
+   #endif
+   }]
+}
+return 1
+}
+
 # Return 1 if we support 32-bit or larger array and structure sizes
 # using default options, 0 otherwise.  Avoid false positive on
 # targets with 20 or 24 bit address spaces.
diff --git a/gcc/testsuite/lib/target-utils.exp 
b/gcc/testsuite/lib/target-utils.exp
index 732a1827a02..f636be2cb01 100644
--- a/gcc/testsuite/lib/target-utils.exp
+++ b/gcc/testsuite/lib/target-utils.exp
@@ -44,5 +44,13 @@ proc ${tool}_check_unsupported_p { output } {
 [string match "*exceeds local store*" $output] } {
return "memory full"
 }
+if { [string match "*error: function pointers not supported*" $output]
+ && ![check_effective_target_function_pointers] } {
+   return "function pointers not supported"
+}
+if { [string match "*error: large return values not supported*" $output]
+ && ![check_effective_target_large_return_values] } {
+   return "large return values not supported"
+}
 return ""
 }
-- 
2.11.0

[PATCH v5 04/10] testsuite: Add check for overflowed IMEM region to testsuite

[Dimitar Dimitrov]

PRU architecture supports maximum 256k program memory (IMEM). Some GCC
test cases manage to produce executables bigger than that.

gcc/testsuite/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* lib/gcc-dg.exp: Bail on region overflow for tiny targets.
* lib/target-utils.exp: Ditto.
* lib/target-supports.exp: Declare PRU target as tiny.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/lib/gcc-dg.exp  | 5 +
 gcc/testsuite/lib/target-supports.exp | 5 +
 gcc/testsuite/lib/target-utils.exp| 4 
 3 files changed, 14 insertions(+)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index c33a50c0b13..59c10016014 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -394,6 +394,11 @@ proc gcc-dg-prune { system text } {
 return "::unsupported::memory full"
 }
 
+if { [regexp "(^|\n)\[^\n\]*: region \[^\n\]* overflowed" $text] 
+  && [check_effective_target_tiny] } {
+   return "::unsupported::memory full"
+}
+
 # Likewise, if we see ".text exceeds local store range" or
 # similar.
 if {[string match "spu-*" $system] && \
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 8caea35edff..13e32377885 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8377,6 +8377,11 @@ proc check_effective_target_tiny {} {
&& [check_effective_target_avr_tiny] } {
   return 1
   }
+  # PRU Program Counter is 16-bits, and trampolines are not supported.
+  # Hence directly declare as a tiny target.
+  if [istarget pru-*-*] {
+  return 1
+  }
   return 0
 }]
 }
diff --git a/gcc/testsuite/lib/target-utils.exp 
b/gcc/testsuite/lib/target-utils.exp
index bd39cc5bc79..732a1827a02 100644
--- a/gcc/testsuite/lib/target-utils.exp
+++ b/gcc/testsuite/lib/target-utils.exp
@@ -35,6 +35,10 @@ proc ${tool}_check_unsupported_p { output } {
   && [check_effective_target_tiny] } {
 return "memory full"
  }
+if { [regexp "(^|\n)\[^\n\]*: region \[^\n\]* overflowed" $output]
+  && [check_effective_target_tiny] } {
+   return "memory full"
+}
 
 if { [istarget spu-*-*] && \
 [string match "*exceeds local store*" $output] } {
-- 
2.11.0

[PATCH v5 02/10] Initial TI PRU libgcc port

[Dimitar Dimitrov]

The floating point support has been borrowed from C6X libgcc port
to help with TI PRU toolchain ABI compatibility.

libgcc/ChangeLog:

2018-10-08  Dimitar Dimitrov  

* config.host: Add PRU target.
* config/pru/asri.c: New file.
* config/pru/eqd.c: New file.
* config/pru/eqf.c: New file.
* config/pru/ged.c: New file.
* config/pru/gef.c: New file.
* config/pru/gtd.c: New file.
* config/pru/gtf.c: New file.
* config/pru/led.c: New file.
* config/pru/lef.c: New file.
* config/pru/lib2bitcountHI.c: New file.
* config/pru/lib2divHI.c: New file.
* config/pru/lib2divQI.c: New file.
* config/pru/lib2divSI.c: New file.
* config/pru/libgcc-eabi.ver: New file.
* config/pru/ltd.c: New file.
* config/pru/ltf.c: New file.
* config/pru/mpyll.S: New file.
* config/pru/pru-abi.h: New file.
* config/pru/pru-asm.h: New file.
* config/pru/pru-divmod.h: New file.
* config/pru/sfp-machine.h: New file.
* config/pru/t-pru: New file.

Signed-off-by: Dimitar Dimitrov 
---
 libgcc/config.host |   7 +++
 libgcc/config/pru/asri.c   |  33 ++
 libgcc/config/pru/eqd.c|  45 +
 libgcc/config/pru/eqf.c|  45 +
 libgcc/config/pru/ged.c|  45 +
 libgcc/config/pru/gef.c|  45 +
 libgcc/config/pru/gtd.c|  45 +
 libgcc/config/pru/gtf.c|  45 +
 libgcc/config/pru/led.c|  45 +
 libgcc/config/pru/lef.c|  45 +
 libgcc/config/pru/lib2bitcountHI.c |  43 +
 libgcc/config/pru/lib2divHI.c  |  42 +
 libgcc/config/pru/lib2divQI.c  |  42 +
 libgcc/config/pru/lib2divSI.c  |  48 ++
 libgcc/config/pru/libgcc-eabi.ver  |  88 ++
 libgcc/config/pru/ltd.c|  45 +
 libgcc/config/pru/ltf.c|  45 +
 libgcc/config/pru/mpyll.S  |  57 +
 libgcc/config/pru/pru-abi.h| 109 
 libgcc/config/pru/pru-asm.h|  35 +++
 libgcc/config/pru/pru-divmod.h | 117 ++
 libgcc/config/pru/sfp-machine.h| 125 +
 libgcc/config/pru/t-pru|  50 +++
 23 files changed, 1246 insertions(+)
 create mode 100644 libgcc/config/pru/asri.c
 create mode 100644 libgcc/config/pru/eqd.c
 create mode 100644 libgcc/config/pru/eqf.c
 create mode 100644 libgcc/config/pru/ged.c
 create mode 100644 libgcc/config/pru/gef.c
 create mode 100644 libgcc/config/pru/gtd.c
 create mode 100644 libgcc/config/pru/gtf.c
 create mode 100644 libgcc/config/pru/led.c
 create mode 100644 libgcc/config/pru/lef.c
 create mode 100644 libgcc/config/pru/lib2bitcountHI.c
 create mode 100644 libgcc/config/pru/lib2divHI.c
 create mode 100644 libgcc/config/pru/lib2divQI.c
 create mode 100644 libgcc/config/pru/lib2divSI.c
 create mode 100644 libgcc/config/pru/libgcc-eabi.ver
 create mode 100644 libgcc/config/pru/ltd.c
 create mode 100644 libgcc/config/pru/ltf.c
 create mode 100644 libgcc/config/pru/mpyll.S
 create mode 100644 libgcc/config/pru/pru-abi.h
 create mode 100644 libgcc/config/pru/pru-asm.h
 create mode 100644 libgcc/config/pru/pru-divmod.h
 create mode 100644 libgcc/config/pru/sfp-machine.h
 create mode 100644 libgcc/config/pru/t-pru

diff --git a/libgcc/config.host b/libgcc/config.host
index 029f6569caf..5206b5dc9d7 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -168,6 +168,9 @@ nios2*-*-*)
 powerpc*-*-*)
cpu_type=rs6000
;;
+pru-*-*)
+   cpu_type=pru
+   ;;
 rs6000*-*-*)
;;
 riscv*-*-*)
@@ -1158,6 +1161,10 @@ powerpcle-*-eabi*)
tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-crtstuff 
t-crtstuff-pic t-fdpbit"
extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o 
crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
;;
+pru-*-*)
+   tmake_file="${tmake_file} t-softfp-sfdf t-softfp-excl t-softfp 
t-gnu-prefix pru/t-pru"
+   tm_file="$tm_file pru/pru-abi.h"
+   ;;
 riscv*-*-linux*)
tmake_file="${tmake_file} riscv/t-softfp${host_address} t-softfp 
riscv/t-elf riscv/t-elf${host_address}"
extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o crtendS.o 
crtbeginT.o"
diff --git a/libgcc/config/pru/asri.c b/libgcc/config/pru/asri.c
new file mode 100644
index 000..591d660f227
--- /dev/null
+++ b/libgcc/config/pru/asri.c
@@ -0,0 +1,33 @@
+/* PRU ABI compatibility functions
+   Arithmetic right shift
+   Copyright (C) 2017-2018 Free Software Foundation, Inc.
+   Contributed by Dimitar Dimitrov 
+
+   This file is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   

[PATCH v5 00/10] New backend for the TI PRU processor

[Dimitar Dimitrov]

This is the latest patch set for adding TI PRU I/O processor backend to GCC.
Comments from all previous series have been addressed [1], [2], [3], [4].

Test results can be downloaded from here:
   http://dinux.eu/gnupru/testresults/20181014-c45bebb5ee9

Changes since patch series v4 [4]:
  - Handle QI const_int signedness using a new "ubyte_constr" mode_attr.
  - Tuned the FP register semantics to align with TI recommendations.
  - Rewrote "mul" pattern with a more robust way to handle the fixed HW
registers.
  - Use output_operand_lossage instead of asserts for modifier validation.
  - Reworked "ashr" to expand to an RTL loop.
  - Whitespace, comment and indentation fixes.
  - Clarified documentation.
  - Removed "sub" pattern with constant operand 2.
  - Simplified code to use strip_offset and plus_constant.
  - Removed length attribute when declared with default value.
  - Marked internal constraints with @intern.
  - Removed PRU's TARGET_MODES_TIEABLE_P callback.
  - Removed PRU's TARGET_PREFERRED_RELOAD_CLASS callback.
  - Refactored code to use the TARGET_COMPUTE_FRAME_LAYOUT hook.
  - Enabled TARGET_SUPPORTS_WIDE_INT.
  - Removed references to reg_renumber.
  - Used more robust method to discern direct function calls from function
pointer references, for -mabi=ti enforcement.
  - Simplified pru_function_arg_regi and put more comments.

[1] http://gcc.gnu.org/ml/gcc-patches/2018-06/msg00775.html
[2] http://gcc.gnu.org/ml/gcc-patches/2018-07/msg01779.html
[3] http://gcc.gnu.org/ml/gcc-patches/2018-08/msg00927.html
[4] http://gcc.gnu.org/ml/gcc-patches/2018-09/msg00392.html


Regards,
Dimitar

Dimitar Dimitrov (10):
  Initial TI PRU GCC port
  Initial TI PRU libgcc port
  testsuite: Add PRU tests
  testsuite: Add check for overflowed IMEM region to testsuite
  testsuite: Add check for unsupported TI ABI PRU features to testsuite
  testsuite: Remove PRU from test cases requiring hosted environment
  testsuite: Define PRU stack usage
  testsuite: Mark that PRU has one-cycle jumps
  testsuite: Mark that PRU uses all function pointer bits
  testsuite: Mark testsuite that PRU has different calling convention

 configure.ac   |7 +
 gcc/common/config/pru/pru-common.c |   36 +
 gcc/config.gcc |9 +
 gcc/config/pru/alu-zext.md |  181 ++
 gcc/config/pru/constraints.md  |  108 +
 gcc/config/pru/predicates.md   |  290 ++
 gcc/config/pru/pru-opts.h  |   31 +
 gcc/config/pru/pru-passes.c|  228 ++
 gcc/config/pru/pru-pragma.c|   86 +
 gcc/config/pru/pru-protos.h|   72 +
 gcc/config/pru/pru.c   | 3003 
 gcc/config/pru/pru.h   |  572 
 gcc/config/pru/pru.md  | 1022 +++
 gcc/config/pru/pru.opt |   54 +
 gcc/config/pru/t-pru   |   31 +
 gcc/doc/extend.texi|   21 +
 gcc/doc/invoke.texi|   65 +
 gcc/doc/md.texi|   19 +
 gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C|2 +-
 gcc/testsuite/gcc.c-torture/execute/20101011-1.c   |3 +
 gcc/testsuite/gcc.dg/20020312-2.c  |2 +
 gcc/testsuite/gcc.dg/builtin-apply2.c  |2 +-
 gcc/testsuite/gcc.dg/stack-usage-1.c   |2 +
 .../gcc.dg/torture/stackalign/builtin-apply-2.c|2 +-
 gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c |2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c |2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c |2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c |2 +-
 gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c |2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c  |2 +-
 gcc/testsuite/gcc.target/pru/abi-arg-struct.c  |  164 ++
 gcc/testsuite/gcc.target/pru/ashiftrt.c|   13 +
 gcc/testsuite/gcc.target/pru/builtins-1.c  |   12 +
 gcc/testsuite/gcc.target/pru/builtins-error.c  |6 +
 gcc/testsuite/gcc.target/pru/clearbit.c|   13 +
 gcc/testsuite/gcc.target/pru/loop-asm.c|   19 +
 gcc/testsuite/gcc.target/pru/loop-dowhile.c|   45 +
 gcc/testsuite/gcc.target/pru/loop-hi-1.c   |   38 +
 gcc/testsuite/gcc.target/pru/loop-hi-2.c   |   17 +
 gcc/testsuite/gcc.target/pru/loop-qi-1.c   |   38 +
 gcc/testsuite/gcc.target/pru/loop-qi-2.c   |   17 +
 gcc/testsuite/gcc.target/pru/loop-short-1.c|   53 +
 gcc/testsuite/gcc.target/pru/loop-short-2.c|   21 +
 gcc/testsuite/gcc.target/pru/loop-si-1.c   |   41 +
 gcc/testsuite/gcc.target/pru/loop-si-2.c   |   20 +
 .../gcc.target/pru/loop-u8_pcrel_overflow.c|   42 

Re: [PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Christophe Lyon]

On Tue, 16 Oct 2018 at 19:33, Giuliano Augusto Faulin Belinassi
 wrote:
>
> Hello,
>
> > cosatanf:
> > .LFB3:
> > .loc 1 44 1 is_stmt 1
> > .cfi_startproc
> >@ args = 0, pretend = 0, frame = 0
> > @ frame_needed = 0, uses_anonymous_args = 0
> > .LVL50:
> > .loc 1 45 5
> > .loc 1 44 1 is_stmt 0
> > push{r4, lr}
> > .cfi_def_cfa_offset 8
> > .cfi_offset 4, -8
> > .cfi_offset 14, -4
> > .loc 1 45 12
> > bl  atanf
> > .LVL51:
> > .loc 1 46 1
> >  pop {r4, lr}
> > .cfi_restore 14
> > .cfi_restore 4
> > .cfi_def_cfa_offset 0
> > .loc 1 45 12
> > b   cosf
> > .LVL52:
>
> This means that the expression 'cos (atan (x))' was not simplified
> :-(. Did the check at line 4281 (svn revision 265209) in gcc/match.pd
> failed?

Do you mean r265064? There's no r265209 in trunk.

> > Yes, if we want to skip the test, but I'm not sure about that?
> Since the only point of this patch is to simplify these kind of
> expressions, and it is not being simplified at all in your arch as the
> asm dump suggests, then it seems safe to skip all sinatan-*.c tests.


> On Tue, Oct 16, 2018 at 1:25 PM Christophe Lyon
>  wrote:
> >
> > On Tue, 16 Oct 2018 at 18:04, Giuliano Augusto Faulin Belinassi
> >  wrote:
> > >
> > > Hello, Christophe
> > > Could you please dump the assembly of cosatanf here?
> > >
> > >
> > Sure:
> > .global cosatanf
> > .syntax unified
> > .arm
> > .fpu softvfp
> > .type   cosatanf, %function
> > cosatanf:
> > .LFB3:
> > .loc 1 44 1 is_stmt 1
> > .cfi_startproc
> > @ args = 0, pretend = 0, frame = 0
> > @ frame_needed = 0, uses_anonymous_args = 0
> > .LVL50:
> > .loc 1 45 5
> > .loc 1 44 1 is_stmt 0
> > push{r4, lr}
> > .cfi_def_cfa_offset 8
> > .cfi_offset 4, -8
> > .cfi_offset 14, -4
> > .loc 1 45 12
> > bl  atanf
> > .LVL51:
> > .loc 1 46 1
> > pop {r4, lr}
> > .cfi_restore 14
> > .cfi_restore 4
> > .cfi_def_cfa_offset 0
> > .loc 1 45 12
> > b   cosf
> > .LVL52:
> > .cfi_endproc
> > .LFE3:
> > .size   cosatanf, .-cosatanf
> >
> > So, upon entry we have r0=0x5f80
> > atanf returns 0x3fc90fdb
> > and cosf returns 0xb33bbd2e
> >
> >
> > > On Tue, Oct 16, 2018 at 12:23 PM Christophe Lyon
> > >  wrote:
> > > >
> > > > On Tue, 16 Oct 2018 at 17:15, Giuliano Augusto Faulin Belinassi
> > > >  wrote:
> > > > >
> > > > > Hello. Sorry for the late reply.
> > > > >
> > > > > > but then cosatanf is computed as (ie there's not call to 
> > > > > > cosatanf()):
> > > > > >movwr3, #48430
> > > > > >movtr3, 45883
> > > > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > > > Does this behavior is still present if we change the line 58 to:
> > > > > int __attribute__ ((optimize("O0")))
> > > > > in sinatan-1.c?
> > > >
> > > > No, this now generates:
> > > > ldr r0, [fp, #-32]
> > > > bl  cosatanf
> > > > where r0=0x5f80, and cosatanf() returns 0xb33bbd2e
> > > > (ie the same value as what was computed by GCC)
> > > >
> > > > > On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
> > > > > >  wrote:
> > > > > > >
> > > > > > > > fc is built with:
> > > > > > > >mov r0, #0
> > > > > > > >movtr0, 24448
> > > > > > > > so r0=0x5f80 (1.8446744E19) which looks ok
> > > > > > >
> > > > > > > this is correct. My x86_64 yields the same value
> > > > > > >
> > > > > > > > but then cosatanf is computed as (ie there's not call to 
> > > > > > > > cosatanf()):
> > > > > > > >movwr3, #48430
> > > > > > > >movtr3, 45883
> > > > > > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > > > > >
> > > > > > > Ugh. So GCC replaced the function call with a precomputed value? 
> > > > > > > This
> > > > > > > does not happens in my x86_64. Maybe it is Ofast's fault?
> > > > > > > Also, it seems that GCC is precomputing cos(atan(x)) before the
> > > > > > > substitution, as the following python script yields the same 
> > > > > > > result:
> > > > > > >
> > > > > >
> > > > > > Yes, I was surprised to see that.
> > > > > >
> > > > > > > import numpy as np
> > > > > > > x = np.float32 (1.8446744e19)
> > > > > > > print (np.cos (np.arctan (x))
> > > > > > >
> > > > > > > I would also like to add that -4.371139E-8 is very far away from
> > > > > > > 5.421011E-20, which is a "more" correct value for this 
> > > > > > > computation. So
> > > > > > > returning 0 may be a better option?
> > > > > > > On Fri, Oct 12, 2018 at 12:57 PM Jeff Law  wrote:
> > > > > > > >
> > > > > > > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > 

[Patch, fortran] PR56386 - [F03] ICE with ASSOCIATE construct and an derived type array component

[Paul Richard Thomas]

This is a semi-obvious patch that fixes no fewer than five PRs: 56386,
58906, 77385, 80260 & 82077. The last two are marked as 7/8/9
regressions and so, although I haven't tested it yet, I suppose that
the others must be too. Thanks to Dominique for picking up the other
four PRs that are fixed by this patch.

Bootstrapped and regtested on FC28/x86_64 - OK for trunk, then 7- and
8-branches?

Paul

2018-10-16  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.

2018-10-16  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c	(revision 265171)
--- gcc/fortran/resolve.c	(working copy)
*** resolve_variable (gfc_expr *e)
*** 5436,5441 
--- 5436,5459 
  	gfc_fix_class_refs (e);
if (!sym->attr.dimension && e->ref && e->ref->type == REF_ARRAY)
  	return false;
+   else if (sym->attr.dimension && (!e->ref || e->ref->type != REF_ARRAY))
+ 	{
+ 	  /* This can happen because the parser did not detect that the
+ 	 associate name is an array and the expression had no array
+ 	 part_ref.  */
+ 	  gfc_ref *ref = gfc_get_ref ();
+ 	  ref->type = REF_ARRAY;
+ 	  ref->u.ar = *gfc_get_array_ref();
+ 	  ref->u.ar.type = AR_FULL;
+ 	  if (sym->as)
+ 	{
+ 	  ref->u.ar.as = sym->as;
+ 	  ref->u.ar.dimen = sym->as->rank;
+ 	}
+ 	  ref->next = e->ref;
+ 	  e->ref = ref;
+ 
+ 	}
  }
  
if (sym->ts.type == BT_DERIVED && sym->ts.u.derived->attr.generic)
Index: gcc/testsuite/gfortran.dg/associate_44.f90
===
*** gcc/testsuite/gfortran.dg/associate_44.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/associate_44.f90	(working copy)
***
*** 0 
--- 1,23 
+ ! { dg-do compile }
+ !
+ ! Test the fix for PR56386
+ !
+ ! Contributed by Vladimir Fuka  
+ !
+ subroutine  CustomSolidBodies
+implicit none
+ 
+ type inner
+   real :: elev
+ end type
+ 
+ type :: outer
+   type(inner),dimension(0) :: PrPoints
+ end type
+ 
+ type(outer) :: SB
+ 
+ associate (Prter=>SB%PrPoints)
+PrTer%elev=0  ! ICE here
+ end associate
+ end subroutine  CustomSolidBodies
Index: gcc/testsuite/gfortran.dg/select_type_45.f90
===
*** gcc/testsuite/gfortran.dg/select_type_45.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/select_type_45.f90	(working copy)
***
*** 0 
--- 1,22 
+ ! { dg-do compile }
+ !
+ ! Tests the fix for PR80260
+ !
+ ! Contributed by Damian Rouson  
+ !
+ type foo
+ end type foo
+ type, extends(foo) :: bar
+ end type
+ contains
+ subroutine f(x)
+   class(foo) x(:,:)
+   select type(x)
+ class is (bar)
+   call g(x(1,:))   ! ICEd here.
+   end select
+ end subroutine
+ subroutine g(y)
+   class(bar) y(:)
+ end subroutine
+ end
Index: gcc/testsuite/gfortran.dg/select_type_46.f90
===
*** gcc/testsuite/gfortran.dg/select_type_46.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/select_type_46.f90	(working copy)
***
*** 0 
--- 1,21 
+ ! { dg-do compile }
+ !
+ ! Tests the fix for PR82077
+ !
+ ! Contributed by Damian Rouson  
+ !
+ type parent
+ end type parent
+ type, extends(parent) :: child
+ end type
+ class(parent), allocatable :: foo(:,:)
+ allocate(child::foo(1,1))
+ select type(foo)
+   class is (child)
+ call gfortran7_ICE(foo(1,:))  ! ICEd here.
+ end select
+ contains
+ subroutine gfortran7_ICE(bar)
+   class(child) bar(:)
+ end subroutine
+ end

[C++ Patch, obvious] PR 84705 ("[6/7/8/9 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390")

[Paolo Carlini]

Hi,

the main issue is already fixed in trunk - we don't ICE anymore - but I 
noticed that for ill-formed code like:


    int i = static_cast(i);

we emit a duplicate diagnostic about the incomplete type d, easy to 
avoid by returning error_mark_node from 
perform_direct_initialization_if_possible when build_special_member_call 
returns it. I think this latter tweak qualifies as obvious, per a 
comment made by Jason a while ago...


Tested x86_64-linux.

Thanks, Paolo.

//

/cp
2018-10-16  Paolo Carlini  

PR c++/84705
* call.c (perform_direct_initialization_if_possible): Early return
error_mark_node if build_special_member_call returns it.

/testsuite
2018-10-16  Paolo Carlini  

PR c++/84705
* g++.dg/cpp0x/pr84705.C: New.
Index: cp/call.c
===
--- cp/call.c   (revision 265200)
+++ cp/call.c   (working copy)
@@ -10995,6 +10995,8 @@ perform_direct_initialization_if_possible (tree ty
   expr = build_special_member_call (NULL_TREE, complete_ctor_identifier,
&args, type, LOOKUP_NORMAL, complain);
   release_tree_vector (args);
+  if (expr == error_mark_node)
+   return error_mark_node;
   return build_cplus_new (type, expr, complain);
 }
 
Index: testsuite/g++.dg/cpp0x/pr84705.C
===
--- testsuite/g++.dg/cpp0x/pr84705.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr84705.C(working copy)
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+int a[]{a};  // { dg-error "invalid conversion" }
+
+template
+struct b {
+  __attribute__((c([] {
+struct {
+  int a = static_cast(a);  // { dg-error "invalid use of 
incomplete type" }
+} e;
+  })));
+};

PING [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00473.html

On 10/08/2018 05:22 PM, Martin Sebor wrote:

Attached is an updated patch with the INTEGRAL_TYPE_P test added
to detect constant non-integer arguments like (void*)0, and with
quoting made unconditional.  I also removed the pretty printer
business to avoid the "value%s" format, and modified the manual
to clarify when each of the attributes are applicable and what
their meaningful argument values are.

On 10/07/2018 04:38 PM, Martin Sebor wrote:

While still testing an enhancement in the area of attributes
I ran across bugs and inconsistencies in how different handlers
deal with positional arguments.  The bugs are either an ICE due
to the handlers not consistently converting positional arguments
to constants (i.e., CONST_DEL to INTEGER_CST in C++) for which
downstream code is unprepared (PR 87541), or errors for valid
code (PR 87542), or failing to diagnose invalid arguments.
The other inconsistencies are simply in responding to the same
invalid condition differently for different attributes .

The attached patch introduces a new function to do validate
positional arguments in a uniform way and replaces the existing
handling with it.

As a consequence of the handling being made consistent a number
of tests needed adjusting. In addition, some invalid arguments
that were previously rejected with a hard error are diagnosed
with just a warning (invalid argument values in attribute format),
and in one other instance what previously triggered a warning is
now accepted without one (attribute alloc_size on a function
without a prototype).  I'd be up tightening things up if that's
preferable as long it's done consistently.

Tested on x86_64-linux.

Martin

PS It would be nice to have a general policy for how to respond
to invalid attribute arguments (warning or error).  Even better,
it would be ideal to move the validation from the front-ends and
back-ends into the middle-end.  I.e., describe attribute arguments
in more detail in struct attribute_spec and have decl_attributes
validate nut just the number of arguments but also their types
and, when appropriate, expected values.

Re: [PATCH] lra: fix spill_hard_reg_in_range clobber check

[Jeff Law]

On 10/16/18 10:10 AM, Ilya Leoshkevich wrote:
>> Am 16.10.2018 um 16:20 schrieb Jeff Law :
>>
>> On 10/16/18 3:17 AM, Ilya Leoshkevich wrote:
>>> Bootstrap and regtest are running on x86_64-redhat-linux.
>>>
>>> Insns in FROM..TO range might not be recognized yet, and their
>>> corresponding entries in lra_insn_recog_data[] might be NULLs.  In the
>>> code from PR87596 the problematic insn is merely
>>>
>>>(note 148 154 68 7 NOTE_INSN_DELETED)
>>>
>>> however I assume that non-note insns may occur as well.  So make sure
>>> they are recognized before touching their lra_insn_recog_data_t.
>>>
>>> gcc/ChangeLog:
>>>
>>> 2018-10-16  Ilya Leoshkevich  
>>>
>>> PR rtl-optimization/87596
>>> * lra-constraints.c (spill_hard_reg_in_range): Use
>>> lra_get_insn_recog_data () instead of lra_insn_recog_data[]
>>> for instructions in FROM..TO range.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2018-10-16  Ilya Leoshkevich  
>>>
>>> PR rtl-optimization/87596
>>> * gcc.target/i386/pr87596.c: New test.
>> I think this is just papering over the problem.
>>
>> AFAICT for something like a deleted note lra_get_insn_recog_data is
>> going to call lra_set_insn_recog_data.  Given that INSN will be a NOTE I
>> think icode will end up being -1 and we'll eventually get into this clause:
>>
>>  if (icode < 0)
>>{
>>  int nop, nalt;
>>  machine_mode operand_mode[MAX_RECOG_OPERANDS];
>>  const char *constraints[MAX_RECOG_OPERANDS];
>>
>>  nop = asm_noperands (PATTERN (insn));
>>
>> And I don't think we should be trying to extract the PATTERN of a note.
>>
>> I think you need to either filter out the non-insn thingies in
>> spill_hard_reg_in_range, or go with your patch plus beefing up the
>> checks in lra_set_insn_recog_data.
>>
>> jeff
>>
> 
> Thanks, you’re absolutely right!
> 
> I re-ran the test with --enable-checking=all, and it crashed in another
> branch of that if statement:
> 
>   else
> {
>   insn_extract (insn);  /* Also uses PATTERN ().  */
>   data->insn_static_data = insn_static_data
> 
> I looked at the usage patterns of lra_insn_recog_data[] and
> lra_get_insn_recog_data (), and noticed that we use the former directly
> only when the insn in question is taken from insn_bitmap, and the latter
> in all other cases.  Furthermore, lra_get_insn_recog_data () is normally
> guarded by INSN_P () or something similar.
> 
> So I plan to keep using lra_get_insn_recog_data (), but with an extra
> INSN_P () check.
Seems reasonable.   Though note that INSN_P will accept DEBUG_INSNs.
That may be OK -- those routines have some code for handling
DEBUG_INSNs, but I didn't audit those paths carefully.

Jeff

Re: [PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Giuliano Augusto Faulin Belinassi]

Hello,

> cosatanf:
> .LFB3:
> .loc 1 44 1 is_stmt 1
> .cfi_startproc
>@ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> .LVL50:
> .loc 1 45 5
> .loc 1 44 1 is_stmt 0
> push{r4, lr}
> .cfi_def_cfa_offset 8
> .cfi_offset 4, -8
> .cfi_offset 14, -4
> .loc 1 45 12
> bl  atanf
> .LVL51:
> .loc 1 46 1
>  pop {r4, lr}
> .cfi_restore 14
> .cfi_restore 4
> .cfi_def_cfa_offset 0
> .loc 1 45 12
> b   cosf
> .LVL52:

This means that the expression 'cos (atan (x))' was not simplified
:-(. Did the check at line 4281 (svn revision 265209) in gcc/match.pd
failed?

> Yes, if we want to skip the test, but I'm not sure about that?
Since the only point of this patch is to simplify these kind of
expressions, and it is not being simplified at all in your arch as the
asm dump suggests, then it seems safe to skip all sinatan-*.c tests.
On Tue, Oct 16, 2018 at 1:25 PM Christophe Lyon
 wrote:
>
> On Tue, 16 Oct 2018 at 18:04, Giuliano Augusto Faulin Belinassi
>  wrote:
> >
> > Hello, Christophe
> > Could you please dump the assembly of cosatanf here?
> >
> >
> Sure:
> .global cosatanf
> .syntax unified
> .arm
> .fpu softvfp
> .type   cosatanf, %function
> cosatanf:
> .LFB3:
> .loc 1 44 1 is_stmt 1
> .cfi_startproc
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> .LVL50:
> .loc 1 45 5
> .loc 1 44 1 is_stmt 0
> push{r4, lr}
> .cfi_def_cfa_offset 8
> .cfi_offset 4, -8
> .cfi_offset 14, -4
> .loc 1 45 12
> bl  atanf
> .LVL51:
> .loc 1 46 1
> pop {r4, lr}
> .cfi_restore 14
> .cfi_restore 4
> .cfi_def_cfa_offset 0
> .loc 1 45 12
> b   cosf
> .LVL52:
> .cfi_endproc
> .LFE3:
> .size   cosatanf, .-cosatanf
>
> So, upon entry we have r0=0x5f80
> atanf returns 0x3fc90fdb
> and cosf returns 0xb33bbd2e
>
>
> > On Tue, Oct 16, 2018 at 12:23 PM Christophe Lyon
> >  wrote:
> > >
> > > On Tue, 16 Oct 2018 at 17:15, Giuliano Augusto Faulin Belinassi
> > >  wrote:
> > > >
> > > > Hello. Sorry for the late reply.
> > > >
> > > > > but then cosatanf is computed as (ie there's not call to cosatanf()):
> > > > >movwr3, #48430
> > > > >movtr3, 45883
> > > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > > Does this behavior is still present if we change the line 58 to:
> > > > int __attribute__ ((optimize("O0")))
> > > > in sinatan-1.c?
> > >
> > > No, this now generates:
> > > ldr r0, [fp, #-32]
> > > bl  cosatanf
> > > where r0=0x5f80, and cosatanf() returns 0xb33bbd2e
> > > (ie the same value as what was computed by GCC)
> > >
> > > > On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
> > > >  wrote:
> > > > >
> > > > > On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
> > > > >  wrote:
> > > > > >
> > > > > > > fc is built with:
> > > > > > >mov r0, #0
> > > > > > >movtr0, 24448
> > > > > > > so r0=0x5f80 (1.8446744E19) which looks ok
> > > > > >
> > > > > > this is correct. My x86_64 yields the same value
> > > > > >
> > > > > > > but then cosatanf is computed as (ie there's not call to 
> > > > > > > cosatanf()):
> > > > > > >movwr3, #48430
> > > > > > >movtr3, 45883
> > > > > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > > > >
> > > > > > Ugh. So GCC replaced the function call with a precomputed value? 
> > > > > > This
> > > > > > does not happens in my x86_64. Maybe it is Ofast's fault?
> > > > > > Also, it seems that GCC is precomputing cos(atan(x)) before the
> > > > > > substitution, as the following python script yields the same result:
> > > > > >
> > > > >
> > > > > Yes, I was surprised to see that.
> > > > >
> > > > > > import numpy as np
> > > > > > x = np.float32 (1.8446744e19)
> > > > > > print (np.cos (np.arctan (x))
> > > > > >
> > > > > > I would also like to add that -4.371139E-8 is very far away from
> > > > > > 5.421011E-20, which is a "more" correct value for this computation. 
> > > > > > So
> > > > > > returning 0 may be a better option?
> > > > > > On Fri, Oct 12, 2018 at 12:57 PM Jeff Law  wrote:
> > > > > > >
> > > > > > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > > > > > > > Hello
> > > > > > > >  What is the output of these functions on such arch? Since 
> > > > > > > > the
> > > > > > > > test didn't fail for the sinatan counterpart, an possible 
> > > > > > > > explanation
> > > > > > > > would be that the calculation of the sqrf, sqrt and sqrtl (lines
> > > > > > > > 62-64) yielded a number that is far behind of what it should be.
> > > > > > > > However, I am still not sure about this, s

Re: [PATCH][AArch64] Use @ pattern to eliminate switch statement in one more place

[Richard Sandiford]

Kyrylo Tkachov  writes:
> Hi all,
>
> We can use the new '@' modifier to MD patterns to generate
> mode-parametrised gen_ functions
> for the despeculate_copy patterns and therefore remove the switch on
> modes in aarch64.c
> that is used to pick the right generator. This simplifies the code.
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
> Ok for trunk?
>
> Thanks,
> Kyrill
>
> 2018-10-16  Kyrylo Tkachov  
>
>  * config/aarch64/aarch64.md (despeculate_copy):
>  Rename to...
>  (@despeculate_copy): ... This.
>  * config/aarch64/aarch64.c (aarch64_speculation_safe_value): Remove
>  switch statement.

OK, thanks.

Richard


>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
> 34d08a075221fd4c098e9b5e8fabd8fe3948d285..03041c5af99e52de8f5b4d8342e93ef2b90985bc
>  100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -17968,26 +17968,7 @@ aarch64_speculation_safe_value (machine_mode mode,
>if (!aarch64_reg_or_zero (failval, mode))
>  failval = copy_to_mode_reg (mode, failval);
>  
> -  switch (mode)
> -{
> -case E_QImode:
> -  emit_insn (gen_despeculate_copyqi (result, val, failval));
> -  break;
> -case E_HImode:
> -  emit_insn (gen_despeculate_copyhi (result, val, failval));
> -  break;
> -case E_SImode:
> -  emit_insn (gen_despeculate_copysi (result, val, failval));
> -  break;
> -case E_DImode:
> -  emit_insn (gen_despeculate_copydi (result, val, failval));
> -  break;
> -case E_TImode:
> -  emit_insn (gen_despeculate_copyti (result, val, failval));
> -  break;
> -default:
> -  gcc_unreachable ();
> -}
> +  emit_insn (gen_despeculate_copy (mode, result, val, failval));
>return result;
>  }
>  
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> 4170d3fbb00c733a1411e726a67af17052800307..32d6f138232c617213f0d3488db49cb3546eb0a9
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -6743,7 +6743,7 @@ (define_insn "speculation_barrier"
>  ;; Support for __builtin_speculation_safe_value when we have speculation
>  ;; tracking enabled.  Use the speculation tracker to decide whether to
>  ;; copy operand 1 to the target, or to copy the fail value (operand 2).
> -(define_expand "despeculate_copy"
> +(define_expand "@despeculate_copy"
>[(set (match_operand:ALLI_TI 0 "register_operand" "=r")
>   (unspec_volatile:ALLI_TI
>[(match_operand:ALLI_TI 1 "register_operand" "r")

Re: [PATCH 14/14] Add D Phobos config, makefiles, and testsuite.

[Richard Sandiford]

Iain Buclaw  writes:
> diff --git a/libphobos/d_rules.am b/libphobos/d_rules.am
> new file mode 100644
> index 000..b16cf5052d2
> --- /dev/null
> +++ b/libphobos/d_rules.am
> @@ -0,0 +1,60 @@
> +# This file contains some common rules for D source compilation
> +# used for libdruntime and libphobos
> +
> +# If there are no sources with known extension (i.e. only D sources)
> +# automake forgets to set this

Needs a copyright notice and licence.

> +# AC_LANG(D)
> +# ---
> +# (we have to use GDC as variable prefix as our GCC patches set GDC
> +#  GDC_FOR_BUILD etc. If we ever want to support other D compilers all
> +#  names need to be changed to DC)

Seems like this is still talking about GDC as a separate project.

> +  # This checks to see if the host supports the compiler-generated builtins
> +  # for atomic operations for various integral sizes. Note, this is intended
> +  # to be an all-or-nothing switch, so all the atomic operations that are
> +  # used should be checked.
> +  AC_MSG_CHECKING([for atomic builtins for byte])
> +  AC_CACHE_VAL(druntime_cv_atomic_byte, [
> +AC_TRY_LINK(
> +  [import gcc.builtins;], [
> +  shared(byte) c1;
> +   byte c2, c3;
> +   __atomic_compare_exchange_1(&c1, &c2, c3, false, 5, 5);
> +   __atomic_load_1(&c1, 5);
> +   __atomic_store_1(&c1, c2, 5);
> +   return 0;
> +  ],
> +  [druntime_cv_atomic_byte=yes],
> +  [druntime_cv_atomic_byte=no])
> +  ])
> +  AC_MSG_RESULT($druntime_cv_atomic_byte)

Link tests generally don't work for newlib targets, since they often
require a specific command-line option to specify the target system.
But perhaps you don't support newlib targets anyway.  Either way,
it shouldn't hold up acceptance.

> --- /dev/null
> +++ b/libphobos/src/Makefile.am
> @@ -0,0 +1,211 @@
> +# Makefile for the Phobos standard library.
> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.

2012-2018.

> diff --git a/libphobos/testsuite/Makefile.am b/libphobos/testsuite/Makefile.am
> new file mode 100644
> index 000..dd99d9d871e
> --- /dev/null
> +++ b/libphobos/testsuite/Makefile.am
> @@ -0,0 +1,15 @@
> +## Process this file with automake to produce Makefile.in.
> +
> +AUTOMAKE_OPTIONS = foreign dejagnu
> +
> +# Setup the testing framework, if you have one
> +EXPECT = $(shell if test -f $(top_builddir)/../expect/expect; then \
> +echo $(top_builddir)/../expect/expect; else echo expect; fi)
> +
> +_RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
> +  echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
> +RUNTEST = "$(_RUNTEST) $(AM_RUNTESTFLAGS)"
> +
> +AM_MAKEFLAGS = "EXEEXT=$(EXEEXT)"
> +
> +CLEANFILES = *.log *.sum

Should probably have a copyright & licence here too, even though
it's small, since it could grow in future.

> +// { dg-shouldfail "static_dtor_exception" }
> +// { dg-output "object.Exception@.*: static_dtor_exception" }
> +// Issue 16594
> +import core.stdc.stdio;

Which bug tracker is this referring to?  Maybe a URI would be better,
to avoid confusion with GCC's bugzilla.  Same for other bugzilla
references in later tests.  Or just remove if the tracker isn't public.

OK otherwise, thanks.

I think that's the last of the unreviewed patches.  Let me know
if I missed one.

Richard

Re: [aarch64}: added variable issue rate feature for falkor

[Kyrill Tkachov]

Hi Kai,

On 11/10/18 16:25, Kai Tietz wrote:

Hi,

I reworked patch use a tuning flag instead of checking explicit for
CPU flavor. I will send soon an update for it, which won't use the
static variable anymore, and uses instead the SCHED-api.

I would like first to get some comments on current version.

Regards,
Kai


Index: trunk/gcc/config/aarch64/aarch64.c
===
--- trunk.orig/gcc/config/aarch64/aarch64.c
+++ trunk/gcc/config/aarch64/aarch64.c
@@ -955,7 +955,7 @@ static const struct tune_params qdf24xx_
   &generic_branch_cost,
   &generic_approx_modes,
   4, /* memmov_cost  */
-  4, /* issue_rate  */
+  8, /* issue_rate  */
   (AARCH64_FUSE_MOV_MOVK | AARCH64_FUSE_ADRP_ADD
| AARCH64_FUSE_MOVK_MOVK), /* fuseable_ops  */
   "16",  /* function_align.  */
@@ -968,7 +968,7 @@ static const struct tune_params qdf24xx_
   2,   /* min_div_recip_mul_df.  */
   0,   /* max_case_values.  */
   tune_params::AUTOPREFETCHER_WEAK,/* autoprefetcher_model.  */
-  AARCH64_EXTRA_TUNE_RENAME_LOAD_REGS, /* tune_flags.  */
+  AARCH64_EXTRA_TUNE_RENAME_LOAD_REGS | AARCH64_EXTRA_TUNE_SCHED_MICRO_OPS, /* 
tune_flags.  */

Thanks for this, this looks much cleaner and externsible.

 &qdf24xx_prefetch_tune
 };
 
@@ -18037,6 +18037,109 @@ aarch64_run_selftests (void)
 
 #endif /* #if CHECKING_P */
 
+/* The number of micro ops left over after issuing the last instruction in a

+   cycle.  This is subtracted from the next cycle before we start issuing 
insns.
+   This is initialized to 0 at the start of every basic block.  */
+static int leftover_uops = 0;
+
+/* Implement TARGET_SCHED_REORDER.  */
+
+static int
+aarch64_sched_reorder (FILE *file, int verbose,
+  rtx_insn **ready ATTRIBUTE_UNUSED,
+  int *n_readyp ATTRIBUTE_UNUSED,
+  int clock)
+{
+  int can_issue_more = aarch64_sched_issue_rate ();
+
+  if ((aarch64_tune_params.extra_tuning_flags
+   & AARCH64_EXTRA_TUNE_SCHED_MICRO_OPS) != 0)
+{
+  /* The start of a basic block.  */
+  if (clock == 0)
+   {
+ if (leftover_uops && file && (verbose > 3))
+   fprintf (file, ";;\tLeftover uops ignored at bb start.\n");
+
+ leftover_uops = 0;
+   }
+
+  /* Account for issue slots left over from previous cycle.  This value
+can be larger than the number of issue slots per cycle, so we need
+to check it here before scheduling any instructions.  */
+  else if (leftover_uops)
+   {
+ can_issue_more -= leftover_uops;
+
+ if (file && (verbose > 3))
+   {
+ fprintf (file, ";;\tUse %d issue slots for leftover uops.\n",
+  leftover_uops);
+ fprintf (file, ";;\t%d issue slots left.\n", can_issue_more);
+   }
+
+ leftover_uops = 0;
+
+ if (can_issue_more < 0)
+   {
+ leftover_uops = 0 - can_issue_more;
+ can_issue_more = 0;
+
+ if (file && (verbose > 3))
+   {
+ fprintf (file, ";;skipping issue cycle.\n");
+ fprintf (file, ";;\t%d uops left over.\n", leftover_uops);
+   }
+   }
+   }
+}
+
+  return can_issue_more;
+}
+
+/* Implement TARGET_SCHED_VARIABLE_ISSUE.  */
+
+static int
+aarch64_variable_issue (FILE *file, int verbose,
+   rtx_insn *insn, int more)
+{
+  if (GET_CODE (PATTERN (insn)) != USE
+  && GET_CODE (PATTERN (insn)) != CLOBBER)
+{
+  if ((aarch64_tune_params.extra_tuning_flags
+  & AARCH64_EXTRA_TUNE_SCHED_MICRO_OPS) == 0)
+   more -= 1;
+  else
+   {
+  /* There is for now just falkor target supporting scheduling
+of micro operations. Therefore we don't need to check.  */
+ int issue_slots = get_attr_falkor_variable_issue (insn);


This is still my concern about having this falkor-specific path.
I think we'll want to go with my suggestion at 
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00815.html
which is to create a generic attribute, called something like 
"number_micro_ops" and have it populated for each core if they decide to use it.
Your patch would provide the falkor numbers initially. Then this part of aarch64.c 
wouldn't be falkor-specific and could use something like 
"get_attr_number_micro_ops".

That is really the biggest concern I had.

Thanks,
Kyrill


+ more -= issue_slots;
+
+ if (file && (verbose > 3))
+   {
+ fprintf (file, ";;\tInsn takes %d issue slots.\n", issue_slots);
+ fprintf (file, ";;\t%d issue slots left.\n", more);
+   }
+
+ /* We schedule an instruction first, and then subtract issue slots,
+which means the result can be negative.  We carry the extra over
+to the next cycle.  */
+
+ if (more < 0)
+   {
+ leftover_uops = 0 - more;
+ mor

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

[James Greenhalgh]

On Mon, Oct 08, 2018 at 05:34:52AM -0500, Martin Liška wrote:
> Hi.
> 
> I'm attaching updated version of the patch.

Can't say I'm thrilled by the allocation/free (aarch64_parse_extension
allocates, everyone else has to free) responsibilities here.

If you can clean that up I'd be much happier. The overall patch is OK.

Thanks,
James

> From d36974540cda9fb0e159103fdcf92d26ef2f1b94 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Thu, 4 Oct 2018 16:31:49 +0200
> Subject: [PATCH] Provide extension hint for aarch64 target (PR driver/83193).
> 
> gcc/ChangeLog:
> 
> 2018-10-05  Martin Liska  
> 
>   PR driver/83193
>   * common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
>   Add new argument invalid_extension.
>   (aarch64_get_all_extension_candidates): New function.
>   (aarch64_rewrite_selected_cpu): Add NULL to function call.
>   * config/aarch64/aarch64-protos.h (aarch64_parse_extension): Add
>   new argument.
>   (aarch64_get_all_extension_candidates): New function.
>   * config/aarch64/aarch64.c (aarch64_parse_arch): Add new
>   argument invalid_extension.
>   (aarch64_parse_cpu): Likewise.
>   (aarch64_print_hint_for_extensions): New function.
>   (aarch64_validate_mcpu): Provide hint about invalid extension.
>   (aarch64_validate_march): Likewise.
>   (aarch64_handle_attr_arch): Pass new argument.
>   (aarch64_handle_attr_cpu): Provide hint about invalid extension.
>   (aarch64_handle_attr_isa_flags): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-10-05  Martin Liska  
> 
>   PR driver/83193
>   * gcc.target/aarch64/spellcheck_7.c: New test.
>   * gcc.target/aarch64/spellcheck_8.c: New test.
>   * gcc.target/aarch64/spellcheck_9.c: New test.
> ---
>  gcc/common/config/aarch64/aarch64-common.c| 24 +-
>  gcc/config/aarch64/aarch64-protos.h   |  4 +-
>  gcc/config/aarch64/aarch64.c  | 75 +++
>  .../gcc.target/aarch64/spellcheck_7.c | 12 +++
>  .../gcc.target/aarch64/spellcheck_8.c | 13 
>  .../gcc.target/aarch64/spellcheck_9.c | 13 
>  6 files changed, 121 insertions(+), 20 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_7.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_8.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/spellcheck_9.c
> 

Re: [patch] allow target config to state r18 is fixed on aarch64

[Kyrill Tkachov]

Hi Olivier,

On 12/10/18 19:43, Olivier Hainque wrote:

Hi Kyrill,

Thanks for your feedback!


On 12 Oct 2018, at 05:50, Kyrill Tkachov  wrote:

CC'ing the aarch64 maintainers as they'll have to approve it.
I'm guessing you've tested this in the usual way (bootstrap and test)?

Sorry, I failed to mention the testing indeed. We don't
have a native box at hand, so I'm not really able to
conduct regular bootstrap and dg testing per se.

We have an active gcc-7 aarch64-vxworks port, still, and have
had good ACATS and internal testsuite results for this port
with this patch, so it doesn't break the build and has
the intended effect on a configuration where FIXED_R18 is
redefined to 1.

We also have good build & tests results on aarch64-elf ports,
which don't redefine the macro.

I checked that we have uses of x18 in several places in libgnat.a
on aarch64-elf, both as a static chain and as a scratch, and
the only references to x18 in the VxWorks libgnat.a are from
functions referring to "environ", precisely the platform specific
use which prevents us from using the register otherwise.

I also sanity checked that "make all-gcc" passes (self tests
included) with mainline + the patch for --target=aarch64-elf
--enable-languages=c.


Any reason not to use the TARGET_CONDITIONAL_REGISTER_USAGE interface to adjust 
the fixed_regs table instead?
I'm not objecting to your approach here, just interested if you considered and 
rejected it.

Hmm, I haven't consciously rejected it. I just went for what
seemed natural at first sight from the elements in place.

In particular, the FIXED_REGS definition comes with a comment
on the use of r18 and it seemed logical to adjust both the comment
and the table there.

I'm happy to move that part to aarch64_conditional_register_usage
if that's considered more canonical of course.


I don't think it's more canonical, and it is a run-time thing, whereas your 
patch changes things
at configure time, so there's no runtime overhead.


It seems like I might need to set call_used_registers to 1 as well.

STATIC_CHAIN_REGNUM still needs to be adjusted directly I think.


I think so too, so you'd still need to have these configure-time changes.
If we could make it all runtime that would be clean, but perhaps it's not worth
splicing the two approaches.


I wondered if we could set it to R11 unconditionally and picked
the way ensuring no change for !vxworks ports, especially since I
don't have means to test more than what I described above.

We're working on a transition to gcc-8 and I can certainly port this
and the rest rapidly to verify that we get similar results on the
more recent code base.


So, do you still want to make this change in current trunk? Or will you make 
the necessary changes
when contributing the vxworks port?

Thanks,
Kyrill


I'll be more than happy to incorporate suggestions of changes in
that process.

Thanks in advance,

With Kind Regards,

Olivier

Account Recovery!!!

[Admin_Supportdesk]

 
 

  
   
  

   
 
   Account Recovery Message
  

 
   Dear gcc-patches@gcc.gnu.org Our record indicates that you recently made a 
request to deactivate this "gcc-patches@gcc.gnu.org" email And this request 
will be processed shortly.
 If this request was made accidentally and you have no knowledge of it, you are 
advised to recover your account now  

  

   
Recover My Account
  

   
   However, if you do not cancel this request,  your account will be 
de-activated shortly 
and all your email data will be lost permanently. Regards.
Email IT Administrator

  

   

 
   
   This message is auto-generated from E-mail IT security server, and replies 
sent to this email can not be delivered. 
This email is meant for: gcc-patches@gcc.gnu.org
  


 

 
 

Re: [v3, testsuite] Introduce dg-add-options net_ts

[Jonathan Wakely]

On 16/10/18 13:38 +0200, Rainer Orth wrote:

Some of the new Networking TS tests FAIL before Solaris 11.4 like this:

FAIL: experimental/net/internet/address/v4/members.cc (test for excess errors)
Excess errors:
Undefined   first referenced
symbol in file
inet_ntop   /var/tmp//ccpcIRXj.o
gai_strerror/var/tmp//ccpcIRXj.o
ld: fatal: symbol referencing errors. No output written to ./members.exe
collect2: error: ld returned 1 exit status

This happens because until the socket etc. functions were integrated
into libc in Solaris 11.4, they only lived in libsocket and libnsl.

The following patch fixes this by introducing a new dg-add-options
keyword net_ts (I'm open for suggestions for the name, of course;
networking_ts might be an option, too) and adding the requirement to the
tests involved.

With the patch below, all but one of the tests PASS on
i386-pc-solaris2.10:

FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test

/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/net/internet/res
olver/ops/lookup.cc:35: void test01(): Assertion '!ec' failed.

The code in question is

 auto addrs = resolv.resolve("localhost", "http", ec);
 VERIFY( !ec );

but "http" is missing from /etc/services before Solaris 11.4.

Ok for mainline?

Btw., one may want to do similarly for the Filesystem TS tests,
introducing dg-add-options fs_ts (or filesystem_ts) instead of repeating
dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" over and over again.


I tried to add this:

diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index f73ce06..fae0b0d 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -254,6 +254,9 @@ proc add_options_for_net_ts { flags } {
if { [istarget *-*-solaris2*] } {
   return "$flags -lsocket -lnsl"
}
+if { [istarget *-*-aix*] } {
+   return "$flags -pthread"
+}
return $flags
}

But it doesn't work. It seems to be ignored, as the test log shows:

extra_tool_flags are:
 -Wl,-bmaxdata:0x2000

That suggests I need to add:

{ dg-additional-options "-pthread" { target *-*-aix* } }

Which is a shame, given that we have your new net_ts that should work.

Re: [PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Christophe Lyon]

On Tue, 16 Oct 2018 at 18:04, Giuliano Augusto Faulin Belinassi
 wrote:
>
> Hello, Christophe
> Could you please dump the assembly of cosatanf here?
>
>
Sure:
.global cosatanf
.syntax unified
.arm
.fpu softvfp
.type   cosatanf, %function
cosatanf:
.LFB3:
.loc 1 44 1 is_stmt 1
.cfi_startproc
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
.LVL50:
.loc 1 45 5
.loc 1 44 1 is_stmt 0
push{r4, lr}
.cfi_def_cfa_offset 8
.cfi_offset 4, -8
.cfi_offset 14, -4
.loc 1 45 12
bl  atanf
.LVL51:
.loc 1 46 1
pop {r4, lr}
.cfi_restore 14
.cfi_restore 4
.cfi_def_cfa_offset 0
.loc 1 45 12
b   cosf
.LVL52:
.cfi_endproc
.LFE3:
.size   cosatanf, .-cosatanf

So, upon entry we have r0=0x5f80
atanf returns 0x3fc90fdb
and cosf returns 0xb33bbd2e


> On Tue, Oct 16, 2018 at 12:23 PM Christophe Lyon
>  wrote:
> >
> > On Tue, 16 Oct 2018 at 17:15, Giuliano Augusto Faulin Belinassi
> >  wrote:
> > >
> > > Hello. Sorry for the late reply.
> > >
> > > > but then cosatanf is computed as (ie there's not call to cosatanf()):
> > > >movwr3, #48430
> > > >movtr3, 45883
> > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > Does this behavior is still present if we change the line 58 to:
> > > int __attribute__ ((optimize("O0")))
> > > in sinatan-1.c?
> >
> > No, this now generates:
> > ldr r0, [fp, #-32]
> > bl  cosatanf
> > where r0=0x5f80, and cosatanf() returns 0xb33bbd2e
> > (ie the same value as what was computed by GCC)
> >
> > > On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
> > >  wrote:
> > > >
> > > > On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
> > > >  wrote:
> > > > >
> > > > > > fc is built with:
> > > > > >mov r0, #0
> > > > > >movtr0, 24448
> > > > > > so r0=0x5f80 (1.8446744E19) which looks ok
> > > > >
> > > > > this is correct. My x86_64 yields the same value
> > > > >
> > > > > > but then cosatanf is computed as (ie there's not call to 
> > > > > > cosatanf()):
> > > > > >movwr3, #48430
> > > > > >movtr3, 45883
> > > > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > > >
> > > > > Ugh. So GCC replaced the function call with a precomputed value? This
> > > > > does not happens in my x86_64. Maybe it is Ofast's fault?
> > > > > Also, it seems that GCC is precomputing cos(atan(x)) before the
> > > > > substitution, as the following python script yields the same result:
> > > > >
> > > >
> > > > Yes, I was surprised to see that.
> > > >
> > > > > import numpy as np
> > > > > x = np.float32 (1.8446744e19)
> > > > > print (np.cos (np.arctan (x))
> > > > >
> > > > > I would also like to add that -4.371139E-8 is very far away from
> > > > > 5.421011E-20, which is a "more" correct value for this computation. So
> > > > > returning 0 may be a better option?
> > > > > On Fri, Oct 12, 2018 at 12:57 PM Jeff Law  wrote:
> > > > > >
> > > > > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > > > > > > Hello
> > > > > > >  What is the output of these functions on such arch? Since the
> > > > > > > test didn't fail for the sinatan counterpart, an possible 
> > > > > > > explanation
> > > > > > > would be that the calculation of the sqrf, sqrt and sqrtl (lines
> > > > > > > 62-64) yielded a number that is far behind of what it should be.
> > > > > > > However, I am still not sure about this, so I will investigate
> > > > > > > further.
> > > > > > >  How about I  write a small program to check if the result
> > > > > > > obtained by this calculation is what it should be?
> > > > > > I suspect it's less the architecture and more the underlying 
> > > > > > library.
> > > > > > As Christophe mentioned, both issues are with newlib which is an C
> > > > > > library primarily used in the emebedded space.  I believe it's math 
> > > > > > code
> > > > > > derives from early BSD libm and likely hasn't been stressed for this
> > > > > > kind of correctness.  It's lightly maintained (primarily for 
> > > > > > cygwin).
> > > > > >
> > > > > > I'm going to run the testcases in my arm linux chroots.  That should
> > > > > > allow us to rule out codegen issues as those chroots will be using 
> > > > > > glibc
> > > > > > for their math library.
> > > > > >
> > > > > > jeff

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

[Kyrill Tkachov]

On 08/10/18 11:34, Martin Liška wrote:

Hi.

I'm attaching updated version of the patch.

Martin


This looks ok to me, but you'll need approval from a maintainer.

Thanks for the iterations,
Kyrill

Re: [PATCH] Initial commit of Networking TS implementation

[Jonathan Wakely]

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

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

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

On 12/10/18 11:50 +0100, Jonathan Wakely wrote:

This implementation is very incomplete (see the various TODO comments
in the code) but rather than keeping it out of tree any longer I'm
committing it to trunk. This will allow others to experiment with it
and (I hope) work on finishing it. Either way we'll ship somehing for
gcc 9. It works OK for some synchronous operations, but most of the
async ops are not done yet.

* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/experimental/bits/net.h: New header for common
implementation details of Networking TS.
* include/experimental/buffer: New header.
* include/experimental/executor: New header.
* include/experimental/internet: New header.
* include/experimental/io_context: New header.
* include/experimental/net: New header.
* include/experimental/netfwd: New header.
* include/experimental/socket: New header.
* include/experimental/timer: New header.
* testsuite/experimental/net/buffer/arithmetic.cc: New test.
* testsuite/experimental/net/buffer/const.cc: New test.
* testsuite/experimental/net/buffer/creation.cc: New test.
* testsuite/experimental/net/buffer/mutable.cc: New test.
* testsuite/experimental/net/buffer/size.cc: New test.
* testsuite/experimental/net/buffer/traits.cc: New test.
* testsuite/experimental/net/execution_context/use_service.cc: New
test.
* testsuite/experimental/net/headers.cc: New test.
* testsuite/experimental/net/internet/address/v4/comparisons.cc: New
test.
* testsuite/experimental/net/internet/address/v4/cons.cc: New test.
* testsuite/experimental/net/internet/address/v4/creation.cc: New
test.
* testsuite/experimental/net/internet/address/v4/members.cc: New
test.
* testsuite/experimental/net/internet/resolver/base.cc: New test.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc: New
test.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc: New
test.
* testsuite/experimental/net/timer/waitable/cons.cc: New test.
* testsuite/experimental/net/timer/waitable/dest.cc: New test.
* testsuite/experimental/net/timer/waitable/ops.cc: New test.


A minor correction. Committed to trunk.


The tests were written three years ago, before we used effective
targets to control the C++14 dialect used for tests. This fixes them
to use the modern style.


And this makes it a bit more portable (but still a long way from
compiling for mingw).


This fixes a name collision in a test, because various systems (at
least GNU and AIX) define struct ip in .

Tested x86_64-linux and powerpc-aix, committed to trunk.

commit 2b7ecc5d99dd705e82c390c7cf8ed01997a94d50
Author: Jonathan Wakely 
Date:   Tue Oct 16 17:08:23 2018 +0100

Rename namespace alias in test to avoid name collision

* testsuite/experimental/net/internet/address/v4/creation.cc: Do not
declare ip in global namespace, to avoid collision with struct ip
defined in .

diff --git a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
index bf92b213fc8..770918f4686 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
@@ -21,8 +21,8 @@
 #include 
 #include 
 
-namespace ip = std::experimental::net::ip;
-using ip::address_v4;
+namespace net = std::experimental::net;
+using net::ip::address_v4;
 
 void
 test01()
@@ -44,12 +44,12 @@ test02()
 {
   bool test __attribute__((unused)) = false;
 
-  auto a0 = ip::make_address_v4(0u);
+  auto a0 = net::ip::make_address_v4(0u);
   VERIFY( a0.to_uint() == 0 );
   VERIFY( a0.to_bytes() == address_v4::bytes_type{} );
 
   address_v4::uint_type u1 = ntohl((5 << 24) | (6 << 16) | (7 << 8) | 8);
-  auto a1 = ip::make_address_v4( u1 );
+  auto a1 = net::ip::make_address_v4( u1 );
   VERIFY( a1.to_uint() == u1 );
   VERIFY( a1.to_bytes() == address_v4::bytes_type( 5, 6, 7, 8 ) );
 }
@@ -59,27 +59,27 @@ test03()
 {
   bool test __attribute__((unused)) = false;
 
-  auto a1 = ip::make_address_v4("127.0.0.1");
+  auto a1 = net::ip::make_address_v4("127.0.0.1");
   VERIFY( a1.is_loopback() );
-  auto a2 = ip::make_address_v4(std::string{"127.0.0.2"});
+  auto a2 = net::ip::make_address_v4(std::string{"127.0.0.2"});
   VERIFY( a2.is_loopback() );
-  auto a3 = ip::make_address_v4(std::experimental::string_view{"127.0.0.3"});
+  auto a3 = net::ip::make_address_v4(std::experimental::string_view{"127.0.0.3"});
   VERIFY( a3.is_loopback() );
 
   std::error_co

Re: [PATCH] Initial commit of Networking TS implementation

[Jonathan Wakely]

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

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

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

On 12/10/18 11:50 +0100, Jonathan Wakely wrote:

This implementation is very incomplete (see the various TODO comments
in the code) but rather than keeping it out of tree any longer I'm
committing it to trunk. This will allow others to experiment with it
and (I hope) work on finishing it. Either way we'll ship somehing for
gcc 9. It works OK for some synchronous operations, but most of the
async ops are not done yet.

* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/experimental/bits/net.h: New header for common
implementation details of Networking TS.
* include/experimental/buffer: New header.
* include/experimental/executor: New header.
* include/experimental/internet: New header.
* include/experimental/io_context: New header.
* include/experimental/net: New header.
* include/experimental/netfwd: New header.
* include/experimental/socket: New header.
* include/experimental/timer: New header.
* testsuite/experimental/net/buffer/arithmetic.cc: New test.
* testsuite/experimental/net/buffer/const.cc: New test.
* testsuite/experimental/net/buffer/creation.cc: New test.
* testsuite/experimental/net/buffer/mutable.cc: New test.
* testsuite/experimental/net/buffer/size.cc: New test.
* testsuite/experimental/net/buffer/traits.cc: New test.
* testsuite/experimental/net/execution_context/use_service.cc: New
test.
* testsuite/experimental/net/headers.cc: New test.
* testsuite/experimental/net/internet/address/v4/comparisons.cc: New
test.
* testsuite/experimental/net/internet/address/v4/cons.cc: New test.
* testsuite/experimental/net/internet/address/v4/creation.cc: New
test.
* testsuite/experimental/net/internet/address/v4/members.cc: New
test.
* testsuite/experimental/net/internet/resolver/base.cc: New test.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc: New
test.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc: New
test.
* testsuite/experimental/net/timer/waitable/cons.cc: New test.
* testsuite/experimental/net/timer/waitable/dest.cc: New test.
* testsuite/experimental/net/timer/waitable/ops.cc: New test.


A minor correction. Committed to trunk.


The tests were written three years ago, before we used effective
targets to control the C++14 dialect used for tests. This fixes them
to use the modern style.


And this makes it a bit more portable (but still a long way from
compiling for mingw).


This fixes the versioned namespace macros, which we use differently on
trunk to how we used them three years ago when I wrote this code.

Tested x86_64-linux and powerpc-aix, committed to trunk.


commit 756b5ac5510ad13ad60cedf71be0c53015b10219
Author: Jonathan Wakely 
Date:   Tue Oct 16 16:51:54 2018 +0100

Fix versioned namespace macros for Networking TS

We no longer put the versioned namespace macros on the innermost
namespace, but always nested directly below namespace std.

* include/experimental/bits/net.h: Move versioned namespace macros
to correct location.
* include/experimental/buffer: Likewise.
* include/experimental/executor: Likewise.
* include/experimental/internet: Likewise.
* include/experimental/io_context: Likewise.
* include/experimental/netfwd: Likewise.
* include/experimental/socket: Likewise.
* include/experimental/timer: Likewise.

diff --git a/libstdc++-v3/include/experimental/bits/net.h b/libstdc++-v3/include/experimental/bits/net.h
index 17bd300ccf2..e2fedd358a5 100644
--- a/libstdc++-v3/include/experimental/bits/net.h
+++ b/libstdc++-v3/include/experimental/bits/net.h
@@ -40,13 +40,13 @@
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
 namespace experimental
 {
 namespace net
 {
 inline namespace v1
 {
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /**
* @ingroup networking
@@ -163,10 +163,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /// @}
 
-_GLIBCXX_END_NAMESPACE_VERSION
 } // namespace v1
 } // namespace net
 } // namespace experimental
+_GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
 #endif // C++14
diff --git a/libstdc++-v3/include/experimental/buffer b/libstdc++-v3/include/experimental/buffer
index 5541823165b..754a9de9953 100644
--- a/libstdc++-v3/include/experimental/buffer
+++ b/libstdc++-v3/include/experimental/buffer
@@ -43,13 +43,13 @@
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
 namespace experimental
 {
 namespace net
 {
 inline namespace v1
 {
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /**
*

Re: [PATCH] Initial commit of Networking TS implementation

[Jonathan Wakely]

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

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

On 12/10/18 11:50 +0100, Jonathan Wakely wrote:

This implementation is very incomplete (see the various TODO comments
in the code) but rather than keeping it out of tree any longer I'm
committing it to trunk. This will allow others to experiment with it
and (I hope) work on finishing it. Either way we'll ship somehing for
gcc 9. It works OK for some synchronous operations, but most of the
async ops are not done yet.

* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/experimental/bits/net.h: New header for common
implementation details of Networking TS.
* include/experimental/buffer: New header.
* include/experimental/executor: New header.
* include/experimental/internet: New header.
* include/experimental/io_context: New header.
* include/experimental/net: New header.
* include/experimental/netfwd: New header.
* include/experimental/socket: New header.
* include/experimental/timer: New header.
* testsuite/experimental/net/buffer/arithmetic.cc: New test.
* testsuite/experimental/net/buffer/const.cc: New test.
* testsuite/experimental/net/buffer/creation.cc: New test.
* testsuite/experimental/net/buffer/mutable.cc: New test.
* testsuite/experimental/net/buffer/size.cc: New test.
* testsuite/experimental/net/buffer/traits.cc: New test.
* testsuite/experimental/net/execution_context/use_service.cc: New
test.
* testsuite/experimental/net/headers.cc: New test.
* testsuite/experimental/net/internet/address/v4/comparisons.cc: New
test.
* testsuite/experimental/net/internet/address/v4/cons.cc: New test.
* testsuite/experimental/net/internet/address/v4/creation.cc: New
test.
* testsuite/experimental/net/internet/address/v4/members.cc: New
test.
* testsuite/experimental/net/internet/resolver/base.cc: New test.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc: New
test.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc: New
test.
* testsuite/experimental/net/timer/waitable/cons.cc: New test.
* testsuite/experimental/net/timer/waitable/dest.cc: New test.
* testsuite/experimental/net/timer/waitable/ops.cc: New test.


A minor correction. Committed to trunk.


The tests were written three years ago, before we used effective
targets to control the C++14 dialect used for tests. This fixes them
to use the modern style.


And this makes it a bit more portable (but still a long way from
compiling for mingw).

Tested x86_64-linux and powerpc-aix, committed to trunk.


commit f0ac14c2e9591577c56d53c57a16e89737f3765b
Author: Jonathan Wakely 
Date:   Tue Oct 16 14:41:20 2018 +0100

Use autoconf to check for features needed by Networking TS

* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for headers used by Networking TS.
* include/experimental/executor: Include 
instead of .
* include/experimental/internet: Use autoconf macros for available
headers.  Include  for.  Remove  and use
__builtin_memcpy and __builtin_strchr.
(resolver_errc) [!_GLIBCXX_HAVE_NETDB_H]: Do not define.
(address_v4::to_string, address_v6::to_string)
[!_GLIBCXX_HAVE_ARPA_INET_H]: Likewise.
(basic_resolver_results) [!_GLIBCXX_HAVE_NETDB_H]: Make private
constructors report errors.
[!_GLIBCXX_HAVE_NETINET_TCP_H] (tcp::no_delay): Do not define.
* include/experimental/io_context: Likewise.
* include/experimental/socket: Likewise.
[!_GLIBCXX_HAVE_SYS_SOCKET_H, !_GLIBCXX_HAVE_POLL_H] (socket_base): Do
not define nested types when relevant header not available.
(__socket_impl::native_non_blocking) [!_GLIBCXX_HAVE_FCNTL_H]: Report
an error.
(__basic_socket_impl::open, __basic_socket_impl::local_endpoint)
(__basic_socket_impl::bind) [!_GLIBCXX_HAVE_SYS_SOCKET_H]: Likewise.
(__basic_socket_impl::io_control) [!_GLIBCXX_HAVE_SYS_IOCTL_H]:
Likewise.
(basic_socket::at_mark, basic_socket::shutdown)
(basic_socket::remote_endpoint, basic_socket::connect)
(basic_socket::async_connect) [!_GLIBCXX_HAVE_SYS_SOCKET_H]: Likewise.
(basic_socket::available) [_GLIBCXX_HAVE_SYS_IOCTL_H]: Check macro
for  availability.
(basic_socket::wait) [!_GLIBCXX_HAVE_POLL_H]: Likewise.
(basic_datagram_socket::receive, basic_datagram_socket::async_receive)
(basic_datagram_socket::receive_from)
(basic_datagram_socket::async_receive_from)
 

Re: [PATCH] lra: fix spill_hard_reg_in_range clobber check

[Ilya Leoshkevich]

> Am 16.10.2018 um 16:20 schrieb Jeff Law :
> 
> On 10/16/18 3:17 AM, Ilya Leoshkevich wrote:
>> Bootstrap and regtest are running on x86_64-redhat-linux.
>> 
>> Insns in FROM..TO range might not be recognized yet, and their
>> corresponding entries in lra_insn_recog_data[] might be NULLs.  In the
>> code from PR87596 the problematic insn is merely
>> 
>>(note 148 154 68 7 NOTE_INSN_DELETED)
>> 
>> however I assume that non-note insns may occur as well.  So make sure
>> they are recognized before touching their lra_insn_recog_data_t.
>> 
>> gcc/ChangeLog:
>> 
>> 2018-10-16  Ilya Leoshkevich  
>> 
>>  PR rtl-optimization/87596
>>  * lra-constraints.c (spill_hard_reg_in_range): Use
>>  lra_get_insn_recog_data () instead of lra_insn_recog_data[]
>>  for instructions in FROM..TO range.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2018-10-16  Ilya Leoshkevich  
>> 
>>  PR rtl-optimization/87596
>>  * gcc.target/i386/pr87596.c: New test.
> I think this is just papering over the problem.
> 
> AFAICT for something like a deleted note lra_get_insn_recog_data is
> going to call lra_set_insn_recog_data.  Given that INSN will be a NOTE I
> think icode will end up being -1 and we'll eventually get into this clause:
> 
>  if (icode < 0)
>{
>  int nop, nalt;
>  machine_mode operand_mode[MAX_RECOG_OPERANDS];
>  const char *constraints[MAX_RECOG_OPERANDS];
> 
>  nop = asm_noperands (PATTERN (insn));
> 
> And I don't think we should be trying to extract the PATTERN of a note.
> 
> I think you need to either filter out the non-insn thingies in
> spill_hard_reg_in_range, or go with your patch plus beefing up the
> checks in lra_set_insn_recog_data.
> 
> jeff
> 

Thanks, you’re absolutely right!

I re-ran the test with --enable-checking=all, and it crashed in another
branch of that if statement:

  else
{
  insn_extract (insn);  /* Also uses PATTERN ().  */
  data->insn_static_data = insn_static_data

I looked at the usage patterns of lra_insn_recog_data[] and
lra_get_insn_recog_data (), and noticed that we use the former directly
only when the insn in question is taken from insn_bitmap, and the latter
in all other cases.  Furthermore, lra_get_insn_recog_data () is normally
guarded by INSN_P () or something similar.

So I plan to keep using lra_get_insn_recog_data (), but with an extra
INSN_P () check.

[gomp5] Add reduction support for taskloop/taskloop simd

[Jakub Jelinek]

Hi!

The following patch adds support for reduction clause on taskloop, which
must not appear if nogroup appears, and if it appears, acts as
task_reduction on the implicit taskgroup around all the tasks created by the
construct and in_reduction on all the created tasks.  We can handle those
more efficiently, don't need to look it up at runtime using
GOMP_task_reduction_remap, but can just call once omp_get_thread_num () and
from the offset and base compute where the private vars are.

Tested on x86_64-linux, committed to gomp-5_0-branch.

2018-10-16  Jakub Jelinek  

* tree-core.h (enum omp_clause_code): Add OMP_CLAUSE__REDUCTEMP_.
* tree.h (OMP_CLAUSE_DECL): Use OMP_CLAUSE__REDUCTEMP_ instead of
OMP_CLAUSE__LOOPTEMP_.
* tree.c (omp_clause_num_ops, omp_clause_code_name): Add _reductemp_
clause.
(walk_tree_1): Handle OMP_CLAUSE__REDUCTEMP_.
* tree-nested.c (convert_nonlocal_omp_clauses,
convert_local_omp_clauses): Likewise.
* tree-pretty-print.c (dump_omp_clause): Likewise.
* omp-low.c (struct omp_context): Add task_reductions and
task_reduction_map fields.
(delete_omp_context): Release task_reductions and task_reduction_map.
(scan_sharing_clauses): Don't add any fields for reduction clause on
taskloop.  Handle OMP_CLAUSE__REDUCTEMP_.
(add_taskreg_looptemp_clauses): Add OMP_CLAUSE__REDUCTEMP_ clause if
needed.
(finish_taskreg_scan): Move also OMP_CLAUSE__REDUCTEMP_ clause in
front if present.
(task_reduction_read): New function.
(lower_rec_input_clauses): Handle OMP_CLAUSE_REDUCTION on taskloop
construct.  Pass NULL_TREE instead of build_outer_var_ref to
omp_clause_default_ctor langhook for task reductions for now.  Handle
OMP_CLAUSE__REDUCTEMP_.
(lower_send_clauses): Handle OMP_CLAUSE__REDUCTEMP_.  Don't send
anything for OMP_CLAUSE_REDUCTION on taskloop.
(lower_omp_task_reductions): Unshare byte positions before gimplifying
them.  Remember mapping of clauses to indexes in the registered array
and if offsets or whole sizes are constant, those constants.  Don't
clear OMP_CLAUSE_REDUCTION_PLACEHOLDER or
OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER for OMP_CLAUSE_REDUCTION.
Handle code OMP_TASKLOOP.
(create_task_copyfn): Copy over OMP_CLAUSE__REDUCTEMP_ pointer.
(lower_omp_taskreg): Handle reduction clause on taskloop construct.
* omp-expand.c (expand_task_call): Add GOMP_TASK_FLAG_REDUCTION flag
to flags if there are any reduction clauses.
gcc/c-family/
* c-omp.c (c_omp_split_clauses) : For
taskloop simd, copy the clause to simd construct transformed into
OMP_CLAUSE_REDUCTION clause.
gcc/c/
* c-typeck.c (handle_omp_array_sections): Call save_expr on array
reductions before calling build_index_type.
(c_finish_omp_clauses): Diagnose nogroup clause used with reduction
clause(s).
gcc/cp/
* pt.c (tsubst_omp_clauses): Handle OMP_CLAUSE_IN_REDUCTION and
OMP_CLAUSE_TASK_REDUCTION.
* semantics.c (handle_omp_array_sections): Call save_expr on array
reductions before calling build_index_type.
(finish_omp_clauses): Diagnose nogroup clause used with reduction
clause(s).
gcc/testsuite/
* c-c++-common/gomp/clauses-1.c (r2): New variable.
(bar): Put taskloop simd inside of taskgroup with task_reduction,
use in_reduction clause instead of reduction.  Add another
taskloop simd without nogroup clause, but with reduction clause and
a new in_reduction.
* c-c++-common/gomp/taskloop-reduction-1.c: New test.
include/
* gomp-constants.h (GOMP_TASK_FLAG_REDUCTION): Define.
libgomp/
* task.c (GOMP_taskgroup_reduction_register): Add ialias.
* taskloop.c (GOMP_taskloop): Handle GOMP_TASK_FLAG_REDUCTION flag
by calling GOMP_taskgroup_reduction_register.
* libgomp_g.h: Include gstdint.h.
(GOMP_taskgroup_reduction_register,
GOMP_taskgroup_reduction_unregister, GOMP_task_reduction_remap): New
prototypes.
* testsuite/libgomp.c-c++-common/taskloop-reduction-1.c: New test.
* testsuite/libgomp.c-c++-common/taskloop-reduction-2.c: New test.
* testsuite/libgomp.c++/taskloop-reduction-1.C: New test.
* testsuite/libgomp.c++/taskloop-reduction-2.C: New test.
* testsuite/libgomp.c++/taskloop-reduction-3.C: New test.
* testsuite/libgomp.c++/taskloop-reduction-4.C: New test.
* testsuite/libgomp.c++/task-reduction-4.C (foo): Turn into function
template, replace all int occurences with the template parameter T.
(test): Likewise.

--- gcc/tree-core.h.jj  2018-08-01 16:36:02.709901571 +0200
+++ gcc/tree-core.h 2018-10-11 13:31:08.055221124 +0200
@@ -340,6 +340,9 @@ enum omp_clause_code {
   /* Internal

Re: [PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Giuliano Augusto Faulin Belinassi]

Hello, Christophe
Could you please dump the assembly of cosatanf here?


On Tue, Oct 16, 2018 at 12:23 PM Christophe Lyon
 wrote:
>
> On Tue, 16 Oct 2018 at 17:15, Giuliano Augusto Faulin Belinassi
>  wrote:
> >
> > Hello. Sorry for the late reply.
> >
> > > but then cosatanf is computed as (ie there's not call to cosatanf()):
> > >movwr3, #48430
> > >movtr3, 45883
> > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > Does this behavior is still present if we change the line 58 to:
> > int __attribute__ ((optimize("O0")))
> > in sinatan-1.c?
>
> No, this now generates:
> ldr r0, [fp, #-32]
> bl  cosatanf
> where r0=0x5f80, and cosatanf() returns 0xb33bbd2e
> (ie the same value as what was computed by GCC)
>
> > On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
> >  wrote:
> > >
> > > On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
> > >  wrote:
> > > >
> > > > > fc is built with:
> > > > >mov r0, #0
> > > > >movtr0, 24448
> > > > > so r0=0x5f80 (1.8446744E19) which looks ok
> > > >
> > > > this is correct. My x86_64 yields the same value
> > > >
> > > > > but then cosatanf is computed as (ie there's not call to cosatanf()):
> > > > >movwr3, #48430
> > > > >movtr3, 45883
> > > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > > >
> > > > Ugh. So GCC replaced the function call with a precomputed value? This
> > > > does not happens in my x86_64. Maybe it is Ofast's fault?
> > > > Also, it seems that GCC is precomputing cos(atan(x)) before the
> > > > substitution, as the following python script yields the same result:
> > > >
> > >
> > > Yes, I was surprised to see that.
> > >
> > > > import numpy as np
> > > > x = np.float32 (1.8446744e19)
> > > > print (np.cos (np.arctan (x))
> > > >
> > > > I would also like to add that -4.371139E-8 is very far away from
> > > > 5.421011E-20, which is a "more" correct value for this computation. So
> > > > returning 0 may be a better option?
> > > > On Fri, Oct 12, 2018 at 12:57 PM Jeff Law  wrote:
> > > > >
> > > > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > > > > > Hello
> > > > > >  What is the output of these functions on such arch? Since the
> > > > > > test didn't fail for the sinatan counterpart, an possible 
> > > > > > explanation
> > > > > > would be that the calculation of the sqrf, sqrt and sqrtl (lines
> > > > > > 62-64) yielded a number that is far behind of what it should be.
> > > > > > However, I am still not sure about this, so I will investigate
> > > > > > further.
> > > > > >  How about I  write a small program to check if the result
> > > > > > obtained by this calculation is what it should be?
> > > > > I suspect it's less the architecture and more the underlying library.
> > > > > As Christophe mentioned, both issues are with newlib which is an C
> > > > > library primarily used in the emebedded space.  I believe it's math 
> > > > > code
> > > > > derives from early BSD libm and likely hasn't been stressed for this
> > > > > kind of correctness.  It's lightly maintained (primarily for cygwin).
> > > > >
> > > > > I'm going to run the testcases in my arm linux chroots.  That should
> > > > > allow us to rule out codegen issues as those chroots will be using 
> > > > > glibc
> > > > > for their math library.
> > > > >
> > > > > jeff

Re: [PATCH] Initial commit of Networking TS implementation

[Jonathan Wakely]

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

On 12/10/18 11:50 +0100, Jonathan Wakely wrote:

This implementation is very incomplete (see the various TODO comments
in the code) but rather than keeping it out of tree any longer I'm
committing it to trunk. This will allow others to experiment with it
and (I hope) work on finishing it. Either way we'll ship somehing for
gcc 9. It works OK for some synchronous operations, but most of the
async ops are not done yet.

* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/experimental/bits/net.h: New header for common
implementation details of Networking TS.
* include/experimental/buffer: New header.
* include/experimental/executor: New header.
* include/experimental/internet: New header.
* include/experimental/io_context: New header.
* include/experimental/net: New header.
* include/experimental/netfwd: New header.
* include/experimental/socket: New header.
* include/experimental/timer: New header.
* testsuite/experimental/net/buffer/arithmetic.cc: New test.
* testsuite/experimental/net/buffer/const.cc: New test.
* testsuite/experimental/net/buffer/creation.cc: New test.
* testsuite/experimental/net/buffer/mutable.cc: New test.
* testsuite/experimental/net/buffer/size.cc: New test.
* testsuite/experimental/net/buffer/traits.cc: New test.
* testsuite/experimental/net/execution_context/use_service.cc: New
test.
* testsuite/experimental/net/headers.cc: New test.
* testsuite/experimental/net/internet/address/v4/comparisons.cc: New
test.
* testsuite/experimental/net/internet/address/v4/cons.cc: New test.
* testsuite/experimental/net/internet/address/v4/creation.cc: New
test.
* testsuite/experimental/net/internet/address/v4/members.cc: New
test.
* testsuite/experimental/net/internet/resolver/base.cc: New test.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc: New
test.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc: New
test.
* testsuite/experimental/net/timer/waitable/cons.cc: New test.
* testsuite/experimental/net/timer/waitable/dest.cc: New test.
* testsuite/experimental/net/timer/waitable/ops.cc: New test.


A minor correction. Committed to trunk.


The tests were written three years ago, before we used effective
targets to control the C++14 dialect used for tests. This fixes them
to use the modern style.

Tested x86_64-linux, committed to trunk.


commit 9abc5d5ee09b86cd1e433de5b41160afe0a7d8a6
Author: Jonathan Wakely 
Date:   Tue Oct 16 16:29:21 2018 +0100

Use effective target in Networking TS tests

* testsuite/experimental/net/headers.cc: Remove dg-options.
* testsuite/experimental/net/buffer/arithmetic.cc: Replace dg-options
with dg-do using effective target.
* testsuite/experimental/net/buffer/const.cc: Likewise.
* testsuite/experimental/net/buffer/creation.cc: Likewise.
* testsuite/experimental/net/buffer/mutable.cc: Likewise.
* testsuite/experimental/net/buffer/size.cc: Likewise.
* testsuite/experimental/net/buffer/traits.cc: Likewise.
* testsuite/experimental/net/execution_context/use_service.cc:
Likewise.
* testsuite/experimental/net/internet/address/v4/comparisons.cc:
Likewise.
* testsuite/experimental/net/internet/address/v4/cons.cc: Likewise.
* testsuite/experimental/net/internet/address/v4/creation.cc:
Likewise.
* testsuite/experimental/net/internet/address/v4/members.cc: Likewise.
* testsuite/experimental/net/internet/resolver/base.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc:
Likewise.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc:
Likewise.
* testsuite/experimental/net/timer/waitable/cons.cc: Likewise.
* testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/experimental/net/buffer/arithmetic.cc b/libstdc++-v3/testsuite/experimental/net/buffer/arithmetic.cc
index 7a894a90530..861afa83e46 100644
--- a/libstdc++-v3/testsuite/experimental/net/buffer/arithmetic.cc
+++ b/libstdc++-v3/testsuite/experimental/net/buffer/arithmetic.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=gnu++14" }
+// { dg-do run { target c++14 } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/buffer/const.cc b/libstdc++-v3/testsuite/experimental/net/buffer/const.cc
index d61f

Re: [PATCH 07/14] Add patches for D language support in GCC targets.

[Richard Sandiford]

Iain Buclaw  writes:
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 4b7cec82382..0b2daa320c3 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -2496,6 +2525,7 @@ s-tm-texi: build/genhooks$(build_exeext) 
> $(srcdir)/doc/tm.texi.in
> && ( test $(srcdir)/doc/tm.texi -nt $(srcdir)/target.def \
>   || test $(srcdir)/doc/tm.texi -nt $(srcdir)/c-family/c-target.def \
>   || test $(srcdir)/doc/tm.texi -nt 
> $(srcdir)/common/common-target.def \
> + || test $(srcdir)/doc/tm.texi -nt $(srcdir)/d/d-target.def \
> ); then \
> echo >&2 ; \
> echo You should edit $(srcdir)/doc/tm.texi.in rather than 
> $(srcdir)/doc/tm.texi . >&2 ; \
> [...]
> @@ -2784,7 +2815,7 @@ build/genrecog.o : genrecog.c $(RTL_BASE_H) 
> $(BCONFIG_H) $(SYSTEM_H)\
>$(CORETYPES_H) $(GTM_H) errors.h $(READ_MD_H) $(GENSUPPORT_H)  
> \
>$(HASH_TABLE_H) inchash.h
>  build/genhooks.o : genhooks.c $(TARGET_DEF) $(C_TARGET_DEF)  \
> -  $(COMMON_TARGET_DEF) $(BCONFIG_H) $(SYSTEM_H) errors.h
> +  $(COMMON_TARGET_DEF) $(D_TARGET_DEF) $(BCONFIG_H) $(SYSTEM_H) errors.h
>  build/genmddump.o : genmddump.c $(RTL_BASE_H) $(BCONFIG_H) $(SYSTEM_H)   
> \
>$(CORETYPES_H) $(GTM_H) errors.h $(READ_MD_H) $(GENSUPPORT_H)
>  build/genmatch.o : genmatch.c $(BCONFIG_H) $(SYSTEM_H) \

I was initially a bit worried about this because it makes the build
depend on the existence of the d/ directory.  But it doesn't look
like we try to ship separate tarballs for specific source languages
any more, so that's probably not a problem.

> @@ -10659,6 +10668,22 @@ unloaded. The default is to return false.
>  Return target-specific mangling context of @var{decl} or @code{NULL_TREE}.
>  @end deftypefn
>  
> +@node D Language and ABI
> +@section D ABI parameters
> +@cindex parameters, d abi
> +
> +@deftypefn {D Target Hook} void TARGET_D_CPU_VERSIONS (void)
> +Declare all environmental version identifiers relating to the target CPU 
> using the function @code{builtin_version}, which takes a string representing 
> the name of the version.  Version identifiers predefined by this hook apply 
> to all modules and being compiled and imported.
> +@end deftypefn

"and being"?  Does this mean "that are being"?

> +@deftypefn {D Target Hook} void TARGET_D_OS_VERSIONS (void)
> +Similarly to @code{TARGET_D_CPU_VERSIONS}, but is used for versions relating 
> to the target operating system.
> +@end deftypefn
> +
> +@deftypefn {D Target Hook} unsigned TARGET_D_CRITSEC_SIZE (void)
> +Returns the size of the data structure used by the targeted operating system 
> for critical sections and monitors.  For example, on Microsoft Windows this 
> would return the @code{sizeof(CRITICAL_SECTION)}, while other platforms that 
> implement pthreads would return @code{sizeof(pthread_mutex_t)}.
> +@end deftypefn

Please reflow the .def so that these fit within 80 chars.

OK otherwise if no target maintainer objects to the changes to their port
(I think they've had plenty of time already :-))

Thanks,
Richard

Re: [PATCH] Initial commit of Networking TS implementation

[Jonathan Wakely]

On 12/10/18 11:50 +0100, Jonathan Wakely wrote:

This implementation is very incomplete (see the various TODO comments
in the code) but rather than keeping it out of tree any longer I'm
committing it to trunk. This will allow others to experiment with it
and (I hope) work on finishing it. Either way we'll ship somehing for
gcc 9. It works OK for some synchronous operations, but most of the
async ops are not done yet.

* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/experimental/bits/net.h: New header for common
implementation details of Networking TS.
* include/experimental/buffer: New header.
* include/experimental/executor: New header.
* include/experimental/internet: New header.
* include/experimental/io_context: New header.
* include/experimental/net: New header.
* include/experimental/netfwd: New header.
* include/experimental/socket: New header.
* include/experimental/timer: New header.
* testsuite/experimental/net/buffer/arithmetic.cc: New test.
* testsuite/experimental/net/buffer/const.cc: New test.
* testsuite/experimental/net/buffer/creation.cc: New test.
* testsuite/experimental/net/buffer/mutable.cc: New test.
* testsuite/experimental/net/buffer/size.cc: New test.
* testsuite/experimental/net/buffer/traits.cc: New test.
* testsuite/experimental/net/execution_context/use_service.cc: New
test.
* testsuite/experimental/net/headers.cc: New test.
* testsuite/experimental/net/internet/address/v4/comparisons.cc: New
test.
* testsuite/experimental/net/internet/address/v4/cons.cc: New test.
* testsuite/experimental/net/internet/address/v4/creation.cc: New
test.
* testsuite/experimental/net/internet/address/v4/members.cc: New
test.
* testsuite/experimental/net/internet/resolver/base.cc: New test.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc: New
test.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc: New
test.
* testsuite/experimental/net/timer/waitable/cons.cc: New test.
* testsuite/experimental/net/timer/waitable/dest.cc: New test.
* testsuite/experimental/net/timer/waitable/ops.cc: New test.


A minor correction. Committed to trunk.


commit 3f35d834c8ac708c25419a8eb770a031ad02f504
Author: Jonathan Wakely 
Date:   Tue Oct 16 16:22:56 2018 +0100

Add missing return

* include/experimental/socket (basic_socket::at_mark): Add missing
return.

diff --git a/libstdc++-v3/include/experimental/socket b/libstdc++-v3/include/experimental/socket
index 7adb42e7e20..e92a4374db9 100644
--- a/libstdc++-v3/include/experimental/socket
+++ b/libstdc++-v3/include/experimental/socket
@@ -756,12 +756,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	const int __result = ::sockatmark(native_handle());
 	if (__result == -1)
-	  __ec.assign(errno, generic_category());
-	else
 	  {
-	__ec.clear();
-	return __result;
+	__ec.assign(errno, generic_category());
+	return false;
 	  }
+	__ec.clear();
+	return (bool)__result;
   }
 
   size_t

Re: [PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Christophe Lyon]

On Tue, 16 Oct 2018 at 17:15, Giuliano Augusto Faulin Belinassi
 wrote:
>
> Hello. Sorry for the late reply.
>
> > but then cosatanf is computed as (ie there's not call to cosatanf()):
> >movwr3, #48430
> >movtr3, 45883
> > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> Does this behavior is still present if we change the line 58 to:
> int __attribute__ ((optimize("O0")))
> in sinatan-1.c?

No, this now generates:
ldr r0, [fp, #-32]
bl  cosatanf
where r0=0x5f80, and cosatanf() returns 0xb33bbd2e
(ie the same value as what was computed by GCC)

> On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
>  wrote:
> >
> > On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
> >  wrote:
> > >
> > > > fc is built with:
> > > >mov r0, #0
> > > >movtr0, 24448
> > > > so r0=0x5f80 (1.8446744E19) which looks ok
> > >
> > > this is correct. My x86_64 yields the same value
> > >
> > > > but then cosatanf is computed as (ie there's not call to cosatanf()):
> > > >movwr3, #48430
> > > >movtr3, 45883
> > > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> > >
> > > Ugh. So GCC replaced the function call with a precomputed value? This
> > > does not happens in my x86_64. Maybe it is Ofast's fault?
> > > Also, it seems that GCC is precomputing cos(atan(x)) before the
> > > substitution, as the following python script yields the same result:
> > >
> >
> > Yes, I was surprised to see that.
> >
> > > import numpy as np
> > > x = np.float32 (1.8446744e19)
> > > print (np.cos (np.arctan (x))
> > >
> > > I would also like to add that -4.371139E-8 is very far away from
> > > 5.421011E-20, which is a "more" correct value for this computation. So
> > > returning 0 may be a better option?
> > > On Fri, Oct 12, 2018 at 12:57 PM Jeff Law  wrote:
> > > >
> > > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > > > > Hello
> > > > >  What is the output of these functions on such arch? Since the
> > > > > test didn't fail for the sinatan counterpart, an possible explanation
> > > > > would be that the calculation of the sqrf, sqrt and sqrtl (lines
> > > > > 62-64) yielded a number that is far behind of what it should be.
> > > > > However, I am still not sure about this, so I will investigate
> > > > > further.
> > > > >  How about I  write a small program to check if the result
> > > > > obtained by this calculation is what it should be?
> > > > I suspect it's less the architecture and more the underlying library.
> > > > As Christophe mentioned, both issues are with newlib which is an C
> > > > library primarily used in the emebedded space.  I believe it's math code
> > > > derives from early BSD libm and likely hasn't been stressed for this
> > > > kind of correctness.  It's lightly maintained (primarily for cygwin).
> > > >
> > > > I'm going to run the testcases in my arm linux chroots.  That should
> > > > allow us to rule out codegen issues as those chroots will be using glibc
> > > > for their math library.
> > > >
> > > > jeff

Re: [PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Giuliano Augusto Faulin Belinassi]

Hello. Sorry for the late reply.

> but then cosatanf is computed as (ie there's not call to cosatanf()):
>movwr3, #48430
>movtr3, 45883
> so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
Does this behavior is still present if we change the line 58 to:
int __attribute__ ((optimize("O0")))
in sinatan-1.c?
On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
 wrote:
>
> On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
>  wrote:
> >
> > > fc is built with:
> > >mov r0, #0
> > >movtr0, 24448
> > > so r0=0x5f80 (1.8446744E19) which looks ok
> >
> > this is correct. My x86_64 yields the same value
> >
> > > but then cosatanf is computed as (ie there's not call to cosatanf()):
> > >movwr3, #48430
> > >movtr3, 45883
> > > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
> >
> > Ugh. So GCC replaced the function call with a precomputed value? This
> > does not happens in my x86_64. Maybe it is Ofast's fault?
> > Also, it seems that GCC is precomputing cos(atan(x)) before the
> > substitution, as the following python script yields the same result:
> >
>
> Yes, I was surprised to see that.
>
> > import numpy as np
> > x = np.float32 (1.8446744e19)
> > print (np.cos (np.arctan (x))
> >
> > I would also like to add that -4.371139E-8 is very far away from
> > 5.421011E-20, which is a "more" correct value for this computation. So
> > returning 0 may be a better option?
> > On Fri, Oct 12, 2018 at 12:57 PM Jeff Law  wrote:
> > >
> > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > > > Hello
> > > >  What is the output of these functions on such arch? Since the
> > > > test didn't fail for the sinatan counterpart, an possible explanation
> > > > would be that the calculation of the sqrf, sqrt and sqrtl (lines
> > > > 62-64) yielded a number that is far behind of what it should be.
> > > > However, I am still not sure about this, so I will investigate
> > > > further.
> > > >  How about I  write a small program to check if the result
> > > > obtained by this calculation is what it should be?
> > > I suspect it's less the architecture and more the underlying library.
> > > As Christophe mentioned, both issues are with newlib which is an C
> > > library primarily used in the emebedded space.  I believe it's math code
> > > derives from early BSD libm and likely hasn't been stressed for this
> > > kind of correctness.  It's lightly maintained (primarily for cygwin).
> > >
> > > I'm going to run the testcases in my arm linux chroots.  That should
> > > allow us to rule out codegen issues as those chroots will be using glibc
> > > for their math library.
> > >
> > > jeff

[PATCH] Define _GLIBCXX_USE_DEV_RANDOM as replacement for _GLIBCXX_USE_RANDOM_TR1

[Jonathan Wakely]

Define and use a new macro with a more descriptive name. Only use the
old macro in .

* acinclude.m4 (GLIBCXX_CHECK_RANDOM_TR1): Replace with ...
(GLIBCXX_CHECK_DEV_RANDOM): New macro with more descriptive name.
Define _GLIBCXX_USE_DEV_RANDOM as well as _GLIBCXX_USE_RANDOM_TR1.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_DEV_RANDOM instead of
GLIBCXX_CHECK_RANDOM_TR1.
crossconfig.m4: Likewise.
* include/bits/random.h (random_device): Use _GLIBCXX_USE_DEV_RANDOM
instead of _GLIBCXX_USE_RANDOM_TR1.
* testsuite/26_numerics/random/random_device/cons/token.cc: Likewise.

Tested x86_64-linux, committed to trunk.


commit 7940f92133f3334da610880e061bb753ec9d795a
Author: Jonathan Wakely 
Date:   Wed Jul 4 15:54:19 2018 +0100

Define _GLIBCXX_USE_DEV_RANDOM as replacement for _GLIBCXX_USE_RANDOM_TR1

Define and use a new macro with a more descriptive name. Only use the
old macro in .

* acinclude.m4 (GLIBCXX_CHECK_RANDOM_TR1): Replace with ...
(GLIBCXX_CHECK_DEV_RANDOM): New macro with more descriptive name.
Define _GLIBCXX_USE_DEV_RANDOM as well as _GLIBCXX_USE_RANDOM_TR1.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_DEV_RANDOM instead of
GLIBCXX_CHECK_RANDOM_TR1.
crossconfig.m4: Likewise.
* include/bits/random.h (random_device): Use _GLIBCXX_USE_DEV_RANDOM
instead of _GLIBCXX_USE_RANDOM_TR1.
* testsuite/26_numerics/random/random_device/cons/token.cc: 
Likewise.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6d68e907426..82a25e5f2f1 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2073,27 +2073,31 @@ AC_DEFUN([GLIBCXX_CHECK_UCHAR_H], [
 
 
 dnl
-dnl Check whether "/dev/random" and "/dev/urandom" are available for the
+dnl Check whether "/dev/random" and "/dev/urandom" are available for
+dnl class std::random_device from C++ 2011 [rand.device], and
 dnl random_device of "TR1" (Chapter 5.1, "Random number generation").
 dnl
-AC_DEFUN([GLIBCXX_CHECK_RANDOM_TR1], [
+AC_DEFUN([GLIBCXX_CHECK_DEV_RANDOM], [
 
-  AC_MSG_CHECKING([for "/dev/random" and "/dev/urandom" for TR1 random_device])
-  AC_CACHE_VAL(glibcxx_cv_random_tr1, [
+  AC_MSG_CHECKING([for "/dev/random" and "/dev/urandom" for 
std::random_device])
+  AC_CACHE_VAL(glibcxx_cv_dev_random, [
 if test -r /dev/random && test -r /dev/urandom; then
-  ## For MSys environment the test above is detect as false-positive
-  ## on mingw-targets.  So disable it explicit for them.
+  ## For MSys environment the test above is detected as false-positive
+  ## on mingw-targets.  So disable it explicitly for them.
   case ${target_os} in
-   *mingw*) glibcxx_cv_random_tr1=no ;;
-   *) glibcxx_cv_random_tr1=yes ;;
+   *mingw*) glibcxx_cv_dev_random=no ;;
+   *) glibcxx_cv_dev_random=yes ;;
   esac
 else
-  glibcxx_cv_random_tr1=no;
+  glibcxx_cv_dev_random=no;
 fi
   ])
-  AC_MSG_RESULT($glibcxx_cv_random_tr1)
+  AC_MSG_RESULT($glibcxx_cv_dev_random)
 
-  if test x"$glibcxx_cv_random_tr1" = x"yes"; then
+  if test x"$glibcxx_cv_dev_random" = x"yes"; then
+AC_DEFINE(_GLIBCXX_USE_DEV_RANDOM, 1,
+ [Define if /dev/random and /dev/urandom are available for
+  std::random_device.])
 AC_DEFINE(_GLIBCXX_USE_RANDOM_TR1, 1,
  [Define if /dev/random and /dev/urandom are available for
   the random_device of TR1 (Chapter 5.1).])
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 332af3706d3..e3612b036df 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -255,8 +255,8 @@ if $GLIBCXX_IS_NATIVE; then
   GLIBCXX_CHECK_MATH_SUPPORT
   GLIBCXX_CHECK_STDLIB_SUPPORT
 
-  # For /dev/random and /dev/urandom for TR1.
-  GLIBCXX_CHECK_RANDOM_TR1
+  # For /dev/random and /dev/urandom for std::random_device.
+  GLIBCXX_CHECK_DEV_RANDOM
 
   # For TLS support.
   GCC_CHECK_TLS
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index 0dbfe4057bd..3de40dc138b 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -66,6 +66,7 @@ case "${host}" in
 GLIBCXX_CHECK_LINKER_FEATURES
 GLIBCXX_CHECK_MATH_SUPPORT
 GLIBCXX_CHECK_STDLIB_SUPPORT
+AC_DEFINE(_GLIBCXX_USE_DEV_RANDOM)
 AC_DEFINE(_GLIBCXX_USE_RANDOM_TR1)
 # We don't yet support AIX's TLS ABI.
 #GCC_CHECK_TLS
@@ -188,6 +189,7 @@ case "${host}" in
 GLIBCXX_CHECK_LINKER_FEATURES
 GLIBCXX_CHECK_MATH_SUPPORT
 GLIBCXX_CHECK_STDLIB_SUPPORT
+AC_DEFINE(_GLIBCXX_USE_DEV_RANDOM)
 AC_DEFINE(_GLIBCXX_USE_RANDOM_TR1)
 GCC_CHECK_TLS
 AC_CHECK_FUNCS(__cxa_thread_atexit_impl)
diff --git a/libstdc++-v3/include/bits/random.h 
b/libstdc++-v3/include/bits/random.h
inde

Re: [PATCH][RFC] Add bitmap_clear_first_set_bit for worklist handling

[Jeff Law]

On 10/16/18 3:12 AM, Richard Biener wrote:
> 
> This adds bitmap_clear_first_set_bit to replace the common
> 
>   unsigned idx = bitmap_first_set_bit (b);
>   bitmap_clear_bit (b, idx);
> 
> pattern which disturbs the bitmap lookup cached element.  We can
> always find and clear the first set bit in O(1) so this implements
> this as a primitive.
> 
> Alternatively one could make sure to never be equal to first
> (but for the only element -- 'current' is a bit weird if you look at 
> bitmap_find_bit).  That would make clearing the first bit never
> update ->current.
> 
> For the weird testcase in PR63155 this makes a noticable difference
> (~5% compile-time).
> 
> Thoughts?
> 
> Thanks,
> Richard.
> 
> 2018-10-16  Richard Biener  
> 
>   * bitmap.h (bitmap_clear_first_set_bit): Declare.
>   * bitmap.c (bitmap_first_set_bit): Make a wrapper around ...
>   (bitmap_first_set_bit_1): ... this worker that now also can
>   clear the bit.
>   (bitmap_clear_first_set_bit): New.
>   * tree-ssa-propagate.c (ssa_propagation_engine::simulate_stmt):
>   Clear stmt from the worklist in callers.
>   (ssa_propagation_engine::simulate_block): Here.
>   (ssa_propagation_engine::ssa_propagate): Use
>   bitmap_clear_first_set_bit to pop off worklist items.
>   * tree-ssa-sccvn.c (do_rpo_vn): Likewise.
>   * tree-ssa-dce.c (simple_dce_from_worklist): Likewise.
>   * tree-cfgcleanup.c (cleanup_tree_cfg_noloop): Likewise.
Seems quite reasonable to me.

Jeff

Re: [PATCH] lra: fix spill_hard_reg_in_range clobber check

[Jeff Law]

On 10/16/18 3:17 AM, Ilya Leoshkevich wrote:
> Bootstrap and regtest are running on x86_64-redhat-linux.
> 
> Insns in FROM..TO range might not be recognized yet, and their
> corresponding entries in lra_insn_recog_data[] might be NULLs.  In the
> code from PR87596 the problematic insn is merely
> 
> (note 148 154 68 7 NOTE_INSN_DELETED)
> 
> however I assume that non-note insns may occur as well.  So make sure
> they are recognized before touching their lra_insn_recog_data_t.
> 
> gcc/ChangeLog:
> 
> 2018-10-16  Ilya Leoshkevich  
> 
>   PR rtl-optimization/87596
>   * lra-constraints.c (spill_hard_reg_in_range): Use
>   lra_get_insn_recog_data () instead of lra_insn_recog_data[]
>   for instructions in FROM..TO range.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-10-16  Ilya Leoshkevich  
> 
>   PR rtl-optimization/87596
>   * gcc.target/i386/pr87596.c: New test.
I think this is just papering over the problem.

AFAICT for something like a deleted note lra_get_insn_recog_data is
going to call lra_set_insn_recog_data.  Given that INSN will be a NOTE I
think icode will end up being -1 and we'll eventually get into this clause:

  if (icode < 0)
{
  int nop, nalt;
  machine_mode operand_mode[MAX_RECOG_OPERANDS];
  const char *constraints[MAX_RECOG_OPERANDS];

  nop = asm_noperands (PATTERN (insn));

And I don't think we should be trying to extract the PATTERN of a note.

I think you need to either filter out the non-insn thingies in
spill_hard_reg_in_range, or go with your patch plus beefing up the
checks in lra_set_insn_recog_data.

jeff

Re: [PATCH] Reset insn priority after inc/ref replacement in haifa sched

[Jeff Law]

On 10/16/18 12:48 AM, Robin Dapp wrote:
>> A C++ style nit/question: instead of adding a new overload 
>>
>>   priority (rtx_insn *, bool)
>>
>> you can add a parameter with a default value in the existing
>> static function
>>
>>   priority (rtx_insn *insn, bool force_recompute = false)
> 
> Sometimes I'm still stuck in C land with GCC :), thanks will change this
> if the rest of the patch is ok.
OK.
jeff

Re: [PATCH] Fix PR87473 (SLSR ICE on hidden basis)

[Jeff Law]

On 10/15/18 3:02 AM, Richard Biener wrote:
> On Fri, Oct 12, 2018 at 10:01 PM Bill Schmidt  wrote:
>>
>> Hi,
>>
>> This patch addresses SLSR bug PR87473.  The underlying problem here is that
>> create_add_on_incoming_edge contains code to handle a phi_arg that is equal
>> to the base expression of the PHI candidate, where the increment assigned to
>> the incoming arc should be zero minus the index expression of the hidden
>> basis; but several other places in SLSR processing need to handle the same
>> case, and fail to do so.  As a result, the code to replace the PHI basis
>> attempts to use an initializing statement that was never created in the first
>> place, and we ICE.  This patch adds the necessary logic in four parts of the
>> code to ensure we handle this consistently throughout.
>>
>> This error survived this long because the typical case when accessing the
>> hidden basis is for the index of the hidden basis to be zero.  For such a
>> case we don't need an initializing statement, and the ICE doesn't trigger.
>> The test case provided with the PR is a counter-example where the hidden
>> basis has an index of 2.
>>
>> For the four functions fixed here, each identified the case of interest,
>> but just didn't do anything when that case arose.  I've reorganized the
>> code in each case to always execute the relevant logic, but change what's
>> done for the specific situation of the "pass-through" PHI argument.  This
>> makes the diffs a little hard to read, unfortunately.
>>
>> During the investigation I noticed that we are dealing with a degenerate PHI,
>> introduced by the loopinit pass, that we would be better off optimizing away
>> sooner:
>>
>>   [local count: 14598063]:
>>   # qz_1 = PHI 
>>   # jl_22 = PHI 
>>   _8 = (unsigned int) jl_22;
>>   _13 = _8 * _15;
>>   qz_11 = (int) _13;
>>
>> The assignment to _8 should just use jl_6 in place of jl_22.  This would
>> greatly simplify SLSR's job, since PHI-free code is handled much more
>> straightforwardly than code that involves conditional updates.  We go through
>> at least 30 passes without having this cleaned up, and I expect other passes
>> than SLSR would perhaps be hamstrung by this as well.  Any recommendations?
> 
> Without more context these are likely loop-closed PHIs.  It's probaby DOM
> after loop that gets rid of them currently but a cheaper way would be to
> propagate them out in pass_tree_loop_done.  Note that IIRC there are some
> other passes rewriting things into loop-closed SSA form that might expose
> such degenerate PHIs as well (a quick look shows invariant motion, both
> VRP and EVRP should eventually propagate them out during their propagation
> step and EVRP shouldn't even need loop-closed SSA?).
There's phi_only_cprop which can deal with this stuff very fast.  It
creates a worklist of degenerate PHIs, propagates them away, adding
anything that becomes a degenerate (including normal statements) to the
worklist.  We typically run it after the dom/vrp or vrp/dom pass pairs
because threading tends to create lots of these degenerates.


The question I would answer is where does the PHI first appear and when
does it become a degenerate?

jeff

Re: [PATCH, OpenACC, 7/8] Multi-dimensional dynamic array support for OpenACC data clauses, libgomp support

[Jakub Jelinek]

On Tue, Oct 16, 2018 at 08:57:00PM +0800, Chung-Lin Tang wrote:
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -490,6 +490,140 @@ gomp_map_val (struct target_mem_desc *tgt, void 
> **hostaddrs, size_t i)
>return tgt->tgt_start + tgt->list[i].offset;
>  }
>  
> +/* Dynamic array related data structures, interfaces with the compiler.  */
> +
> +struct da_dim {
> +  size_t base;
> +  size_t length;
> +  size_t elem_size;
> +  size_t is_array;
> +};
> +
> +struct da_descr_type {
> +  void *ptr;
> +  size_t ndims;
> +  struct da_dim dims[];
> +};

Why do you call the non-contiguous arrays dynamic arrays?  Is that some OpenACC 
term?
I'd also prefix those with gomp_ and it is important to make it clear what
is the ABI type shared with the compiler and what are the internal types.
struct gomp_array_descr would look more natural to me.

> +  for (i = 0; i < mapnum; i++)
> +{
> +  int kind = get_kind (short_mapkind, kinds, i);
> +  if (GOMP_MAP_DYNAMIC_ARRAY_P (kind & typemask))
> + {
> +   da_data_row_num += gomp_dynamic_array_count_rows (hostaddrs[i]);
> +   da_info_num += 1;
> + }
> +}

I'm not really happy by adding several extra loops which will not do
anything in the case there are no non-contiguous arrays being mapped (for
now always for OpenMP (OpenMP 5 has support for non-contigious target update
to/from though) and guess rarely for OpenACC).
Can't you use some flag bit in flags passed to GOMP_target* etc. and do the
above loop only if the compiler indicated there are any?

> +  tgt = gomp_malloc (sizeof (*tgt)
> +  + sizeof (tgt->list[0]) * (mapnum + da_data_row_num));
> +  tgt->list_count = mapnum + da_data_row_num;
>tgt->refcount = pragma_kind == GOMP_MAP_VARS_ENTER_DATA ? 0 : 1;
>tgt->device_descr = devicep;
>struct gomp_coalesce_buf cbuf, *cbufp = NULL;

> @@ -687,6 +863,55 @@ gomp_map_vars (struct gomp_device_descr *devicep, size_t 
> mapnum,
>   }
>  }
>  
> +  /* For dynamic arrays. Each data row is one target item, separated from
> + the normal map clause items, hence we order them after mapnum.  */
> +  for (i = 0, da_index = 0, row_start = 0; i < mapnum; i++)

Even if nothing is in flags, you could just avoid this loop if the previous
loop(s) haven't found any noncontiguous arrays.

> @@ -976,6 +1210,108 @@ gomp_map_vars (struct gomp_device_descr *devicep, 
> size_t mapnum,
>   array++;
> }
> }
> +
> +  /* Processing of dynamic array rows.  */
> +  for (i = 0, da_index = 0, row_start = 0; i < mapnum; i++)
> + {
> +   int kind = get_kind (short_mapkind, kinds, i);
> +   if (!GOMP_MAP_DYNAMIC_ARRAY_P (kind & typemask))
> + continue;

Again.

Jakub

[PATCH, OpenACC, 8/8] Multi-dimensional dynamic array support for OpenACC data clauses, libgomp testsuite additions

[Chung-Lin Tang]

These are the added cases for testing the OpenACC dynamic (sub)arrays 
functionality.

Thanks,
Chung-Lin

libgomp/
* testsuite/libgomp.oacc-c-c++-common/da-1.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-3.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-4.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-utils.h: New test.
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/da-1.c 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/da-1.c
new file mode 100644
index 000..c1c205d
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/da-1.c
@@ -0,0 +1,103 @@
+/* { dg-do run { target { ! openacc_host_selected } } } */
+
+#include 
+#include 
+
+#define n 100
+#define m 100
+
+int b[n][m];
+
+void
+test1 (void)
+{
+  int i, j, *a[100];
+
+  /* Array of pointers form test.  */
+  for (i = 0; i < n; i++)
+{
+  a[i] = (int *)malloc (sizeof (int) * m);
+  for (j = 0; j < m; j++)
+   b[i][j] = j - i;
+}
+
+  #pragma acc parallel loop copyout(a[0:n][0:m]) copyin(b)
+  for (i = 0; i < n; i++)
+#pragma acc loop
+for (j = 0; j < m; j++)
+  a[i][j] = b[i][j];
+
+  for (i = 0; i < n; i++)
+{
+  for (j = 0; j < m; j++)
+   assert (a[i][j] == b[i][j]);
+  /* Clean up.  */
+  free (a[i]);
+}
+}
+
+void
+test2 (void)
+{
+  int i, j, **a = (int **) malloc (sizeof (int *) * n);
+
+  /* Separately allocated blocks.  */
+  for (i = 0; i < n; i++)
+{
+  a[i] = (int *)malloc (sizeof (int) * m);
+  for (j = 0; j < m; j++)
+   b[i][j] = j - i;
+}
+
+  #pragma acc parallel loop copyout(a[0:n][0:m]) copyin(b)
+  for (i = 0; i < n; i++)
+#pragma acc loop
+for (j = 0; j < m; j++)
+  a[i][j] = b[i][j];
+
+  for (i = 0; i < n; i++)
+{
+  for (j = 0; j < m; j++)
+   assert (a[i][j] == b[i][j]);
+  /* Clean up.  */
+  free (a[i]);
+}
+  free (a);
+}
+
+void
+test3 (void)
+{
+  int i, j, **a = (int **) malloc (sizeof (int *) * n);
+  a[0] = (int *) malloc (sizeof (int) * n * m);
+
+  /* Rows allocated in one contiguous block.  */
+  for (i = 0; i < n; i++)
+{
+  a[i] = *a + i * m;
+  for (j = 0; j < m; j++)
+   b[i][j] = j - i;
+}
+
+  #pragma acc parallel loop copyout(a[0:n][0:m]) copyin(b)
+  for (i = 0; i < n; i++)
+#pragma acc loop
+for (j = 0; j < m; j++)
+  a[i][j] = b[i][j];
+
+  for (i = 0; i < n; i++)
+for (j = 0; j < m; j++)
+  assert (a[i][j] == b[i][j]);
+
+  free (a[0]);
+  free (a);
+}
+
+int
+main (void)
+{
+  test1 ();
+  test2 ();
+  test3 ();
+  return 0;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/da-2.c 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/da-2.c
new file mode 100644
index 000..6ee7855
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/da-2.c
@@ -0,0 +1,37 @@
+/* { dg-do run { target { ! openacc_host_selected } } } */
+
+#include 
+#include "da-utils.h"
+
+int
+main (void)
+{
+  int n = 10;
+  int ***a = (int ***) create_da (sizeof (int), n, 3);
+  int ***b = (int ***) create_da (sizeof (int), n, 3);
+  int ***c = (int ***) create_da (sizeof (int), n, 3);
+
+  for (int i = 0; i < n; i++)
+for (int j = 0; j < n; j++)
+  for (int k = 0; k < n; k++)
+   {
+ a[i][j][k] = i + j * k + k;
+ b[i][j][k] = j + k * i + i * j;
+ c[i][j][k] = a[i][j][k];
+   }
+
+  #pragma acc parallel copy (a[0:n][0:n][0:n]) copyin (b[0:n][0:n][0:n])
+  {
+for (int i = 0; i < n; i++)
+  for (int j = 0; j < n; j++)
+   for (int k = 0; k < n; k++)
+ a[i][j][k] += b[k][j][i] + i + j + k;
+  }
+
+  for (int i = 0; i < n; i++)
+for (int j = 0; j < n; j++)
+  for (int k = 0; k < n; k++)
+   assert (a[i][j][k] == c[i][j][k] + b[k][j][i] + i + j + k);
+
+  return 0;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/da-3.c 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/da-3.c
new file mode 100644
index 000..877c6df
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/da-3.c
@@ -0,0 +1,45 @@
+/* { dg-do run { target { ! openacc_host_selected } } } */
+
+#include 
+#include "da-utils.h"
+
+int main (void)
+{
+  int n = 20, x = 5, y = 12;
+  int *a = (int *) create_da (sizeof (int), n, 5);
+
+  int sum1 = 0, sum2 = 0, sum3 = 0;
+
+  for (int i = 0; i < n; i++)
+for (int j = 0; j < n; j++)
+  for (int k = 0; k < n; k++)
+   for (int l = 0; l < n; l++)
+ for (int m = 0; m < n; m++)
+   {
+ a[i][j][k][l][m] = 1;
+ sum1++;
+   }
+
+  #pragma acc parallel copy (a[x:y][x:y][x:y][x:y][x:y]) copy(sum2)
+  {
+for (int i = x; i < x + y; i++)
+  for (int j = x; j < x + y; j++)
+   for (int k = x; k < x + y; k++)
+ for (int l = x; l < x + y; l++)
+   for (int m = x; m < x + y; m++)
+ {
+   a[i][j][k][l][m] = 0;
+   sum2++;
+

[PATCH, OpenACC, 7/8] Multi-dimensional dynamic array support for OpenACC data clauses, libgomp support

[Chung-Lin Tang]

This part is the libgomp runtime handling for OpenACC dynamic arrays.

We handle such arrays by creating a "pointer block" that emulates the N-1 
dimensions,
and then treating each data row of the final Nth dimension as an individual 
object
mapped in the TGT. All the rows are processed as appended after all the other 
map
kind objects.

Thanks,
Chung-Lin

libgomp/
* target.c (struct da_dim): New struct declaration.
(struct da_descr_type): Likewise.
(struct da_info): Likewise.
(gomp_dynamic_array_count_rows): New function.
(gomp_dynamic_array_compute_info): Likewise.
(gomp_dynamic_array_fill_rows_1): Likewise.
(gomp_dynamic_array_fill_rows): Likewise.
(gomp_dynamic_array_create_ptrblock): Likewise.
(gomp_map_vars): Add code to handle dynamic array map kinds.
diff --git a/libgomp/target.c b/libgomp/target.c
index 4c9fae0..071dc70 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -490,6 +490,140 @@ gomp_map_val (struct target_mem_desc *tgt, void 
**hostaddrs, size_t i)
   return tgt->tgt_start + tgt->list[i].offset;
 }
 
+/* Dynamic array related data structures, interfaces with the compiler.  */
+
+struct da_dim {
+  size_t base;
+  size_t length;
+  size_t elem_size;
+  size_t is_array;
+};
+
+struct da_descr_type {
+  void *ptr;
+  size_t ndims;
+  struct da_dim dims[];
+};
+
+/* Internal dynamic array info struct, used only here inside the runtime. */
+
+struct da_info
+{
+  struct da_descr_type *descr;
+  size_t map_index;
+  size_t ptrblock_size;
+  size_t data_row_num;
+  size_t data_row_size;
+};
+
+static size_t
+gomp_dynamic_array_count_rows (struct da_descr_type *descr)
+{
+  size_t nrows = 1;
+  for (size_t d = 0; d < descr->ndims - 1; d++)
+nrows *= descr->dims[d].length / sizeof (void *);
+  return nrows;
+}
+
+static void
+gomp_dynamic_array_compute_info (struct da_info *da)
+{
+  size_t d, n = 1;
+  struct da_descr_type *descr = da->descr;
+
+  da->ptrblock_size = 0;
+  for (d = 0; d < descr->ndims - 1; d++)
+{
+  size_t dim_count = descr->dims[d].length / descr->dims[d].elem_size;
+  size_t dim_ptrblock_size = (descr->dims[d + 1].is_array
+ ? 0 : descr->dims[d].length * n);
+  da->ptrblock_size += dim_ptrblock_size;
+  n *= dim_count;
+}
+  da->data_row_num = n;
+  da->data_row_size = descr->dims[d].length;
+}
+
+static void
+gomp_dynamic_array_fill_rows_1 (struct da_descr_type *descr, void *da,
+   size_t d, void ***row_ptr, size_t *count)
+{
+  if (d < descr->ndims - 1)
+{
+  size_t elsize = descr->dims[d].elem_size;
+  size_t n = descr->dims[d].length / elsize;
+  void *p = da + descr->dims[d].base;
+  for (size_t i = 0; i < n; i++)
+   {
+ void *ptr = p + i * elsize;
+ /* Deref if next dimension is not array.  */
+ if (!descr->dims[d + 1].is_array)
+   ptr = *((void **) ptr);
+ gomp_dynamic_array_fill_rows_1 (descr, ptr, d + 1, row_ptr, count);
+   }
+}
+  else
+{
+  **row_ptr = da + descr->dims[d].base;
+  *row_ptr += 1;
+  *count += 1;
+}
+}
+
+static size_t
+gomp_dynamic_array_fill_rows (struct da_descr_type *descr, void *rows[])
+{
+  size_t count = 0;
+  void **p = rows;
+  gomp_dynamic_array_fill_rows_1 (descr, descr->ptr, 0, &p, &count);
+  return count;
+}
+
+static void *
+gomp_dynamic_array_create_ptrblock (struct da_info *da,
+   void *tgt_addr, void *tgt_data_rows[])
+{
+  struct da_descr_type *descr = da->descr;
+  void *ptrblock = gomp_malloc (da->ptrblock_size);
+  void **curr_dim_ptrblock = (void **) ptrblock;
+  size_t n = 1;
+
+  for (size_t d = 0; d < descr->ndims - 1; d++)
+{
+  int curr_dim_len = descr->dims[d].length;
+  int next_dim_len = descr->dims[d + 1].length;
+  int curr_dim_num = curr_dim_len / sizeof (void *);
+
+  void *next_dim_ptrblock
+   = (void *)(curr_dim_ptrblock + n * curr_dim_num);
+
+  for (int b = 0; b < n; b++)
+for (int i = 0; i < curr_dim_num; i++)
+ {
+   if (d < descr->ndims - 2)
+ {
+   void *ptr = (next_dim_ptrblock
++ b * curr_dim_num * next_dim_len
++ i * next_dim_len);
+   void *tgt_ptr = tgt_addr + (ptr - ptrblock);
+   curr_dim_ptrblock[b * curr_dim_num + i] = tgt_ptr;
+ }
+   else
+ {
+   curr_dim_ptrblock[b * curr_dim_num + i]
+ = tgt_data_rows[b * curr_dim_num + i];
+ }
+   void *addr = &curr_dim_ptrblock[b * curr_dim_num + i];
+   assert (ptrblock <= addr && addr < ptrblock + da->ptrblock_size);
+ }
+
+  n *= curr_dim_num;
+  curr_dim_ptrblock = next_dim_ptrblock;
+}
+  assert (n == da->data_row_num);
+  return ptrblock;
+}
+
 attribute_hidden struct target_mem_desc *
 gomp_map

[PATCH, OpenACC, 6/8] Multi-dimensional dynamic array support for OpenACC data clauses, tree pretty-printing additions

[Chung-Lin Tang]

This tree-pretty-print.c patch allows proper dumping of the dynamic arrays case
of OMP_CLAUSE_MAP.

Thanks,
Chung-Lin

gcc/
* tree-pretty-print.c (dump_omp_clauses): Add cases for printing
GOMP_MAP_DYNAMIC_ARRAY map kinds.
diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 1c7982c..803f76b 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -745,6 +745,33 @@ dump_omp_clause (pretty_printer *pp, tree clause, int spc, 
dump_flags_t flags)
case GOMP_MAP_LINK:
  pp_string (pp, "link");
  break;
+   case GOMP_MAP_DYNAMIC_ARRAY_TO:
+ pp_string (pp, "to,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_FROM:
+ pp_string (pp, "from,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_TOFROM:
+ pp_string (pp, "tofrom,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_FORCE_TO:
+ pp_string (pp, "force_to,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_FORCE_FROM:
+ pp_string (pp, "force_from,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_FORCE_TOFROM:
+ pp_string (pp, "force_tofrom,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_ALLOC:
+ pp_string (pp, "alloc,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_FORCE_ALLOC:
+ pp_string (pp, "force_alloc,dynamic_array");
+ break;
+   case GOMP_MAP_DYNAMIC_ARRAY_FORCE_PRESENT:
+ pp_string (pp, "force_present,dynamic_array");
+ break;
default:
  gcc_unreachable ();
}
@@ -766,6 +793,10 @@ dump_omp_clause (pretty_printer *pp, tree clause, int spc, 
dump_flags_t flags)
case GOMP_MAP_TO_PSET:
  pp_string (pp, " [pointer set, len: ");
  break;
+   case GOMP_MAP_DYNAMIC_ARRAY:
+ gcc_assert (TREE_CODE (OMP_CLAUSE_SIZE (clause)) == TREE_LIST);
+ pp_string (pp, " [dimensions: ");
+ break;
default:
  pp_string (pp, " [len: ");
  break;

[PATCH, OpenACC, 5/8] Multi-dimensional dynamic array support for OpenACC data clauses, omp-low: bias scanning/adjustment during omp-lowering

[Chung-Lin Tang]

This part is also in omp-low.c.

We scan and adjust the code during omp-lowering, to add the biases for each 
dimension when
a dynamic array access is detected, which is required for generally supporting 
copying
sections of each dimension.

The code is a bit sophisticated, and I wonder if this is better implemented in 
gimplify.c
(though probably a non-trivial task as well). Nevertheless, it is currently 
working.

Thanks,
Chung-Lin

gcc/
* omp-low.c (dynamic_array_lookup): New function.
(dynamic_array_reference_start): Likewise.
(scan_for_op): Likewise.
(scan_for_reference): Likewise.
(da_create_bias): Likewise.
(da_dimension_peel): Likewise.
(lower_omp_1): Add case to look for start of dynamic array reference,
and handle bias adjustments for the code sequence.
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 6a1cb05..4c44800 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -8734,6 +8946,201 @@ lower_omp_grid_body (gimple_stmt_iterator *gsi_p, 
omp_context *ctx)
   gimple_build_omp_return (false));
 }
 
+/* Helper to lookup dynamic array through nested omp contexts. Returns
+   TREE_LIST of dimensions, and the CTX where it was found in *CTX_P.  */
+
+static tree
+dynamic_array_lookup (tree t, omp_context **ctx_p)
+{
+  omp_context *c = *ctx_p;
+  while (c)
+{
+  tree *dims = c->dynamic_arrays->get (t);
+  if (dims)
+   {
+ *ctx_p = c;
+ return *dims;
+   }
+  c = c->outer;
+}
+  return NULL_TREE;
+}
+
+/* Tests if this gimple STMT is the start of a dynamic array access sequence.
+   Returns true if found, and also returns the gimple operand ptr and
+   dimensions tree list through *OUT_REF and *OUT_DIMS respectively.  */
+
+static bool
+dynamic_array_reference_start (gimple *stmt, omp_context **ctx_p,
+  tree **out_ref, tree *out_dims)
+{
+  if (gimple_code (stmt) == GIMPLE_ASSIGN)
+for (unsigned i = 1; i < gimple_num_ops (stmt); i++)
+  {
+   tree *op = gimple_op_ptr (stmt, i), dims;
+   if (TREE_CODE (*op) == ARRAY_REF)
+ op = &TREE_OPERAND (*op, 0);
+   if (TREE_CODE (*op) == MEM_REF)
+ op = &TREE_OPERAND (*op, 0);
+   if ((dims = dynamic_array_lookup (*op, ctx_p)) != NULL_TREE)
+ {
+   *out_ref = op;
+   *out_dims = dims;
+   return true;
+ }
+  }
+  return false;
+}
+
+static tree
+scan_for_op (tree *tp, int *walk_subtrees, void *data)
+{
+  struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
+  tree t = *tp;
+  tree op = (tree) wi->info;
+  *walk_subtrees = 1;
+  if (operand_equal_p (t, op, 0))
+{
+  wi->info = tp;
+  return t;
+}
+  return NULL_TREE;
+}
+
+static tree *
+scan_for_reference (gimple *stmt, tree op)
+{
+  struct walk_stmt_info wi;
+  memset (&wi, 0, sizeof (wi));
+  wi.info = op;
+  if (walk_gimple_op (stmt, scan_for_op, &wi))
+return (tree *) wi.info;
+  return NULL;
+}
+
+static tree
+da_create_bias (tree orig_bias, tree unit_type)
+{
+  return build2 (MULT_EXPR, sizetype, fold_convert (sizetype, orig_bias),
+TYPE_SIZE_UNIT (unit_type));
+}
+
+/* Main worker for adjusting dynamic array accesses, handles the adjustment
+   of many cases of statement forms, and called multiple times to 'peel' away
+   each dimension.  */
+
+static gimple_stmt_iterator
+da_dimension_peel (omp_context *da_ctx,
+  gimple_stmt_iterator da_gsi, tree orig_da,
+  tree *da_op_p, tree *da_type_p, tree *da_dims_p)
+{
+  gimple *stmt = gsi_stmt (da_gsi);
+  tree lhs = gimple_assign_lhs (stmt);
+  tree rhs = gimple_assign_rhs1 (stmt);
+
+  if (gimple_num_ops (stmt) == 2
+  && TREE_CODE (rhs) == MEM_REF
+  && operand_equal_p (*da_op_p, TREE_OPERAND (rhs, 0), 0)
+  && !operand_equal_p (orig_da, TREE_OPERAND (rhs, 0), 0)
+  && (TREE_OPERAND (rhs, 1) == NULL_TREE
+ || integer_zerop (TREE_OPERAND (rhs, 1
+{
+  gcc_assert (TREE_CODE (TREE_TYPE (*da_type_p)) == POINTER_TYPE);
+  *da_type_p = TREE_TYPE (*da_type_p);
+}
+  else 
+{
+  gimple *g;
+  gimple_seq ilist = NULL;
+  tree bias, t;
+  tree op = *da_op_p;
+  tree orig_type = *da_type_p;
+  tree orig_bias = TREE_PURPOSE (*da_dims_p);
+  bool by_ref = false;
+
+  if (TREE_CODE (orig_bias) != INTEGER_CST)
+   orig_bias = lookup_decl (orig_bias, da_ctx);
+
+  if (gimple_num_ops (stmt) == 2)
+   {
+ if (TREE_CODE (rhs) == ADDR_EXPR)
+   {
+ rhs = TREE_OPERAND (rhs, 0);
+ *da_dims_p = NULL_TREE;
+   }
+
+ if (TREE_CODE (rhs) == ARRAY_REF
+ && TREE_CODE (TREE_OPERAND (rhs, 0)) == MEM_REF
+ && operand_equal_p (TREE_OPERAND (TREE_OPERAND (rhs, 0), 0),
+ *da_op_p, 0))
+   {
+ bias = da_create_bias (orig_bias,
+

[PATCH, OpenACC, 3/8] Multi-dimensional dynamic array support for OpenACC data clauses, gimplify patch

[Chung-Lin Tang]

This gimplify.c patch adds to the omp clause scanning to handle dynamic array
cases, mainly to properly handle dimension biases of GOMP_MAP_DYNAMIC_ARRAYs by
making sure the bias field is seen in the omp-ctx.

Thanks,
Chung-Lin

gcc/
* gimplify.c (gimplify_scan_omp_clauses): For dynamic array map kinds,
make sure bias in each dimension are put into firstprivate variables.
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 781d430..09ef876 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -7901,8 +7901,28 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
*pre_p,
  if (OMP_CLAUSE_SIZE (c) == NULL_TREE)
OMP_CLAUSE_SIZE (c) = DECL_P (decl) ? DECL_SIZE_UNIT (decl)
  : TYPE_SIZE_UNIT (TREE_TYPE (decl));
- if (gimplify_expr (&OMP_CLAUSE_SIZE (c), pre_p,
-NULL, is_gimple_val, fb_rvalue) == GS_ERROR)
+ if (OMP_CLAUSE_SIZE (c)
+ && TREE_CODE (OMP_CLAUSE_SIZE (c)) == TREE_LIST
+ && GOMP_MAP_DYNAMIC_ARRAY_P (OMP_CLAUSE_MAP_KIND (c)))
+   {
+ tree dims = OMP_CLAUSE_SIZE (c);
+ for (tree t = dims; t; t = TREE_CHAIN (t))
+   {
+ /* If a dimension bias isn't a constant, we have to ensure
+that the value gets transferred to the offload target.  */
+ tree low_bound = TREE_PURPOSE (t);
+ if (TREE_CODE (low_bound) != INTEGER_CST)
+   {
+ low_bound = get_initialized_tmp_var (low_bound, pre_p,
+  NULL, false);
+ omp_add_variable (ctx, low_bound,
+   GOVD_FIRSTPRIVATE | GOVD_SEEN);
+ TREE_PURPOSE (t) = low_bound;
+   }
+   }
+   }
+ else if (gimplify_expr (&OMP_CLAUSE_SIZE (c), pre_p,
+ NULL, is_gimple_val, fb_rvalue) == GS_ERROR)
{
  remove = true;
  break;

[PATCH, OpenACC, 4/8] Multi-dimensional dynamic array support for OpenACC data clauses, omp-low: dynamic array descriptor creation

[Chung-Lin Tang]

The next two patches are the bulk of the compiler patch in the middle-ends.

The first patch here, implements the creation of dynamic array descriptors to
pass to the runtime, a different way than completely using map-clauses.

Because we support arbitrary number of dimensions, adding more map kind cases
may convolute a lot of the compiler/runtime logic handling the long map 
sequences.

This implementation uses a descriptor struct created on stack, and passes the
pointer to descriptor through to the libgomp runtime, using the exact same 
receiver field
for the dynamic array.

The libgomp runtime then does its stuff to set things up, and properly adjusts 
the device-side
receiver field pointer to the on-device created dynamic array structures. I.e. 
the same receiver
field serves as descriptor address field on the compiler side, and as the 
actual data address
once we get to device code (a pretty important point needed to clarify).

Thanks,
Chung-Lin

gcc/
* omp-low.c (struct omp_context):
Add 'hash_map *dynamic_arrays' field, also
added include of "tree-hash-traits.h".
(append_field_to_record_type): New function.
(create_dynamic_array_descr_type): Likewise.
(create_dynamic_array_descr_init_code): Likewise.
(new_omp_context): Add initialize of dynamic_arrays field.
(delete_omp_context): Add delete of dynamic_arrays field.
(scan_sharing_clauses): For dynamic array map kinds, check for
supported dimension structure, and install dynamic array variable into
current omp_context.
(lower_omp_target): Add handling for dynamic array map kinds.
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 6a1cb05..4c44800 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -60,6 +60,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "hsa-common.h"
 #include "stringpool.h"
 #include "attribs.h"
+#include "tree-hash-traits.h"
 
 /* Lowering of OMP parallel and workshare constructs proceeds in two
phases.  The first phase scans the function looking for OMP statements
@@ -124,6 +125,9 @@ struct omp_context
 
   /* True if this construct can be cancelled.  */
   bool cancellable;
+
+  /* Hash map of dynamic arrays in this context.  */
+  hash_map *dynamic_arrays;
 };
 
 static splay_tree all_contexts;
@@ -843,6 +847,136 @@ omp_copy_decl (tree var, copy_body_data *cb)
   return error_mark_node;
 }
 
+/* Helper function for create_dynamic_array_descr_type(), to append a new field
+   to a record type.  */
+
+static void
+append_field_to_record_type (tree record_type, tree fld_ident, tree fld_type)
+{
+  tree *p, fld = build_decl (UNKNOWN_LOCATION, FIELD_DECL, fld_ident, 
fld_type);
+  DECL_CONTEXT (fld) = record_type;
+
+  for (p = &TYPE_FIELDS (record_type); *p; p = &DECL_CHAIN (*p))
+;
+  *p = fld;
+}
+
+/* Create type for dynamic array descriptor. Returns created type, and
+   returns the number of dimensions in *DIM_NUM.  */
+
+static tree
+create_dynamic_array_descr_type (tree decl, tree dims, int *dim_num)
+{
+  int n = 0;
+  tree da_descr_type, name, x;
+  gcc_assert (TREE_CODE (dims) == TREE_LIST);
+
+  da_descr_type = lang_hooks.types.make_type (RECORD_TYPE);
+  name = create_tmp_var_name (".omp_dynamic_array_descr_type");
+  name = build_decl (UNKNOWN_LOCATION, TYPE_DECL, name, da_descr_type);
+  DECL_ARTIFICIAL (name) = 1;
+  DECL_NAMELESS (name) = 1;
+  TYPE_NAME (da_descr_type) = name;
+  TYPE_ARTIFICIAL (da_descr_type) = 1;
+
+  /* Main starting pointer/array.  */
+  tree main_var_type = TREE_TYPE (decl);
+  if (TREE_CODE (main_var_type) == REFERENCE_TYPE)
+main_var_type = TREE_TYPE (main_var_type);
+  append_field_to_record_type (da_descr_type, DECL_NAME (decl),
+  (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE
+   ? main_var_type
+   : build_pointer_type (main_var_type)));
+  /* Number of dimensions.  */
+  append_field_to_record_type (da_descr_type, get_identifier ("$dim_num"),
+  sizetype);
+
+  for (x = dims; x; x = TREE_CHAIN (x), n++)
+{
+  char *fldname;
+  /* One for the start index.  */
+  ASM_FORMAT_PRIVATE_NAME (fldname, "$dim_base", n);
+  append_field_to_record_type (da_descr_type, get_identifier (fldname),
+  sizetype);
+  /* One for the length.  */
+  ASM_FORMAT_PRIVATE_NAME (fldname, "$dim_length", n);
+  append_field_to_record_type (da_descr_type, get_identifier (fldname),
+  sizetype);
+  /* One for the element size.  */
+  ASM_FORMAT_PRIVATE_NAME (fldname, "$dim_elem_size", n);
+  append_field_to_record_type (da_descr_type, get_identifier (fldname),
+  sizetype);
+  /* One for is_array flag.  */
+  ASM_FORMAT_PRIVATE_NAME (fldname, "$dim_is_array", n);
+  append_field_to_record_type (da_descr_type, get_identifier (fl

[PATCH, OpenACC, 2/8] Multi-dimensional dynamic array support for OpenACC data clauses, C/C++ front-end parts

[Chung-Lin Tang]

These are the parts for the C/C++ front-ends. We now allow certain 
non-contiguous
cases under OpenACC, and pass the defined base/length pairs for each
array dimension as a TREE_LIST passed to the middle-end through OMP_CLAUSE_SIZE.

Thanks,
Chung-Lin

gcc/c/
* c-typeck.c (handle_omp_array_sections_1): Add 'bool &non_contiguous'
parameter, adjust recursive call site, add cases for allowing
pointer based multi-dimensional arrays for OpenACC.
(handle_omp_array_sections): Adjust handle_omp_array_sections_1 call,
handle non-contiguous case to create dynamic array map.

gcc/cp/
* semantics.c (handle_omp_array_sections_1): Add 'bool &non_contiguous'
parameter, adjust recursive call site, add cases for allowing
pointer based multi-dimensional arrays for OpenACC.
(handle_omp_array_sections): Adjust handle_omp_array_sections_1 call,
handle non-contiguous case to create dynamic array map.
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 0f639be..c273435 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12409,7 +12409,7 @@ c_finish_omp_cancellation_point (location_t loc, tree 
clauses)
 static tree
 handle_omp_array_sections_1 (tree c, tree t, vec &types,
 bool &maybe_zero_len, unsigned int &first_non_one,
-enum c_omp_region_type ort)
+bool &non_contiguous, enum c_omp_region_type ort)
 {
   tree ret, low_bound, length, type;
   if (TREE_CODE (t) != TREE_LIST)
@@ -12494,7 +12494,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec 
&types,
 }
 
   ret = handle_omp_array_sections_1 (c, TREE_CHAIN (t), types,
-maybe_zero_len, first_non_one, ort);
+maybe_zero_len, first_non_one,
+non_contiguous, ort);
   if (ret == error_mark_node || ret == NULL_TREE)
 return ret;
 
@@ -12654,6 +12655,21 @@ handle_omp_array_sections_1 (tree c, tree t, vec 
&types,
}
}
}
+
+ /* For OpenACC, if the low_bound/length suggest this is a subarray,
+and is referenced through by a pointer, then mark this as
+non-contiguous.  */
+ if (ort == C_ORT_ACC
+ && types.length () > 0
+ && (TREE_CODE (low_bound) != INTEGER_CST
+ || integer_nonzerop (low_bound)
+ || (length && (TREE_CODE (length) != INTEGER_CST
+|| !tree_int_cst_equal (size, length)
+   {
+ tree x = types.last ();
+ if (TREE_CODE (x) == POINTER_TYPE)
+   non_contiguous = true;
+   }
}
   else if (length == NULL_TREE)
{
@@ -12695,13 +12711,16 @@ handle_omp_array_sections_1 (tree c, tree t, 
vec &types,
   /* If there is a pointer type anywhere but in the very first
 array-section-subscript, the array section can't be contiguous.  */
   if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_DEPEND
- && TREE_CODE (TREE_CHAIN (t)) == TREE_LIST)
+ && TREE_CODE (TREE_CHAIN (t)) == TREE_LIST
+ && ort != C_ORT_ACC)
{
  error_at (OMP_CLAUSE_LOCATION (c),
"array section is not contiguous in %qs clause",
omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
  return error_mark_node;
}
+  else if (TREE_CODE (TREE_CHAIN (t)) == TREE_LIST)
+   non_contiguous = true;
 }
   else
 {
@@ -12729,10 +12748,11 @@ handle_omp_array_sections (tree c, enum 
c_omp_region_type ort)
 {
   bool maybe_zero_len = false;
   unsigned int first_non_one = 0;
+  bool non_contiguous = false;
   auto_vec types;
   tree first = handle_omp_array_sections_1 (c, OMP_CLAUSE_DECL (c), types,
maybe_zero_len, first_non_one,
-   ort);
+   non_contiguous, ort);
   if (first == error_mark_node)
 return true;
   if (first == NULL_TREE)
@@ -12765,6 +12785,7 @@ handle_omp_array_sections (tree c, enum 
c_omp_region_type ort)
   unsigned int num = types.length (), i;
   tree t, side_effects = NULL_TREE, size = NULL_TREE;
   tree condition = NULL_TREE;
+  tree da_dims = NULL_TREE;
 
   if (int_size_in_bytes (TREE_TYPE (first)) <= 0)
maybe_zero_len = true;
@@ -12788,6 +12809,13 @@ handle_omp_array_sections (tree c, enum 
c_omp_region_type ort)
length = fold_convert (sizetype, length);
  if (low_bound == NULL_TREE)
low_bound = integer_zero_node;
+
+ if (non_contiguous)
+   {
+ da_dims = tree_cons (low_bound, length, da_dims);
+ continue;
+   }
+
  if (!maybe_zero_len && i > first_non_one)
{
  if (integer_nonzerop (low_bound))
@@ -128

[PATCH, OpenACC, 1/8] Multi-dimensional dynamic array support for OpenACC data clauses, gomp-constants.h additions

[Chung-Lin Tang]

This part defines GOMP_MAP_DYNAMIC_ARRAY_* symbols in include/gomp-constants.h.
Basically use the next bit to define GOMP_MAP_FLAG_SPECIAL_3 to achieve this
purpose.

Thanks,
Chung-Lin Tang

include/
* gomp-constants.h (GOMP_MAP_FLAG_SPECIAL_3): Define.
(enum gomp_map_kind): Add GOMP_MAP_DYNAMIC_ARRAY,
GOMP_MAP_DYNAMIC_ARRAY_TO, GOMP_MAP_DYNAMIC_ARRAY_FROM,
GOMP_MAP_DYNAMIC_ARRAY_TOFROM, GOMP_MAP_DYNAMIC_ARRAY_FORCE_TO,
GOMP_MAP_DYNAMIC_ARRAY_FORCE_FROM, GOMP_MAP_DYNAMIC_ARRAY_FORCE_TOFROM,
GOMP_MAP_DYNAMIC_ARRAY_ALLOC, GOMP_MAP_DYNAMIC_ARRAY_FORCE_ALLOC,
GOMP_MAP_DYNAMIC_ARRAY_FORCE_PRESENT.
(GOMP_MAP_DYNAMIC_ARRAY_P): Define.
diff --git a/include/gomp-constants.h b/include/gomp-constants.h
index ccfb657..f25169c 100644
--- a/include/gomp-constants.h
+++ b/include/gomp-constants.h
@@ -40,6 +40,7 @@
 #define GOMP_MAP_FLAG_SPECIAL_0(1 << 2)
 #define GOMP_MAP_FLAG_SPECIAL_1(1 << 3)
 #define GOMP_MAP_FLAG_SPECIAL_2(1 << 4)
+#define GOMP_MAP_FLAG_SPECIAL_3(1 << 5)
 #define GOMP_MAP_FLAG_SPECIAL  (GOMP_MAP_FLAG_SPECIAL_1 \
 | GOMP_MAP_FLAG_SPECIAL_0)
 /* Flag to force a specific behavior (or else, trigger a run-time error).  */
@@ -128,6 +129,26 @@ enum gomp_map_kind
 /* Decrement usage count and deallocate if zero.  */
 GOMP_MAP_RELEASE = (GOMP_MAP_FLAG_SPECIAL_2
 | GOMP_MAP_DELETE),
+/* Mapping kinds for dynamic arrays.  */
+GOMP_MAP_DYNAMIC_ARRAY =   (GOMP_MAP_FLAG_SPECIAL_3),
+GOMP_MAP_DYNAMIC_ARRAY_TO =(GOMP_MAP_DYNAMIC_ARRAY
+| GOMP_MAP_TO),
+GOMP_MAP_DYNAMIC_ARRAY_FROM =  (GOMP_MAP_DYNAMIC_ARRAY
+| GOMP_MAP_FROM),
+GOMP_MAP_DYNAMIC_ARRAY_TOFROM =(GOMP_MAP_DYNAMIC_ARRAY
+| GOMP_MAP_TOFROM),
+GOMP_MAP_DYNAMIC_ARRAY_FORCE_TO =  (GOMP_MAP_DYNAMIC_ARRAY_TO
+| GOMP_MAP_FLAG_FORCE),
+GOMP_MAP_DYNAMIC_ARRAY_FORCE_FROM =
(GOMP_MAP_DYNAMIC_ARRAY_FROM
+| GOMP_MAP_FLAG_FORCE),
+GOMP_MAP_DYNAMIC_ARRAY_FORCE_TOFROM =  (GOMP_MAP_DYNAMIC_ARRAY_TOFROM
+| GOMP_MAP_FLAG_FORCE),
+GOMP_MAP_DYNAMIC_ARRAY_ALLOC = (GOMP_MAP_DYNAMIC_ARRAY
+| GOMP_MAP_ALLOC),
+GOMP_MAP_DYNAMIC_ARRAY_FORCE_ALLOC =   (GOMP_MAP_DYNAMIC_ARRAY
+| GOMP_MAP_FORCE_ALLOC),
+GOMP_MAP_DYNAMIC_ARRAY_FORCE_PRESENT = (GOMP_MAP_DYNAMIC_ARRAY
+| GOMP_MAP_FORCE_PRESENT),
 
 /* Internal to GCC, not used in libgomp.  */
 /* Do not map, but pointer assign a pointer instead.  */
@@ -156,6 +177,8 @@ enum gomp_map_kind
 #define GOMP_MAP_ALWAYS_P(X) \
   (GOMP_MAP_ALWAYS_TO_P (X) || ((X) == GOMP_MAP_ALWAYS_FROM))
 
+#define GOMP_MAP_DYNAMIC_ARRAY_P(X) \
+  ((X) & GOMP_MAP_DYNAMIC_ARRAY)
 
 /* Asynchronous behavior.  Keep in sync with
libgomp/{openacc.h,openacc.f90,openacc_lib.h}:acc_async_t.  */

[PATCH, OpenACC, 0/8] Multi-dimensional dynamic array support for OpenACC data clauses

[Chung-Lin Tang]

Hi Jakub, this patch set is supposed to be OpenACC functionality, but most of 
it touches shared code,
so I have CCed both you and Thomas.

This patch adds capability to handle C/C++ non-contiguous, dynamically
allocated multi-dimensional arrays in OpenACC data clauses:

int *a[100], **b;

#pragma acc parallel copyin (a[0:n][0:m], b[1:x][5:y]) // re-constructs array 
slices on GPU and copies data in

We currently only allow arrays (e.g. []) at the "outermost" dimension, for 
example:

// These are all okay
int **p;
int ***m;
int n;
int *x[100];

int (*y)[100];   // not allowed

Some of this was due to limiting the scope of implementation, but may actually 
be extended to support with reasonable effort.

I have added descriptions of each part of the implementation in the respective
patch mails. The test results are all okay, no regressions of any sort.
Asking for permission to apply to trunk.

Thanks,
Chung-Lin

2018-10-16  Chung-Lin Tang  

include/
* gomp-constants.h (GOMP_MAP_FLAG_SPECIAL_3): Define.
(enum gomp_map_kind): Add GOMP_MAP_DYNAMIC_ARRAY,
GOMP_MAP_DYNAMIC_ARRAY_TO, GOMP_MAP_DYNAMIC_ARRAY_FROM,
GOMP_MAP_DYNAMIC_ARRAY_TOFROM, GOMP_MAP_DYNAMIC_ARRAY_FORCE_TO,
GOMP_MAP_DYNAMIC_ARRAY_FORCE_FROM, GOMP_MAP_DYNAMIC_ARRAY_FORCE_TOFROM,
GOMP_MAP_DYNAMIC_ARRAY_ALLOC, GOMP_MAP_DYNAMIC_ARRAY_FORCE_ALLOC,
GOMP_MAP_DYNAMIC_ARRAY_FORCE_PRESENT.
(GOMP_MAP_DYNAMIC_ARRAY_P): Define.

gcc/c/
* c-typeck.c (handle_omp_array_sections_1): Add 'bool &non_contiguous'
parameter, adjust recursive call site, add cases for allowing
pointer based multi-dimensional arrays for OpenACC.
(handle_omp_array_sections): Adjust handle_omp_array_sections_1 call,
handle non-contiguous case to create dynamic array map.

gcc/cp/
* semantics.c (handle_omp_array_sections_1): Add 'bool &non_contiguous'
parameter, adjust recursive call site, add cases for allowing
pointer based multi-dimensional arrays for OpenACC.
(handle_omp_array_sections): Adjust handle_omp_array_sections_1 call,
handle non-contiguous case to create dynamic array map.

gcc/
* gimplify.c (gimplify_scan_omp_clauses): For dynamic array map kinds,
make sure bias in each dimension are put into firstprivate variables.
* tree-pretty-print.c (dump_omp_clauses): Add cases for printing
GOMP_MAP_DYNAMIC_ARRAY map kinds.
* omp-low.c (struct omp_context):
Add 'hash_map *dynamic_arrays' field, also
added include of "tree-hash-traits.h".
(append_field_to_record_type): New function.
(create_dynamic_array_descr_type): Likewise.
(create_dynamic_array_descr_init_code): Likewise.
(new_omp_context): Add initialize of dynamic_arrays field.
(delete_omp_context): Add delete of dynamic_arrays field.
(scan_sharing_clauses): For dynamic array map kinds, check for
supported dimension structure, and install dynamic array variable into
current omp_context.
(lower_omp_target): Add handling for dynamic array map kinds.
(dynamic_array_lookup): New function.
(dynamic_array_reference_start): Likewise.
(scan_for_op): Likewise.
(scan_for_reference): Likewise.
(da_create_bias): Likewise.
(da_dimension_peel): Likewise.
(lower_omp_1): Add case to look for start of dynamic array reference,
and handle bias adjustments for the code sequence.

libgomp/
PR other/76739
* target.c (struct da_dim): New struct declaration.
(struct da_descr_type): Likewise.
(struct da_info): Likewise.
(gomp_dynamic_array_count_rows): New function.
(gomp_dynamic_array_compute_info): Likewise.
(gomp_dynamic_array_fill_rows_1): Likewise.
(gomp_dynamic_array_fill_rows): Likewise.
(gomp_dynamic_array_create_ptrblock): Likewise.
(gomp_map_vars): Add code to handle dynamic array map kinds.
* testsuite/libgomp.oacc-c-c++-common/da-1.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-3.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-4.c: New test.
* testsuite/libgomp.oacc-c-c++-common/da-utils.h: New test.

Re: [v3, testsuite] Introduce dg-add-options net_ts

[Jonathan Wakely]

On 16/10/18 13:38 +0200, Rainer Orth wrote:

Some of the new Networking TS tests FAIL before Solaris 11.4 like this:

FAIL: experimental/net/internet/address/v4/members.cc (test for excess errors)
Excess errors:
Undefined   first referenced
symbol in file
inet_ntop   /var/tmp//ccpcIRXj.o
gai_strerror/var/tmp//ccpcIRXj.o
ld: fatal: symbol referencing errors. No output written to ./members.exe
collect2: error: ld returned 1 exit status

This happens because until the socket etc. functions were integrated
into libc in Solaris 11.4, they only lived in libsocket and libnsl.

The following patch fixes this by introducing a new dg-add-options
keyword net_ts (I'm open for suggestions for the name, of course;
networking_ts might be an option, too) and adding the requirement to the
tests involved.

With the patch below, all but one of the tests PASS on
i386-pc-solaris2.10:

FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test

/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/net/internet/res
olver/ops/lookup.cc:35: void test01(): Assertion '!ec' failed.

The code in question is

 auto addrs = resolv.resolve("localhost", "http", ec);
 VERIFY( !ec );

but "http" is missing from /etc/services before Solaris 11.4.

Ok for mainline?


OK, thanks.

[PATCH] Fix tests that fail when compiled without optimisation

[Jonathan Wakely]

* testsuite/20_util/duration/literals/range_neg.cc: Adjust pruned
diagnostic to account for quotes around 'constexpr'.
* testsuite/23_containers/deque/capacity/max_size.cc: Define static
variable.
* testsuite/23_containers/vector/capacity/max_size.cc: Likewise.

Tested x86_64-linux, committed to trunk.

commit cea66d7e4067fd6d44b3834e5a8b9caaf3e8caa4
Author: Jonathan Wakely 
Date:   Tue Oct 16 12:08:57 2018 +0100

Fix tests that fail when compiled without optimisation

* testsuite/20_util/duration/literals/range_neg.cc: Adjust pruned
diagnostic to account for quotes around 'constexpr'.
* testsuite/23_containers/deque/capacity/max_size.cc: Define static
variable.
* testsuite/23_containers/vector/capacity/max_size.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc 
b/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
index f28f2f6a4e8..7b76ecb1460 100644
--- a/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
@@ -28,4 +28,4 @@ test01()
   auto h = 9223372036854775808h;
   // { dg-error "cannot be represented" "" { target *-*-* } 908 }
 }
-// { dg-prune-output "in constexpr expansion" } // needed for -O0
+// { dg-prune-output "in .constexpr. expansion" } // needed for -O0
diff --git a/libstdc++-v3/testsuite/23_containers/deque/capacity/max_size.cc 
b/libstdc++-v3/testsuite/23_containers/deque/capacity/max_size.cc
index 1a38c4ed698..99160700cff 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/capacity/max_size.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/capacity/max_size.cc
@@ -121,6 +121,8 @@ private:
   static const char value = 'x';
 };
 
+const char Iter::value;
+
 Iter operator+(Iter i, Iter::difference_type n) { return i += n; }
 Iter operator+(Iter::difference_type n, Iter i) { return i += n; }
 Iter operator-(Iter::difference_type n, Iter i) { return i -= n; }
diff --git a/libstdc++-v3/testsuite/23_containers/vector/capacity/max_size.cc 
b/libstdc++-v3/testsuite/23_containers/vector/capacity/max_size.cc
index 34d3c4ab96e..bde4c10ac92 100644
--- a/libstdc++-v3/testsuite/23_containers/vector/capacity/max_size.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/capacity/max_size.cc
@@ -121,6 +121,8 @@ private:
   static const char value = 'x';
 };
 
+const char Iter::value;
+
 Iter operator+(Iter i, Iter::difference_type n) { return i += n; }
 Iter operator+(Iter::difference_type n, Iter i) { return i += n; }
 Iter operator-(Iter::difference_type n, Iter i) { return i -= n; }

[v3, testsuite] Introduce dg-add-options net_ts

[Rainer Orth]

Some of the new Networking TS tests FAIL before Solaris 11.4 like this:

FAIL: experimental/net/internet/address/v4/members.cc (test for excess errors)
Excess errors:
Undefined   first referenced
 symbol in file
inet_ntop   /var/tmp//ccpcIRXj.o
gai_strerror/var/tmp//ccpcIRXj.o
ld: fatal: symbol referencing errors. No output written to ./members.exe
collect2: error: ld returned 1 exit status

This happens because until the socket etc. functions were integrated
into libc in Solaris 11.4, they only lived in libsocket and libnsl.

The following patch fixes this by introducing a new dg-add-options
keyword net_ts (I'm open for suggestions for the name, of course;
networking_ts might be an option, too) and adding the requirement to the
tests involved.

With the patch below, all but one of the tests PASS on
i386-pc-solaris2.10:

FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test

/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/net/internet/res
olver/ops/lookup.cc:35: void test01(): Assertion '!ec' failed.

The code in question is

  auto addrs = resolv.resolve("localhost", "http", ec);
  VERIFY( !ec );

but "http" is missing from /etc/services before Solaris 11.4.

Ok for mainline?

Btw., one may want to do similarly for the Filesystem TS tests,
introducing dg-add-options fs_ts (or filesystem_ts) instead of repeating
dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" over and over again.

Rainer

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


2018-10-16  Rainer Orth  

libstdc++-v3:
* testsuite/lib/dg-options.exp (add_options_for_net_ts): New proc.
* testsuite/experimental/net/internet/address/v4/comparisons.cc:
Add dg-add-options net_ts.
* testsuite/experimental/net/internet/address/v4/cons.cc: Likewise.
* testsuite/experimental/net/internet/address/v4/creation.cc: Likewise.
* testsuite/experimental/net/internet/address/v4/members.cc: Likewise.
* testsuite/experimental/net/internet/resolver/base.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc: Likewise.

# HG changeset patch
# Parent  a0cb3bedd3f9d8fb598a779b1954c257c9a97cc7
Introduce dg-add-options net_ts

diff --git a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/comparisons.cc b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/comparisons.cc
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/comparisons.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/comparisons.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-options "-std=gnu++14" }
+// { dg-add-options net_ts }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-options "-std=gnu++14" }
+// { dg-add-options net_ts }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-options "-std=gnu++14" }
+// { dg-add-options net_ts }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-options "-std=gnu++14" }
+// { dg-add-options net_ts }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/internet/resolver/base.cc b/libstdc++-v3/testsuite/experimental/net/internet/resolver/base.cc
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/base.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/base.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-options "-std=gnu++14" }
+// { dg-add-options net_ts }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
+++

[PATCH] PR libstdc++/87618 fix typos in linker script

[Jonathan Wakely]

PR libstdc++/87618
* config/abi/pre/gnu.ver: Fix typos in patterns for basic_stringbuf.
* testsuite/27_io/basic_stringbuf/cons/char/default.cc: Disable
optimisation to check constructor definition can be linked to.
* testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc: Likewise.

Tested x86_64-linux, committed to trunk.


commit 158dfd8b832f5f6f560955081259f3454507c54c
Author: Jonathan Wakely 
Date:   Tue Oct 16 11:55:46 2018 +0100

PR libstdc++/87618 fix typos in linker script

PR libstdc++/87618
* config/abi/pre/gnu.ver: Fix typos in patterns for basic_stringbuf.
* testsuite/27_io/basic_stringbuf/cons/char/default.cc: Disable
optimisation to check constructor definition can be linked to.
* testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc: Likewise.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 4766d28f708..f90ead30dd1 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2032,10 +2032,10 @@ GLIBCXX_3.4.26 {
 _ZNSt13runtime_erroraSEOS_;
 
 # Default constructors for stringstreams
-_ZNSt15basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+_ZNSt15basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
 _ZNSt18basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
 _ZNSt19basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
-_ZNSt7__cxx1115basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+_ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
 
_ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
 
_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
 
diff --git a/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/char/default.cc 
b/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/char/default.cc
index 06b242f8295..44a8c4f8da6 100644
--- a/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/char/default.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/char/default.cc
@@ -17,6 +17,7 @@
 
 // C++11 27.8.2.1  basic_stringbuf constructors  [stringbuf.cons]
 
+// { dg-options "-O0" }
 // { dg-do run { target c++11 } }
 
 #include 
@@ -29,7 +30,15 @@ void test01()
   test.operator()();
 }
 
-int main() 
+void test02()
+{
+  // PR libstdc++/87618
+  // Compiled without optimisation to check this constructor is exported.
+  std::stringbuf sb;
+}
+
+int main()
 {
   test01();
+  test02();
 }
diff --git 
a/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc 
b/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc
index 6ac75ab65c3..e51154e54b6 100644
--- a/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc
@@ -17,6 +17,7 @@
 
 // C++11 27.8.2.1  basic_stringbuf constructors  [stringbuf.cons]
 
+// { dg-options "-O0" }
 // { dg-do run { target c++11 } }
 
 #include 
@@ -29,7 +30,15 @@ void test01()
   test.operator()();
 }
 
-int main() 
+void test02()
+{
+  // PR libstdc++/87618
+  // Compiled without optimisation to check this constructor is exported.
+  std::wstringbuf sb;
+}
+
+int main()
 {
   test01();
+  test02();
 }

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Richard Sandiford]

Hi Martin,

Thanks for the reply.

"Uecker, Martin"  writes:
> Hi Richard,
>
> as Joseph pointed out, there are some related discussions
> on the WG14 reflector. How a about moving the discussion
> there?

The idea was to get a feel for what would be acceptable to GCC
maintainers.  When Arm presented an extension of P0214 to support SVE
at the last C++ committee meeting, using this sizeless type extension
as a possible way of providing the underlying vector types, the feeling
seemed to be that it wouldn't be considered unless it had already been
proven in compilers.

> I find your approach very interesting and that it already
> comes with an implementation is of course very useful
>
> But I don't really understand the reasons why this is not based
> on (2). These types are not "sizeless" at all, their size
> just isn't known at compile time. So to me this seems to me
> a misnomer.
>
> In fact, to me these types *do* in fact seem very similar
> to VLAs as VLAs are also complete types which also do no
> have a known size at compile time.
>
> That arrays decay to pointers doesn't mean that we
> couldn't have similar vectors types which don't decay.
> This is hardly a fundamental problem.

I think it is for some poople though.  If the vectors don't decay to
pointers, they're moe akin to a VLA wrapped in a structure rather than
a stand-alone VLA.  There is a GNU extension for that, e.g.:

  int
  f (int n)
  {
struct s {
  int x[n];
} foo;
return sizeof (foo.x);
  }

But even though clang supports VLAs (of course), it rejects the
above with:

  error: fields must have a constant size: 'variable length array in structure' 
extension will never be supported

This gives a strong impression that wrapping a VLA type like this
is a bridge too far for some :-)  The message makes it clear that's
a case of "don't even bother asking".

The vector tuple types would be very similar to this if modelled as VLAs.

> I also don't understand the problem about the array
> size. If I understand this correctly, the size is somehow
> known at run-time and implicitly passed along with the
> values. So these new types do not need to have a
> size expression (as in your proposal). 

The problem isn't so much that the size is only known at runtime,
but that the size isn't necessarily invariant, and the size of an
object doesn't carry the size information with it.

This means you can't tell what size a given object is, even at runtime.
All you can tell is what size the object would be if you created it
from scratch.  E.g.:

  svint8_t *ptr;  // pointer to variable-length vector type

  void thread1 (void)
  {
svint8_t local;
*ptr = &local;
...run for a long time...
  }

  void thread2 (void)
  {
... sizeof (*ptr); ...;
  }

If thread1 and thread2 have different vector lengths, thread2 has no way
of knowing what size *ptr is.

Of course, thread2 can't validly use *ptr if it has wider vectors than
thread1, but if we resort to saying "undefined behavior" for the above,
then it becomes difficult to define when the size actually is defined.
It's simpler not to make it measurable via sizeof at all.  (And that's
a much less invasive change to the language.)

> Assignment, the possibility to return the type from
> functions, and something like __sizeless_structs would
> make sense for VLAs too.
>
> So creating a new category "variable-length types" for 
> both VLAs and variably-length vector types seems do make
> much more sense to me. As I see it, this would be mainly
> a change in terminology and not so much of the underlying
> approach.

But do you have any feel for whether this would ever be acceptable
in C++?  One of the main requirements for this was that it needs
to work in both C and C++, with the same ABI representation.
I thought VLAs were added to an early draft of C++14 and then
removed before it was published.  They weren't added back for C++17,
and I'd seen other proposals about classes having a "sizeof field"
instead (i.e. the type would carry the size information with it,
which we don't want).  So the prospects didn't look good.

Thanks,
Richard

[AARCH64]Don't force symbols which referencing per-function literal pool into memory

[Renlin Li]

Hi all,

"-mcmodel=large" and "-mpc-relative-loads" are used to avoid adrp+add to 
address symbols.
When the combination is used, the original symbol is first forced into 
per-function literal pools.
And a local symbol is created to reference it.

In this case, the way to reference this local symbol is pc relative. According 
to the original logic,
the local symbol will be forced into memory, and another local symbol will be 
created again.

For example, during expand stage,

(insn 5 2 6 2 (set (reg/f:DI 92)
 (mem/u/c:DI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0  S8 A64])) 
"imm.c":5 -1
  (expr_list:REG_EQUAL (symbol_ref/u:DI ("*.LC0") [flags 0x2])
 (nil)))
(insn 6 5 10 2 (set (reg:TI 90 [  ])
 (mem/u/c:TI (reg/f:DI 92) [0  S16 A128])) "imm.c":5 -1
  (expr_list:REG_EQUAL (const_wide_int 0x123456789abcdef0fedcba987654321)
 (nil)))

However, later, the CSE will replace memory load in insn 5 with its equivalent value 
(symbol_ref/u:DI ("*.LC0").
So there is no issue in the final code-generation.
However, if the CSE is not enabled, for example with -O0, a load will be 
generated.

The patch here simplifies the rtx in expand stage.
Instead of force the local symbol in the memory again, the symbol is classified 
as SYMBOL_TINY_ABSOLUTE.
The following rtx is generated directly.

(insn 5 2 6 2 (set (reg/f:DI 92)
 (symbol_ref/u:DI ("*.LC0") [flags 0x2])) "imm.c":5 -1
  (nil))
(insn 6 5 10 2 (set (reg:TI 90 [  ])
 (mem/u/c:TI (reg/f:DI 92) [0  S16 A128])) "imm.c":5 -1
  (expr_list:REG_EQUAL (const_wide_int 0x123456789abcdef0fedcba987654321)
 (nil)))

Similar change is added to handle literal pool referencing in small memory 
model when option
"-mpc-relative-loads" is present. The symbol is classified as 
SYMBOL_TINY_ABSOLUTE, instead of SYMBOL_SMALL_ABSOLUTE.
So that, in the final code-generation, a single ADR instruction could be used, 
instead of ADRP+ADD.

A test case is added, which should be applicable at O0 optimization level for 
all memory models (tiny, small and large).

Okay to commit?


gcc/ChangeLog:

2018-10-15  Renlin Li  

 * config/aarch64/aarch64.c (aarch64_classify_symbol): Direct address
 symbols referencing per function literl pool.

gcc/testsuite/ChangeLog:

2018-10-15  Renlin Li  

 * gcc.target/aarch64/pr79041-2.c: Skip when mcmodel is defined by
 dejagnu configuration.
 * gcc.target/aarch64/pr79041-3.c: New.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2f98a21acf16297bdd7c4742cbcfc695cdc4e5f9..bd6369ca08707cca59809bf970830238b05fa2bc 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11845,7 +11845,13 @@ aarch64_classify_symbol (rtx x, HOST_WIDE_INT offset)
 	  || !IN_RANGE (offset, HOST_WIDE_INT_C (-4294967263),
 			HOST_WIDE_INT_C (4294967264)))
 	return SYMBOL_FORCE_TO_MEM;
-	  return SYMBOL_SMALL_ABSOLUTE;
+	  /* Use ADR when addressing per-function constant pool if
+	 pcrelative_literal_loads is enabled.  */
+	  else if (CONSTANT_POOL_ADDRESS_P (x)
+		   && aarch64_pcrelative_literal_loads)
+	return SYMBOL_TINY_ABSOLUTE;
+	  else
+	return SYMBOL_SMALL_ABSOLUTE;
 
 	case AARCH64_CMODEL_TINY_PIC:
 	  if (!aarch64_symbol_binds_local_p (x))
@@ -11857,14 +11863,24 @@ aarch64_classify_symbol (rtx x, HOST_WIDE_INT offset)
 	  if (!aarch64_symbol_binds_local_p (x))
 	return (aarch64_cmodel == AARCH64_CMODEL_SMALL_SPIC
 		?  SYMBOL_SMALL_GOT_28K : SYMBOL_SMALL_GOT_4G);
-	  return SYMBOL_SMALL_ABSOLUTE;
+	  /* Use ADR when addressing per-function constant pool if
+	 pcrelative_literal_loads is enabled.  */
+	  else if (CONSTANT_POOL_ADDRESS_P (x)
+		   && aarch64_pcrelative_literal_loads)
+	return SYMBOL_TINY_ABSOLUTE;
+	  else
+	return SYMBOL_SMALL_ABSOLUTE;
 
 	case AARCH64_CMODEL_LARGE:
-	  /* This is alright even in PIC code as the constant
-	 pool reference is always PC relative and within
-	 the same translation unit.  */
-	  if (!aarch64_pcrelative_literal_loads && CONSTANT_POOL_ADDRESS_P (x))
-	return SYMBOL_SMALL_ABSOLUTE;
+	  if (CONSTANT_POOL_ADDRESS_P (x))
+	{
+	  /* Use ADR when addressing per-function constant pool if
+		 pcrelative_literal_loads is enabled.  */
+	  if (aarch64_pcrelative_literal_loads)
+		return SYMBOL_TINY_ABSOLUTE;
+	  else
+		return SYMBOL_SMALL_ABSOLUTE;
+	}
 	  else
 	return SYMBOL_FORCE_TO_MEM;
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr79041-2.c b/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
index 4695b5c1b2b7c9b515995e242dd38e0519a48a2b..42695be127db454934d2791474d5f97fc5667403 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
@@ -2,6 +2,7 @@
 /* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads" } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-skip-if "-mcmodel=large, no support for -fpic" { aarch64-*-* }  { "-fpic" } 

[00/10][RFC] Splitting the C and C++ concept of "complete type"

[Richard Sandiford]

The C standard says:

At various points within a translation unit an object type may be
"incomplete" (lacking sufficient information to determine the size of
objects of that type) or "complete" (having sufficient information).

For AArch64 SVE, we'd like to split this into two concepts:

  * has the type been fully defined?
  * would fully-defining the type determine its size?

This is because we'd like to be able to represent SVE vectors as C and C++
types.  Since SVE is a "vector-length agnostic" architecture, the size
of the vectors is determined by the runtime environment rather than the
programmer or compiler.  In that sense, defining an SVE vector type does
not determine its size.  It's nevertheless possible to use SVE vector types
in meaningful ways, such as having automatic vector variables and passing
vectors between functions.

The main questions in the RFC are:

  1) is splitting the definition like this OK in principle?
  2) are the specific rules described below OK?
  3) coding-wise, how should the split be represented in GCC?

Terminology
---

Going back to the second bullet above:

  * would fully-defining the type determine its size?

the rest of the RFC calls a type "sized" if fully defining it would
determine its size.  The type is "sizeless" otherwise.

Contents


The RFC is organised as follows.  I've erred on the side of including
detail rather than leaving it out, but each section is meant to be
self-contained and skippable:

  - An earlier RFC
  - Quick overview of SVE
  - Why we need SVE types in C and C++
  - How we ended up with this definition
  - The SVE types in more detail
  - Outline of the type system changes
  - Sizeless structures (and testing on non-SVE targets)
  - Other variable-length vector architectures
  - Edits to the C standard
- Base changes
- Updates for consistency
- Sizeless structures
  - Edits to the C++ standard
  - GCC implementation questions

I'll follow up with patches that implement the split.



An earlier RFC
==

For the record (in case this sounds familiar) I sent an RFC about the
sizeless type extension a while ago:

https://gcc.gnu.org/ml/gcc/2017-08/msg00012.html

The rules haven't changed since then, but this version includes more
information and includes support for sizeless structures.


Quick overview of SVE
=

SVE is a vector extension to AArch64.  A detailed description is
available here:

https://static.docs.arm.com/ddi0584/a/DDI0584A_a_SVE_supp_armv8A.pdf

but the only feature that really matters for this RFC is that SVE has no
fixed or preferred vector length.  Implementations can instead choose
from a range of possible vector lengths, with 128 bits being the minimum
and 2048 bits being the maximum.  Priveleged software can further
constrain the vector length within the range offered by the implementation;
e.g. linux currently provides per-thread control of the vector length.


Why we need SVE types in C and C++
==

SVE was designed to be an easy target for autovectorising normal scalar
code.  There are also various language extensions that support explicit
data parallelism or that make explicit vector chunking easier to do in
an architecture-neutral way (e.g. C++ P0214).  This means that many users
won't need to do anything SVE-specific.

Even so, there's always going to be a place for writing SVE-specific
optimisations, with full access to the underlying ISA.  As for other
vector architectures, we'd like users to be able to write such routines
in C and C++ rather than force them to go all the way to assembly.

We'd also like C and C++ functions to be able to take SVE vector
parameters and return SVE vector results, which is particularly useful
when implementing things like vector math routines.  In this case in
particular, the types need to map directly to something that fits in
an SVE register, so that passing and returning vectors has minimal
overhead.


How we ended up with this definition


Requirements


We need the SVE vector types to define and use SVE intrinsic functions
and to write SVE vector library routines.  The key requirements when
defining the types were:

  * They must be available in both C and C++ (because we want to be able
add SVE optimisations to C-only codebases).

  * They must fit in an SVE vector register (so there can be no on-the-side
information).

  * It must be possible to define automatic variables with these types.

  * It must be possible to pass and return objects of these types
(since that's what intrinsics and vector library routines need to do).

  * It must be possible to use the types in _Generic associations
(so that _Generic can be used to provide tgmath.h-style overloads).

  * It must be possible to use pointers or references to the types
(for passing or returning by pointer or reference, and because not
allowin

Re: [PATCH 02/14] Add D frontend (GDC) implementation.

[Richard Sandiford]

Iain Buclaw  writes:
> On 18 September 2018 at 02:33, Iain Buclaw  wrote:
>> This patch adds the D front-end implementation, the only part of the
>> compiler that interacts with GCC directly, and being the parts that I
>> maintain, is something that I can talk about more directly.
>>
>> For the actual code generation pass, that converts the front-end AST
>> to GCC trees, most parts use a separate Visitor interfaces to do a
>> certain kind of lowering, for instance, types.cc builds *_TYPE trees
>> from AST Type's.  The Visitor class is part of the DMD front-end, and
>> is defined in dfrontend/visitor.h.
>>
>> There are also a few interfaces which have their headers in the DMD
>> frontend, but are implemented here because they do something that
>> requires knowledge of the GCC backend (d-target.cc), does something
>> that may not be portable, or differ between D compilers
>> (d-frontend.cc) or are a thin wrapper around something that is managed
>> by GCC (d-diagnostic.cc).
>>
>> Many high level operations result in generation of calls to D runtime
>> library functions (runtime.def), all with require some kind of runtime
>> type information (typeinfo.cc).  The compiler also generates functions
>> for registering/deregistering compiled modules with the D runtime
>> library (modules.cc).
>>
>> As well as the D language having it's own built-in functions
>> (intrinsics.cc), we also expose GCC builtins to D code via a
>> `gcc.builtins' module (d-builtins.cc), and give special treatment to a
>> number of UDAs that could be applied to functions (d-attribs.cc).
>>
>>
>> That is roughly the high level jist of how things are currently organized.
>>
>> ftp://ftp.gdcproject.org/patches/v4/02-v4-d-frontend-gdc.patch
>>
>
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00587.html
>
> During the last round, the last comment given was that the reviewer
> wasn't going to dive deep into this code, as it's essentially
> converting between the different representations and is code that I'd
> be maintaining.
>
> As this is code that other gcc maintainers will be potentially looking
> after as well, I'd like any glaring problems to be dealt with
> immediately.

I won't claim that I dived deep into the code either, since with a patch
of this size that would take weeks.  But FWIW I read it through trying
to scan for anything that stood out.

I think the patch is OK besides the below.  The comments are in patch
order and so mix very trivial stuff with things that seem more fundamental.
I think the only real blocker is the point below about translations.

> +/* Define attributes that are mutually exclusive with one another.  */
> +static const struct attribute_spec::exclusions attr_noreturn_exclusions[] =
> +{
> +  ATTR_EXCL ("noreturn", true, true, true),

Why does noreturn exclude itself?  Probably worth a comment if deliberate.

> +tree
> +build_attributes (Expressions *eattrs)
> +{
> [...]
> +  tree list = build_tree_list (get_identifier (name), args);
> +  attribs =  chainon (attribs, list);

Too many spaces before "chainon".

> +static tree
> +handle_const_attribute (tree *node, tree ARG_UNUSED (name),
> + tree ARG_UNUSED (args), int ARG_UNUSED (flags),
> + bool * ARG_UNUSED (no_add_attrs))
> +{
> +  tree type = TREE_TYPE (*node);
> +
> +  /* See FIXME comment on noreturn in c_common_attribute_table.  */

Seems strange to be referencing c-family code here, especially since
there's no corresponding comment for handle_noreturn_attribute and
also no FIXME comment in the D version of the table.  Think we should
just drop the comment above.

It's unfortunate that there's so much cut-&-paste with c-attribs.c,
but there again, the current split between target-independent code
(attribs.*) and frontend code (c-attribs.*) isn't very clear-cut,
so I don't think this should hold up acceptance.

I'm going to review it as new code though, so:

> +/* Handle a "malloc" attribute; arguments as in
> +   struct attribute_spec.handler.  */
> +
> +tree
> +handle_malloc_attribute (tree *node, tree ARG_UNUSED (name),
> +  tree ARG_UNUSED (args), int ARG_UNUSED (flags),
> +  bool * ARG_UNUSED (no_add_attrs))
> +{
> +  if (TREE_CODE (*node) == FUNCTION_DECL
> +  && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (*node
> +DECL_IS_MALLOC (*node) = 1;
> +  else
> +gcc_unreachable ();
> +
> +  return NULL_TREE;
> +}
> +
> +/* Handle a "pure" attribute; arguments as in
> +   struct attribute_spec.handler.  */
> +
> +static tree
> +handle_pure_attribute (tree *node, tree ARG_UNUSED (name),
> +tree ARG_UNUSED (args), int ARG_UNUSED (flags),
> +bool * ARG_UNUSED (no_add_attrs))
> +{
> +  if (TREE_CODE (*node) == FUNCTION_DECL)
> +DECL_PURE_P (*node) = 1;
> +  else
> +gcc_unreachable ();
> +
> +  return NULL_TREE;
> +}
> +
> +/* Handle a "no vops" attribute; arguments as in
> +   struct attribute_spec.handler.  */
> +
> +

Re: [PATCH 04/14] Add D front-end (GDC) config, Makefile, and manpages.

[Richard Sandiford]

I'll pretend to be a doc reviewer...

Iain Buclaw  writes:
> +@page
> +@vskip 0pt plus 1filll
> +Published by the Free Software Foundation @*
> +51 Franklin Street, Fifth Floor@*
> +Boston, MA 02110-1301, USA@*

Would be good to copy the expanded GNU Press stuff from gcc.texi.

> +The @command{gdc} command is a frontend to @command{gcc} and supports many
> +of the same options.

A bit pedantic, but I think this should be something like:

  The @command{gdc} command is the GNU compiler for the D language and
  supports many of the same options as @command{gcc}.

> +@menu
> +* Input and Output files::  Controlling the kind of output:
> +an executable, object files, assembler files,
> +* Runtime Options:: Options controlling runtime behaviour

"behavior"

> +* Directory Options::   Where to find module files
> +* Code Generation:: Options controlling the output of gdc
> +* Warnings::Options controlling warnings specific to gdc
> +* Linking:: Options influceing the linking step

"influencing"

> +* Developer Options::   Options you won't use

Don't know if this came from an earlier version of the main GCC manual,
but it seems a bit off-message for the FSF.  Something boring like:

  Options useful for developers of gdc

might be better.

> +For any given input file, the file name suffix determines what kind of
> +compilation is done.  The following kinds of input file names are supported:
> +
> +@table @gcctabopt
> +@item @var{file}.d
> +D source files.
> +@item @var{file}.dd
> +Ddoc source files.
> +@item @var{file}.di
> +D interface files.
> +@end table
> +
> +You can specify more than one input file on the @command{gdc} command line,
> +in which case they will all be compiled.  If you specify a

The documentation convention is to avoid the future tense for things
like this.  s/will all be/are all/ doesn't read very naturally so it
might need to be reworded.

> +@code{-o @var{file}} option, all the input files will be compiled together,

Same here.

> +@item -fno-bounds-check
> +@cindex @option{-fbounds-check}
> +@cindex @option{-fno-bounds-check}
> +Turns off array bounds checking for all functions, which can improve
> +performance for code that uses array extensively.  Note that this

"uses arrays extensively"?  Or maybe some markup is missing from "array".

> +can result in unpredictable behavior if the code in question actually
> +does violate array bounds constraints.  It is safe to use this option
> +if you are sure that your code will never throw a @code{RangeError}.

s/will never throw/never throws/

> +@item -fno-builtin
> +@cindex @option{-fbuiltin}
> +@cindex @option{-fno-builtin}
> +Don't recognize built-in functions that do not begin with
> +@samp{__builtin_} as prefix.  By default, the compiler will recognize
> +when a function in the @code{core.stdc} package is a built-in function.

maybe "unless they begin with the prefix @samp{__builtin_}"?
s/will recognize/recognizes/

> +@table @samp
> +@item level
> +@cindex @option{-fdebug=level}
> +Sets the debug level to @var{level}, any @code{debug} code <= @var{level}
> +is compiled into the program.
> +@item ident
> +@cindex @option{-fdebug=ident}
> +Turns on compilation of any @code{debug} code identified by @var{ident}.
> +@end table

Should be @var rather than @samp in the @table.  Also @var{...} in
the @option{...}s.

> +@item -fno-moduleinfo
> +@cindex @option{-fmoduleinfo}
> +@cindex @option{-fno-moduleinfo}
> +Turns off generation of the @code{ModuleInfo} and related functions
> +that would become unreferenced without it, which may allow linking
> +to programs not written in D.  Functions that will not be generated

s/will not be/are not/

> +include module constructor and destructors (@code{static this} and

s/constructor/constructors/?  Or is there only one of each, in which
case maybe "the module constructor and destructor".

> +@item -frelease
> +@cindex @option{-frelease}
> +@cindex @option{-fno-release}
> +Turns on compiling in release mode, which means not emitting runtime
> +checks for contracts and asserts.  Array bounds checking is not done
> +for @code{@@system} and @code{@@trusted} functions, and assertion
> +failures are undefined behaviour.

"behavior"

> +This is equivalent to compiling with the following options:
> +
> +@example
> +gdc -fno-assert -fbounds-check=safe -fno-invariants \
> +-fno-postconditions -fno-preconditions -fno-switch-errors
> +@end example
> +
> +@item -fno-switch-errors
> +@cindex @option{-fswitch-errors}
> +@cindex @option{-fno-switch-errors}
> +This option controls what code should be generated when no case is

s/should be/is/

> +matched in a @code{final switch} statement.  The default run time
> +behavior is that a @code{SwitchError} will be thrown.  Turning off

"is to throw a @code{SwitchError}"

> +@item -fversion=@var{value}
> +@cindex @option{-fversion}
> +Turns on compilation of conditional @code{version} cod

Re: Extend usage of C++11 direct init in __debug::vector

[Jonathan Wakely]

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

On 15/10/18 22:45 +0200, François Dumont wrote:

On 10/15/2018 12:10 PM, Jonathan Wakely wrote:

On 15/10/18 07:23 +0200, François Dumont wrote:
This patch extend usage of C++11 direct initialization in 
__debug::vector and makes some calls to operator - more 
consistent.


Note that I also rewrote following expression in erase method:

-      return begin() + (__first.base() - cbegin().base());
+      return { _Base::begin() + (__first.base() - 
_Base::cbegin()), this };


The latter version was building 2 safe iterators and 
incrementing 1 with the additional debug check inherent to such 
an operation whereas the new version just build 1 safe iterator 
with directly the expected offset.


Makes sense.


2018-10-15  François Dumont 

    * include/debug/vector (vector<>::cbegin()): Use C++11 direct
    initialization.
    (vector<>::cend()): Likewise.
    (vector<>::emplace(const_iterator, _Args&&...)): Likewise and use
    consistent iterator comparison.
    (vector<>::insert(const_iterator, size_type, const _Tp&)): Likewise.
    (vector<>::insert(const_iterator, _InputIterator, _InputIterator)):
    Likewise.
    (vector<>::erase(const_iterator)): Likewise.
    (vector<>::erase(const_iterator, const_iterator)): Likewise.

Tested under Linux x86_64 Debug mode and committed.

François




@@ -542,7 +542,8 @@ namespace __debug
  {
__glibcxx_check_insert(__position);
bool __realloc = this->_M_requires_reallocation(this->size() + 1);
-    difference_type __offset = __position.base() - _Base::begin();
+    difference_type __offset
+  = __position.base() - 
__position._M_get_sequence()->_M_base().begin();


What's the reason for this change?

Doesn't __glibcxx_check_insert(__position) already ensure that
__position is attached to *this, and so _Base::begin() returns the
same thing as __position._M_get_sequence()->_M_base().begin() ?

If they're equivalent, the original code seems more readable.



This is the consistent iterator comparison part. Depending on C++ 
mode __position can be iterator or const_iterator.


As _M_get_sequence() return type depends on iterator type we always 
have iterator - iterator or const_iterator - const_iterator so no 
conversion.



It used to work without a conversion. It only involves a conversion
because you removed this operator a few weeks ago:

-  template
-inline typename _Safe_iterator<_IteratorL, _Sequence,
-   std::random_access_iterator_tag>::difference_type
-operator-(const _Safe_iterator<_IteratorL, _Sequence,
-  std::random_access_iterator_tag>& __lhs,
- const _Safe_iterator<_IteratorR, _Sequence,
-  std::random_access_iterator_tag>& __rhs)

So now there are extra conversions, and you're obfuscating the code to
avoid them.

Either the conversions are harmless and we don't need the operator, or
they're too expensive and we should keep the operator.


Oh, I got confused, the operation is on the underlying base
iterator type, not the safe iterators. So doesn't that use this
overload from  ?

 // _GLIBCXX_RESOLVE_LIB_DEFECTS
 // According to the resolution of DR179 not only the various comparison
 // operators but also operator- must accept mixed iterator/const_iterator
 // parameters.
 template
#if __cplusplus >= 201103L
   // DR 685.
   inline auto
   operator-(const __normal_iterator<_IteratorL, _Container>& __lhs,
  const __normal_iterator<_IteratorR, _Container>& __rhs) noexcept
   -> decltype(__lhs.base() - __rhs.base())
#else
   inline typename __normal_iterator<_IteratorL, _Container>::difference_type
   operator-(const __normal_iterator<_IteratorL, _Container>& __lhs,
  const __normal_iterator<_IteratorR, _Container>& __rhs)
#endif
   { return __lhs.base() - __rhs.base(); }

Why would that involve any conversion?

Re: Extend usage of C++11 direct init in __debug::vector

[Jonathan Wakely]

On 15/10/18 22:45 +0200, François Dumont wrote:

On 10/15/2018 12:10 PM, Jonathan Wakely wrote:

On 15/10/18 07:23 +0200, François Dumont wrote:
This patch extend usage of C++11 direct initialization in 
__debug::vector and makes some calls to operator - more 
consistent.


Note that I also rewrote following expression in erase method:

-      return begin() + (__first.base() - cbegin().base());
+      return { _Base::begin() + (__first.base() - 
_Base::cbegin()), this };


The latter version was building 2 safe iterators and incrementing 
1 with the additional debug check inherent to such an operation 
whereas the new version just build 1 safe iterator with directly 
the expected offset.


Makes sense.


2018-10-15  François Dumont 

    * include/debug/vector (vector<>::cbegin()): Use C++11 direct
    initialization.
    (vector<>::cend()): Likewise.
    (vector<>::emplace(const_iterator, _Args&&...)): Likewise and use
    consistent iterator comparison.
    (vector<>::insert(const_iterator, size_type, const _Tp&)): Likewise.
    (vector<>::insert(const_iterator, _InputIterator, _InputIterator)):
    Likewise.
    (vector<>::erase(const_iterator)): Likewise.
    (vector<>::erase(const_iterator, const_iterator)): Likewise.

Tested under Linux x86_64 Debug mode and committed.

François




@@ -542,7 +542,8 @@ namespace __debug
  {
__glibcxx_check_insert(__position);
bool __realloc = this->_M_requires_reallocation(this->size() + 1);
-    difference_type __offset = __position.base() - _Base::begin();
+    difference_type __offset
+  = __position.base() - 
__position._M_get_sequence()->_M_base().begin();


What's the reason for this change?

Doesn't __glibcxx_check_insert(__position) already ensure that
__position is attached to *this, and so _Base::begin() returns the
same thing as __position._M_get_sequence()->_M_base().begin() ?

If they're equivalent, the original code seems more readable.



This is the consistent iterator comparison part. Depending on C++ mode 
__position can be iterator or const_iterator.


As _M_get_sequence() return type depends on iterator type we always 
have iterator - iterator or const_iterator - const_iterator so no 
conversion.



It used to work without a conversion. It only involves a conversion
because you removed this operator a few weeks ago:

-  template
-inline typename _Safe_iterator<_IteratorL, _Sequence,
-   std::random_access_iterator_tag>::difference_type
-operator-(const _Safe_iterator<_IteratorL, _Sequence,
-  std::random_access_iterator_tag>& __lhs,
- const _Safe_iterator<_IteratorR, _Sequence,
-  std::random_access_iterator_tag>& __rhs)

So now there are extra conversions, and you're obfuscating the code to
avoid them.

Either the conversions are harmless and we don't need the operator, or
they're too expensive and we should keep the operator.

[PATCH] lra: fix spill_hard_reg_in_range clobber check

[Ilya Leoshkevich]

Bootstrap and regtest are running on x86_64-redhat-linux.

Insns in FROM..TO range might not be recognized yet, and their
corresponding entries in lra_insn_recog_data[] might be NULLs.  In the
code from PR87596 the problematic insn is merely

(note 148 154 68 7 NOTE_INSN_DELETED)

however I assume that non-note insns may occur as well.  So make sure
they are recognized before touching their lra_insn_recog_data_t.

gcc/ChangeLog:

2018-10-16  Ilya Leoshkevich  

PR rtl-optimization/87596
* lra-constraints.c (spill_hard_reg_in_range): Use
lra_get_insn_recog_data () instead of lra_insn_recog_data[]
for instructions in FROM..TO range.

gcc/testsuite/ChangeLog:

2018-10-16  Ilya Leoshkevich  

PR rtl-optimization/87596
* gcc.target/i386/pr87596.c: New test.
---
 gcc/lra-constraints.c   |  3 ++-
 gcc/testsuite/gcc.target/i386/pr87596.c | 16 
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr87596.c

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 774d1ff3aaa..0d9cac07fb2 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -5696,10 +5696,11 @@ spill_hard_reg_in_range (int regno, enum reg_class 
rclass, rtx_insn *from, rtx_i
continue;
   for (insn = from; insn != NEXT_INSN (to); insn = NEXT_INSN (insn))
{
- lra_insn_recog_data_t id = lra_insn_recog_data[uid = INSN_UID (insn)];
+ lra_insn_recog_data_t id = lra_get_insn_recog_data (insn);
  struct lra_static_insn_data *static_id = id->insn_static_data;
  struct lra_insn_reg *reg;
 
+ uid = INSN_UID (insn);
  if (bitmap_bit_p (&lra_reg_info[hard_regno].insn_bitmap, uid))
break;
  for (reg = static_id->hard_regs; reg != NULL; reg = reg->next)
diff --git a/gcc/testsuite/gcc.target/i386/pr87596.c 
b/gcc/testsuite/gcc.target/i386/pr87596.c
new file mode 100644
index 000..764708b694a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr87596.c
@@ -0,0 +1,16 @@
+/* LRA corner case which triggered a segfault.  */
+/* Reduced testcase by Arseny Solokha.  */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O1 -fschedule-insns -ftrapv -funroll-all-loops 
-fno-tree-dominator-opts -fno-tree-loop-im" } */
+
+void
+wh (__int128 *ku)
+{
+  unsigned int *dp;
+
+  while (*ku < 1)
+{
+  *dp <<= 32;  /* { dg-warning "left shift count >= width of type" } */
+  ++*ku;
+}
+}
-- 
2.19.0

Re: [Patch, Fortran] PR87556 – for FORM TEAM also use argse.pre/post

[Paul Richard Thomas]

Hi Tobias,

Following our exchange off-list, I rather agree with you that a
testcase is pointless. Besides which, I do not see this regressing :-)

OK for trunk and, if you are feeling strong, 8-branch.

Thanks and welcome back.

Paul
On Mon, 15 Oct 2018 at 20:46, Tobias Burnus  wrote:
>
> as the subject states, FORM TEAM was only using the resulting tree
> expression, ignoring code which was generated before (or afterward).
>
> I am not sure how to best convert it to a test-suite test case. For
>
> form team (team(this_image()), my_team2)
>
> the old dump was:
>
>  integer(kind=4) D.3829;
> …
>  _gfortran_caf_form_team (team (&D.3829), &my_team2, 0);
>
> the new one is:
>
>{
>  integer(kind=4) D.3822;
>
>  D.3822 = _gfortran_caf_this_image (0);
>  _gfortran_caf_form_team (team (&D.3822), &my_team2, 0);
>}
>
> [Does it make sense to check for 5 "this_image (0)" calls? or for 4
> "D.\[0-9\]+ = _gfortran_caf_this_image (0);" calls?]
>
>
> Build and on-going regtesting on x86-64-gnu-linux.
>
> OK for the trunk?
>
> Tobias
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[PATCH][RFC] Add bitmap_clear_first_set_bit for worklist handling

[Richard Biener]

This adds bitmap_clear_first_set_bit to replace the common

  unsigned idx = bitmap_first_set_bit (b);
  bitmap_clear_bit (b, idx);

pattern which disturbs the bitmap lookup cached element.  We can
always find and clear the first set bit in O(1) so this implements
this as a primitive.

Alternatively one could make sure to never be equal to first
(but for the only element -- 'current' is a bit weird if you look at 
bitmap_find_bit).  That would make clearing the first bit never
update ->current.

For the weird testcase in PR63155 this makes a noticable difference
(~5% compile-time).

Thoughts?

Thanks,
Richard.

2018-10-16  Richard Biener  

* bitmap.h (bitmap_clear_first_set_bit): Declare.
* bitmap.c (bitmap_first_set_bit): Make a wrapper around ...
(bitmap_first_set_bit_1): ... this worker that now also can
clear the bit.
(bitmap_clear_first_set_bit): New.
* tree-ssa-propagate.c (ssa_propagation_engine::simulate_stmt):
Clear stmt from the worklist in callers.
(ssa_propagation_engine::simulate_block): Here.
(ssa_propagation_engine::ssa_propagate): Use
bitmap_clear_first_set_bit to pop off worklist items.
* tree-ssa-sccvn.c (do_rpo_vn): Likewise.
* tree-ssa-dce.c (simple_dce_from_worklist): Likewise.
* tree-cfgcleanup.c (cleanup_tree_cfg_noloop): Likewise.

Index: gcc/bitmap.c
===
--- gcc/bitmap.c(revision 265185)
+++ gcc/bitmap.c(working copy)
@@ -771,12 +771,12 @@ bitmap_single_bit_set_p (const_bitmap a)
 
 
 /* Return the bit number of the first set bit in the bitmap.  The
-   bitmap must be non-empty.  */
+   bitmap must be non-empty.  Clear the bit if clear_p is true.  */
 
-unsigned
-bitmap_first_set_bit (const_bitmap a)
+static unsigned
+bitmap_first_set_bit_1 (bitmap a, bool clear_p)
 {
-  const bitmap_element *elt = a->first;
+  bitmap_element *elt = a->first;
   unsigned bit_no;
   BITMAP_WORD word;
   unsigned ix;
@@ -818,9 +818,29 @@ bitmap_first_set_bit (const_bitmap a)
 
  gcc_checking_assert (word & 1);
 #endif
+ if (clear_p)
+   {
+ BITMAP_WORD bit_val = ((BITMAP_WORD) 1) << (bit_no % BITMAP_WORD_BITS);
+ elt->bits[ix] &= ~bit_val;
+ if (!elt->bits[ix]
+&& bitmap_element_zerop (elt))
+   bitmap_element_free (a, elt);
+   }
  return bit_no;
 }
 
+unsigned
+bitmap_clear_first_set_bit (bitmap a)
+{
+  return bitmap_first_set_bit_1 (a, true);
+}
+
+unsigned
+bitmap_first_set_bit (const_bitmap a)
+{
+  return bitmap_first_set_bit_1 (const_cast(a), false);
+}
+
 /* Return the bit number of the first set bit in the bitmap.  The
bitmap must be non-empty.  */
 
Index: gcc/bitmap.h
===
--- gcc/bitmap.h(revision 265185)
+++ gcc/bitmap.h(working copy)
@@ -52,9 +52,10 @@ along with GCC; see the file COPYING3.
 
The following operations can always be performed in O(1) time:
 
+ * empty_p : bitmap_empty_p
  * clear   : bitmap_clear
- * choose_one  : (not implemented, but could be
-  implemented in constant time)
+ * choose_one  : bitmap_first_set_bit
+ * remove_one  : bitmap_clear_first_set_bit
 
The following operations can be performed in O(E) time worst-case (with
E the number of elements in the linked list), but in O(1) time with a
@@ -359,6 +360,7 @@ extern void debug (const bitmap_head &re
 extern void debug (const bitmap_head *ptr);
 
 extern unsigned bitmap_first_set_bit (const_bitmap);
+extern unsigned bitmap_clear_first_set_bit (bitmap);
 extern unsigned bitmap_last_set_bit (const_bitmap);
 
 /* Compute bitmap hash (for purposes of hashing etc.)  */
Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 265185)
+++ gcc/tree-ssa-propagate.c(working copy)
@@ -213,9 +213,6 @@ ssa_propagation_engine::simulate_stmt (g
   edge taken_edge = NULL;
   tree output_name = NULL_TREE;
 
-  /* Pull the stmt off the SSA edge worklist.  */
-  bitmap_clear_bit (ssa_edge_worklist, gimple_uid (stmt));
-
   /* Don't bother visiting statements that are already
  considered varying by the propagator.  */
   if (!prop_simulate_again_p (stmt))
@@ -322,7 +319,10 @@ ssa_propagation_engine::simulate_block (
   /* Always simulate PHI nodes, even if we have simulated this block
  before.  */
   for (gsi = gsi_start_phis (block); !gsi_end_p (gsi); gsi_next (&gsi))
-simulate_stmt (gsi_stmt (gsi));
+{
+  bitmap_clear_bit (ssa_edge_worklist, gimple_uid (gsi_stmt (gsi)));
+  simulate_stmt (gsi_stmt (gsi));
+}
 
   /* If this is the first time we've simulated this block, then we
  must simulate each of its statements.  */
@@ -334,7 +334,10 @@ ssa_propagation_engine::simulate_block (
   ed

[wwwdocs] Announce Solaris 10 obsoletion

[Rainer Orth]

The following patch documents the Solaris 10 obsoletion in the GCC 9
changes.html.  I've based this on the GCC 4.9 text which allowed for
obsoletion of several targets.  Tested by inspection in Firefox.

Ok to install?

As a followup, we should update criteria.html to name
sparc-sun-solaris2.11 as primary platform.  Although mechanical, I
suspect this requires SC approval?

Rainer

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


2018-10-16  Rainer Orth  

* htdocs/gcc-9/changes.html (GCC 9 Release Series, Caveats):
Announce Solaris 10 obsoletion.

? update.log
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.22
diff -u -p -r1.22 changes.html
--- htdocs/gcc-9/changes.html	30 Sep 2018 14:38:54 -	1.22
+++ htdocs/gcc-9/changes.html	16 Oct 2018 09:00:05 -
@@ -28,7 +28,21 @@ a work-in-progress.
 
 Caveats
 
-  ...
+  Support for a number of older systems and recently
+  unmaintained or untested target ports of GCC has been declared
+  obsolete in GCC 9.  Unless there is activity to revive them, the
+  next release of GCC will have their sources permanently
+  removed.
+
+The following ports for individual systems on
+  particular architectures have been obsoleted:
+
+
+  Solaris 10 (*-*-solaris2.10).  Details can be found
+  in the https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html";;>
+  announcement.
+
+  
 
 
 

Re: [Patch, Fortran] PR67125 - ALLOCATE with source-expr lbounds/ubound off by one

[Paul Richard Thomas]

Hi Tobias,

Your patch is OK for trunk and, I would suggest 8-branch.

As a matter of curiosity, why did you not use the condition:
if (!(expr3_desc && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (expr3_desc)))  ?

Your solution is fine, though.

Cheers

Paul

On Fri, 12 Oct 2018 at 12:29, Tobias Burnus
 wrote:
>
> Hello all,
>
> "When an ALLOCATE statement is executed for an array with no
>  allocate-shape-spec-list, the bounds of source-expr determine
>  the bounds of the array." (F2018, 9.7.1.2 (6))
>
> That seems to work fine for arrays which have an array descriptor.
> However, as the current code shows, it fails for array constructors
> where the lbound is zero instead of the expected one.
>
> It turns out (PR67125) that functions results which don't use array
> descriptors have the same problem as do stack/static allocated
> array variables (PR87580).
>
> I am not sure that my check for array descriptors is the best but
> it seems to work and fixes the problem.
>
> OK for the trunk?
> Build and regtested on x86-64-linux.
>
> Tobias



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[PATCH][AArch64] Use @ pattern to eliminate switch statement in one more place

[Kyrylo Tkachov]

Hi all,

We can use the new '@' modifier to MD patterns to generate mode-parametrised 
gen_ functions
for the despeculate_copy patterns and therefore remove the switch on modes in 
aarch64.c
that is used to pick the right generator. This simplifies the code.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2018-10-16  Kyrylo Tkachov  

* config/aarch64/aarch64.md (despeculate_copy):
Rename to...
(@despeculate_copy): ... This.
* config/aarch64/aarch64.c (aarch64_speculation_safe_value): Remove
switch statement.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 34d08a075221fd4c098e9b5e8fabd8fe3948d285..03041c5af99e52de8f5b4d8342e93ef2b90985bc 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -17968,26 +17968,7 @@ aarch64_speculation_safe_value (machine_mode mode,
   if (!aarch64_reg_or_zero (failval, mode))
 failval = copy_to_mode_reg (mode, failval);
 
-  switch (mode)
-{
-case E_QImode:
-  emit_insn (gen_despeculate_copyqi (result, val, failval));
-  break;
-case E_HImode:
-  emit_insn (gen_despeculate_copyhi (result, val, failval));
-  break;
-case E_SImode:
-  emit_insn (gen_despeculate_copysi (result, val, failval));
-  break;
-case E_DImode:
-  emit_insn (gen_despeculate_copydi (result, val, failval));
-  break;
-case E_TImode:
-  emit_insn (gen_despeculate_copyti (result, val, failval));
-  break;
-default:
-  gcc_unreachable ();
-}
+  emit_insn (gen_despeculate_copy (mode, result, val, failval));
   return result;
 }
 
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 4170d3fbb00c733a1411e726a67af17052800307..32d6f138232c617213f0d3488db49cb3546eb0a9 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -6743,7 +6743,7 @@ (define_insn "speculation_barrier"
 ;; Support for __builtin_speculation_safe_value when we have speculation
 ;; tracking enabled.  Use the speculation tracker to decide whether to
 ;; copy operand 1 to the target, or to copy the fail value (operand 2).
-(define_expand "despeculate_copy"
+(define_expand "@despeculate_copy"
   [(set (match_operand:ALLI_TI 0 "register_operand" "=r")
 	(unspec_volatile:ALLI_TI
 	 [(match_operand:ALLI_TI 1 "register_operand" "r")

[build, doc] Obsolete Solaris 10 support

[Rainer Orth]

This patch implements the Solaris 10 obsoletion announced yesterday:

https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html

Bootstrapped on i386-pc-solaris2.10 without and with --enable-obsolete
and inspected gccinstall.info.  The contrib-list.mk part is untested,
but completely mechanical.

Installed on mainline.

Rainer

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


2018-10-15  Rainer Orth  

contrib:
* config-list.mk (LIST): Switch to i686-solaris2.11,
sparc64-sun-solaris2.11.

gcc:
* config.gcc: Obsolete *-*-solaris2.10*.
* doc/install.texi (Specific, *-*-solaris2*): Document it.

# HG changeset patch
# Parent  d932b52fba66cf1b8732b7dd27865820b1654f9b
Obsolete Solaris 10 support

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -51,7 +51,7 @@ LIST = aarch64-elf aarch64-linux-gnu aar
   i686-netbsdelf9 \
   i686-openbsd i686-elf i686-kopensolaris-gnu i686-symbolics-gnu \
   i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \
-  i686-rtems i686-solaris2.10 i686-wrs-vxworks \
+  i686-rtems i686-solaris2.11 i686-wrs-vxworks \
   i686-wrs-vxworksae \
   i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
   ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \
@@ -87,7 +87,7 @@ LIST = aarch64-elf aarch64-linux-gnu aar
   sh-rtems sh-wrs-vxworks sparc-elf \
   sparc-leon-elf sparc-rtems sparc-linux-gnu \
   sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \
-  sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \
+  sparc64-sun-solaris2.11OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \
   sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \
   sparc64-netbsd sparc64-openbsd spu-elf \
   tilegx-linux-gnu tilegxbe-linux-gnu tilepro-linux-gnu \
diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -236,7 +236,8 @@ md_file=
 
 # Obsolete configurations.
 case ${target} in
-  powerpc*-*-*spe*			\
+  *-*-solaris2.10*			\
+  | powerpc*-*-*spe*			\
   | tile*-*-*\
  )
 if test "x$enable_obsolete" != xyes; then
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4408,9 +4408,11 @@ supported as cross-compilation target on
 @c alone is too unspecific and must be avoided.
 @anchor{x-x-solaris2}
 @heading *-*-solaris2*
-Support for Solaris 9 has been removed in GCC 5.  Support for Solaris
-8 has been removed in GCC 4.8.  Support for Solaris 7 has been removed
-in GCC 4.6.
+Support for Solaris 10 has been obsoleted in GCC 9, but can still be
+enabled by configuring with @option{--enable-obsolete}.  Support will be
+removed in GCC 10.  Support for Solaris 9 has been removed in GCC 5.
+Support for Solaris 8 has been removed in GCC 4.8.  Support for Solaris
+7 has been removed in GCC 4.6.
 
 Sun does not ship a C compiler with Solaris 2 before Solaris 10, though
 you can download the Sun Studio compilers for free.  In Solaris 10 and

Re: [PATCH] __debug::list use C++11 direct initialization

[Jonathan Wakely]

On 16/10/18 07:06 +0200, François Dumont wrote:

On 10/15/2018 12:07 PM, Jonathan Wakely wrote:

On 09/10/18 07:11 +0200, François Dumont wrote:
Here is the communication for my yesterday's patch which I thought 
svn had failed to commit (I had to interrupt it).


Similarly to what I've done for associative containers here is a 
cleanup of the std::__debug::list implementation leveraging more 
on C++11 direct initialization.


I also made sure we use consistent comparison between 
iterator/const_iterator in erase and emplace methods.


2018-10-08  François Dumont 

    * include/debug/list (list<>::cbegin()): Use C++11 direct
    initialization.
    (list<>::cend()): Likewise.
    (list<>::emplace<>(const_iterator, _Args&&...)): Likewise.
    (list<>::insert(const_iterator, initializer_list<>)): Likewise.
    (list<>::insert(const_iterator, size_type, const _Tp&)): Likewise.
    (list<>::erase(const_iterator, const_iterator)): Ensure consistent
    iterator comparisons.
    (list<>::splice(const_iterator, list&&, const_iterator,
    const_iterator)): Likewise.

Tested under Linux x86_64 Debug mode and committed.

François



diff --git a/libstdc++-v3/include/debug/list 
b/libstdc++-v3/include/debug/list

index 8add1d596e0..879e1177497 100644
--- a/libstdc++-v3/include/debug/list
+++ b/libstdc++-v3/include/debug/list
@@ -244,11 +244,11 @@ namespace __debug
#if __cplusplus >= 201103L
  const_iterator
  cbegin() const noexcept
-  { return const_iterator(_Base::begin(), this); }
+  { return { _Base::begin(), this }; }

  const_iterator
  cend() const noexcept
-  { return const_iterator(_Base::end(), this); }
+  { return { _Base::end(), this }; }


For functions like emplace (which are C++11-only) and for forward_list
(also C++11-only) using this syntax makes it clearer.

But for these functions it just makes cbegin() and cend() look
different to the C++98 begin() and end() functions, for no obvious
benefit.

Simply using { return end(); } would have been another option.


Personnaly I hesitated in writting:

{ return { _Base::cbegin(), this }; }

cause I prefer when you see clearly that Debug implem forward calls to 
the Normal implem.


I thought that using C++11 direct init was more likely to have gcc 
elide the copy constructor so I used it everywhere possible.


It should make no difference to elision at all.

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Richard Biener]

On Mon, Oct 15, 2018 at 8:40 PM Uecker, Martin
 wrote:
>
>
> Hi Richard,
>
> as Joseph pointed out, there are some related discussions
> on the WG14 reflector. How a about moving the discussion
> there?
>
> I find your approach very interesting and that it already
> comes with an implementation is of course very useful
>
> But I don't really understand the reasons why this is not based
> on (2). These types are not "sizeless" at all, their size
> just isn't known at compile time. So to me this seems to me
> a misnomer.
>
> In fact, to me these types *do* in fact seem very similar
> to VLAs as VLAs are also complete types which also do no
> have a known size at compile time.
>
> That arrays decay to pointers doesn't mean that we
> couldn't have similar vectors types which don't decay.
> This is hardly a fundamental problem.
>
> I also don't understand the problem about the array
> size. If I understand this correctly, the size is somehow
> known at run-time and implicitly passed along with the
> values. So these new types do not need to have a
> size expression (as in your proposal).
>
> Assignment, the possibility to return the type from
> functions, and something like __sizeless_structs would
> make sense for VLAs too.
>
> So creating a new category "variable-length types" for
> both VLAs and variably-length vector types seems do make
> much more sense to me. As I see it, this would be mainly
> a change in terminology and not so much of the underlying
> approach.

I agree - those types very much feel like VLAs.

I think there's also the existing vector extension of GCC to
factor in which introduces (non-VLA) vector types to the
language and allows arithmetic on them as well as
indexing and passing and returing them by values.
Variable-size vectors should play well in that context.

Richard.

>
> Best,
> Martin
>
> Am Montag, den 15.10.2018, 15:30 +0100 schrieb Richard Sandiford:
> > The C standard says:
> >
> > At various points within a translation unit an object type may be
> > "incomplete" (lacking sufficient information to determine the size of
> > objects of that type) or "complete" (having sufficient information).
> >
> > For AArch64 SVE, we'd like to split this into two concepts:
> >
> >   * has the type been fully defined?
> >   * would fully-defining the type determine its size?
> >
> > This is because we'd like to be able to represent SVE vectors as C and C++
> > types.  Since SVE is a "vector-length agnostic" architecture, the size
> > of the vectors is determined by the runtime environment rather than the
> > programmer or compiler.  In that sense, defining an SVE vector type does
> > not determine its size.  It's nevertheless possible to use SVE vector types
> > in meaningful ways, such as having automatic vector variables and passing
> > vectors between functions.
> >
> > The main questions in the RFC are:
> >
> >   1) is splitting the definition like this OK in principle?
> >   2) are the specific rules described below OK?
> >   3) coding-wise, how should the split be represented in GCC?
> >
> > Terminology
> > ---
> >
> > Going back to the second bullet above:
> >
> >   * would fully-defining the type determine its size?
> >
> > the rest of the RFC calls a type "sized" if fully defining it would
> > determine its size.  The type is "sizeless" otherwise.
> >
> > Contents
> > 
> >
> > The RFC is organised as follows.  I've erred on the side of including
> > detail rather than leaving it out, but each section is meant to be
> > self-contained and skippable:
> >
> >   - An earlier RFC
> >   - Quick overview of SVE
> >   - Why we need SVE types in C and C++
> >   - How we ended up with this definition
> >   - The SVE types in more detail
> >   - Outline of the type system changes
> >   - Sizeless structures (and testing on non-SVE targets)
> >   - Other variable-length vector architectures
> >   - Edits to the C standard
> > - Base changes
> > - Updates for consistency
> > - Sizeless structures
> >   - Edits to the C++ standard
> >   - GCC implementation questions
> >
> > I'll follow up with patches that implement the split.
> >
> >
> >
> > An earlier RFC
> > ==
> >
> > For the record (in case this sounds familiar) I sent an RFC about the
> > sizeless type extension a while ago:
> >
> > https://gcc.gnu.org/ml/gcc/2017-08/msg00012.html
> >
> > The rules haven't changed since then, but this version includes more
> > information and includes support for sizeless structures.
> >
> >
> > Quick overview of SVE
> > =
> >
> > SVE is a vector extension to AArch64.  A detailed description is
> > available here:
> >
> > https://static.docs.arm.com/ddi0584/a/DDI0584A_a_SVE_supp_armv8A.pdf
> >
> > but the only feature that really matters for this RFC is that SVE has no
> > fixed or preferred vector length.  Implementations can instead choose
> > from a range of possible vector lengths, with 128 bits being the minimum
> > and 204