date:20200228

New Russian PO file for 'cpplib' (version 10.1-b20200209)

2020-02-28 Thread Translation Project Robot

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/ru.po

(This file, 'cpplib-10.1-b20200209.ru.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/cpplib/

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/cpplib.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.

Contents of PO file 'cpplib-10.1-b20200209.ru.po'

2020-02-28 Thread Translation Project Robot



cpplib-10.1-b20200209.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

[pushed] c++: implement C++20 Disambiguating Nested-Requirements (P2092R0)

2020-02-28 Thread Jason Merrill

The rule change in the title matches GCC's current behavior, so no change
was needed.  But the paper also makes 'typename' optional in a
requirement-parameter-list, so this implements that.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog
2020-02-28  Jason Merrill  

Implement P2092R0, Disambiguating Nested-Requirements
* parser.c (cp_parser_requirement_parameter_list): Pass
CP_PARSER_FLAGS_TYPENAME_OPTIONAL.
---
 gcc/cp/parser.c | 4 ++--
 gcc/testsuite/g++.dg/cpp2a/concepts-p2092.C | 8 
 2 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-p2092.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ca85d899427..24f71671469 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -27716,8 +27716,8 @@ cp_parser_requirement_parameter_list (cp_parser *parser)
   if (!parens.require_open (parser))
 return error_mark_node;
 
-  tree parms
-= cp_parser_parameter_declaration_clause (parser, CP_PARSER_FLAGS_NONE);
+  tree parms = (cp_parser_parameter_declaration_clause
+   (parser, CP_PARSER_FLAGS_TYPENAME_OPTIONAL));
 
   if (!parens.require_close (parser))
 return error_mark_node;
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-p2092.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-p2092.C
new file mode 100644
index 000..f293581a75a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-p2092.C
@@ -0,0 +1,8 @@
+// P2092R0
+// { dg-do compile { target concepts } }
+
+template 
+concept Bar = requires (T::type t) { ++t; };
+
+template 
+concept Foo = requires { requires { T(); }; }; // { dg-error "" }

base-commit: 586b016cd48f5a5f6f2ba9f179105fabaa3e85dd
-- 
2.18.1

Re: [PATCH 01/10] i386: Properly encode vector registers in vector move

2020-02-28 Thread H.J. Lu

On Fri, Feb 28, 2020 at 4:16 PM Jeff Law  wrote:
>
> On Thu, 2020-02-27 at 06:50 -0800, H.J. Lu wrote:
> >
> > How about this?  If it looks OK, I will post the whole patch set.
> It's better.  I'm guessing the two cases that were previously handled with
> vextract/vbroadcast aren't supposed to happen?  They're caught here IIUC:
>
> > +  /* NB: To move xmm16-xmm31/ymm16-ymm31 registers without AVX512VL,
> > + we can only use zmm register move without memory operand.  */
> > +   if (evex_reg_p
> > +   && !TARGET_AVX512VL
> > +   && GET_MODE_SIZE (mode) < 64)
> > + {
> > +   if (memory_operand (operands[0], mode)
> > +|| memory_operand (operands[1], mode))
> > + gcc_unreachable ();
> >
>
> If they truly can't happen, that's fine.  My worry is I don't see changes to
> the operand predicates or constraints which would avoid this case.   Is it
> prevented by the mode iterator on the operands?  Again, just want to make sure
> I understand why the vextract/vbroadcast stuff isn't in the new code.

There are no GCC testcases to show that they are actually ever used.   That is
why I removed them and added gcc_unreachable ().

> I'm doing a little assuming that the  bits in the old code are
> mapped correctly to the 32/64 suffixes on the opcodes in the new version.
>
> I'm also assuming that mapping of "size" in the argument to ix86_get_ssemov to
> the operand modifiers g, t, and x are right.  I'm guessing the operand
> modifiers weren't needed in the original because we had the actual operand and
> could look at it to get the right modifier.  In the evex, but not avx512vl 
> case
> those are forced to a g modifier which seems to match the original.
>
> Are we going to need further refinements to 
> ix86_output_ssemov/ix86_get_ssemov?
> If so, then I'd suggest the next patch be those patterns which don't require
> further refinements to ix86_output_ssemov.

4 patches don't require changes in ix86_output_ssemov/ix86_get_ssemov:

https://gitlab.com/x86-gcc/gcc/-/commit/426f2464abb80b97b8533f9efa15bbe72e6aa888
https://gitlab.com/x86-gcc/gcc/-/commit/ec5b40d77f7a4424935275f1a7ccedbce83b6f54
https://gitlab.com/x86-gcc/gcc/-/commit/92fdd98234984f86b66fb5403dd828661cd7999f
https://gitlab.com/x86-gcc/gcc/-/commit/f8fa5e571caf6740b36d042d631b4ace11683cd7

I can combine them into a single patch.

Other 5 patches contain a small change to  ix86_output_ssemov:

https://gitlab.com/x86-gcc/gcc/-/commit/b1746392e1d350d689a80fb71b2c72f909c20f30
https://gitlab.com/x86-gcc/gcc/-/commit/14c3cbdbdcc36fa1edea4572b89a039726a4e2bc
https://gitlab.com/x86-gcc/gcc/-/commit/69c8c928b26242116cc261a9d2f6b1265218f1d3
https://gitlab.com/x86-gcc/gcc/-/commit/04335f582f0b281d5f357185d154087997fd7cfd
https://gitlab.com/x86-gcc/gcc/-/commit/64f6a5d6d3405331d9c02aaae0faccf449d6647a

Should I made the change and submit them for review?

> If no further refinements to ix86_output_ssemov/ix86_get_ssemov are required,
> then I think you can just send the rest of the pattern changes in a single
> unit.
>
> jeff
>

Thanks.

-- 
H.J.

Re: [PATCH 01/10] i386: Properly encode vector registers in vector move

2020-02-28 Thread Jeff Law

On Thu, 2020-02-27 at 06:50 -0800, H.J. Lu wrote:
> 
> How about this?  If it looks OK, I will post the whole patch set.
It's better.  I'm guessing the two cases that were previously handled with
vextract/vbroadcast aren't supposed to happen?  They're caught here IIUC:

> +  /* NB: To move xmm16-xmm31/ymm16-ymm31 registers without AVX512VL,
> + we can only use zmm register move without memory operand.  */
> +   if (evex_reg_p
> +   && !TARGET_AVX512VL
> +   && GET_MODE_SIZE (mode) < 64)
> + {
> +   if (memory_operand (operands[0], mode)
> +|| memory_operand (operands[1], mode))
> + gcc_unreachable ();
> 

If they truly can't happen, that's fine.  My worry is I don't see changes to
the operand predicates or constraints which would avoid this case.   Is it
prevented by the mode iterator on the operands?  Again, just want to make sure
I understand why the vextract/vbroadcast stuff isn't in the new code.

I'm doing a little assuming that the  bits in the old code are
mapped correctly to the 32/64 suffixes on the opcodes in the new version.

I'm also assuming that mapping of "size" in the argument to ix86_get_ssemov to
the operand modifiers g, t, and x are right.  I'm guessing the operand
modifiers weren't needed in the original because we had the actual operand and
could look at it to get the right modifier.  In the evex, but not avx512vl case
those are forced to a g modifier which seems to match the original.

Are we going to need further refinements to ix86_output_ssemov/ix86_get_ssemov?
If so, then I'd suggest the next patch be those patterns which don't require
further refinements to ix86_output_ssemov.

If no further refinements to ix86_output_ssemov/ix86_get_ssemov are required,
then I think you can just send the rest of the pattern changes in a single
unit.

jeff

Re: [committed] libstdc++: Add __maybe_const_t and __maybe_empty_t aliases

2020-02-28 Thread Jonathan Wakely

On 27/02/20 00:02 +, Jonathan Wakely wrote:

On Wed, 26 Feb 2020 at 18:31, Daniel Krügler wrote:

Am Mi., 26. Feb. 2020 um 16:20 Uhr schrieb Jonathan Wakely :
>
> This introduces a couple of convenience alias templates to be used for
> some repeated patterns using std::conditional_t.

I find it a bit confusing/inconsistent to define __maybe_const_t such
that the bool argument says "is const", while for __maybe_empty_t the
corresponding bool argument says "is not empty". Suggestion: Implement
__maybe_empty_t such that its bool argument says "is empty" or change
the alias to __maybe_nonempty_t.

Good point, I'll make that change. Thanks.

Here's what I'm proposing to change it to. The name "maybe present"
matches the relevant wording in the working draft, fixes the reversed
logic w.r.t the bool argument, and doesn't refer to the fact that the
type may be empty (which is not really the salient point about it).

While preparing this change it occurred to me that all types using
this alias might end up with a member of the same __detail::_Empty
type. If two such types would otherwise be at the same address, the
_Empty data member would force them to have different addresses. I
think in practice that's not an issue, because the only class template
that uses __maybe_present_t without any other data members is
_RangeAdaptor, and I don't think we need to care about users doing
something like:

struct Wtf : decltype(std::views::filter), decltype(std::views::take)
{ };

With the current code the two base classes can't have the same
address, because they each have a single data member of type
__detail::_Empty, which must have unique addresses.

It would be possible to implement those range adaptors so that the two
base subobjects could be at the same address, and so sizeof(Wtf) would
be smaller. I don't think I care about that.

commit 43cab9a6e5ea3b2b31ce6b82074d09bfd764640c
Author: Jonathan Wakely 
Date:   Fri Feb 28 22:56:07 2020 +

libstdc++: Rename __detail::__maybe_empty_t alias template

The key property of this alias is not that it may be an empty type, but
that the type argument may not be used. The fact it's replaced by an
empty type is just an implementation detail.  The name was also
backwards with respect to the bool argument.

This patch changes the name to better reflect its purpose.

* include/std/ranges (__detail::__maybe_empty_t): Rename to
__maybe_present_t.
(__adaptor::_RangeAdaptor, join_view, split_view): Use new name.

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 19d3da950e7..c71cf918cfc 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1030,9 +1030,14 @@ namespace __detail
 {
   struct _Empty { };

-  template
-using __maybe_empty_t = conditional_t<_NonEmpty, _Tp, _Empty>;
+  // Alias for a type that is conditionally present
+  // (and is an empty type otherwise).
+  // Data members using this alias should use [[no_unique_address]] so that
+  // they take no space when not needed.
+  template
+using __maybe_present_t = conditional_t<_Present, _Tp, _Empty>;

+  // Alias for a type that is conditionally const.
   template
 using __maybe_const_t = conditional_t<_Const, const _Tp, _Tp>;

@@ -1065,8 +1070,8 @@ namespace views
   {
   protected:
 	[[no_unique_address]]
-	  __detail::__maybe_empty_t,
-_Callable> _M_callable;
+	  __detail::__maybe_present_t,
+  _Callable> _M_callable;

   public:
 	constexpr
@@ -2211,8 +2216,9 @@ namespace views

   static constexpr bool _S_needs_cached_begin = !random_access_range<_Vp>;
   [[no_unique_address]]
-	__detail::__maybe_empty_t<_S_needs_cached_begin,
-  __detail::_CachedPosition<_Vp>> _M_cached_begin;
+	__detail::__maybe_present_t<_S_needs_cached_begin,
+__detail::_CachedPosition<_Vp>>
+  _M_cached_begin;

 public:
   drop_view() = default;
@@ -2592,8 +2598,8 @@ namespace views

   // XXX: _M_inner is "present only when !is_reference_v<_InnerRange>"
   [[no_unique_address]]
-	__detail::__maybe_empty_t,
-  views::all_t<_InnerRange>> _M_inner;
+	__detail::__maybe_present_t,
+views::all_t<_InnerRange>> _M_inner;

 public:
   join_view() = default;
@@ -2728,8 +2734,8 @@ namespace views

 	  // XXX: _M_current is present only if "V models forward_range"
 	  [[no_unique_address]]
-	__detail::__maybe_empty_t,
-  iterator_t<_Base>> _M_current;
+	__detail::__maybe_present_t,
+	iterator_t<_Base>> _M_current;

 	public:
 	  using iterator_concept = conditional_t,
@@ -2969,7 +2975,7 @@ namespace views

   // XXX: _M_current is "present only if !forward_range"
   [[no_unique_address]]
-	__detail::__maybe_empty_t, iterator_t<_Vp>>
+	__detail::__maybe_present_t, iterator_t<_Vp>>
 	  _M_current;

@@ -3180,8 +3186,9 @@ namespace views
   static constexpr bool _S_needs

Re: [PATCH] tighten up validation of built-in redeclarations (PR 93926)

2020-02-28 Thread Jeff Law

On Thu, 2020-02-27 at 15:40 -0700, Martin Sebor wrote:
> GCC considers valid explicit declarations of built-ins whose return
> types match in their modes, even if the types themselves are
> incompatible (say integer and pointer of the same size).  This is
> more permissive than for argument types where a pointer/integer
> mismatch disqualifies the redeclaration.
> 
> With -Wextra enabled although -Wbuiltin-declaration-mismatch
> diagnoses these "benign" mismatches in return types the C front-end
> still considers the mismatched declaration one of the built-in.  That
> can lead to problems down the line when the middle attempts to do its
> own sanity checking based on some simple and reasonable notion of type
> compatibility (like a malloc kind of function returning a pointer).
> 
> The attached patch tightens up the requirements a declaration has to
> meet in order to match a built-in to apply the same matching to their
> return types as to their arguments.
> 
> Tested on x86_64-linux.
> 
> Martin
> PR middle-end/93926 - ICE on a built-in redeclaration returning an integer
> instead of a pointer
> 
> gcc/c/ChangeLog:
> 
>   PR middle-end/93926
>   * c-decl.c (types_close_enough_to_match): New function.
>   (match_builtin_function_types):
>   (diagnose_mismatched_decls): Add missing inform call to a warning.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR middle-end/93926
>   * gcc.dg/Wbuiltin-declaration-mismatch-13.c: New test.
OK
jeff

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Joseph Myers

On Fri, 28 Feb 2020, Tobias Burnus wrote:

> Regarding MIN and MAX: I think the IEEE 754 decided at some point
> decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> recall correctly). I think one has to check what exactly the test case
> does and what is guaranteed where. I also do not know whether a more
> recent IEEE 754 (754:2019) has changed something again.

It has.  The maxNum/minNum operations from IEEE 754-2008 were removed and 
replaced by recommended operations maximum/minimum (treat NaNs the same 
way as other operations do, i.e. produce a quiet NaN result if either 
operand is a NaN) and maximumNumber/minimumNumber (return the number if 
the other operand is a NaN, even a signaling NaN, with "invalid" raised in 
the signaling NaN case).  Those new operations also treat +0 as greater 
than -0, whereas maxNum/minNum did not specify the result in that case.  
(The choice of which operand is the result is still unspecified when the 
two operands are different DFP members of the same cohort, i.e. with 
different quantum exponents.)

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

Re: [committed] libstdc++: Add lightweight replacement for std::numeric_limits (PR 92546)

2020-02-28 Thread Jonathan Wakely


On 17/02/20 15:32 +, Jonathan Wakely wrote:

Many uses of std::numeric_limits in C++17 and C++20 features only really
need the min(), max() and digits constants for integral types. By adding
__detail::__int_limits we can avoid including the whole  header.

The  header isn't especially large, but avoiding it still gives
small savings in compilation time and memory usage for the compiler.

There are also C++11 features that could benefit from this change (e.g.
 and ) but I won't
change those until stage 1.

The implementation of __int_limits assumes two's complement integers,
which is true for all targets supported by GCC.

PR libstdc++/92546 (partial)
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/int_limits.h: New header.
* include/bits/parse_numbers.h (__select_int::_Select_int): Replace
numeric_limits with __detail::__int_limits.
* include/std/bit (__rotl, __rotr, __countl_zero, __countl_one)
(__countr_zero, __countr_one, __popcount, __ceil2, __floor2, __log2p1):
Likewise.
* include/std/charconv (__to_chars_8, __from_chars_binary)
(__from_chars_alpha_to_num, from_chars): Likewise.
* include/std/memory_resource (polymorphic_allocator::allocate)
(polymorphic_allocator::allocate_object): Likewise.
* include/std/string_view (basic_string_view::_S_compare): Likewise.
* include/std/utility (in_range): Likewise.
* testsuite/20_util/integer_comparisons/in_range_neg.cc: Adjust for
extra error about incomplete type __int_limits.
* testsuite/26_numerics/bit/bit.count/countl_one.cc: Include .
* testsuite/26_numerics/bit/bit.count/countl_zero.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/countr_one.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/countr_zero.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/popcount.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ceil2_neg.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ceil2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/floor2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ispow2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/log2p1.cc: Likewise.
* testsuite/26_numerics/bit/bit.rotate/rotl.cc: Likewise.
* testsuite/26_numerics/bit/bit.rotate/rotr.cc: Likewise.

Tested powerpc64le-linux, committed to master.


I think I probably should have just used __gnu_cxx::__numeric_traits
instead of adding a new trait. That already has min, max and digits
and is much smaller than the whole of .

Re: [PATCH] libstdc++: Fix bogus use of memcmp in ranges::lexicographical_compare (PR 93972)

2020-02-28 Thread Jonathan Wakely


On 28/02/20 14:59 -0500, Patrick Palka wrote:

We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral types and for integral types larger than a byte.  But memcmp
gives the wrong answer for arrays of such types.  This patch fixes this issue by
refining the condition that enables the memcmp optimization.  It's now
consistent with the corresponding condition used in
std::lexicographical_compare.

libstdc++-v3/ChangeLog:

PR libstdc++/93972
* include/bits/ranges_algo.h (__lexicographical_compare_fn::operator()):
Fix condition for when to use memcmp, making it consistent with the
corresponding condition used in std::lexicographical_compare.
* testsuite/25_algorithms/lexicographical_compare/93972.cc: New test.
---
libstdc++-v3/include/bits/ranges_algo.h   |   8 +-
.../lexicographical_compare/93972.cc  | 169 ++
2 files changed, 175 insertions(+), 2 deletions(-)
create mode 100644 
libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/93972.cc

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 05c0851d411..8fa4a8a9161 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -3466,9 +3466,13 @@ namespace ranges
  {
using _ValueType1 = iter_value_t<_Iter1>;
using _ValueType2 = iter_value_t<_Iter2>;
+   // This condition is consistent with the one in
+   // __lexicographical_compare_aux in .
constexpr bool __use_memcmp
- = ((is_integral_v<_ValueType1> || is_pointer_v<_ValueType1>)
-&& is_same_v<_ValueType1, _ValueType2>
+ = (__is_byte<_ValueType1>::__value
+&& __is_byte<_ValueType2>::__value
+&& !__gnu_cxx::__numeric_traits<_ValueType1>::__is_signed
+&& !__gnu_cxx::__numeric_traits<_ValueType2>::__is_signed


I think this could be:

 && !is_signed_v<_ValueType1>
 && !is_signed_v<_ValueType2>

because this code doesn't need to be valid for C++98. But on the other
hand, there's value in being consistent with the condition in
std::lexicographical_compare.

OK for master, thanks for the quick fix.

Re: [PATCH v2] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Jason Merrill


On 2/28/20 4:12 PM, Alexey Neyman wrote:


On 2/28/20 12:28 PM, Jason Merrill wrote:

On 2/28/20 2:11 PM, Alexander Monakov wrote:



On Fri, 28 Feb 2020, Eric Botcazou wrote:

+1 - I think Alexey correctly pointed out in the Bugzilla that 
debuginfo

growth from this change would be minimal (usually the number of global
variables is very small compared to number of functions (and 
linemap info).


Well, this will drag the associated types too, so figures would be 
welcome...


Below are the numbers from compiling GLIBC 2.31 for 
x86_64-unknown-linux-gnu. The first column is with a pristine copy of 
GCC at -g1, the 2nd/3rd columns are -g1 with this patch, 4th/5th columns 
are -g2.


.debug_ranges�� 125872� 125872� 0%� 452864� 260%
.debug_str� 88689�� 102005� 15% 183650� 107%
.debug_abbrev�� 112470� 255769� 127%��� 735914� 554%
.debug_line 647942� 705070� 9%� 1544877 138%
.debug_loc� 64150�� 64150�� 0%� 2976025 4539%
.debug_aranges� 77712�� 80784�� 4%� 80912�� 4%
.debug_info 240284� 907461� 278%��� 4707104 1859%
TOTAL�� 1357119 224 65% 10681346��� 687%

So indeed, an increase due to type info is substantial - but still 
nothing compared to -g2 increase.
Hm. So apparently at -g1 we don't emit type information for 
functions, and

gdb sees each function as 'void foo()' regardless of actual prototype.
Otherwise I would expect most of the types to be already present in 
debug info.


I wonder if it would make sense to emit defined variables in a 
similar fashion,

i.e. only address and size?

I'll see if I can modify the patch to do so.


I think so.� And we probably don't want function-scope or class-scope 
variables that happen to be TREE_PUBLIC.


Can you give an example of such function/class scope variables being 
TREE_PUBLIC? I tried a static variable described within a function 
scope, it was not TREE_PUBLIC.


A class static data member, or a static variable in an inline function 
or template instantiation.


Jason

Re: collect2.exe errors not pruned

2020-02-28 Thread Joseph Myers

On Fri, 28 Feb 2020, Alexandre Oliva wrote:

> I'm not sure it's appropriate for the error to not omit the host
> platform's executable suffix, just as it omits directory components from
> argv[0], so I'm undecided between fixing collect2.c's initialization of
> progname or extending the regexp, as in the (untested) patchlet below.

I don't think the error should mention .exe, but I also don't think the 
error should mention collect2 (see what I said in 
, the existence 
of collect2 is an implementation detail).

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

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

2020-02-28 Thread H.J. Lu

On Fri, Feb 28, 2020 at 1:16 PM Jeff Law  wrote:
>
> On Fri, 2020-02-28 at 05:54 -0800, H.J. Lu wrote:
> > On Fri, Feb 28, 2020 at 5:44 AM Maciej W. Rozycki  wrote:
> > > On Fri, 28 Feb 2020, H.J. Lu wrote:
> > >
> > > > > libffi/
> > > > > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > > > > files.
> > > > > * configure: Regenerate.
> > > > > * testsuite/libffi-site-extra.exp.in: New file.
> > > > > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> > > > > variable.
> > > > > * testsuite/Makefile.in: Regenerate.
> > > > > * testsuite/lib/libffi.exp (libffi-init): Handle
> > > > > GCC_UNDER_TEST.
> > > > > (libffi_target_compile): Likewise.
> > > >
> > > > Upstream libffi has local.exp.  Is that possible to use the same file?
> > >
> > >  Thanks for the suggestion; I didn't realise we are so out of date WRT the
> > > upstream version.
> > >
> > >  I find the way local.exp has been wired in rather hackish as it makes the
> > > template buried in `configure.ac' and also it requires running `autoconf'
> > > whenever there is a need to change it.
> > >
> > >  However that hack has been actually made to address this very problem
> > > discussed with this submission, so why not simply sync our copy of libffi
> > > with the upstream version?  Then we can decide if changing the hack into
> > > something cleaner is worth the hassle.
> >
> > I'd love to sync with upstream libffi.  In fact, I have done it on my
> > users/hjl/cet/master
> > branch:
> >
> > https://gitlab.com/x86-gcc/gcc/-/commit/9090e840b8464ce0f684e305eb75ff4655d05deb
> I think we'd like to update as well, but isn't there an ABI change in libffi
> that has to be fixed first?

Libffi 3.4 ABI was changed to support CET.  But it isn't the first
time ABI change for libffi,

-- 
H.J.

Re: [PATCH] handle attribute format on functions without prototype (PR 93812)

2020-02-28 Thread Jeff Law

On Wed, 2020-02-26 at 15:51 -0700, Martin Sebor wrote:
> GCC accepts attribute format even on functions without a prototype.
> However, when such a function is subsequently redeclared with
> a prototype the attribute validation runs into trouble.  To avoid
> the ICE I considered a) dropping the attribute on functions declared
> without a prototype (like Clang does) and b) dropping the attribute
> only when the function is subsequently redeclared with a prototype.
> Since (b) is slightly safer in terms of retaining potentially useful
> functionality the attached patch implements it and verifies that
> the attribute is still accepted on functions without a prototype
> and has the expected effect.
> 
> Tested on x86_64-linux.  I propose this for both GCC 10 and 9.
> 
> Martin
> 
> PS The solution causes a redunant warning for each instance of
> a redeclaration with a prototype of a function without a prototype
> but with attribute format.  Since this seems like a rare problem
> I don't think it's worth going to the trouble of making sure only
> one warning.
> 
> PPS I don't think it's intentional that GCC accepts attribute format
> on functions without a prototype, first because it normally requires
> that the format argument be a char*, and second because I could find
> no tests for the "feature" in the test suite.  It would make sense
> to me reject such declarations but I don't think now is a good time
> for such a change.

> PR c/93812 - ICE on redeclaration of an attribute format function without
> protoype
> 
> gcc/c/ChangeLog:
> 
>   PR c/93812
>   * c-typeck.c (build_functype_attribute_variant): New function.
>   (composite_type): Call it.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c/93812
>   * gcc.dg/format/proto.c: New test.
OK.  

If you want to drop like Clang for gcc-11, that's fine with me, but we'll
definitely want to warn when we drop and document the behavior change.

Thanks,
Jeff

Re: [testsuite] Update several scev/IVOPTs cases

2020-02-28 Thread Jeff Law

On Tue, 2020-02-25 at 17:52 +0800, Kewen.Lin wrote:
> Hi, 
> 
> Several scev/IVOPTs cases aim to check some array references are sceved and
> later marked as REFERENCE ADDRESS IV groups. With IV group type dumping
> improving, these check strings can be improved. Otherwise, they become
> fragile
> with dumping changes.
> 
> This patch is to keep check strings concise, meanwhile recover the coverage
> of
> case scev-8.c.
> 
> Bootstrapped/regtested on powerpc64le-linux-gnu (LE). 
> 
> Is it ok for trunk?
> 
> BR,
> Kewen
> ---
> 
> gcc/testsuite/ChangeLog
> 
> 2020-02-25  Kewen Lin  
> 
>   * gcc.dg/tree-ssa/scev-8.c: Revise check string.
>   * gcc.dg/tree-ssa/scev-9.c: Ditto.
>   * gcc.dg/tree-ssa/scev-10.c: Ditto.
>   * gcc.dg/tree-ssa/scev-11.c: Ditto.
>   * gcc.dg/tree-ssa/scev-12.c: Ditto.
OK
jeff

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

2020-02-28 Thread Jeff Law

On Fri, 2020-02-28 at 05:54 -0800, H.J. Lu wrote:
> On Fri, Feb 28, 2020 at 5:44 AM Maciej W. Rozycki  wrote:
> > On Fri, 28 Feb 2020, H.J. Lu wrote:
> > 
> > > > libffi/
> > > > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > > > files.
> > > > * configure: Regenerate.
> > > > * testsuite/libffi-site-extra.exp.in: New file.
> > > > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> > > > variable.
> > > > * testsuite/Makefile.in: Regenerate.
> > > > * testsuite/lib/libffi.exp (libffi-init): Handle
> > > > GCC_UNDER_TEST.
> > > > (libffi_target_compile): Likewise.
> > > 
> > > Upstream libffi has local.exp.  Is that possible to use the same file?
> > 
> >  Thanks for the suggestion; I didn't realise we are so out of date WRT the
> > upstream version.
> > 
> >  I find the way local.exp has been wired in rather hackish as it makes the
> > template buried in `configure.ac' and also it requires running `autoconf'
> > whenever there is a need to change it.
> > 
> >  However that hack has been actually made to address this very problem
> > discussed with this submission, so why not simply sync our copy of libffi
> > with the upstream version?  Then we can decide if changing the hack into
> > something cleaner is worth the hassle.
> 
> I'd love to sync with upstream libffi.  In fact, I have done it on my
> users/hjl/cet/master
> branch:
> 
> https://gitlab.com/x86-gcc/gcc/-/commit/9090e840b8464ce0f684e305eb75ff4655d05deb
I think we'd like to update as well, but isn't there an ABI change in libffi
that has to be fixed first?

jeff

Re: [PATCH 4/4] arc: Update legitimate small data address.

2020-02-28 Thread Jeff Law

On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> All ARC's small data adressing is using address scaling feature of the
> load/store instructions (i.e., the address is made of a general
> pointer plus a shifted offset. The shift amount depends on the
> addressing mode).  This patch is checking the offset of an address if
> it fits the scalled constraint.  If so, a small data access is
> generated.  This patch fixes execute' pr93249 failure.

> 
> gcc/
> -xx-xx  Claudiu Zissulescu  
> 
>   * config/arc/arc.c (leigitimate_small_data_address_p): Check if an
>   address has an offset which fits the scalling constraint for a
>   load/store operation.
>   (legitimate_scaled_address_p): Update use
>   leigitimate_small_data_address_p.
>   (arc_print_operand): Likewise.
>   (arc_legitimate_address_p): Likewise.
>   (legitimate_small_data_address_p): Likewise.
OK.
jeff
>

Re: [PATCH v2] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Alexey Neyman




On 2/28/20 12:28 PM, Jason Merrill wrote:

On 2/28/20 2:11 PM, Alexander Monakov wrote:



On Fri, 28 Feb 2020, Eric Botcazou wrote:

+1 - I think Alexey correctly pointed out in the Bugzilla that 
debuginfo

growth from this change would be minimal (usually the number of global
variables is very small compared to number of functions (and 
linemap info).


Well, this will drag the associated types too, so figures would be 
welcome...


Below are the numbers from compiling GLIBC 2.31 for 
x86_64-unknown-linux-gnu. The first column is with a pristine copy of 
GCC at -g1, the 2nd/3rd columns are -g1 with this patch, 4th/5th columns 
are -g2.


.debug_rangesï¿½ï¿½ 125872ï¿½ 125872ï¿½ 0%ï¿½ï¿½ï¿½ï¿½ï¿½ 452864ï¿½ï¿½ï¿½ï¿½ï¿½ 
260%
.debug_strï¿½ï¿½ï¿½ï¿½ï¿½ 88689ï¿½ï¿½ 102005ï¿½ 15%ï¿½ï¿½ï¿½ï¿½ 
183650ï¿½ï¿½ï¿½ï¿½ï¿½ 107%
.debug_abbrevï¿½ï¿½ 112470ï¿½ 255769ï¿½ 127%ï¿½ï¿½ï¿½ 735914ï¿½ï¿½ï¿½ï¿½ï¿½ 554%
.debug_lineï¿½ï¿½ï¿½ï¿½ 647942ï¿½ 705070ï¿½ 9%ï¿½ï¿½ï¿½ï¿½ï¿½ 
1544877ï¿½ï¿½ï¿½ï¿½ 138%
.debug_locï¿½ï¿½ï¿½ï¿½ï¿½ 64150ï¿½ï¿½ 64150ï¿½ï¿½ 0%ï¿½ï¿½ï¿½ï¿½ï¿½ 
2976025ï¿½ï¿½ï¿½ï¿½ 4539%
.debug_arangesï¿½ 77712ï¿½ï¿½ 80784ï¿½ï¿½ 4%ï¿½ï¿½ï¿½ï¿½ï¿½ 
80912ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 4%
.debug_infoï¿½ï¿½ï¿½ï¿½ 240284ï¿½ 907461ï¿½ 278%ï¿½ï¿½ï¿½ 4707104ï¿½ï¿½ï¿½ï¿½ 
1859%
TOTALï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 1357119 224 65%ï¿½ï¿½ï¿½ï¿½ 
10681346ï¿½ï¿½ï¿½ 687%

So indeed, an increase due to type info is substantial - but still 
nothing compared to -g2 increase.
Hm. So apparently at -g1 we don't emit type information for 
functions, and

gdb sees each function as 'void foo()' regardless of actual prototype.
Otherwise I would expect most of the types to be already present in 
debug info.


I wonder if it would make sense to emit defined variables in a 
similar fashion,

i.e. only address and size?

I'll see if I can modify the patch to do so.


I think so.ï¿½ And we probably don't want function-scope or class-scope 
variables that happen to be TREE_PUBLIC.


Can you give an example of such function/class scope variables being 
TREE_PUBLIC? I tried a static variable described within a function 
scope, it was not TREE_PUBLIC.


Regards,
Alexey.

Re: [PATCH] use pointer size rather than array size when storing the former (PR 93829)

2020-02-28 Thread Jeff Law

On Wed, 2020-02-26 at 16:18 -0700, Martin Sebor wrote:
> On 2/26/20 3:09 PM, Jeff Law wrote:
> > On Wed, 2020-02-19 at 17:26 -0700, Martin Sebor wrote:
> > > The buffer overflow detection for multi-char stores uses the size
> > > of a source array even when what's actually being accessed (read
> > > and stored) is a pointer to the array.  That leads to incorrect
> > > warnings in some cases.
> > > 
> > > The attached patch corrects the function that computes the size of
> > > the access to set it to that of a pointer instead if the source is
> > > an address expression.
> > > 
> > > Tested on x86_64-linux.
> > > if (TREE_CODE (exp) == ADDR_EXPR)
> > > -exp = TREE_OPERAND (exp, 0);
> > > +{
> > > +  /* If the size of the access hasn't been determined yet it's that
> > > +  of a pointer.  */
> > > +  if (!nbytes)
> > > + nbytes = tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (exp)));
> > > +  exp = TREE_OPERAND (exp, 0);
> > > +}
> > >   
> > This doesn't make any sense to me.  You're always going to get the size of
> > a
> > pointer here.  Don't you want the size of the TYPE of the operand?
> 
> The function correctly handles cases when the expression is an array
> because the array is what's being stored.  The bug is in stripping
> the ADDR_EXPR and then using the size of the operand when what's
> being stored is actually a pointer.
> 
> This test case illustrates the difference:
> 
>struct S { char *p, *q, r[8]; } a;
> 
>void f (void)
>{
>  struct S b = { 0, "1234567", "abcdefgh" };
>  __builtin_memcpy (&a, &b, sizeof a);
>}
> 
> The memcpy results in:
> 
>MEM  [(char * {ref-all})&b] = 0B;
>MEM  [(char * {ref-all})&b + 8B] = "1234567";
>MEM  [(char * {ref-all})&a] = MEM  char[24]> [(char * {ref-all})&b];
> 
> The RHS of the second MEM_REF is ADDR_EXPR (STRING_CST).  The RHS
> of the third MEM_REF is the  array case (that's handled correctly).
> 
> I think computing the size of the store could be simplified (it
> seems it should be the same as type of either the RHS or the LHS)
> but I didn't want to mess with things too much this late.
Sorry, I should have just thrown this under the debugger, but I was short of
time.

ISTM like the problem is we have an RHS like:


> 
> >   > type  > type  > char>
> > BLK
> > size 
> > unit-size 
> > align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> > 0x7fffea939690 domain 
> > pointer_to_this >
> > unsigned DI
> > size 
> > unit-size 
> > align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> > 0x7fffea939d20>
> > readonly constant
> > arg:0 
> > readonly constant static
> > "0123456789012345678901234567890123456789\000">
> > j.c:20:10 start: j.c:20:10 finish: j.c:20:10>
> > 

The current code unconditionally strips the ADDR_EXPR at this point and as a
result will use the length of STRING_CST node, which is obviously wrong.

With your change, if we haven't already determined a length, we extract the
length of the pointer then strip the ADDR_EXPR.

Yea, this is all ripe for some cleanup.  For example it's not at all clear that
just because we don't have a size at this point in count_nonzero_bytes and
we've got an ADDR_EXPR that we want the size of the pointer.That may in
fact be true, but it's not easy to ascertain with the current spaghetti code.

OK for the trunk, but let's queue this area for some cleanup in gcc-11.

jeff






> Martin
>

[committed] coroutines: Update func-params-08.C test to suspend three times.

2020-02-28 Thread Iain Sandoe

Hi,

The awaitable initially committed for this test was returning 
"always ready” which meant that the suspension code was not
used.  Update the test to suspend at each co_await, since this
exercises more of the infrastructure.

tested on x86_64-darwin16,
applied to master,
thanks
Iain

gcc/testsuite/ChangeLog:

2020-02-28  Iain Sandoe  

* g++.dg/coroutines/torture/func-params-08.C: Update
to suspend for each co_await operation.

diff --git a/gcc/testsuite/g++.dg/coroutines/torture/func-params-08.C 
b/gcc/testsuite/g++.dg/coroutines/torture/func-params-08.C
index c34d143fa68..c166745e052 100644
--- a/gcc/testsuite/g++.dg/coroutines/torture/func-params-08.C
+++ b/gcc/testsuite/g++.dg/coroutines/torture/func-params-08.C
@@ -46,7 +46,7 @@ struct Foo {
{
  int v;
  awaitable (int _v) : v(_v) {}
- bool await_ready() { return true; }
+ bool await_ready() { return false; }
  void await_suspend(coro::coroutine_handle<>) {}
  int await_resume() { return v;}
};

Re: [PATCH v2] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Jason Merrill


On 2/28/20 2:11 PM, Alexander Monakov wrote:



On Fri, 28 Feb 2020, Eric Botcazou wrote:


+1 - I think Alexey correctly pointed out in the Bugzilla that debuginfo
growth from this change would be minimal (usually the number of global
variables is very small compared to number of functions (and linemap info).


Well, this will drag the associated types too, so figures would be welcome...


Hm. So apparently at -g1 we don't emit type information for functions, and
gdb sees each function as 'void foo()' regardless of actual prototype.
Otherwise I would expect most of the types to be already present in debug info.

I wonder if it would make sense to emit defined variables in a similar fashion,
i.e. only address and size?


I think so.  And we probably don't want function-scope or class-scope 
variables that happen to be TREE_PUBLIC.


Jason

libgo patch committed: Handle arm64 GNU/Linux signal register values

2020-02-28 Thread Ian Lance Taylor

This libgo patch by eric fang sets sigpc and implement dumpregs for
arm64 GNU/Linux.  Without this change, the cmd/vet tool test will fail
randomly, as discussed at https://golang.org/issue/20931.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
d13e079f4b6e1ac76984d8734e6879f1e3a4e9e7
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index a62c8292e0a..6b4c21fabf5 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-5fc21bb0d91d916940c21e6d4a3e10ad3f45343d
+7a62a49e62c090118fa003d9265c5f5e2090c4f9
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/runtime/go-signal.c b/libgo/runtime/go-signal.c
index 081604e1849..a07fdeafeb4 100644
--- a/libgo/runtime/go-signal.c
+++ b/libgo/runtime/go-signal.c
@@ -205,28 +205,18 @@ getSiginfo(siginfo_t *info, void *context 
__attribute__((unused)))
// Use unportable code to pull it from context, and if that fails
// try a stack backtrace across the signal handler.
 
-#ifdef __x86_64__
- #ifdef __linux__
+#if defined(__x86_64__) && defined(__linux__)
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[REG_RIP];
- #endif
-#endif
-#ifdef __i386__
-  #ifdef __linux__
+#elif defined(__i386__) && defined(__linux__)
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[REG_EIP];
-  #endif
-#endif
-#ifdef __alpha__
-  #ifdef __linux__
+#elif defined(__alpha__) && defined(__linux__)
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.sc_pc;
-  #endif
-#endif
-#ifdef __PPC__
-  #ifdef __linux__
+#elif defined(__PPC__) && defined(__linux__)
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.regs->nip;
-  #endif
-  #ifdef _AIX
+#elif defined(__PPC__) && defined(_AIX)
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.jmp_context.iar;
-  #endif
+#elif defined(__aarch64__) && defined(__linux__)
+   ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.pc;
 #endif
 
if (ret.sigpc == 0) {
@@ -250,8 +240,7 @@ void dumpregs(siginfo_t *, void *)
 void
 dumpregs(siginfo_t *info __attribute__((unused)), void *context 
__attribute__((unused)))
 {
-#ifdef __x86_64__
- #ifdef __linux__
+#if defined(__x86_64__) && defined(__linux__)
{
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
 
@@ -277,11 +266,7 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("fs %X\n", (m->gregs[REG_CSGSFS] >> 16) & 
0x);
runtime_printf("gs %X\n", (m->gregs[REG_CSGSFS] >> 32) & 
0x);
  }
- #endif
-#endif
-
-#ifdef __i386__
- #ifdef __linux__
+#elif defined(__i386__) && defined(__linux__)
{
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
 
@@ -299,11 +284,7 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("fs %x\n", m->gregs[REG_FS]);
runtime_printf("gs %x\n", m->gregs[REG_GS]);
  }
- #endif
-#endif
-
-#ifdef __alpha__
-  #ifdef __linux__
+#elif defined(__alpha__) && defined(__linux__)
{
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
 
@@ -340,11 +321,7 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("sp  %X\n", m->sc_regs[30]);
runtime_printf("pc  %X\n", m->sc_pc);
  }
-  #endif
-#endif
-
-#if defined(__PPC__) && defined(__LITTLE_ENDIAN__)
-  #ifdef __linux__
+#elif defined(__PPC__) && defined(__LITTLE_ENDIAN__) && defined(__linux__)
  {
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
int i;
@@ -358,11 +335,7 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("ctr %X\n", m->regs->ctr);
runtime_printf("xer %X\n", m->regs->xer);
  }
-  #endif
-#endif
-
-#ifdef __PPC__
-  #ifdef _AIX
+#elif defined(__PPC__) && defined(_AIX)
  {
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
int i;
@@ -376,6 +349,16 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("ctr %p\n", m->jmp_context.ctr);
runtime_printf("xer %x\n", m->jmp_context.xer);
  }
-  #endif
+#elif defined(__aarch64__) && defined(__linux__)
+ {
+   mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
+   int i;
+
+   for (i = 0; i < 31; i++)
+   runtime_printf("x%d%X\n", i, m->regs[i]);
+   runtime_printf("sp %X\n", m->sp);
+   runtime_printf("pc %X\n", m->pc);
+   runtime_printf("pstate %X\n", m->pstate);
+ }
 #endif
 }

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

2020-02-28 Thread Jason Merrill


On 2/28/20 12:45 PM, Martin Sebor wrote:

On 2/28/20 9:58 AM, Jason Merrill wrote:

On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).



+ a new entry for it and return unless it's a declaration
+ involving a template that may need to be diagnosed by
+ -Wredundant-tags.  */
   *rdl = class_decl_loc_t (class_key, false, def_p);
-  return;
+  if (TREE_CODE (decl) != TEMPLATE_DECL)
+    return;


How can the first appearance of a class template be redundant?


I'm not sure I correctly understand the question.  The comment says
"involving a template" (i.e., not one of the first declaration of
a template).  The test case that corresponds to this test is:

   template  struct S7 { };
   struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" }

where DECL is the TEPLATE_DECL of S7.

As I mentioned, more work is still needed to handle templates right
because some redundant tags are still not diagnosed.  For example:

   template  struct S7 { };
   template 
   using U = struct S7;   // missing warning


When we get here for an instance of a template, it doesn't make sense to 
treat it as a new type.


If decl is a template and type_decl is an instance of that template, do 
we want to (before the lookup) change type_decl to the template or the 
corresponding generic TYPE_DECL, which should already be in the table?


Jason

Minor regression due to recent IRA changes

2020-02-28 Thread Jeff Law

This change:

> commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
> Author: Vladimir N. Makarov 
> Date:   Sun Feb 23 16:20:05 2020 -0500
> 
> Changing cost propagation and ordering colorable bucket heuristics for
> PR93564.
> 
> 2020-02-23  Vladimir Makarov  
> 
> PR rtl-optimization/93564
> * ira-color.c (struct update_cost_queue_elem): New member start.
> (queue_update_cost, get_next_update_cost): Add new arg start.
> (allocnos_conflict_p): New function.
> (update_costs_from_allocno): Add new arg conflict_cost_update_p.
> Add checking conflicts with allocnos_conflict_p.
> (update_costs_from_prefs, restore_costs_from_copies): Adjust
> update_costs_from_allocno calls.
> (update_conflict_hard_regno_costs): Add checking conflicts with
> allocnos_conflict_p.  Adjust calls of queue_update_cost and
> get_next_update_cost.
> (assign_hard_reg): Adjust calls of queue_update_cost.  Add
> debugging print.
> (bucket_allocno_compare_func): Restore previous version.
> 

Is causing c-torture/compile/sync-1 to fail with an ICE on sh4eb (search for
"Tests that now fail, but worked before":


http://3.14.90.209:8080/job/sh4eb-linux-gnu/lastFailedBuild/console


In the .log we have:

> /home/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:253:1: error:
> unable to find a register to spill in class 'R0_REGS'^M
> /home/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:253:1: error: this
> is the insn:^M
> (insn 209 207 212 2 (parallel [^M
> (set (subreg:SI (reg:HI 431) 0)^M
> (unspec_volatile:SI [^M
> (mem/v:HI (reg/f:SI 299) [-1  S2 A16])^M
> (subreg:HI (reg:SI 6 r6 [orig:425 uc+-3 ] [425]) 2)^M
> (reg:HI 5 r5 [orig:428 sc+-1 ] [428])^M
> ] UNSPECV_CMPXCHG_1))^M
> (set (mem/v:HI (reg/f:SI 299) [-1  S2 A16])^M
> (unspec_volatile:HI [^M
> (const_int 0 [0])^M
> ] UNSPECV_CMPXCHG_2))^M
> (set (reg:SI 147 t)^M
> (unspec_volatile:SI [^M
> (const_int 0 [0])^M
> ] UNSPECV_CMPXCHG_3))^M
> (clobber (scratch:SI))^M
> (clobber (reg:SI 0 r0))^M
> (clobber (reg:SI 1 r1))^M
> ]) "/home/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c":245:8 
> 406 {atomic_compare_and_swaphi_soft_gusa}^M
>  (expr_list:REG_DEAD (reg:HI 5 r5 [orig:428 sc+-1 ] [428])^M
> (expr_list:REG_DEAD (reg:SI 6 r6 [orig:425 uc+-3 ] [425])^M
> (expr_list:REG_DEAD (reg/f:SI 299)^M
> (expr_list:REG_UNUSED (reg:HI 431)^M
> (expr_list:REG_UNUSED (reg:SI 1 r1)^M
> (expr_list:REG_UNUSED (reg:SI 0 r0)^M
> (nil^M
> 

You should be able to trigger it with a cross compiler at -O2 with the attached
testcase.

This could well be a target issue.  I haven't tried to debug it.  If it's a
target issue, I'm fully comfortable punting it to the SH folks for resolving.
/* { dg-message "note: '__sync_fetch_and_nand' changed semantics in GCC 4.4" "fetch_and_nand" { target *-*-* } 0 } */
/* { dg-message "note: '__sync_nand_and_fetch' changed semantics in GCC 4.4" "nand_and_fetch" { target *-*-* } 0 } */
/* { dg-options "-ffat-lto-objects" } */

/* Validate that each of the __sync builtins compiles.  This won't 
   necessarily link, since the target might not support the builtin,
   so this may result in external library calls.  */

signed char sc;
unsigned char uc;
signed short ss;
unsigned short us;
signed int si;
unsigned int ui;
signed long sl;
unsigned long ul;
signed long long sll;
unsigned long long ull;
void *vp;
int *ip;
struct S { struct S *next; int x; } *sp;

void test_op_ignore (void)
{
  (void) __sync_fetch_and_add (&sc, 1);
  (void) __sync_fetch_and_add (&uc, 1);
  (void) __sync_fetch_and_add (&ss, 1);
  (void) __sync_fetch_and_add (&us, 1);
  (void) __sync_fetch_and_add (&si, 1);
  (void) __sync_fetch_and_add (&ui, 1);
  (void) __sync_fetch_and_add (&sl, 1);
  (void) __sync_fetch_and_add (&ul, 1);
  (void) __sync_fetch_and_add (&sll, 1);
  (void) __sync_fetch_and_add (&ull, 1);

  (void) __sync_fetch_and_sub (&sc, 1);
  (void) __sync_fetch_and_sub (&uc, 1);
  (void) __sync_fetch_and_sub (&ss, 1);
  (void) __sync_fetch_and_sub (&us, 1);
  (void) __sync_fetch_and_sub (&si, 1);
  (void) __sync_fetch_and_sub (&ui, 1);
  (void) __sync_fetch_and_sub (&sl, 1);
  (void) __sync_fetch_and_sub (&ul, 1);
  (void) __sync_fetch_and_sub (&sll, 1);
  (void) __sync_fetch_and_sub (&ull, 1);

  (void) __sync_fetch_and_or (&sc, 1);
  (void) __sync_fetch_and_or (&uc, 1);
  (void) __sync_fetch_and_or (&ss, 1);
  (void) __sync_fetch_and_or (&us, 1);
  (void) __sync_fetch_and_or (&si, 1);
  (

Results for 10.0.1 20200227 (experimental) [master revision r10-6885-g5f9cd512c427] (GCC) testsuite on x86_64-apple-darwin1

2020-02-28 Thread Iain Sandoe

LAST_UPDATED: Thu Feb 27 09:29:19 UTC 2020 (revision r10-6885-g5f9cd512c427)

=== acats tests ===

=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-apple-darwin16

=== g++ tests ===


Running target unix/-m32
FAIL: c-c++-common/asan/alloca_big_alignment.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -Os  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto -flto-partition=none  output 
pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -Os  output pattern test
FAIL: g++.dg/asan/pr69276.C   -O0  output pattern test
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C compilation,  -O3 -g  
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-1.C compilation,  -O3 -g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C compilation,  -g  -fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-1.C compilation,  -g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C execution,-O3 -g  
-fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C execution,-O3 -g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C execution,-g  -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C execution,-g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C compilation,  -O3 -g  
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation,  -O3 -g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C compilation,  -g  -fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation,  -g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O3 -g  
-fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O3 -g  -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-g  -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-g  -fprofile-arcs
WARNING: g++.dg/coroutines/co-return-syntax-09-lambda-auto.C  (test for errors, 
line 15) program timed out.
FAIL: g++.dg/ext/pr84828.C  -std=gnu++14 (internal compiler error)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++17 (internal compiler error)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++2a (internal compiler error)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++2a (test for excess errors)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++98 (internal compiler error)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/ipa/pr67056.C   scan-ipa-dump cp "Speculative outer type:struct 
CompositeClass"
FAIL: g++.dg/pr80481.C  -std=gnu++14  scan-assembler-not vmovaps
FAIL: g++.dg/pr80481.C  -std=gnu++17  scan-assembler-not vmovaps
FAIL: g++.dg/pr80481.C  -std=gnu++2a  scan-assembler-not vmovaps
FAIL: g++.dg/pr80481.C  -std=gnu++98  scan-assembler-not vmovaps
FAIL: g++.dg/tree-ssa/pr90883.C   scan-tree-dump dse1 "Deleted redundant store: 
.*.a = {}"
FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 
-std=c++11
FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link,  
-std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type 
FAIL: g++.dg/lto/pr89335 cp_lto_pr89335_0.o assemble, -O2 -flto 
-Wsuggest-final-methods
WARNING: g++.dg/torture/pr64978.C   -Os  (test for excess errors) program timed 
out.
FAIL: g++.dg/torture/pr64978.C   -Os  (test for excess errors)
FAIL: g++.dg/tree-prof/pr57451.C compilation,  -fprofile-generate 
-D_PROFILE_GENERATE
UNRESOLVED: g++.dg/tree-prof/pr57451.C compilation,  -fprofile-use 
-D_PROFILE_USE
UNRESOLVED: g++.dg/tree-prof/pr57451.C execution,-fprofile-generate 
-D_PROFILE_GENERATE
UNRESOLVED: g++.dg/tree-prof/pr57451.C execution,-fprofile-use 
-D_PROFILE_USE
FAIL: g++.dg/tree-prof/pr63581.C compilation,  -fprofile-generate 
-D_PROFILE_GENERATE
UNRESOLVED: g++.dg/tree-prof/pr63581.C compilation,  -fprofile-use 
-D_PROFILE_USE
UNRESOLVED: g++.dg/tree-prof/pr63581.C execution,-fprofile-generate 
-D_PROFILE_GENERATE
UNRESOLVED: g++.dg/tree-prof/pr63581.C execution,-fprofile-use 
-D_PROFILE_USE

=== g++ Summary for unix/-m32 ===

# of expected passes182164
# of unexpected failures37
# of expected failures  731
# of unresolved testcases   18
# of unsupported tests  8112

Running target unix/-m64
FAIL: c-c++-common

[PATCH] libstdc++: Fix bogus use of memcmp in ranges::lexicographical_compare (PR 93972)

2020-02-28 Thread Patrick Palka

We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral types and for integral types larger than a byte.  But memcmp
gives the wrong answer for arrays of such types.  This patch fixes this issue by
refining the condition that enables the memcmp optimization.  It's now
consistent with the corresponding condition used in
std::lexicographical_compare.

libstdc++-v3/ChangeLog:

PR libstdc++/93972
* include/bits/ranges_algo.h (__lexicographical_compare_fn::operator()):
Fix condition for when to use memcmp, making it consistent with the
corresponding condition used in std::lexicographical_compare.
* testsuite/25_algorithms/lexicographical_compare/93972.cc: New test.
---
 libstdc++-v3/include/bits/ranges_algo.h   |   8 +-
 .../lexicographical_compare/93972.cc  | 169 ++
 2 files changed, 175 insertions(+), 2 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/93972.cc

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 05c0851d411..8fa4a8a9161 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -3466,9 +3466,13 @@ namespace ranges
  {
using _ValueType1 = iter_value_t<_Iter1>;
using _ValueType2 = iter_value_t<_Iter2>;
+   // This condition is consistent with the one in
+   // __lexicographical_compare_aux in .
constexpr bool __use_memcmp
- = ((is_integral_v<_ValueType1> || is_pointer_v<_ValueType1>)
-&& is_same_v<_ValueType1, _ValueType2>
+ = (__is_byte<_ValueType1>::__value
+&& __is_byte<_ValueType2>::__value
+&& !__gnu_cxx::__numeric_traits<_ValueType1>::__is_signed
+&& !__gnu_cxx::__numeric_traits<_ValueType2>::__is_signed
 && is_pointer_v<_Iter1>
 && is_pointer_v<_Iter2>
 && (is_same_v<_Comp, ranges::less>
diff --git 
a/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/93972.cc 
b/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/93972.cc
new file mode 100644
index 000..53c4e0daddc
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/93972.cc
@@ -0,0 +1,169 @@
+// Copyright (C) 2020 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++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+using std::signed_integral;
+
+namespace ranges = std::ranges;
+
+template
+void
+test01()
+{
+  T i[] = { -1 };
+  T j[] = { 1 };
+
+  VERIFY( ranges::lexicographical_compare(i, j) );
+  VERIFY( !ranges::lexicographical_compare(i, j, ranges::greater{}) );
+
+  VERIFY( !ranges::lexicographical_compare(j, i) );
+  VERIFY( ranges::lexicographical_compare(j, i, ranges::greater{}) );
+}
+
+template
+void
+test02()
+{
+  T i[] = { -5 };
+  T j[] = { -5, 3 };
+
+  VERIFY( ranges::lexicographical_compare(i, j) );
+  VERIFY( ranges::lexicographical_compare(i, j, ranges::greater{}) );
+
+  VERIFY( !ranges::lexicographical_compare(j, i) );
+  VERIFY( !ranges::lexicographical_compare(j, i, ranges::greater{}) );
+}
+
+template
+void
+test03()
+{
+  T i[] = { -10 };
+  T j[] = { -5, 3 };
+
+  VERIFY( ranges::lexicographical_compare(i, j) );
+  VERIFY( !ranges::lexicographical_compare(i, j, ranges::greater{}) );
+
+  VERIFY( !ranges::lexicographical_compare(j, i) );
+  VERIFY( ranges::lexicographical_compare(j, i, ranges::greater{}) );
+}
+
+template
+void
+test04()
+{
+  T i[] = { -2 };
+  T j[] = { -5, 3 };
+
+  VERIFY( !ranges::lexicographical_compare(i, j) );
+  VERIFY( ranges::lexicographical_compare(i, j, ranges::greater{}) );
+
+  VERIFY( ranges::lexicographical_compare(j, i) );
+  VERIFY( !ranges::lexicographical_compare(j, i, ranges::greater{}) );
+}
+
+void
+test05()
+{
+  unsigned i[] = { 1 };
+  unsigned j[] = { 256 };
+
+  VERIFY( ranges::lexicographical_compare(i, j) );
+  VERIFY( !ranges::lexicographical_compare(i, j, ranges::greater{}) );
+
+  VERIFY( !ranges::lexicographical_compare(j, i) );
+  VERIFY( ranges::lexicographical_compare(j, i, ra

Re: [PATCH v2] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Alexander Monakov

On Fri, 28 Feb 2020, Eric Botcazou wrote:

> > +1 - I think Alexey correctly pointed out in the Bugzilla that debuginfo
> > growth from this change would be minimal (usually the number of global
> > variables is very small compared to number of functions (and linemap info).
> 
> Well, this will drag the associated types too, so figures would be welcome...

Hm. So apparently at -g1 we don't emit type information for functions, and
gdb sees each function as 'void foo()' regardless of actual prototype.
Otherwise I would expect most of the types to be already present in debug info.

I wonder if it would make sense to emit defined variables in a similar fashion,
i.e. only address and size?

(assuming that still fits Alexey's needs)

Thanks.
Alexander

[pushed] c++: Fix constrained conversion op.

2020-02-28 Thread Jason Merrill

We don't want to promote a conversion from viable == 0 to viable == -1.
Found in ranges-v3.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog
2020-02-28  Jason Merrill  

* call.c (build_user_type_conversion_1): Don't look at the second
conversion of a non-viable candidate.
---
 gcc/cp/call.c   |  4 
 gcc/testsuite/g++.dg/cpp2a/concepts-conv1.C | 15 +++
 2 files changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-conv1.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index e07ee85c06e..85bbd043a1d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4083,6 +4083,10 @@ build_user_type_conversion_1 (tree totype, tree expr, 
int flags,
 
   for (cand = candidates; cand != old_candidates; cand = cand->next)
{
+ if (cand->viable == 0)
+   /* Already rejected, don't change to -1.  */
+   continue;
+
  tree rettype = TREE_TYPE (TREE_TYPE (cand->fn));
  conversion *ics
= implicit_conversion (totype,
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-conv1.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-conv1.C
new file mode 100644
index 000..aa29acbcb13
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-conv1.C
@@ -0,0 +1,15 @@
+// { dg-do compile { target concepts } }
+
+template  concept False = false;
+
+template 
+struct A
+{
+  explicit operator bool ();
+  explicit operator bool () requires False;
+};
+
+int main()
+{
+  int i { A() };  // { dg-error "" }
+}

base-commit: 77e596cf3c1b7bc11ba946394ed8d62a49157b49
-- 
2.18.1

[committed] libstdc++: test for failing assertion should use 'run' not 'compile'

2020-02-28 Thread Jonathan Wakely

And it only needs to define _GLIBCXX_ASSERTIONS not _GLIBCXX_DEBUG.

* testsuite/24_iterators/range_operations/advance_debug_neg.cc: Run
test instead of just compiling it.

Tested x86_64-linux, committed to master.

commit 4735f92d48c373031be296fd0f7a2cf31fc955da
Author: Jonathan Wakely 
Date:   Fri Feb 28 17:05:45 2020 +

libstdc++: test for failing assertion should use 'run' not 'compile'

And it only needs to define _GLIBCXX_ASSERTIONS not _GLIBCXX_DEBUG.

* testsuite/24_iterators/range_operations/advance_debug_neg.cc: Run
test instead of just compiling it.

diff --git 
a/libstdc++-v3/testsuite/24_iterators/range_operations/advance_debug_neg.cc 
b/libstdc++-v3/testsuite/24_iterators/range_operations/advance_debug_neg.cc
index ffda650fb0a..7a1ef97df14 100644
--- a/libstdc++-v3/testsuite/24_iterators/range_operations/advance_debug_neg.cc
+++ b/libstdc++-v3/testsuite/24_iterators/range_operations/advance_debug_neg.cc
@@ -15,8 +15,9 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=gnu++2a -D_GLIBCXX_DEBUG" }
-// { dg-do compile { xfail c++2a } }
+// { dg-options "-std=gnu++2a -D_GLIBCXX_ASSERTIONS" }
+// { dg-do run { xfail *-*-* } }
+// { dg-require-effective-target c++2a }
 
 #include 
 #include 
@@ -29,3 +30,8 @@ test01()
   auto iter = c.begin();
   std::ranges::advance(iter, -1);
 }
+
+int main()
+{
+  test01();
+}

Re: [Patch, fortran] PR92785 - expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

2020-02-28 Thread Paul Richard Thomas

Committed as revision r10-6924-g7485ace81de9ec9dd5c87edf67e359d31ce35a20

On Fri, 28 Feb 2020 at 12:15, Paul Richard Thomas
 wrote:
>
> I will commit this tonight as 'obvious' unless there are any
> complaints. This descriptor renormalisation is already present in
> gfc_conv_derived_to_class.
>
> Paul
>
> 2020-02-28  Paul Thomas  
>
> PR fortran/92785
> * trans-expr.c (gfc_conv_intrinsic_to_class): Renormalise non-
> variable expressions to be unity lbound based.
>
> 2020-02-28  Paul Thomas  
>
> PR fortran/92785
> * gfortran.dg/unlimited_polymorphic_31.f03 : New test.



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

Re: [PATCH] libstdc++: P1645R1 constexpr for algorithms

2020-02-28 Thread Jonathan Wakely


On 28/02/20 12:57 -0500, Patrick Palka wrote:

On Fri, 28 Feb 2020, Jonathan Wakely wrote:


On 26/02/20 10:28 -0500, Patrick Palka wrote:
> On Wed, 26 Feb 2020, Jonathan Wakely wrote:
>
> > On 25/02/20 15:36 -0500, Patrick Palka wrote:
> > > This adds constexpr to 11 algorithms defined in  as per
> > P1645R1.
> > >
> > > Tested on x86_64-pc-linux-gnu, OK to commit?
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > >  P1645R1 constexpr for  algorithms
> > >  * include/bits/stl_numeric.h (iota, accumulate, inner_product,
> > >  partial_sum, adjacent_difference): Make conditionally constexpr for
> > >  C++20.
> > >  * include/std/numeric (reduce, transform_reduce, exclusive_scan,
> > >  inclusive_scan, transform_exclusive_scan, transform_inclusive_scan):
> > >  Likewise.  Define the feature test macro __cpp_lib_constexpr_numeric.
> > >  * testsuite/26_numerics/accumulate/constexpr.cc: New test.
> > >  * testsuite/26_numerics/adjacent_difference/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/exclusive_scan/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/inclusive_scan/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/inner_product/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/iota/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/partial_sum/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/reduce/constexpr.cc: Likewise.
> > >  * testsuite/26_numerics/transform_exclusive_scan/constexpr.cc:
> > > Likewise.
> > >  * testsuite/26_numerics/transform_inclusive_scan/constexpr.cc:
> > > Likewise.
> > >  * testsuite/26_numerics/transform_reduce/constexpr.cc: Likewise.

testsuite/26_numerics/headers/numeric/synopsis.cc is now failing when
run with -std=gnu++2a.

For testsuite/25_algorithms/headers/algorithm/synopsis.cc we just
added _GLIBCXX20_CONSTEXPR to the test as needed.


Does this look OK to commit?


Yes, thanks.

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Jakub Jelinek

On Fri, Feb 28, 2020 at 06:50:20PM +0100, Thomas Koenig wrote:
> Am 28.02.20 um 17:58 schrieb Steve Kargl:
> > Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to
> > be a pessimization for correctly written code.
> 
> Also note the following part of changes.html for 9.2:
> 
> The MAX and MIN intrinsics are no longer guaranteed to return any
> particular value in case one of the arguments is a NaN. Note that this
> conforms to the Fortran standard and to what other Fortran compilers do.
> If there is a need to handle that case in some specific way, one needs
> to explicitly check for NaN's before calling MAX or MIN, e.g. by using
> the IEEE_IS_NAN function from the intrinsic module IEEE_ARITHMETIC.
> 
> This was discussed (and decided) at the time.

But then the tests shouldn't actually test it, or should be restricted
to targets where it will work anyway at least.

Jakub

Re: [PATCH] libstdc++: P1645R1 constexpr for algorithms

2020-02-28 Thread Patrick Palka

On Fri, 28 Feb 2020, Jonathan Wakely wrote:

> On 26/02/20 10:28 -0500, Patrick Palka wrote:
> > On Wed, 26 Feb 2020, Jonathan Wakely wrote:
> > 
> > > On 25/02/20 15:36 -0500, Patrick Palka wrote:
> > > > This adds constexpr to 11 algorithms defined in  as per
> > > P1645R1.
> > > >
> > > > Tested on x86_64-pc-linux-gnu, OK to commit?
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > P1645R1 constexpr for  algorithms
> > > > * include/bits/stl_numeric.h (iota, accumulate, inner_product,
> > > > partial_sum, adjacent_difference): Make conditionally constexpr 
> > > > for
> > > > C++20.
> > > > * include/std/numeric (reduce, transform_reduce, exclusive_scan,
> > > > inclusive_scan, transform_exclusive_scan, 
> > > > transform_inclusive_scan):
> > > > Likewise.  Define the feature test macro 
> > > > __cpp_lib_constexpr_numeric.
> > > > * testsuite/26_numerics/accumulate/constexpr.cc: New test.
> > > > * testsuite/26_numerics/adjacent_difference/constexpr.cc: 
> > > > Likewise.
> > > > * testsuite/26_numerics/exclusive_scan/constexpr.cc: Likewise.
> > > > * testsuite/26_numerics/inclusive_scan/constexpr.cc: Likewise.
> > > > * testsuite/26_numerics/inner_product/constexpr.cc: Likewise.
> > > > * testsuite/26_numerics/iota/constexpr.cc: Likewise.
> > > > * testsuite/26_numerics/partial_sum/constexpr.cc: Likewise.
> > > > * testsuite/26_numerics/reduce/constexpr.cc: Likewise.
> > > > * testsuite/26_numerics/transform_exclusive_scan/constexpr.cc:
> > > > Likewise.
> > > > * testsuite/26_numerics/transform_inclusive_scan/constexpr.cc:
> > > > Likewise.
> > > > * testsuite/26_numerics/transform_reduce/constexpr.cc: Likewise.
> 
> testsuite/26_numerics/headers/numeric/synopsis.cc is now failing when
> run with -std=gnu++2a.
> 
> For testsuite/25_algorithms/headers/algorithm/synopsis.cc we just
> added _GLIBCXX20_CONSTEXPR to the test as needed.

Does this look OK to commit?

-- >8 --

Subject: [PATCH] libstdc++: Update the  synopsis test to latest
 standard

Tested with

  make check RUNTESTFLAGS="conformance.exp=*numeric*synopsis* 
--target_board=unix/-std=$std"

for std in {c++98, c++11, c++17, c++2a}.

libstdc++-v3/ChangeLog:

* testsuite/26_numerics/headers/numeric/synopsis.cc: Add signatures for
functions introduced in C++11, C++17 and C++2a.  Add 'constexpr' to
existing signatures for C++2a.
---
 .../26_numerics/headers/numeric/synopsis.cc   | 111 ++
 1 file changed, 111 insertions(+)

diff --git a/libstdc++-v3/testsuite/26_numerics/headers/numeric/synopsis.cc 
b/libstdc++-v3/testsuite/26_numerics/headers/numeric/synopsis.cc
index 8d3850ff0cf..5a9465c45f4 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/numeric/synopsis.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/numeric/synopsis.cc
@@ -19,46 +19,157 @@
 
 #include 
 
+#if __cplusplus > 201703L
+#define CONSTEXPR constexpr
+#else
+#define CONSTEXPR
+#endif
+
 namespace std {
   template 
+CONSTEXPR
 T accumulate(InputIterator first, InputIterator last, T init);
 
   template 
+CONSTEXPR
 T accumulate(InputIterator first, InputIterator last, T init,
  BinaryOperation binary_op);
 
   template 
+CONSTEXPR
 T inner_product(InputIterator1 first1, InputIterator1 last1,
 InputIterator2 first2, T init);
 
   template 
+CONSTEXPR
 T inner_product(InputIterator1 first1, InputIterator1 last1,
 InputIterator2 first2, T init,
 BinaryOperation1 binary_op1,
 BinaryOperation2 binary_op2);
 
   template 
+CONSTEXPR
 OutputIterator partial_sum(InputIterator first,
InputIterator last,
OutputIterator result);
 
   template 
+CONSTEXPR
 OutputIterator partial_sum(InputIterator first,
InputIterator last,
OutputIterator result,
BinaryOperation binary_op);
 
   template 
+CONSTEXPR
 OutputIterator adjacent_difference(InputIterator first,
InputIterator last,
OutputIterator result);
 
   template 
+CONSTEXPR
 OutputIterator adjacent_difference(InputIterator first,
InputIterator last,
OutputIterator result,
BinaryOperation binary_op);
+#if __cplusplus >= 201103L
+  template
+CONSTEXPR void iota(ForwardIterator first, ForwardIterator last, T value);
+#endif // C++11
+
+#if __cplusplus >= 201703L
+  template
+CONSTEXPR typename iterator_traits::value_type
+reduce(InputIterator first, InputIterator last);
+
+  template
+CONSTEXPR T reduce(InputIterator first,

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Segher Boessenkool

On Fri, Feb 28, 2020 at 04:32:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> > On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > > testcase is just invalid?
> > 
> > Ups, that shouldn't happen. It does seem to work here
> > (x86-64-gnu-linux), however, running various compile flags including -O3
> > and -O2.
> > 
> > Regarding MIN and MAX: I think the IEEE 754 decided at some point
> > decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> > recall correctly). I think one has to check what exactly the test case
> > does and what is guaranteed where. I also do not know whether a more
> > recent IEEE 754 (754:2019) has changed something again.
> 
> Yes, that is what IEEE 754 says I believe.

Yup.

> But that is not what is provided by GCC {MIN,MAX}_EXPR or s{min,max}*
> optabs.

On the other hand, the gfortran manual says
  The Fortran standard does not specify what the result of the 'MAX' and
  'MIN' intrinsics are if one of the arguments is a 'NaN'.  Accordingly,
  the GNU Fortran compiler does not specify that either, as this allows
  for faster and more compact code to be generated.  If the programmer
  wishes to take some specific action in case one of the arguments is a
  'NaN', it is necessary to explicitly test the arguments before calling
  'MAX' or 'MIN', e.g.  with the 'IEEE_IS_NAN' function from the intrinsic
  module 'IEEE_ARITHMETIC'.

There is IEEE_MAX_NUM, maybe the testcase should use that?

Segher

Re: GCC 9 backports

2020-02-28 Thread Martin Liška


On 10/23/19 2:11 PM, Martin Liška wrote:

On 9/2/19 10:56 AM, Martin Liška wrote:

Hi.

There are 2 more patches that I've just tested.

Martin


Hi.

There are 2 more patches that I've just tested.

Martin



Hi.

There's one more patch.

Martin
>From 08bf7bde9f2987b1c623d272cc71fc14a1622442 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 28 Feb 2020 17:52:57 +0100
Subject: Backport 08bf7bde9f2987b1c623d272cc71fc14a1622442

gcc/ChangeLog:

2020-02-28  Martin Liska  

	PR other/93965
	* configure.ac: Improve detection of ld_date by requiring
	either two dashes or none.
	* configure: Regenerate.

---
diff --git a/gcc/configure b/gcc/configure
index f55cdb8c77f..5381e107bce 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -23384,7 +23384,7 @@ if test $in_tree_ld != yes ; then
   ld_vers=`echo $ld_ver | sed -n \
 	  -e 's,^.*[	 ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
 fi
-ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
+ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
 ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
 ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
 ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0e6e475950d..0d6230e0ca1 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2804,7 +2804,7 @@ if test $in_tree_ld != yes ; then
   ld_vers=`echo $ld_ver | sed -n \
 	  -e 's,^.*[	 ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
 fi
-ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
+ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
 ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
 ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
 ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
--
2.25.0

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Thomas Koenig


Am 28.02.20 um 17:58 schrieb Steve Kargl:

Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to
be a pessimization for correctly written code.


Also note the following part of changes.html for 9.2:

The MAX and MIN intrinsics are no longer guaranteed to return any
particular value in case one of the arguments is a NaN. Note that this
conforms to the Fortran standard and to what other Fortran compilers do.
If there is a need to handle that case in some specific way, one needs
to explicitly check for NaN's before calling MAX or MIN, e.g. by using
the IEEE_IS_NAN function from the intrinsic module IEEE_ARITHMETIC.

This was discussed (and decided) at the time.

Regards

Thomas

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

2020-02-28 Thread Martin Sebor


On 2/28/20 9:58 AM, Jason Merrill wrote:

On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).



+ a new entry for it and return unless it's a declaration
+ involving a template that may need to be diagnosed by
+ -Wredundant-tags.  */
   *rdl = class_decl_loc_t (class_key, false, def_p);
-  return;
+  if (TREE_CODE (decl) != TEMPLATE_DECL)
+    return;


How can the first appearance of a class template be redundant?


I'm not sure I correctly understand the question.  The comment says
"involving a template" (i.e., not one of the first declaration of
a template).  The test case that corresponds to this test is:

  template  struct S7 { };
  struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" }

where DECL is the TEPLATE_DECL of S7.

As I mentioned, more work is still needed to handle templates right
because some redundant tags are still not diagnosed.  For example:

  template  struct S7 { };
  template 
  using U = struct S7;   // missing warning

Martin

Re: [PATCH v2] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Eric Botcazou

> +1 - I think Alexey correctly pointed out in the Bugzilla that debuginfo
> growth from this change would be minimal (usually the number of global
> variables is very small compared to number of functions (and linemap info).

Well, this will drag the associated types too, so figures would be welcome...

-- 
Eric Botcazou

Re: [PATCH v3] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Alexander Monakov

Hi, 

On Fri, 28 Feb 2020, Alexey Neyman wrote:
> On 2/26/20 11:40 AM, Richard Biener wrote:
> 
> Attached is a revised patch that enables DIE generation for external variables
> at -g1 without an additional option.

I can't substantially review the patch, but there's a couple of nits that
will need fixing anyway:

This file seems to be missing from the patch:

* gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-3: New test.

Also please note that GCC coding style requires a space before a paren:

TREE_PUBLIC (decl)

Thanks.
Alexander

[PATCH v3] debug/93751 Option to generate DIEs for external variables - ping

2020-02-28 Thread Alexey Neyman


On 2/26/20 11:40 AM, Richard Biener wrote:


On February 26, 2020 8:26:06 PM GMT+01:00, Alexander Monakov 
 wrote:

On Wed, 26 Feb 2020, Jason Merrill wrote:


Don't we want to fix the DWARF behavior to match the documentation?

+1 - I think Alexey correctly pointed out in the Bugzilla that
debuginfo
growth from this change would be minimal (usually the number of global
variables is very small compared to number of functions (and linemap
info).

+1 from me as well

Richard.


Attached is a revised patch that enables DIE generation for external 
variables at -g1 without an additional option.


Regards,
Alexey.

>From eba778fd7c2489e2966c55bb8c11bdc48480fc52 Mon Sep 17 00:00:00 2001
From: Alexey Neyman 
Date: Thu, 13 Feb 2020 22:01:10 -0800
Subject: [PATCH] debug/93751 DWARF DIEs for external vars with -g1

-g1 is described in the manual to generate debug info for functions and
external variables. It does that for older debugging formats but not for
DWARF. This change brings DWARF in line with the rest of the debugging
formats and with the manual.

2020-02-14  Alexey Neyman  

PR debug/93751
* dwarf2out.c (gen_decl_die): Proceed to generating the DIE if
the debug level is terse and the declaration is public.
(dwarf2out_decl): Same.
* gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-1: New test.
* gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-2: New test.
* gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-3: New test.

Signed-off-by: Alexey Neyman 
---
 gcc/dwarf2out.c   | 12 
 gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-1.c |  6 ++
 gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-2.c |  6 ++
 3 files changed, 20 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-1.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-2.c

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index fe46c7e1eee..4d9bfe3a68b 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -26354,8 +26354,10 @@ gen_decl_die (tree decl, tree origin, struct vlr_context *ctx,
 case VAR_DECL:
 case RESULT_DECL:
   /* If we are in terse mode, don't generate any DIEs to represent any
-	 variable declarations or definitions.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+	 variable declarations or definitions unless it is external.  */
+  if (debug_info_level < DINFO_LEVEL_TERSE
+	  || (debug_info_level == DINFO_LEVEL_TERSE
+	  && !TREE_PUBLIC(decl_or_origin)))
 	break;
 
   /* Avoid generating stray type DIEs during late dwarf dumping.
@@ -26831,8 +26833,10 @@ dwarf2out_decl (tree decl)
 	context_die = lookup_decl_die (DECL_CONTEXT (decl));
 
   /* If we are in terse mode, don't generate any DIEs to represent any
-	 variable declarations or definitions.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+	 variable declarations or definitions unless it is external.  */
+  if (debug_info_level < DINFO_LEVEL_TERSE
+	  || (debug_info_level == DINFO_LEVEL_TERSE
+	  && !TREE_PUBLIC(decl)))
 	return;
   break;
 
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-1.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-1.c
new file mode 100644
index 000..4be170c57d6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-1.c
@@ -0,0 +1,6 @@
+// { dg-do compile }
+// { dg-options "-O -gdwarf-2 -g1 -dA" }
+static int bar;
+
+// Verify that with -g1 we still do not generate DIEs for static variables.
+// { dg-final { scan-assembler-not " DW_TAG_variable" } }
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-2.c
new file mode 100644
index 000..3ee369bd99e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr93751-2.c
@@ -0,0 +1,6 @@
+// { dg-do compile }
+// { dg-options "-O -gdwarf-2 -g1 -dA" }
+int foo;
+
+// Verify that with -g1 we generate DIEs for external variables.
+// { dg-final { scan-assembler " DW_TAG_variable" } }
-- 
2.20.1

Re: [PATCH] libstdc++: P1645R1 constexpr for algorithms

2020-02-28 Thread Jonathan Wakely


On 26/02/20 10:28 -0500, Patrick Palka wrote:

On Wed, 26 Feb 2020, Jonathan Wakely wrote:


On 25/02/20 15:36 -0500, Patrick Palka wrote:
> This adds constexpr to 11 algorithms defined in  as per P1645R1.
>
> Tested on x86_64-pc-linux-gnu, OK to commit?
>
> libstdc++-v3/ChangeLog:
>
>P1645R1 constexpr for  algorithms
>* include/bits/stl_numeric.h (iota, accumulate, inner_product,
>partial_sum, adjacent_difference): Make conditionally constexpr for
>C++20.
>* include/std/numeric (reduce, transform_reduce, exclusive_scan,
>inclusive_scan, transform_exclusive_scan, transform_inclusive_scan):
>Likewise.  Define the feature test macro __cpp_lib_constexpr_numeric.
>* testsuite/26_numerics/accumulate/constexpr.cc: New test.
>* testsuite/26_numerics/adjacent_difference/constexpr.cc: Likewise.
>* testsuite/26_numerics/exclusive_scan/constexpr.cc: Likewise.
>* testsuite/26_numerics/inclusive_scan/constexpr.cc: Likewise.
>* testsuite/26_numerics/inner_product/constexpr.cc: Likewise.
>* testsuite/26_numerics/iota/constexpr.cc: Likewise.
>* testsuite/26_numerics/partial_sum/constexpr.cc: Likewise.
>* testsuite/26_numerics/reduce/constexpr.cc: Likewise.
>* testsuite/26_numerics/transform_exclusive_scan/constexpr.cc:
> Likewise.
>* testsuite/26_numerics/transform_inclusive_scan/constexpr.cc:
> Likewise.
>* testsuite/26_numerics/transform_reduce/constexpr.cc: Likewise.


testsuite/26_numerics/headers/numeric/synopsis.cc is now failing when
run with -std=gnu++2a.

For testsuite/25_algorithms/headers/algorithm/synopsis.cc we just
added _GLIBCXX20_CONSTEXPR to the test as needed.

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Steve Kargl

On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > testcase is just invalid?
> 
> Ups, that shouldn't happen. It does seem to work here
> (x86-64-gnu-linux), however, running various compile flags including -O3
> and -O2.
> 
> Regarding MIN and MAX: I think the IEEE 754 decided at some point
> decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> recall correctly). I think one has to check what exactly the test case
> does and what is guaranteed where. I also do not know whether a more
> recent IEEE 754 (754:2019) has changed something again.

IEEE-754-2008 does not have MAX(), and it defines quiet and signaling
NaNs.  It does have maxNum():

  maxNum(x, y) is the canonicalized number y if x < y, x if y < x,
  the canonicalized number if one operand is a number and the other
  a quiet NaN. Otherwise it is either x or y, canonicalized (this
  means results might differ among implementations). When either x
  or y is a signalingNaN, then the result is according to 6.2.

-- 
Steve

Re: [PATCH] Improve detection of ld_date.

2020-02-28 Thread Jakub Jelinek

On Fri, Feb 28, 2020 at 05:54:56PM +0100, Martin Liška wrote:
> On 2/28/20 5:28 PM, Jakub Jelinek wrote:
> > That is not what you did (or at least you should pretend you didn't do it 
> > that
> > way).  Please write it as
> > * configure.ac: Improve ...
> > * configure: Regenerated.
> 
> Sorry, I didn't pay enough attention to the ChangeLog entry.
> 
> > 
> > Ok with that change.
> 
> Installed. Would it be fine to backport that into release
> branches?

Yes, but wait after 8.4 is released on the 8 branch.

Jakub

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

2020-02-28 Thread Jason Merrill


On 2/24/20 6:58 PM, Martin Sebor wrote:

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).



+a new entry for it and return unless it's a declaration
+involving a template that may need to be diagnosed by
+-Wredundant-tags.  */
  *rdl = class_decl_loc_t (class_key, false, def_p);
- return;
+ if (TREE_CODE (decl) != TEMPLATE_DECL)
+   return;


How can the first appearance of a class template be redundant?

Jason

Re: [PATCH 2/4] arc: Improve code gen for 64bit add/sub operations.

2020-02-28 Thread Jeff Law

On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> Early expand ADDDI3 and SUBDI3 for better code gen.
> 
> gcc/
> -xx-xx  Claudiu Zissulescu  
> 
>   * config/arc/arc.md (adddi3): Early expand the 64bit operation into
>   32bit ops.
>   (subdi3): Likewise.
>   (adddi3_i): Remove pattern.
>   (subdi3_i): Likewise.
OK
jeff
>

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Steve Kargl

On Fri, Feb 28, 2020 at 04:04:10PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 08:53:11AM -0600, Segher Boessenkool wrote:
> > On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> > > On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> > > > 
> > > > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. 
> > > > ppc64le/x86.
> > > 
> > > IMHO, using -ffast-math with Fortran code is never correct.
> > > With this option, you got exactly what you wanted.
> > 
> > It happens with -O2 already.
> > 
> > The frontend generates a MIN_EXPR (or MAX_EXPR) for this, which is
> > undefined for NaNs already.  I think the testcase is just invalid?
> 
> Or maybe just the FE shouldn't use MIN_EXPR/MAX_EXPR if NaN is allowed,
> but fmax/fmaxf/fmaxl etc. or x < y ? x : y or whatever exactly is expected
> instead to yield the right answer for NaN?
> 

If a Fortran program does not use the IEEE_ARITHMETIC
module and specifically handle +-inf and nan and that
program generates one of those values, then that program
is in "undefined behavior" territory. 

Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to
be a pessimization for correctly written code.


-- 
Steve

Re: [PATCH 3/4] arc: Use accl_operand predicate for fma instructions.

2020-02-28 Thread Jeff Law

On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> With the refurbish of ARC600' accumulator support, the mlo_operand
> doesn't reflect the proper low accumulator register for the newer
> ARCv2 accumulator register used by the fma instructions, replace
> it with accl_operand predicate.
> 
> gcc/
> -xx-xx  Claudiu Zissulescu  
> 
>   * config/arc/arc.md (fmasf4_fpu): Use accl_operand predicate.
>   (fnmasf4_fpu): Likewise.
OK
jeff
>

Re: [PATCH 1/4] arc: Add length attribute to eh_return pattern.

2020-02-28 Thread Jeff Law

On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> Add length attribute to eh_return pattern.
> 
> gcc/
> -xx-xx  Claudiu Zissulescu  
> 
>   * config/arc/arc.md (eh_return): Add length info.
OK
jeff
>

Re: [PATCH] Improve detection of ld_date.

2020-02-28 Thread Martin Liška


On 2/28/20 5:28 PM, Jakub Jelinek wrote:

That is not what you did (or at least you should pretend you didn't do it that
way).  Please write it as
* configure.ac: Improve ...
* configure: Regenerated.


Sorry, I didn't pay enough attention to the ChangeLog entry.



Ok with that change.


Installed. Would it be fine to backport that into release
branches?

Martin

Re: [PATCH] libstdc++: Also disable caching of reverse_view::begin() for common_ranges

2020-02-28 Thread Jonathan Wakely


On 28/02/20 11:34 -0500, Patrick Palka wrote:

When the underlying range models common_range, then reverse_view::begin() is
O(1) without caching.  So we should disable the cache in this case too.

libstdc++-v3/ChangeLog:

* include/std/ranges (reverse_view::_S_needs_cached_begin): Set to false
whenever the underlying range models common_range.


OK, thanks.

Re: patch to fix PR93564

2020-02-28 Thread Vladimir Makarov




On 2020-02-24 4:54 a.m., Christophe Lyon wrote:

Hi,

On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov  wrote:

The following patch is for

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

The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.



It seems this patch causes regression on some arm cores (seen on
cortex-a15 and cortex-57).
When configuring
--target arm-none-linux-gnueabihf
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8

gcc.target/arm/unaligned-memcpy-2.c: ldrd found 1 times
FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times ldrd 0
gcc.target/arm/unaligned-memcpy-2.c: strd found 2 times
FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times strd 1

This one regresses only on cortex-a15:
gcc.target/arm/unaligned-memcpy-3.c: ldrd found 2 times
FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times ldrd 1
gcc.target/arm/unaligned-memcpy-3.c: strd found 1 times
FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times strd 0


I've just submitted a patch which I hope will solve some of the failures.

One more patch for PR93564

2020-02-28 Thread Vladimir Makarov

 The following patch is dealing with arm failures after submitting 
original patch for PR93564.


  Changing heuristics in the original patch resulted in different order 
of allocation and creating gaps in hard reg file which were not enough 
for pseudos requiring double regs.  So RA started to use caller-saved 
regs and additional store/load insns in function prologue. That is the 
reason for some arm failures.


  The patch was successfully bootstrapped and benchmarked on x86-64.  
On x86-64 SPEC2000 the patch generates a bit smaller and faster in 
average code.



diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f6a9ae2375e..1451807f7d9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-02-28  Vladimir Makarov  
+
+	PR rtl-optimization/93564
+	* ira-color.c (assign_hard_reg): Prefer smaller hard regno when we
+	do not honor reg alloc order.
+
 2020-02-27  Joel Hutton  
 
 	PR target/87612
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 0ffdd192020..a2bf108c38e 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1925,7 +1925,9 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
 	}
   if (min_cost > cost)
 	min_cost = cost;
-  if (min_full_cost > full_cost)
+  if (min_full_cost > full_cost
+	  || (!HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
+	  && best_hard_regno > hard_regno))
 	{
 	  min_full_cost = full_cost;
 	  best_hard_regno = hard_regno;

Re: GLIBC libmvec status

2020-02-28 Thread GT

‐‐‐ Original Message ‐‐‐
On Thursday, February 27, 2020 4:32 PM, Bill Schmidt  
wrote:

> On 2/27/20 2:21 PM, Bill Schmidt wrote:
>
> > On 2/27/20 12:48 PM, GT wrote:
> >
> > > Done.
> > >
> > > The updated document is at:
> > > https://sourceware.org/glibc/wiki/HomePage?action=AttachFile&do=view&target=powerarchvectfuncabi.html
>
> Looks good.  Can you please also remove the 'c' ABI from the mangling, as 
> earlier agreed?
>

1. Reference to 'c' ABI deleted.
2. In final paragraph of section "Vector Function ABI Overview", removed 
reference to
ELFv2 specification. Replaced with reference to OpenPOWER IBM Power ISA v2.07.
3. Cleaned up display of angle brackets in section "Vector Function Name 
Mangling".

Question:
Do we want to change the name and title of the document since Segher doesn't 
believe it
is an ABI. My initial suggestion: "POWER Architecture Specification of Scalar 
Function
to Vector Function Mapping".

Bert.

[PATCH] libstdc++: Also disable caching of reverse_view::begin() for common_ranges

2020-02-28 Thread Patrick Palka

When the underlying range models common_range, then reverse_view::begin() is
O(1) without caching.  So we should disable the cache in this case too.

libstdc++-v3/ChangeLog:

* include/std/ranges (reverse_view::_S_needs_cached_begin): Set to false
whenever the underlying range models common_range.
---
 libstdc++-v3/include/std/ranges | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 2f773130979..19d3da950e7 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -3177,7 +3177,8 @@ namespace views
 private:
   _Vp _M_base = _Vp();
 
-  static constexpr bool _S_needs_cached_begin = !random_access_range<_Vp>;
+  static constexpr bool _S_needs_cached_begin
+   = !common_range<_Vp> && !random_access_range<_Vp>;
   [[no_unique_address]]
__detail::__maybe_empty_t<_S_needs_cached_begin,
  __detail::_CachedPosition<_Vp>> 
_M_cached_begin;
-- 
2.25.1.377.g2d2118b814

Re: GLIBC libmvec status

2020-02-28 Thread Jakub Jelinek

On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
> Do we want to change the name and title of the document since Segher doesn't 
> believe it
> is an ABI. My initial suggestion: "POWER Architecture Specification of Scalar 
> Function
> to Vector Function Mapping".

It is an ABI, similarly like e.g. the C++ Itanium ABI is an ABI, it specifies
mangling of certain functions and how the function argument types and return
types are transformed.

Jakub

Re: [PATCH] Improve detection of ld_date.

2020-02-28 Thread Jakub Jelinek

On Fri, Feb 28, 2020 at 05:15:29PM +0100, Martin Liška wrote:
> Hi.
> 
> The patch is about better ld date format detection as
> described in the PR in more detail. I'm also changing
> '[-]' into '-' which is a simplification.
> 
> Ready to be installed after tests?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-02-28  Martin Liska  
> 
>   PR other/93965
>   * configure: Improve detection of ld_date by requiring
>   either two dashes or none.
>   * configure.ac: Likewise.

That is not what you did (or at least you should pretend you didn't do it that
way).  Please write it as
* configure.ac: Improve ...
* configure: Regenerated.

Ok with that change.

> diff --git a/gcc/configure b/gcc/configure
> index f55cdb8c77f..5381e107bce 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -23384,7 +23384,7 @@ if test $in_tree_ld != yes ; then
>ld_vers=`echo $ld_ver | sed -n \
> -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
>  fi
> -ld_date=`echo $ld_ver | sed -n 
> 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
> +ld_date=`echo $ld_ver | sed -n 
> 's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
>  ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
>  ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
>  ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 0e6e475950d..0d6230e0ca1 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -2804,7 +2804,7 @@ if test $in_tree_ld != yes ; then
>ld_vers=`echo $ld_ver | sed -n \
> -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
>  fi
> -ld_date=`echo $ld_ver | sed -n 
> 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
> +ld_date=`echo $ld_ver | sed -n 
> 's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
>  ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
>  ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
>  ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
> 


Jakub

[PATCH] sccvn: Improve handling of load masked with integer constant [PR93582]

2020-02-28 Thread Jakub Jelinek

Hi!

As mentioned in the PR and discussed on IRC, the following patch is the
patch that fixes the originally reported issue.
We have there because of the premature bitfield comparison -> BIT_FIELD_REF
optimization:
  s$s4_19 = 0;
  s.s4 = s$s4_19;
  _10 = BIT_FIELD_REF ;
  _13 = _10 & 8;
and no other s fields are initialized.  If they would be all initialized with
constants, then my earlier PR93582 bitfield handling patches would handle it
already, but if at least one bit we ignore after the BIT_AND_EXPR masking
is not initialized or is initialized earlier to non-constant, we aren't able
to look through it until combine, which is too late for the warnings on the
dead code.
This patch handles BIT_AND_EXPR where the first operand is a SSA_NAME
initialized with a memory load and second operand is INTEGER_CST, by trying
a partial def lookup after pushing the ranges of 0 bits in the mask as
artificial initializers.  In the above case on little-endian, we push
offset 0 size 3 {} partial def and offset 4 size 4 (the result is unsigned
char) and then perform normal partial def handling.
My initial version of the patch failed miserably during bootstrap, because
data->finish (...) called vn_reference_lookup_or_insert_for_pieces
which I believe tried to remember the masked value rather than real for the
reference, or for failed lookup visit_reference_op_load called
vn_reference_insert.  The following version makes sure we aren't calling
either of those functions in the masked case, as we don't know anything
better about the reference from whatever has been discovered when the load
stmt has been visited, the patch just calls vn_nary_op_insert_stmt on
failure with the lhs (apparently calling it with the INTEGER_CST doesn't
work).

Bootstrapped/regtested on powerpc64{,le}-linux, I've additionally
gathered statistics of successful BIT_AND_EXPR optimizations (attached, first
column is uniq -c count, second BITS_PER_WORD, then filename, function name,
the mask on BIT_AND_EXPR and finally the value it returned).
Ok for trunk if it also passes bootstrap/regtest on x86_64-linux and
i686-linux?

2020-02-28  Jakub Jelinek  

PR tree-optimization/93582
* tree-ssa-sccvn.h (vn_reference_lookup): Add mask argument.
* tree-ssa-sccvn.c (struct vn_walk_cb_data): Add masked_p member,
initialize it in the constructor.
(vn_walk_cb_data::finish): If masked_p is true, return val instead
of calling vn_reference_lookup_or_insert_for_pieces.  Formatting fix.
(vn_reference_lookup_pieces): Adjust vn_walk_cb_data initialization.
Formatting fix.
(vn_reference_lookup): Add mask argument.  If non-NULL, don't call
fully_constant_vn_reference_p nor vn_reference_lookup_1 and
artificially push partial {} defs for the portions of the mask that
contains zeros.
(visit_nary_op): Handle BIT_AND_EXPR of a memory load and INTEGER_CST
mask.
(visit_reference_op_load): Add mask argument, pass it through
to vn_reference_lookup.  If non-NULL, don't call vn_reference_insert.
(visit_stmt): Adjust visit_reference_op_load caller.  Formatting fix.

* gcc.dg/tree-ssa/pr93582-10.c: New test.
* gcc.dg/pr93582.c: New test.
* gcc.c-torture/execute/pr93582.c: New test.

--- gcc/tree-ssa-sccvn.h.jj 2020-02-28 11:56:39.506941888 +0100
+++ gcc/tree-ssa-sccvn.h2020-02-28 12:01:42.677404902 +0100
@@ -256,7 +256,7 @@ tree vn_reference_lookup_pieces (tree, a
 vec ,
 vn_reference_t *, vn_lookup_kind);
 tree vn_reference_lookup (tree, tree, vn_lookup_kind, vn_reference_t *, bool,
- tree * = NULL);
+ tree * = NULL, tree = NULL_TREE);
 void vn_reference_lookup_call (gcall *, vn_reference_t *, vn_reference_t);
 vn_reference_t vn_reference_insert_pieces (tree, alias_set_type, tree,
   vec ,
--- gcc/tree-ssa-sccvn.c.jj 2020-02-28 11:56:39.506941888 +0100
+++ gcc/tree-ssa-sccvn.c2020-02-28 12:53:58.500459041 +0100
@@ -1686,9 +1686,9 @@ struct pd_data
 struct vn_walk_cb_data
 {
   vn_walk_cb_data (vn_reference_t vr_, tree orig_ref_, tree *last_vuse_ptr_,
-  vn_lookup_kind vn_walk_kind_, bool tbaa_p_)
+  vn_lookup_kind vn_walk_kind_, bool tbaa_p_, bool masked_p_)
 : vr (vr_), last_vuse_ptr (last_vuse_ptr_), last_vuse (NULL_TREE),
-  vn_walk_kind (vn_walk_kind_), tbaa_p (tbaa_p_),
+  vn_walk_kind (vn_walk_kind_), tbaa_p (tbaa_p_), masked_p (masked_p_),
   saved_operands (vNULL), first_set (-2), known_ranges (NULL)
{
  if (!last_vuse_ptr)
@@ -1705,6 +1705,7 @@ struct vn_walk_cb_data
   tree last_vuse;
   vn_lookup_kind vn_walk_kind;
   bool tbaa_p;
+  bool masked_p;
   vec saved_operands;
 
   /* The VDEFs of partial defs we come along.  */
@@ -1731,9 +1732,12 @@ vn_walk_cb_data::finish (alias_set_type
 {

[PATCH] Improve detection of ld_date.

2020-02-28 Thread Martin Liška


Hi.

The patch is about better ld date format detection as
described in the PR in more detail. I'm also changing
'[-]' into '-' which is a simplification.

Ready to be installed after tests?
Thanks,
Martin

gcc/ChangeLog:

2020-02-28  Martin Liska  

PR other/93965
* configure: Improve detection of ld_date by requiring
either two dashes or none.
* configure.ac: Likewise.
---
 gcc/configure| 2 +-
 gcc/configure.ac | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/gcc/configure b/gcc/configure
index f55cdb8c77f..5381e107bce 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -23384,7 +23384,7 @@ if test $in_tree_ld != yes ; then
   ld_vers=`echo $ld_ver | sed -n \
 	  -e 's,^.*[	 ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
 fi
-ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
+ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
 ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
 ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
 ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0e6e475950d..0d6230e0ca1 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2804,7 +2804,7 @@ if test $in_tree_ld != yes ; then
   ld_vers=`echo $ld_ver | sed -n \
 	  -e 's,^.*[	 ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
 fi
-ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
+ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
 ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
 ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
 ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`

Re: [PATCH] lto: Also copy .note.gnu.property section

2020-02-28 Thread H.J. Lu

On Fri, Feb 28, 2020 at 6:30 AM H.J. Lu  wrote:
>
> When generating the separate file with LTO debug sections, we should
> also copy .note.gnu.property section.
>
> OK for master if there is no regression?
>
> Thanks.
>
> H.J.
> ---
> libiberty/
>
> PR lto/93966
> * simple-object.c (handle_lto_debug_sections): Also copy
> .note.gnu.property section.
>
> gcc/
>
> PR lto/93966
> * configure.ac (HAVE_LD_CET_REPORT_SUPPORT): New.  Set to 1 if
> linker supports -z cet-report=.
> * config.in: Regenerated.
> * configure: Likewise.
>
> gcc/testsuite/
>
> PR lto/93966
> * gcc.target/i386/pr93966.c: New file.
> * lib/target-supports.exp (check_effective_target_cet_report): New.

The test will fail on non-CET enabled OS.   Here is the updated patch without
testcase.OK for master and backport to GCC 8/9 branches?

Thanks.


-- 
H.J.
From 3504e52532359db1697f741606d04fd43d852e0a Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 28 Feb 2020 06:22:18 -0800
Subject: [PATCH] lto: Also copy .note.gnu.property section

When generating the separate file with LTO debug sections, we should
also copy .note.gnu.property section.

	PR lto/93966
	* simple-object.c (handle_lto_debug_sections): Also copy
	.note.gnu.property section.
---
 libiberty/simple-object.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libiberty/simple-object.c b/libiberty/simple-object.c
index d9c648af717..e6c466ab767 100644
--- a/libiberty/simple-object.c
+++ b/libiberty/simple-object.c
@@ -293,6 +293,9 @@ handle_lto_debug_sections (const char *name, int rename)
   /* Copy over .note.GNU-stack section under the same name if present.  */
   else if (strcmp (name, ".note.GNU-stack") == 0)
 return strcpy (newname, name);
+  /* Copy over .note.gnu.property section under the same name if present.  */
+  else if (strcmp (name, ".note.gnu.property") == 0)
+return strcpy (newname, name);
   /* Copy over .comment section under the same name if present.  Solaris
  ld uses them to relax its checking of ELF gABI access rules for
  COMDAT sections in objects produced by GCC.  */
-- 
2.24.1

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Jakub Jelinek

On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > testcase is just invalid?
> 
> Ups, that shouldn't happen. It does seem to work here
> (x86-64-gnu-linux), however, running various compile flags including -O3
> and -O2.
> 
> Regarding MIN and MAX: I think the IEEE 754 decided at some point
> decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> recall correctly). I think one has to check what exactly the test case
> does and what is guaranteed where. I also do not know whether a more
> recent IEEE 754 (754:2019) has changed something again.

Yes, that is what IEEE 754 says I believe.
But that is not what is provided by GCC {MIN,MAX}_EXPR or s{min,max}*
optabs.
See https://gcc.gnu.org/ml/gcc-patches/2005-01/msg01609.html that documented
it.
So, in short, the FE shouldn't emit {MIN,MAX}_EXPR if it expects the IEEE
754 behavior and should instead emit something different, like
COND_EXPR.
If one writes in C:
double foo (double x, double y) { return x > y ? x : y; }
double bar (double x, double y) { return x >= y ? x : y; }
it is also only converted into MAX_EXPR if one uses -ffinite-math-only
-fno-signed-zeros and not otherwise.  Already fold-const.c can do that,
or e.g. phiopt pass.

Jakub

Re: [PATCH] c++: Further tweak for P1937R2 - const{expr,eval} inconsistencies

2020-02-28 Thread Jason Merrill


On 2/28/20 3:23 AM, Jakub Jelinek wrote:

Hi!

Seems I've missed one thing, as the first hunk in
https://github.com/cplusplus/draft/commit/c8e68ed202b4a9260616bcee8a9768b5dca4bbca
changes the wording so that only potentially-evaluated id-expressions that
denote immediate functions must appear only in the specified contexts.
That IMO means that in unevaluated contexts there aren't such restrictions
anymore, so I think in unevaluated contexts one should be able to take the
address of an immediate function.

The following patch implements it, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?


OK.


2020-02-28  Jakub Jelinek  

P1937R2 - Fixing inconsistencies between const{expr,eval} functions
* typeck.c (cp_build_addr_expr_1): Allow taking address of immediate
functions in unevaluated contexts.

* g++.dg/cpp2a/consteval3.C: Change dg-error about taking address of
immediate function in unevaluated contexts into dg-bogus.
* g++.dg/cpp2a/consteval16.C: New test.

--- gcc/cp/typeck.c.jj  2020-02-27 09:28:46.328957157 +0100
+++ gcc/cp/typeck.c 2020-02-27 12:51:35.798841665 +0100
@@ -6325,6 +6325,7 @@ cp_build_addr_expr_1 (tree arg, bool str
tree stripped_arg = tree_strip_any_location_wrapper (arg);
if (TREE_CODE (stripped_arg) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (stripped_arg)
+ && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl)))
{
--- gcc/testsuite/g++.dg/cpp2a/consteval3.C.jj  2020-02-24 15:24:33.792751698 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval3.C 2020-02-27 12:55:19.271507525 
+0100
@@ -31,8 +31,8 @@ consteval consteval int f11 () { return
  struct U { consteval ~U () {} };  // { dg-error "a destructor cannot be 
'consteval'" }
  struct V { consteval int v = 5; };// { dg-error "non-static data member 'v' 
declared 'consteval'" }
  struct W { consteval static int w; }; // { dg-error "static data member 'w' 
declared 'consteval'" }
-int i = sizeof (&f6);  // { dg-error "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
-using j = decltype (&f6);  // { dg-error "taking address of an immediate 
function 'consteval int f6\\(int\\)'" }
+int i = sizeof (&f6);  // { dg-bogus "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
+using j = decltype (&f6);  // { dg-bogus "taking address of an immediate 
function 'consteval int f6\\(int\\)'" }
  int k = sizeof (f6 (d));  // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
  using l = decltype (f6 (d));  // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
  bool m = noexcept (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
--- gcc/testsuite/g++.dg/cpp2a/consteval16.C.jj 2020-02-27 12:55:25.414415871 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval16.C2020-02-27 12:56:55.891065989 
+0100
@@ -0,0 +1,7 @@
+// { dg-do compile }
+// { dg-options "-std=c++2a" }
+
+consteval int foo () { return 0; }
+int bar (int (*) ());
+auto sz = sizeof (bar (foo));  // { dg-bogus "taking address of an immediate 
function" }
+decltype (bar (foo)) baz;  // { dg-bogus "taking address of an immediate 
function" }

Jakub

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Tobias Burnus


On 2/28/20 3:53 PM, Segher Boessenkool wrote:

It happens with -O2 already. The frontend generates a MIN_EXPR (or
MAX_EXPR) for this, which is undefined for NaNs already. I think the
testcase is just invalid?


Ups, that shouldn't happen. It does seem to work here
(x86-64-gnu-linux), however, running various compile flags including -O3
and -O2.

Regarding MIN and MAX: I think the IEEE 754 decided at some point
decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
recall correctly). I think one has to check what exactly the test case
does and what is guaranteed where. I also do not know whether a more
recent IEEE 754 (754:2019) has changed something again.

The Fortran standard by itself does not know about NaN; however, things
do change if an intrinsic IEEE_* module is loaded – I don't quickly
which one needs to be loaded and which part has to be checked there.

I think in terms of NaN/INF and MAX/MIN, the normal MAX/MIN remain the
same (nothing said about nonnormal numbers except 0), but IEEE_MAX_NUM
does take care of the IEEE 754 semantic.

Tobias

PS: I currently do not have the time dig into this; maybe on Monday or
at the weekend.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Jakub Jelinek

On Fri, Feb 28, 2020 at 08:53:11AM -0600, Segher Boessenkool wrote:
> On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> > On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> > > 
> > > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. 
> > > ppc64le/x86.
> > 
> > IMHO, using -ffast-math with Fortran code is never correct.
> > With this option, you got exactly what you wanted.
> 
> It happens with -O2 already.
> 
> The frontend generates a MIN_EXPR (or MAX_EXPR) for this, which is
> undefined for NaNs already.  I think the testcase is just invalid?

Or maybe just the FE shouldn't use MIN_EXPR/MAX_EXPR if NaN is allowed,
but fmax/fmaxf/fmaxl etc. or x < y ? x : y or whatever exactly is expected
instead to yield the right answer for NaN?

Jakub

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Segher Boessenkool

Hi Tobias,

On Fri, Feb 28, 2020 at 10:58:36AM +0100, Tobias Burnus wrote:
> (Do you really need to post to gcc@, fortran@ and gcc-patches@?
> Shouldn't be one of the list sufficient – like fortran@?)

Many people do not read that list.  I asked Jiu Fu to post to both
fortran@ and one of gcc@ and gcc-patches@, but I wasn't clear enough I
guess.  Sorry :-)

https://gcc.gnu.org/lists.html says
  fortran is the main discussion and development list for the Fortran
  language front end of GCC, and the corresponding runtime library.
  Patches to gfortran and libgfortran should go to both this list and
  gcc-patches.

Segher

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Segher Boessenkool

On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> > 
> > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. 
> > ppc64le/x86.
> 
> IMHO, using -ffast-math with Fortran code is never correct.
> With this option, you got exactly what you wanted.

It happens with -O2 already.

The frontend generates a MIN_EXPR (or MAX_EXPR) for this, which is
undefined for NaNs already.  I think the testcase is just invalid?

Segher

[PATCH] lto: Also copy .note.gnu.property section

2020-02-28 Thread H.J. Lu

When generating the separate file with LTO debug sections, we should
also copy .note.gnu.property section.

OK for master if there is no regression?

Thanks.

H.J.
---
libiberty/

PR lto/93966
* simple-object.c (handle_lto_debug_sections): Also copy
.note.gnu.property section.

gcc/

PR lto/93966
* configure.ac (HAVE_LD_CET_REPORT_SUPPORT): New.  Set to 1 if
linker supports -z cet-report=.
* config.in: Regenerated.
* configure: Likewise.

gcc/testsuite/

PR lto/93966
* gcc.target/i386/pr93966.c: New file.
* lib/target-supports.exp (check_effective_target_cet_report): New.
---
 gcc/config.in   |  6 
 gcc/configure   | 24 +
 gcc/configure.ac| 20 +++
 gcc/testsuite/gcc.target/i386/pr93966.c | 10 ++
 gcc/testsuite/lib/target-supports.exp   | 47 +
 libiberty/simple-object.c   |  3 ++
 6 files changed, 110 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr93966.c

diff --git a/gcc/config.in b/gcc/config.in
index 01fb18dbbb5..288f4ad509d 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1500,6 +1500,12 @@
 #endif
 
 
+/* Define if your linker supports -z cet-report=. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_LD_CET_REPORT_SUPPORT
+#endif
+
+
 /* Define if the linker supports clearing hardware capabilities via mapfile.
*/
 #ifndef USED_FOR_TARGET
diff --git a/gcc/configure b/gcc/configure
index f55cdb8c77f..c132887083e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30714,6 +30714,30 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ld_bndplt_support" >&5
 $as_echo "$ld_bndplt_support" >&6; }
 
+# Check linker supports '-z cet-report='.
+ld_cet_report_support=no
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker -z cet-report= 
option" >&5
+$as_echo_n "checking linker -z cet-report= option... " >&6; }
+if test x"$ld_is_gold" = xno; then
+  if test $in_tree_ld = yes ; then
+if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 33 -o "$gcc_cv_gld_major_version" -gt 2; then
+  ld_cet_report_support=yes
+fi
+  elif test x$gcc_cv_ld != x; then
+# Check if linker supports -a cet-report= option
+if $gcc_cv_ld --help 2>&1 | grep -- '-z cet-report=' > /dev/null; then
+  ld_cet_report_support=yes
+fi
+  fi
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_LD_CET_REPORT_SUPPORT `if test x"$ld_cet_report_support" = xyes; 
then echo 1; else echo 0; fi`
+_ACEOF
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ld_cet_report_support" >&5
+$as_echo "$ld_cet_report_support" >&6; }
+
 # Check linker supports '--push-state'/'--pop-state'
 ld_pushpopstate_support=no
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking linker 
--push-state/--pop-state options" >&5
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0e6e475950d..b1bff5064ca 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -6838,6 +6838,26 @@ if test x"$ld_bndplt_support" = xyes; then
 fi
 AC_MSG_RESULT($ld_bndplt_support)
 
+# Check linker supports '-z cet-report='.
+ld_cet_report_support=no
+AC_MSG_CHECKING(linker -z cet-report= option)
+if test x"$ld_is_gold" = xno; then
+  if test $in_tree_ld = yes ; then
+if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 33 -o "$gcc_cv_gld_major_version" -gt 2; then
+  ld_cet_report_support=yes
+fi
+  elif test x$gcc_cv_ld != x; then
+# Check if linker supports -a cet-report= option
+if $gcc_cv_ld --help 2>&1 | grep -- '-z cet-report=' > /dev/null; then
+  ld_cet_report_support=yes
+fi
+  fi
+fi
+AC_DEFINE_UNQUOTED(HAVE_LD_CET_REPORT_SUPPORT,
+  [`if test x"$ld_cet_report_support" = xyes; then echo 1; else echo 0; fi`],
+  [Define if your linker supports -z cet-report=.])
+AC_MSG_RESULT($ld_cet_report_support)
+
 # Check linker supports '--push-state'/'--pop-state'
 ld_pushpopstate_support=no
 AC_MSG_CHECKING(linker --push-state/--pop-state options)
diff --git a/gcc/testsuite/gcc.target/i386/pr93966.c 
b/gcc/testsuite/gcc.target/i386/pr93966.c
new file mode 100644
index 000..05ac88acf8a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr93966.c
@@ -0,0 +1,10 @@
+/* { dg-do run { target cet } } */
+/* { dg-require-effective-target lto } */
+/* { dg-require-effective-target cet_report } */
+/* { dg-options "-flto -fcf-protection -g -Wl,-z,cet-report=error" } */
+
+int
+main ()
+{
+  return 0;
+}
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ca3895c2269..9847e224ed6 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9477,6 +9477,53 @@ proc check_effective_target_tls_get_addr_via_got { } {
 }]
 }
 
+# Return 1 if the x86 linker supports -z cet-report=, 0 otherwise.
+# Cache the result.
+
+proc check_effective_target_cet_report { } {
+global tool
+

Re: [PATCH] libstdc++: Memoize {drop,drop_while,filter,reverse}_view::begin

2020-02-28 Thread Jonathan Wakely

On 27/02/20 14:26 -0500, Patrick Palka wrote:

On Wed, 26 Feb 2020, Patrick Palka wrote:

On Tue, 11 Feb 2020, Patrick Palka wrote:

> This patch adds memoization for these four views so that their begin() has the
> required constant time amortized complexity.
>
> In the general case we use std::optional to cache the result.  When the
> underlying range is a random_access_range then we store the cache as an offset
> from the beginning of the range, which should be more compact.  And when the
> underlying iterator is not copyable, then we completely disable the cache.
>
> Using std::optional in the cache is not ideal though because it means that the
> cache can't be utilized during constexpr evaluation.  If instead of
> std::optional we store a separate flag to denote an empty cache then we'll be
> able to use the cache during constexpr evaluation at the cost of a extra byte 
or
> so.  I am not sure which design to settle on.

Here's v2 of this patch which uses the new helper
__detail::__maybe_empty_t and provides a more descriptive commit
message.  It also refines the constraints on the partial specializations
of _CachedPosition.

-- >8 --

Here's v3 of this patch which takes advantage of the fact that
value-initialized forward iterators can be compared to.  This means we
can cache the bare iterator instead of having to use std::optional or
needing an external flag denoting the empty state of the cache, which is
both optimal space-wise and constexpr safe!

Nice. OK for master, thanks.

Re: [PATCH] Limit includes in hashtable_policy.h

2020-02-28 Thread Jonathan Wakely


On 27/02/20 19:30 +0100, François Dumont wrote:
When I use std::is_permutation in hashtable_policy.h I included 
stl_algo.h which is a large header. No other header in include/bits 
does this, I would prefer not being the first to do such a thing.


As it is a recent change I prefer to submit this patch now.

Git commit message:

    libstdc++ Hashtable: Move std::is_permutation to limit includes

    * include/bits/stl_algo.h (__find_if, __count_if, 
std::is_permutation): Move...

    * include/bits/stl_algobase.h: ...here.
    * include/bits/hashtable_policy.h: Remove  include.

testsuite/23_containers/unordered* tested under Linux x86_64, I'll run 
full before any commit.


Ok to commit now ?

Ok to commit once back in stage 1 ?


I was already thinking of doing something like this in stage 1. But
you're right that this is a recent regression on master. Before
 got added the preprocessed size of 
had got much smaller due to  no longer including .
But including  made it almost the same size as in
gcc-9 again.

With your patch we remove 7kloc from  again.

OK for master now, thanks.

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

2020-02-28 Thread H.J. Lu

On Fri, Feb 28, 2020 at 5:44 AM Maciej W. Rozycki  wrote:
>
> On Fri, 28 Feb 2020, H.J. Lu wrote:
>
> > > libffi/
> > > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > > files.
> > > * configure: Regenerate.
> > > * testsuite/libffi-site-extra.exp.in: New file.
> > > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> > > variable.
> > > * testsuite/Makefile.in: Regenerate.
> > > * testsuite/lib/libffi.exp (libffi-init): Handle GCC_UNDER_TEST.
> > > (libffi_target_compile): Likewise.
> >
> > Upstream libffi has local.exp.  Is that possible to use the same file?
>
>  Thanks for the suggestion; I didn't realise we are so out of date WRT the
> upstream version.
>
>  I find the way local.exp has been wired in rather hackish as it makes the
> template buried in `configure.ac' and also it requires running `autoconf'
> whenever there is a need to change it.
>
>  However that hack has been actually made to address this very problem
> discussed with this submission, so why not simply sync our copy of libffi
> with the upstream version?  Then we can decide if changing the hack into
> something cleaner is worth the hassle.

I'd love to sync with upstream libffi.  In fact, I have done it on my
users/hjl/cet/master
branch:

https://gitlab.com/x86-gcc/gcc/-/commit/9090e840b8464ce0f684e305eb75ff4655d05deb


-- 
H.J.

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

2020-02-28 Thread Maciej W. Rozycki

On Fri, 28 Feb 2020, H.J. Lu wrote:

> > libffi/
> > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > files.
> > * configure: Regenerate.
> > * testsuite/libffi-site-extra.exp.in: New file.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> > variable.
> > * testsuite/Makefile.in: Regenerate.
> > * testsuite/lib/libffi.exp (libffi-init): Handle GCC_UNDER_TEST.
> > (libffi_target_compile): Likewise.
> 
> Upstream libffi has local.exp.  Is that possible to use the same file?

 Thanks for the suggestion; I didn't realise we are so out of date WRT the 
upstream version.

 I find the way local.exp has been wired in rather hackish as it makes the 
template buried in `configure.ac' and also it requires running `autoconf' 
whenever there is a need to change it.

 However that hack has been actually made to address this very problem 
discussed with this submission, so why not simply sync our copy of libffi 
with the upstream version?  Then we can decide if changing the hack into 
something cleaner is worth the hassle.

  Maciej

Re: [PATCH] libstdc++: Fix FS-dependent filesystem tests

2020-02-28 Thread Jonathan Wakely


On 28/02/20 13:25 +, Jonathan Wakely wrote:

These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.

Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.

This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.

* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.

Tested powerpc64le-linux and x86_64-linux, on ext4 and XFS.


Huh. I've just noticed that the powerpc64le machine (gcc112) also has
XFS, but on that system I can set (and read back) times past the
epochalypse. Here's a file on that host:

-rw-rw-r--. 1 jwakely jwakely 0 9223372036854775806 
filesystem-test.bPba4m-last_write_time

Which matches what I get on my machine's tmpfs partition:

-rw-rw-r--. 1 jwakely jwakely 0 9223372036854775806 
/tmp/filesystem-test.R6DKwt-last_write_time

But on my machine's XFS partition the same timestamp gets silently
truncated:

-rw-rw-r--. 1 jwakely jwakely 0 Jan 19  2038 
testsuite/filesystem-test.r8FeLP-last_write_time

I don't know how the XFS disk on gcc112 can store 64-bit time stamps
when XFS doesn't support them. Odd.

Anyway, the patch is committed and I no longer see failures on my XFS
disks.

[PATCH] libstdc++: Fix FS-dependent filesystem tests

2020-02-28 Thread Jonathan Wakely

These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.

Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.

This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.

* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.

Tested powerpc64le-linux and x86_64-linux, on ext4 and XFS.

commit a51a546c1704cd572c35c11e539568c04d99e7d1
Author: Jonathan Wakely 
Date:   Thu Feb 27 16:38:00 2020 +

libstdc++: Fix FS-dependent filesystem tests

These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.

Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.

This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.

* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes 
for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.

diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
index a6be926143c..2bba02f6899 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
@@ -32,9 +32,12 @@
 #if _GLIBCXX_HAVE_UTIME_H
 # include 
 #endif
+#include 
 
 using time_type = std::filesystem::file_time_type;
 
+namespace chrono = std::chrono;
+
 void
 test01()
 {
@@ -67,10 +70,15 @@ test01()
 
   auto end_of_time = time_type::duration::max();
   auto last_second
-= std::chrono::duration_cast(end_of_time).count();
+= chrono::duration_cast(end_of_time).count();
   if (last_second > std::numeric_limits::max())
-return; // can't test overflow
+  {
+puts("Range of time_t is smaller than range of chrono::file_clock, "
+"can't test for overflow on this target.");
+return;
+  }
 
+  // Set mtime to a date past the maximum possible file_time_type:
 #if _GLIBCXX_USE_UTIMENSAT
   struct ::timespec ts[2];
   ts[0].tv_sec = 0;
@@ -84,25 +92,34 @@ test01()
   times.actime = std::numeric_limits::max() - 1;
   VERIFY( !::utime(p.string().c_str(), ×) );
 #else
+  puts("No utimensat or utime, giving up.");
   return;
 #endif
 
+  // Try to read back the impossibly-large mtime:
   mtime = last_write_time(p, ec);
-  VERIFY( ec );
-  VERIFY( ec == std::make_error_code(std::errc::value_too_large) );
-  VERIFY( mtime == time_type::min() );
+  // Some filesystems (e.g. XFS) silently truncate distant times to
+  // the time_t epochalypse, Jan 19 2038, so we won't get an error when
+  // reading it back:
+  if (ec)
+  {
+VERIFY( ec == std::make_error_code(std::errc::value_too_large) );
+VERIFY( mtime == time_type::min() );
+  }
+  else
+puts("No overflow error, filesystem may not support 64-bit time_t.");
 
 #if __cpp_exceptions
-  caught = false;
+  // Once more, with exceptions:
   try {
-mtime = last_write_time(p);
-  } catch (std::system_error const& e) {
-caught = true;
-ec = e.code();
+auto mtime2 = last_write_time(p);
+// If it didn't throw, expect to have read back the same value:
+VERIFY( mtime2 == mtime );
+  } catch (std::filesystem::filesystem_error const& e) {
+// If it did throw, expect the error_code to be the same:
+VERIFY( e.code() == ec );
+VERIFY( e.path1() == p );
   }
-  VERIFY( caught );
-  VERIFY( ec );
-  VERIFY( ec == std::make_error_code(std::errc::value_too_large) );
 #endif
 }
 
@@ -111,7 +128,7 @@ bool approx_equal(time_type file_time, time_type expected)
   auto delta = expected - file_time;
   if (delta < delta.zero())
 delta = -delta;
-  return delta < std::chrono::seconds(1);
+  return delta < chrono::seconds(1);
 }
 
 void
@@ -124,20 +141,20 @@ test02()
   std::error_code ec;
   time_type time;
 
+  ec = bad_ec;
   time = last_write_time(f.path);
-  ec = bad_ec;
   last_write_time(f.path, time, ec);
   VERIFY( !ec );
   VERIFY( approx_equal(last_write_time(f.path), time) );
 
   ec = bad_ec;
-  time -= std::chrono::milliseconds(1000 * 60 * 10 + 15);
+  time -= chrono::milliseconds(1000 * 60 * 10 + 15);
   last_write_time(f.path, time, ec);
   VERIFY( !ec );
   VERIFY( approx_equal(last_w

Re: -Wstringop-overflow warning in std::string

2020-02-28 Thread Jonathan Wakely


On 27/02/20 14:43 -0700, Martin Sebor wrote:

Should I just add -Wno-stringop-overflow to the testcase, or would it
be worth doing something like this to inform the compiler?


I'm not sure.  Since the ctor is undefined when passed a size in
excess of the argument size the warning might be useful even if
the library handles it.  But then again, since the library handles
it (at least in a subset of cases) it's not necessarily undefined.


Well, the library refuses to create a string of that size, but even
calling that constructor with those arguments is still undefined
because it violates the precondition that [str,str+n) is a valid
range.

So I think getting a warning from the compiler telling you that you're
doing something very wrong is useful. Just not in the context of this
test, because we know we're doing something dumb, that's part of the
test.


For what it's worth, when I wrote the library we grappled with
this question and ended up deciding that providing well-defined
semantics for undefined behavior wasn't as helpful as it seemed
at first unless we could do it reliably.


Yes, I think I'll just disable the warning in the testcase. Thanks for
your input.

The attached patch has been committed to master.

commit 86e2dc22c91a722d2624c0010d81f1ce4b911bbd
Author: Jonathan Wakely 
Date:   Thu Feb 27 17:22:50 2020 +

libstdc++: Fix failing test in debug mode

This fixes a failure due to a (correct) warning seen when testing with
-D_GLIBCXX_USE_CXX11_ABI=0 -D_GLIBCXX_ASSERTIONS:

include/bits/char_traits.h:365: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

FAIL: 21_strings/basic_string/cons/char/1.cc (test for excess errors)

* testsuite/21_strings/basic_string/cons/char/1.cc: Disable
-Wstringop-overflow warnings.

diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
index 66054588273..1c3e43f2fd4 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
@@ -19,6 +19,8 @@
 
 // 21.3.1 basic_string constructors.
 
+// { dg-options "-Wno-stringop-overflow" }
+
 #include 
 #include 
 #include

Re: [PATCH], PR target/93937, Fix variable vec_extract insn that will never match

2020-02-28 Thread Segher Boessenkool

Hi!

On Fri, Feb 28, 2020 at 12:32:06AM -0500, Michael Meissner wrote:
> As part of my work in adding support for -mcpu=future, I noticed an insn that
> would never match.

> It will never match, because the zero_extend result is the same mode as the
> input, so the machine independent parts of the compiler would never insert the
> zero extend.

It's not valid RTL, even:
  @findex zero_extend
  @item (zero_extend:@var{m} @var{x})
  Represents the result of zero-extending the value @var{x}
  to machine mode @var{m}.  @var{m} must be a fixed-point mode
  and @var{x} a fixed-point value of a mode narrower than @var{m}.

> There is a wider issue to optimize all cases of vec_extract to do the sign,
> zero, and float extension automatically when we are loading from memory, which
> is PR target/93230.  I have patches for all of the cases for 93230, but they
> will need to wait until GCC 11 opens up.

If you don't use reload_completed in the split condition you do not have
this problem (in the normal case).  Please work on that?

> But it irks me to have this pattern that mostly was correct, but it would 
> never
> match.  As I see it, there are 4 options:
> 
> 1) Delete the insn completely, since it doesn't match, and then put in code
> later to cover the case when PR target/93230 is done.

Such a patch is pre-approved.

> 3) Patch the existing insns so that they do match, but don't add all of the
> other options that could be added (adding sign extension, adding the ability 
> to
> load the value into vector registers with ISA 2.07, optimizing vec_extract
> being cnverted to floating point to avoid direct moves, etc.).
> 
> 4) Do all of the possibilities now.  The trouble is due to the number of
> special cases, this can add up to a number of new insns (for example, dealing
> with HImode/QImode also being zero extended to SImode in addition to DImode,
> dealing with QImode not having a sign extending load, dealing with SImode that
> can load into the vector registers at ISA 2.05/2.06 which HI/QI modes need
> 2.07, etc.).
> 
> Given we are in stage 4, I think #4 is not appropriate (but if you want, I can
> do the patches).

That goes for option 3 as well.

Thanks,


Segher

[Patch, fortran] PR fortran/93963 Select rank mishandling allocatable and pointer arguments with bind(c)

2020-02-28 Thread José Rui Faustino de Sousa


Hi all!

Proposed patch to Bug 93963 - Select rank mishandling allocatable and 
pointer arguments with bind(c).


Patch tested only on x86_64-pc-linux-gnu.

cfi_desc_to_gfc_desc, in ISO_Fortran_binding.c, will likely store -1 (or 
garbage) in the upper bound of the descriptor for unallocated, or 
unassociated, allocatable, or pointer, arrays effectively marking them 
as assumed size arrays.


gfc_trans_select_rank_cases, in trans-stmt.c, will check the upper bound 
of arguments in order to check for assumed size arrays even if the array 
is a pointer or an allocatable.


Thank you very much.

Best regards,
José Rui

2020-2-27  José Rui Faustino de Sousa  

 PR fortran/93963
 * trans-stmt.c (gfc_trans_select_rank_cases): Add if conditional
 short circuiting the evaluation of rank for allocatable and pointer
 arguments.

 PR fortran/93963
 * ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Add if conditional
 guarding the calculation of dimensional bounds if the data pointer
 is NULL.

2020-2-28  José Rui Faustino de Sousa  

 PR fortran/93963
 * PR93963.f90: New test.


diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 4e9b5ad..6a39bda 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -3641,12 +3641,11 @@ gfc_trans_select_rank_cases (gfc_code * code)
   tree low;
   tree sexpr;
   tree rank;
-  tree rank_minus_one;
-  tree minus_one;
   gfc_se se;
   gfc_se cse;
   stmtblock_t block;
   stmtblock_t body;
+  symbol_attribute attr;
   bool def = false;

   gfc_start_block (&block);
@@ -3655,25 +3654,35 @@ gfc_trans_select_rank_cases (gfc_code * code)
   gfc_init_se (&se, NULL);
   gfc_conv_expr_descriptor (&se, code->expr1);
   rank = gfc_conv_descriptor_rank (se.expr);
-  rank = gfc_evaluate_now (rank, &block);
-  minus_one = build_int_cst (TREE_TYPE (rank), -1);
-  tmp = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_array_index_type,
-fold_convert (gfc_array_index_type, rank),
-build_int_cst (gfc_array_index_type, 1));
-  rank_minus_one = gfc_evaluate_now (tmp, &block);
-  tmp = gfc_conv_descriptor_ubound_get (se.expr, rank_minus_one);
-  cond = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
- tmp, build_int_cst (TREE_TYPE (tmp), -1));
-  tmp = fold_build3_loc (input_location, COND_EXPR,
-TREE_TYPE (rank), cond,
-rank, minus_one);
-  cond = fold_build2_loc (input_location, EQ_EXPR, logical_type_node,
- rank, build_int_cst (TREE_TYPE (rank), 0));
-  sexpr = fold_build3_loc (input_location, COND_EXPR,
-  TREE_TYPE (rank), cond,
-  rank, tmp);
-  sexpr = gfc_evaluate_now (sexpr, &block);
+  attr = gfc_expr_attr (code->expr1);
+  if (attr.pointer || attr.allocatable)
+sexpr = gfc_evaluate_now (rank, &block);
+  else
+{
+  tree rank_minus_one;
+  tree minus_one;
+
+  rank = gfc_evaluate_now (rank, &block);
+  minus_one = build_int_cst (TREE_TYPE (rank), -1);
+  tmp = fold_build2_loc (input_location, MINUS_EXPR,
+gfc_array_index_type,
+fold_convert (gfc_array_index_type, rank),
+build_int_cst (gfc_array_index_type, 1));
+  rank_minus_one = gfc_evaluate_now (tmp, &block);
+  tmp = gfc_conv_descriptor_ubound_get (se.expr, rank_minus_one);
+  cond = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
+ tmp, build_int_cst (TREE_TYPE (tmp), -1));
+  tmp = fold_build3_loc (input_location, COND_EXPR,
+TREE_TYPE (rank), cond,
+rank, minus_one);
+  cond = fold_build2_loc (input_location, EQ_EXPR, logical_type_node,
+ rank, build_int_cst (TREE_TYPE (rank), 0));
+  sexpr = fold_build3_loc (input_location, COND_EXPR,
+  TREE_TYPE (rank), cond,
+  rank, tmp);
+  sexpr = gfc_evaluate_now (sexpr, &block);
+}
+
   TREE_USED (code->exit_label) = 0;

 repeat:
diff --git a/gcc/testsuite/gfortran.dg/PR93963.f90 
b/gcc/testsuite/gfortran.dg/PR93963.f90

new file mode 100644
index 000..15ab59a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR93963.f90
@@ -0,0 +1,146 @@
+! { dg-do run }
+!
+! PR fortran/93963
+!
+
+function rank_p(this) result(rnk) bind(c)
+  use, intrinsic :: iso_c_binding, only: c_int
+
+  implicit none
+
+  integer(kind=c_int), pointer, intent(in) :: this(..)
+  integer(kind=c_int)  :: rnk
+
+  select rank(this)
+  rank(0)
+rnk = 0
+  rank(1)
+rnk = 1
+  rank(2)
+rnk = 2
+  rank(3)
+rnk = 3
+  rank(4)
+rnk = 4
+  rank(5)
+rnk = 5
+  rank(6)
+rnk = 6
+  rank(7)
+rnk = 7
+  rank(8)
+rnk = 8
+  rank(9)
+rnk = 9
+  rank(10)
+rnk = 10
+  rank(11)
+rnk = 11
+  rank(12

[Patch, fortran] PR92785 - expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

2020-02-28 Thread Paul Richard Thomas

I will commit this tonight as 'obvious' unless there are any
complaints. This descriptor renormalisation is already present in
gfc_conv_derived_to_class.

Paul

2020-02-28  Paul Thomas  

PR fortran/92785
* trans-expr.c (gfc_conv_intrinsic_to_class): Renormalise non-
variable expressions to be unity lbound based.

2020-02-28  Paul Thomas  

PR fortran/92785
* gfortran.dg/unlimited_polymorphic_31.f03 : New test.

Re: [PATCH], PR target/93932, GCC 9 backport, Do not use input_operand for variable vector extract insns on PowerPC

2020-02-28 Thread Segher Boessenkool

On Thu, Feb 27, 2020 at 06:53:10PM -0500, Michael Meissner wrote:
> On Thu, Feb 27, 2020 at 04:57:28PM -0600, Segher Boessenkool wrote:
> > On Thu, Feb 27, 2020 at 03:38:54PM -0500, Michael Meissner wrote:
> > > Here are the equivalent changes for PR target/93932 for the GCC 9 branch. 
> > >  I
> > > have built both big and little endian PowerPC linux compilers and both
> > > bootstrapped.  The make check actually fixes the tests that were broken 
> > > by the
> > > register allocation behavior.  Can I check these patches into GCC 9?
> > 
> > So what is different in this backport?
> > 
> > Either way, it needs some soaking time first.  This patch is not much
> > safer than average.
> 
> Fair enough.
> 
> The difference is GCC 9 has all of the old constraints that were eliminated in
> the current master branch.
> 
> I.e. the first patch for the current master, uses "wa" for the second
> constraint, while GCC 9 used "" (which in GCC 9 expanded to "wa" in both
> cases).

Ah okay.  Thanks.

Okay for the 9 branch some time next week, then.  Monday perhaps, so
that it gets some exposure before the RC?


Segher

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

2020-02-28 Thread H.J. Lu

On Thu, Feb 27, 2020 at 5:18 PM Maciej W. Rozycki  wrote:
>
> Fix a problem with the libffi testsuite using a method to determine the
> compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> inability to actually choose any compiler at all in a cross-compilation
> configuration.
>
> Address this problem by providing a DejaGNU configuration file defining
> the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC
> by autoconf, which will have all the required options set for the target
> compiler to build executables in the environment configured, removing
> failures like:
>
> FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess 
> errors)
> Excess errors:
> default_target_compile: No compiler to compile with
> UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation 
> failed to produce executable
>
> and bringing overall test results for the `riscv64-linux-gnu' target
> (here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user
> emulation mode as the target board) from:
>
> === libffi Summary ===
>
> # of unexpected failures708
> # of unresolved testcases   708
> # of unsupported tests  30
>
> to:
>
> === libffi Summary ===
>
> # of expected passes1934
> # of unsupported tests  28
>
> Also respect the TOOL_EXECUTABLE TCL variable for a standalone run via
> `runtest' and remove an unused TOOL_OPTIONS TCL variable instance.
>
> libffi/
> * configure.ac: Add testsuite/libffi-site-extra.exp to output
> files.
> * configure: Regenerate.
> * testsuite/libffi-site-extra.exp.in: New file.
> * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> variable.
> * testsuite/Makefile.in: Regenerate.
> * testsuite/lib/libffi.exp (libffi-init): Handle GCC_UNDER_TEST.
> (libffi_target_compile): Likewise.

Upstream libffi has local.exp.  Is that possible to use the same file?


-- 
H.J.

[PATCH] MAINTAINERS (Write After Approval): Add myself

2020-02-28 Thread Joel

Add myself to MAINTAINERS file.

2020-02-28  Joel Hutton  

* MAINTAINERS (Write After Approval) : Add myself.
>From c0671c0d82c6858a90ab4abc62cdb302646f2d51 Mon Sep 17 00:00:00 2001
From: Joel Hutton 
Date: Fri, 28 Feb 2020 11:06:05 +
Subject: [PATCH] Add myself to MAINTAINERS

2020-02-28  Joel Hutton  

	* MAINTAINERS (Write After Approval) : Add myself.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 89e443b3d5758503ae6892acf14bd628afee4f36..5e0ce37b6c511a6abfe0ff36dee0929f7d43e8be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -429,6 +429,7 @@ Falk Hueffner	
 Andrew John Hughes
 Dominique d'Humieres
 Andy Hutchinson	
+Joel Hutton	
 Lewis Hyatt	
 Naveen H.S	
 Roland Illig	
-- 
2.17.1

Re: maxval on -inf and nan in Fortran

2020-02-28 Thread Tobias Burnus


Hi,

(Do you really need to post to gcc@, fortran@ and gcc-patches@?
Shouldn't be one of the list sufficient – like fortran@?)

On 2/28/20 6:02 AM, Jiufu Guo wrote:


When I check a PR93709, I find the testcase maxlocval_4.f90  […]
With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g. ppc64le/x86.

To my knowledge, this test case is never be run with -ffast-math;
for sure, it is not run with that option on my x86-64-gnu-linux system.
Given that it uses NaN and INF, it is also not suitable for -ffast-math
(cf. below) – and probably no one has tested or intended to run it with
-ffast-math.

Thus, it is not that unexpected that it fails with -ffast-math. As it
does what it is supposed to do with -O3 and no -ffast-math.

Hence, I fail to understand the problem.


The test case does not check NaN explicitly.  So, strictly speaking,
this code may need more stronger to check NaN, otherwise it may STOP
during execution, and this STOP is acceptable. Right?


In terms of GCC,  "-ffast-math: Sets the options -fno-math-errno,
-funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math,
-fno-signaling-nans, -fcx-limited-range and -fexcess-precision=fast"
See "man gcc" or https://gcc.gnu.org/onlinedocs/ → GCC Manual
→ "Option Index" or Invoking → Optimization

And in the test case, the neither "mnan" nor "minf" falls under
"finite-math-only".

Regarding -fast-math etc, see also:
https://gcc.gnu.org/wiki/FloatingPointMath
https://gcc.gnu.org/wiki/x87note
https://gcc.gnu.org/wiki/Math_Optimization_Flags

and, talking about FP math in general,
the Goldberg paper, http://www.validlab.com/goldberg/paper.pdf
and similar but both less famous and written more recently:
a paper by Monniaux, https://hal.archives-ouvertes.fr/hal-00128124

Cheers,

Tobias

PS: Using -ffast-math is fine, if one is careful – but one should
then strongly avoid trickery with NaN, INF etc. BTW: Talking about
optimizations, -Ofast (which was not used by you) also enables
-ffast-math but additionally turns implies "-fno-protect-parens",
which otherwise are protected according to the Fortran standard.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

[committed] testsuite: Fix up g++.dg/torture/pr92152.C test for ilp32 targets

2020-02-28 Thread Jakub Jelinek

On Wed, Feb 26, 2020 at 11:42:54AM +0100, Jan Hubicka wrote:
> 2020-02-26  Jan Hubicka  
> 
>   PR middle-end/92152
>   * alias.c (ends_tbaa_access_path_p): Break out from ...
>   (component_uses_parent_alias_set_from): ... here.
>   * alias.h (ends_tbaa_access_path_p): Declare.
>   * tree-ssa-alias.c (access_path_may_continue_p): Break out from ...;
>   handle trailing arrays past end of tbaa access path.
>   (aliasing_component_refs_p): ... here; likewise.
>   (nonoverlapping_refs_since_match_p): Track TBAA segment of the access
>   path; disambiguate also past end of it.
>   (nonoverlapping_component_refs_p): Use only TBAA segment of the access
>   path.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-02-26  Jan Hubicka  
> 
>   * gcc.dg/tree-ssa/alias-access-path-12.c: New testcase.
>   * g++.dg/torture/pr92152.C: New testcase.

This test FAILs on 32-bit targets:
.../gcc/testsuite/g++.dg/torture/pr92152.C: In constructor 
'HPHP::jit::VregSet::VregSet()':
.../gcc/testsuite/g++.dg/torture/pr92152.C:17:47: warning: unsigned conversion 
from 'long long int' to 'uint64_t' {aka 'long unsigned int'} changes value from 
'281474976710656' to '0' [-Woverflow]

The fix is obvious, use unsigned long long which is 64-bit on all current
targets, and use real size_t.

Fixed thusly, tested on x86_64-linux -m32/-m64 with both the above changes
reverted (where it now has only execution FAILs at some -O* levels
on both arches, while previously it also FAILed at all optimization levels with
-m32) and on current trunk (where previously it FAILed similarly and now
it passes), committed to trunk as obvious.

2020-02-28  Jakub Jelinek  

PR middle-end/92152
* g++.dg/torture/pr92152.C (size_t): Use decltype (sizeof (0)) instead
of hardcoding unsigned long.
(uint64_t): Use unsigned long long instead of unsigned long.

--- gcc/testsuite/g++.dg/torture/pr92152.C.jj   2020-02-28 09:33:40.656403598 
+0100
+++ gcc/testsuite/g++.dg/torture/pr92152.C  2020-02-28 09:39:42.047992711 
+0100
@@ -1,6 +1,6 @@
 /* { dg-do run } */
-using size_t = unsigned long;
-using uint64_t = unsigned long;
+using size_t = decltype (sizeof (0));
+using uint64_t = unsigned long long;
 
 namespace HPHP {
 


Jakub

[PATCH] c++: Further tweak for P1937R2 - const{expr,eval} inconsistencies

2020-02-28 Thread Jakub Jelinek

Hi!

Seems I've missed one thing, as the first hunk in
https://github.com/cplusplus/draft/commit/c8e68ed202b4a9260616bcee8a9768b5dca4bbca
changes the wording so that only potentially-evaluated id-expressions that
denote immediate functions must appear only in the specified contexts.
That IMO means that in unevaluated contexts there aren't such restrictions
anymore, so I think in unevaluated contexts one should be able to take the
address of an immediate function.

The following patch implements it, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?

2020-02-28  Jakub Jelinek  

P1937R2 - Fixing inconsistencies between const{expr,eval} functions
* typeck.c (cp_build_addr_expr_1): Allow taking address of immediate
functions in unevaluated contexts.

* g++.dg/cpp2a/consteval3.C: Change dg-error about taking address of
immediate function in unevaluated contexts into dg-bogus.
* g++.dg/cpp2a/consteval16.C: New test.

--- gcc/cp/typeck.c.jj  2020-02-27 09:28:46.328957157 +0100
+++ gcc/cp/typeck.c 2020-02-27 12:51:35.798841665 +0100
@@ -6325,6 +6325,7 @@ cp_build_addr_expr_1 (tree arg, bool str
   tree stripped_arg = tree_strip_any_location_wrapper (arg);
   if (TREE_CODE (stripped_arg) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (stripped_arg)
+ && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl)))
{
--- gcc/testsuite/g++.dg/cpp2a/consteval3.C.jj  2020-02-24 15:24:33.792751698 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval3.C 2020-02-27 12:55:19.271507525 
+0100
@@ -31,8 +31,8 @@ consteval consteval int f11 () { return
 struct U { consteval ~U () {} };   // { dg-error "a destructor cannot be 
'consteval'" }
 struct V { consteval int v = 5; }; // { dg-error "non-static data member 
'v' declared 'consteval'" }
 struct W { consteval static int w; };  // { dg-error "static data member 'w' 
declared 'consteval'" }
-int i = sizeof (&f6);  // { dg-error "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
-using j = decltype (&f6);  // { dg-error "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
+int i = sizeof (&f6);  // { dg-bogus "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
+using j = decltype (&f6);  // { dg-bogus "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
 int k = sizeof (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
 using l = decltype (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
 bool m = noexcept (f6 (d));// { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
--- gcc/testsuite/g++.dg/cpp2a/consteval16.C.jj 2020-02-27 12:55:25.414415871 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval16.C2020-02-27 12:56:55.891065989 
+0100
@@ -0,0 +1,7 @@
+// { dg-do compile }
+// { dg-options "-std=c++2a" }
+
+consteval int foo () { return 0; }
+int bar (int (*) ());
+auto sz = sizeof (bar (foo));  // { dg-bogus "taking address of an immediate 
function" }
+decltype (bar (foo)) baz;  // { dg-bogus "taking address of an immediate 
function" }

Jakub

82 matches

Mail list logo