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

[Kugan Vivekanandarajah]

Hi Richard,

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

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

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


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

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

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

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

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

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

I will add them in the next version.

Thanks,
Kugan

>
> Thanks for tackling this!
> Richard.
>
>> Thanks,
>> Andrew
>
>> >
>> > Thanks,
>> > Kugan
>> >
>> >
>> > gcc/ChangeLog:
>> >
>> > 2018-05-13  Kugan Vivekanandarajah  
>> >
>> > * expr.c (expand_expr_real_2): Handle ABSU_EXPR.
>> > * fold-const.c (fold_cond_expr_with_comparison): Generate ABSU_EXPR
>> > (fold_unary_loc): Handle ABSU_EXPR.
>> > * optabs-tree.c (optab_for_tree_code): Likewise.
>> > * tree-cfg.c (verify_expr): Likewise.
>> > (verify_gimple_assign_unary):  Likewise.
>> > * tree-if-conv.c (fold_build_cond_expr):  Likewise.
>> > * 

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00869.html

[PATCH] refine -Wstringop-truncation and -Wsizeof-pointer-memaccess for strncat of nonstrings (PR 85602)

[Martin Sebor]

The -Wstringop-truncation and -Wsizeof-pointer-memaccess warnings
I added and enhanced, respectively, in GCC 8 are arguably overly
strict for source arguments declared with the nonstring attribute.

For example, -Wsizeof-pointer-memaccess triggers for the strncat
call below:

  __attribute__ ((nonstring)) char nonstr[8];
  extern char *d;
  strncat (d, nonstr, sizeof nonstr);

even though it's still a fairly common (if unsafe) idiom from
the early UNIX days (V7 from 1979 to be exact) where strncat
was introduced.  (This use case, modulo the attribute, was
reduced from coreutils.)

Simialrly, -Wstringop-truncation warns for some strcat calls that
are actually safe, such as in:

  strcpy (nonstr, "123");
  strncat (d, nonstr, 32);

To help with the adoption of the warnings and the attribute and
avoid unnecessary churn the attached patch relaxes both warnings
to accept code like this without diagnostics.

The patch doesn't add any new warnings so I'd like it considered
for GCC 8 in addition to trunk.

Thanks
Martin
PR middle-end/85602 -  -Wsizeof-pointer-memaccess for strncat with size of source

gcc/c-family/ChangeLog:

	PR middle-end/85602
	* c-warn.c (sizeof_pointer_memaccess_warning): Check for attribute
	nonstring.

gcc/ChangeLog:

	PR middle-end/85602
	* calls.c (maybe_warn_nonstring_arg): Handle strncat.
	* tree-ssa-strlen.c (is_strlen_related_p): Make extern.
	Handle integer subtraction.
	(maybe_diag_stxncpy_trunc): Handle nonstring source arguments.
	* tree-ssa-strlen.h (is_strlen_related_p): Declare.

gcc/testsuite/ChangeLog:

	PR middle-end/85602
	* c-c++-common/attr-nonstring-3.c: Adjust.
	* c-c++-common/attr-nonstring-6.c: New test.

diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index d0d9c78..dc87f01 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gcc-rich-location.h"
 #include "gimplify.h"
 #include "c-family/c-indentation.h"
+#include "calls.h"
 
 /* Print a warning if a constant expression had overflow in folding.
Invoke this function on every expression that the language
@@ -798,7 +799,12 @@ sizeof_pointer_memaccess_warning (location_t *sizeof_arg_loc, tree callee,
 	  tem = tree_strip_nop_conversions (src);
 	  if (TREE_CODE (tem) == ADDR_EXPR)
 	tem = TREE_OPERAND (tem, 0);
-	  if (operand_equal_p (tem, sizeof_arg[idx], OEP_ADDRESS_OF))
+
+	  /* Avoid diagnosing sizeof SRC when SRC is declared with
+	 attribute nonstring.  */
+	  tree dummy;
+	  if (operand_equal_p (tem, sizeof_arg[idx], OEP_ADDRESS_OF)
+	  && !get_attr_nonstring_decl (tem, ))
 	warning_at (sizeof_arg_loc[idx], OPT_Wsizeof_pointer_memaccess,
 			"argument to % in %qD call is the same "
 			"expression as the source; did you mean to use "
diff --git a/gcc/calls.c b/gcc/calls.c
index 9eb0467..472c330 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-chkp.h"
 #include "tree-vrp.h"
 #include "tree-ssanames.h"
+#include "tree-ssa-strlen.h"
 #include "rtl-chkp.h"
 #include "intl.h"
 #include "stringpool.h"
@@ -1614,9 +1615,12 @@ maybe_warn_nonstring_arg (tree fndecl, tree exp)
 
   /* It's safe to call "bounded" string functions with a non-string
  argument since the functions provide an explicit bound for this
- purpose.  */
-  switch (DECL_FUNCTION_CODE (fndecl))
+ purpose.  The exception is strncat where the bound may refer to
+ either the destination or the source.  */
+  int fncode = DECL_FUNCTION_CODE (fndecl);
+  switch (fncode)
 {
+case BUILT_IN_STRNCAT:
 case BUILT_IN_STPNCPY:
 case BUILT_IN_STPNCPY_CHK:
 case BUILT_IN_STRNCMP:
@@ -1687,30 +1691,89 @@ maybe_warn_nonstring_arg (tree fndecl, tree exp)
   if (!decl)
 	continue;
 
-  tree type = TREE_TYPE (decl);
-
   offset_int wibnd = 0;
-  if (bndrng[0])
+
+  if (argno && fncode == BUILT_IN_STRNCAT)
+	{
+	  /* See if the bound in strncat is derived from the length
+	 of the strlen of the destination (as it's expected to be).
+	 If so, reset BOUND and FNCODE to trigger a warning.  */
+	  tree dstarg = CALL_EXPR_ARG (exp, 0);
+	  if (is_strlen_related_p (dstarg, bound))
+	{
+	  /* The bound applies to the destination, not to the source,
+		 so reset these to trigger a warning without mentioning
+		 the bound.  */
+	  bound = NULL;
+	  fncode = 0;
+	}
+	  else if (bndrng[1])
+	/* Use the upper bound of the range for strncat.  */
+	wibnd = wi::to_offset (bndrng[1]);
+	}
+  else if (bndrng[0])
+	/* Use the lower bound of the range for functions other than
+	   strncat.  */
 	wibnd = wi::to_offset (bndrng[0]);
 
+  /* Determine the size of the argument array if it is one.  */
   offset_int asize = wibnd;
+  bool known_size = false;
+  tree type = TREE_TYPE (decl);
 
   if (TREE_CODE (type) == ARRAY_TYPE)
 	if (tree arrbnd = TYPE_DOMAIN (type))
 	  {
 

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

[Paolo Carlini]

Hi again,

On 18/05/2018 02:31, Paolo Carlini wrote:

Hi,

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

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

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

PS: maybe better using function_declarator_p?

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

formed expression?!?

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

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

+    return error_mark_node;

...if cp_parser_parse_definitely returns false, parsing as a
declarator failed, so we shouldn't look at "declarator".
Uhm, then you are saying that we should fix cp_parser_declarator 
itself, right? Because we don't want cp_parser_parse_definitely 
returning false after cp_parser_declarator parses, say, 'if (int 
foo())' and therefore cp_parser_condition proceed with 
cp_parser_expression, we want to emit our error and bail out. 
Therefore the problem in the new patch seems that it tries to paper 
over that cp_parser_declarator issue in the caller?!? Like, Ok, 
cp_parser_declarator failed, but it was anyway trying to declare a 
function / array and that can't possibly be an expression, see what I 
mean? *Somehow*, the question you answered above.
Ok, now I finally see what's the exact issue you pointed out (I'm a bit 
tired). Seems fixable.


If I understand correctly, the reason why the 3 lines you cited above 
are wrong as they are is that my patch *assumes* that 
cp_parser_declarator didn't really fail and cp_parser_condition has 
forced the tentative parse to fail by calling cp_parser_simulate_error 
immediately before when it didn't see an initializer immediately 
following. That's actually true for 'if (int foo())', thus it makes 
sense to check the declarator anyway for such cases *even* if 
cp_parser_parse_definitely returns false. See what I mean?


Therefore, it seems to me that an amended patch would rearrange 
cp_parser_condition to *not* call cp_parser_simulate_error for the cases 
we care about ('if (int foo())') and instead check the declarator.


I'll work on that tomorrow...

Thanks,
Paolo.

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

[Paolo Carlini]

Hi,

On 18/05/2018 01:21, Jason Merrill wrote:

On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini  wrote:

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

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

PS: maybe better using function_declarator_p?

I think so, yes.  The relevant rule seems to be "The declarator shall
not specify a function or an array.", so let's check for arrays, too.

Agreed. I had the amended patch ready when I noticed (again) that it wasn't
addressing another related class of issues which involves declarators not
followed by initializers. Thus I tried to fix those too, and the below which
moves the check up appears to work fine, passes testing, etc. Are there any
risks that an erroneous function / array as declarator is in fact a well
formed expression?!?

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

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

...if cp_parser_parse_definitely returns false, parsing as a
declarator failed, so we shouldn't look at "declarator".
Uhm, then you are saying that we should fix cp_parser_declarator itself, 
right? Because we don't want cp_parser_parse_definitely returning false 
after cp_parser_declarator parses, say, 'if (int foo())' and therefore 
cp_parser_condition proceed with cp_parser_expression, we want to emit 
our error and bail out. Therefore the problem in the new patch seems 
that it tries to paper over that cp_parser_declarator issue in the 
caller?!? Like, Ok, cp_parser_declarator failed, but it was anyway 
trying to declare a function / array and that can't possibly be an 
expression, see what I mean? *Somehow*, the question you answered above.


Paolo.

Re: [PATCH] use string length to relax -Wstringop-overflow for nonstrings (PR 85623)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00509.html

On 05/10/2018 01:26 PM, Martin Sebor wrote:

GCC 8.1 warns for unbounded (and some bounded) string comparisons
involving arrays declared attribute nonstring (i.e., char arrays
that need not be nul-terminated).  For instance:

  extern __attribute__((nonstring)) char a[4];

  int f (void)
  {
return strncmp (a, "123", sizeof a);
  }

  warning: ‘strcmp’ argument 1 declared attribute ‘nonstring’

Note that the warning refers to strcmp even though the call in
the source is to strncmp, because prior passes transform one to
the other.

The warning above is unnecessary (for strcmp) and incorrect for
strncmp because the call reads exactly four bytes from the non-
string array a regardless of the bound and so there is no risk
that it will read past the end of the array.

The attached change enhances the warning to use the length of
the string argument to suppress some of these needless warnings
for both bounded and unbounded string comparison functions.
When the length of the string is unknown, the warning uses its
size (when possible) as the upper bound on the number of accessed
bytes.  The change adds no new warnings.

I'm looking for approval to commit it to both trunk and 8-branch.

Martin

libcpp PATCH to avoid deprecated copy assignment

[Jason Merrill]

Another case of assignment from a value-initialized temporary, which
in this case ought to be placement new.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit ccd4031ebdabf02fe0d54bb43a68c0fa72ec2708
Author: Jason Merrill 
Date:   Thu May 17 17:16:28 2018 -0400

* line-map.c (linemap_init): Use placement new.

* system.h: #include .

diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index a84084c99f0..b2ebfeb16d4 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -348,7 +348,7 @@ linemap_init (struct line_maps *set,
   /* PR33916, needed to fix PR82939.  */
   memset (set, 0, sizeof (struct line_maps));
 #else
-  *set = line_maps ();
+  new (set) line_maps();
 #endif
   set->highest_location = RESERVED_LOCATION_COUNT - 1;
   set->highest_line = RESERVED_LOCATION_COUNT - 1;
diff --git a/libcpp/system.h b/libcpp/system.h
index 719435df949..76420e16cfb 100644
--- a/libcpp/system.h
+++ b/libcpp/system.h
@@ -438,6 +438,10 @@ extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
 /* Some compilers do not allow the use of unsigned char in bitfields.  */
 #define BOOL_BITFIELD unsigned int
 
+#ifdef __cplusplus
+#include 
+#endif
+
 /* Poison identifiers we do not want to use.  */
 #if (GCC_VERSION >= 3000)
 #undef calloc

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

[Jason Merrill]

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

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

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

...if cp_parser_parse_definitely returns false, parsing as a
declarator failed, so we shouldn't look at "declarator".

Also, "here" in the diagnostic seems unnecessarily vague; we could be
more specific.  Maybe "condition declares a function/array"?

Jason

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov  ---
It seems these lines in is_masked_range_test should be removed:
  if (wi::neg_p (val, TYPE_SIGN (type)))
std::swap (*low, *high);
Sadly there were no tests which tested negative constants. I'll bootstrap and
send patch tomorrow (hope there's no urgency?).

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[andrew at sifive dot com]

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

--- Comment #10 from Andrew Waterman  ---
Thanks for the suggestion.  Let's go with the CFI-directive approach.

On Sat, Apr 28, 2018 at 5:45 AM, aurelien at aurel32 dot net
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492
>
> --- Comment #7 from Aurelien Jarno  ---
> (In reply to Jim Wilson from comment #3)
> Thanks a lot Jim for finding out the issue without using gdb, that was quite a
> challenge.
>
> (In reply to Jim Wilson from comment #6)
>> I suggest you handle the glibc patch.
>
> Should I just close this bug and open a new one on the glibc side?
>
>> Note that you can probably also fix this by adding unwind direcives to
>> _start to say that the return address is in x0.  This would avoid the minor
>> code size increase, but takes a little more effort to figure out how to add
>> the right unwind directives to assembly code to make this work.  I haven't
>> tried that.
>
> I think this should be done with the cfi_undefined directive, like in the 
> patch
> below:
>
> --- a/sysdeps/riscv/start.S
> +++ b/sysdeps/riscv/start.S
> @@ -43,6 +43,8 @@
> __libc_start_main wants this in a5.  */
>
>  ENTRY (ENTRY_POINT)
> +   /* Mark ra as undefined in order to stop unwinding here!  */
> +   cfi_undefined (ra)
> call  .Lload_gp
> mva5, a0  /* rtld_fini.  */
> /* main may be in a shared library.  */

[Bug c++/85825] New: Incorrect selection of method in template class specialization.

[christosstratopoulos1 at gmail dot com]

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

Bug ID: 85825
   Summary: Incorrect selection of method in template class
specialization.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christosstratopoulos1 at gmail dot com
  Target Milestone: ---

Created attachment 44144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44144=edit
The output of compilation with -save-temps

Here is the full sample code that causes the issue:

#include 

enum class Frac : unsigned { half = 2, quarter = 4 };

enum class Whole : unsigned { two = 2, five = 5 };

template
class A;

template
class A {
public:
constexpr double val() const noexcept { return 2.0; }
};

template
class A {
public:
constexpr double val() const noexcept { return 1.0; }
};

int main()
{   
auto frac4 = A<100, Frac::quarter>{}.val();
auto whole5 = A<100, Whole::five>{}.val();

assert(frac4 != whole5); // passes

auto frac2 = A<100, Frac::half>{}.val();
auto whole2 = A<100, Whole::two>{}.val();

assert(frac2 != whole2); // fails on g++ 7.x, fine on 8.1, 9 HEAD
}

This is a heavily reduced version of something I encountered at work today,
originally when compiling some code for g++-7.3.0 on a Bash subsystem of a
windows 10 install. I've attached a .ii for that file, and marked this as a
g++-7.3 bug, but testing on wandbox.org has shown this holds for other g++ 7.x,
but seems fine on 8 and 9.

I first ran into this as a compile-time error when trying to compile with the
windows version of clang 6, which reports "definition with same mangled name as
other definition". I have not been able to repro this with online (Linux)
versions of clang.

Here is the output of g++-7 -v:

Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-16ubuntu3~16.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3~16.04.1)

and the command line invocation is

g++-7 -std=c++17 gcc_bug_simple.cpp && ./a.out

Re: [PATCH 2/2, RISC-V] Optimize switch with sign-extended index.

[Jim Wilson]

On Wed, May 2, 2018 at 3:05 PM, Jim Wilson  wrote:>
> * config/riscv/riscv.c (riscv_extend_comparands): In unsigned QImode
> test, check for sign extended subreg and/or constant operands, and
> do a sign extend in that case.
>
> gcc/testsuite/
> * gcc.target/riscv/switch-qi.c: New.
> * gcc.target/riscv/switch-si.c: New.

Committed.

Jim

Re: [PATCH 1/2, expr.c] Optimize switch with sign-extended index.

[Jim Wilson]

On Thu, May 17, 2018 at 12:25 AM, Eric Botcazou  wrote:
> The patch looks OK to me, modulo:
>
>> +   && ! (INTVAL (range) & (HOST_WIDE_INT_1U << (width - 1
>
> I'd use UINTVAL instead of INTVAL here.

Thanks.  Committed with that change.

Jim

gcc-7-20180517 is now available

[gccadmin]

Snapshot gcc-7-20180517 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180517/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 260339

You'll find:

 gcc-7-20180517.tar.xzComplete GCC

  SHA256=78acc1dbad063ca5b42887b993de25bda208f1ebde20c1475d6c008de14bb067
  SHA1=0455eca25828df63d5649420603694e131f117d1

Diffs from 7-20180510 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris SPARC when parsing a simple character class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-17
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Wanying Luo from comment #0)
> gcc version 4.9.2 (GCC) 

The earliest currently supported release is GCC 6.4, but this doesn't appear to
have been fixed already.

> In libstdc++-v3/include/bits/locale_classes.tcc, do_transform() is defined
> as follows:
> 
> do_transform(const _CharT* __lo, const _CharT* __hi) const
> {
> ...
>   size_t __res = _M_transform(__c, __p, __len);
> ...
>   __ret.append(__c, __res);
> 
> 
> When _M_transform() calls strxfrm() and gets -1 when converting 0x80 under
> the UTF-8 locale on Solaris SPARC, it simply assigns -1 to __res of type
> size_t which creates a very large number. This causes __ret.append(__c,
> __res) to crash.

Well the value returned is already a size_t, so it's already a very large
number (not -1), and we do check for larger values than expected, but we don't
check for errors.

> I think it would be nice if the code checks errno and
> issues a better error message than the one above.

Yes, we need to check errno for errors from strxfrm.

[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-17
 Ever confirmed|0   |1

[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
*** Bug 85823 has been marked as a duplicate of this bug. ***

[Bug c++/85823] Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Thanks, Andrew.

*** This bug has been marked as a duplicate of bug 80485 ***

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

[Paolo Carlini]

Hi,

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

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

PS: maybe better using function_declarator_p?

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


Thanks!
Paolo.


Index: cp/parser.c
===
--- cp/parser.c (revision 260331)
+++ cp/parser.c (working copy)
@@ -11527,6 +11527,33 @@ cp_parser_selection_statement (cp_parser* parser,
 }
 }
 
+/* Helper function for cp_parser_condition.  Enforces [stmt.stmt]:
+   The declarator shall not specify a function or an array.  Returns
+   TRUE is the declator is valid, FALSE otherwise.  */
+
+static bool
+cp_parser_check_condition_declarator (cp_parser* parser,
+ cp_declarator *declarator,
+ location_t loc)
+{
+  if (function_declarator_p (declarator)
+  || declarator->kind == cdk_array)
+{
+  if (declarator->kind == cdk_array)
+   error_at (loc, "an array type is not allowed here");
+  else
+   error_at (loc, "a function type is not allowed here");
+  if (parser->fully_implicit_function_template_p)
+   abort_fully_implicit_template (parser);
+  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+/*or_comma=*/false,
+/*consume_paren=*/false);
+  return false;
+}
+  else
+return true;
+}
+
 /* Parse a condition.
 
condition:
@@ -11571,6 +11598,7 @@ cp_parser_condition (cp_parser* parser)
   tree attributes;
   cp_declarator *declarator;
   tree initializer = NULL_TREE;
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
 
   /* Parse the declarator.  */
   declarator = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
@@ -11592,10 +11620,15 @@ cp_parser_condition (cp_parser* parser)
   if (cp_lexer_next_token_is_not (parser->lexer, CPP_EQ)
  && cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_BRACE))
cp_parser_simulate_error (parser);
-   
+
   /* If we did see an `=' or '{', then we are looking at a declaration
 for sure.  */
-  if (cp_parser_parse_definitely (parser))
+  bool decl_p = cp_parser_parse_definitely (parser);
+
+  if (!cp_parser_check_condition_declarator (parser, declarator, loc))
+   return error_mark_node;
+
+  if (decl_p)
{
  tree pushed_scope;
  bool non_constant_p;
Index: testsuite/g++.dg/cpp0x/cond1.C
===
--- testsuite/g++.dg/cpp0x/cond1.C  (nonexistent)
+++ testsuite/g++.dg/cpp0x/cond1.C  (working copy)
@@ -0,0 +1,23 @@
+// PR c++/84588
+// { dg-do compile { target c++11 } }
+
+void foo()
+{
+  if (int bar() {})  // { dg-error "function type is not allowed" }
+;
+
+  for (;int bar() {};)  // { dg-error "function type is not allowed" }
+;
+
+  while (int bar() {})  // { dg-error "function type is not allowed" }
+;
+
+  if (int a[] {})  // { dg-error "array type is not allowed" }
+;
+
+  for (;int a[] {};)  // { dg-error "array type is not allowed" }
+;
+
+  while (int a[] {})  // { dg-error "array type is not allowed" }
+;
+}
Index: testsuite/g++.dg/cpp1y/pr84588-1.C
===
--- testsuite/g++.dg/cpp1y/pr84588-1.C  (nonexistent)
+++ testsuite/g++.dg/cpp1y/pr84588-1.C  (working copy)
@@ -0,0 +1,25 @@
+// { dg-do compile { target c++14 } }
+
+struct a {
+  void b() {}
+  void c(void (*) () = [] {
+  if (a a(int auto) {})  // { dg-error "two or more data types|function 
type" }
+  ;
+  }) {}
+};
+
+struct d {
+  void e() {}
+  void f(void (*) () = [] {
+  for (;d d(int auto) {};)  // { dg-error "two or more data types|function 
type" }
+  ;
+  }) {}
+};
+
+struct g {
+  void h() {}
+  void i(void (*) () = [] {
+  while (g g(int auto) {})  // { dg-error "two or more data types|function 
type" }
+  ;
+  }) {}
+};
Index: testsuite/g++.dg/cpp1y/pr84588-2.C
===
--- testsuite/g++.dg/cpp1y/pr84588-2.C  (nonexistent)
+++ testsuite/g++.dg/cpp1y/pr84588-2.C  (working copy)
@@ -0,0 +1,25 @@
+// { dg-do compile { target c++14 } }
+
+struct a {
+  void b() {}
+  void 

[Bug tree-optimization/85803] [6/7/8/9 Regression] DSE removes live global store

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-17
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
(> I think the only in-tree language eventually specifying behavior for stuff
> like above is Ada - so, any comments / attempts for testcases where we do
> not follow language specified behavior?

I don't think that the language fully does it, it's quite borderline.

But something changed in DSE yesterday, the following procedure compiled with
-gnatp -O used to print "SEGV Handler" and now it runs quietly.

with Ada.Text_IO;

procedure p is

   procedure leaf is
  type Int_Ptr is access all Integer;
  function n return Int_Ptr is
  begin return null; end;

  Data : Int_Ptr := n;
   begin
  Data.all := 0;
   end;

begin
   leaf;
exception
   when others =>
  Ada.Text_IO.Put_Line ("SEGV Handler");
end;

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

Re: [Patch] Do not call the linker if we are creating precompiled header files

[Steve Ellcey]

Ping.

Steve Ellcey
sell...@cavium.com


On Wed, 2018-05-02 at 12:47 -0700, Steve Ellcey wrote:
> This is a new version of a patch I sent out last year to stop gcc from
> trying to do a link when creating precompiled headers and a linker
> flag is also given.
> 
> When I build and test GCC I also build glibc and then I run the GCC tests
> with -Wl,-rpath and -Wl,--dynamic-linker so that I don't have to install
> glibc and the compiler in the default locations.  When I do this some
> precompiled header tests fail because the existance of the linker flags
> causes the compiler to try and call the linker when we really just want to
> create pch files.
> 
> I tracked this down to driver::maybe_run_linker where it sees the linker
> flags and increments num_linker_inputs, this causes the routine to call
> the linker.   This patch checks to see if we are creating precompiled
> header files and avoids calling the linker in that case.
> 
> I tested this with the GCC testsuite and got no regressions, OK to
> checkin?
> 
> Steve Ellcey
> sell...@cavium.com
> 
> 
> 2018-05-02  Steve Ellcey  
> 
>   * gcc.c (create_pch_flag): New variable.
>   (driver::prepare_infiles): Set create_pch_flag
>   when we are creating precompiled headers.
>   (driver::maybe_run_linker): Do not link if
>   create_pch_flag is set.
>   (driver::finalize): Reset create_pch_flag.
> 
> 
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index a716f70..ca986cf 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -208,6 +208,9 @@ int is_cpp_driver;
>  /* Flag set to nonzero if an @file argument has been supplied to gcc.  */
>  static bool at_file_supplied;
>  
> +/* Flag set to nonzero if we are generating a precompiled header.  */
> +static bool create_pch_flag;
> +
>  /* Definition of string containing the arguments given to configure.  */
>  #include "configargs.h"
>  
> @@ -8095,8 +8098,15 @@ driver::prepare_infiles ()
>      strlen (name),
>      infiles[i].langua
> ge);
>  
> -  if (compiler && !(compiler->combinable))
> - combine_inputs = false;
> +  if (compiler)
> + {
> +   if (!(compiler->combinable))
> + combine_inputs = false;
> +
> +   if ((strcmp(compiler->suffix, "@c-header") == 0)
> +   || (strcmp(compiler->suffix, "@c++-header") == 0))
> + create_pch_flag = true;
> + }
>  
>    if (lang_n_infiles > 0 && compiler != input_file_compiler
>     && infiles[i].language && infiles[i].language[0] != '*')
> @@ -8282,6 +8292,10 @@ driver::maybe_run_linker (const char *argv0)
> const
>    int linker_was_run = 0;
>    int num_linker_inputs;
>  
> +  /* If we are creating a precompiled header, do not run the linker.  */
> +  if (create_pch_flag)
> +return;
> +
>    /* Determine if there are any linker input files.  */
>    num_linker_inputs = 0;
>    for (i = 0; (int) i < n_infiles; i++)
> @@ -10052,6 +10066,7 @@ driver::finalize ()
>  
>    is_cpp_driver = 0;
>    at_file_supplied = 0;
> +  create_pch_flag = 0;
>    print_help_list = 0;
>    print_version = 0;
>    verbose_only_flag = 0;

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

[Carl Love]

On Thu, 2018-05-17 at 15:31 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, May 16, 2018 at 12:53:13PM -0700, Carl Love wrote:
> > diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > b/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > index b0267b5..1f3175f 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > @@ -18,7 +18,7 @@ vector char scz;
> >  vector unsigned char uca =
> > {0,4,8,1,5,9,2,6,10,3,7,11,15,12,14,13};
> >  vector unsigned char ucb =
> > {6,4,8,3,1,9,2,6,10,3,7,11,15,12,14,13};
> >  vector unsigned char uc_expected =
> > {3,4,8,2,3,9,2,6,10,3,7,11,15,12,14,13};
> > -vector char ucz;
> > +vector unsigned char ucz;
> 
> Why?  Was this a bug in the test case, does it quieten a warning?

I was actually just making the naming consistent with the rest of the
variable naming.  It doesn't impact the functionality.  The other
variables, uca, ucb for example have their types explicitly stated as 
"unsigned char" where the leading "u" stands for unsigned, "c"
represents char.  However, we have ucz as type char not explicitly
"unsigned char".  So, was just looking for consistency in the
name/declaration.

> 
> > diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > b/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > index 1e690be..f1eb78f 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > @@ -1,4 +1,4 @@
> > -/* { dg-do compile { target powerpc*-*-* } } */
> > +/* { dg-do compile { target powerpc64-*-* } } */
> 
> This is not correct.  The target triple is the (canonical) name of
> the
> architecture the compiler is built for, but you can do for example
> powerpc64-linux-gcc -m32, because we are a biarch target; a typical
> way to test is

OK, wasn't thinking about the fact that the change makes it a 64-bit
only test.  The test is supposed to be for big endian, i.e. the name is
altivec-7-be.c.  We have another test file altivec-7-le.c for little
endian testing.  The change was trying to make it a BE only test but as
you point out, I lose the 32-bit testing.  The 32-bit mode will
obviously be BE.  The thinking was powerpc64-*-* restricts the test to
BE where as powerpc64le-*-* restricts the test to LE.  So I need to
qualify that on 64-bit I only want to run if I am on a 64-bit BE
system.  How can I do that?

> > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > b/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > index 2dd4953..c74c493 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > @@ -1,5 +1,5 @@
>  /* { dg-do compile { target { powerpc64le-*-* } } } */
> > -/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-
> > mcpu=*" } { "-mcpu=power8" } } */
> > +/* { dg-skip-if "do not override -mcpu" { powerpc64le-*-* } { "-
> > mcpu=*" } { "-mcpu=power8" } } */
> 
> This makes no difference, does it?  Please keep it as it was.

Ditto, trying to make this only run on LE as there is also a test file
builtins-1-be.c with  /* { dg-do compile { target { powerpc64-*-* } } }
*/ for testing on BE.  
> 
> > diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> > b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> > index 2df9fca..85d57c8 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> > @@ -1,4 +1,4 @@
> > -/* { dg-do compile { target powerpc*-*-* } } */
> > +/* { dg-do compile { target powerpc64-*-* } } */
> >  /* { dg-require-effective-target powerpc_vsx_ok } */
> >  /* { dg-options "-mvsx" } */
> >  
> > @@ -27,21 +27,21 @@
> >  /* { dg-final { scan-assembler-times "vmulosb" 1 } } */
> >  
> >  // For LE platforms P9 and later, we generate the lxv insn instead
> > of lxvd2x.
> > -/* { dg-final { scan-assembler-times {\mlxvd2x\M}  0  { target { {
> > powerpc64*le-*-* } && { p9vector_hw } } } } } */
> > -/* { dg-final { scan-assembler-times {\mlxv\M}36  { target { {
> > powerpc64*le-*-* } && { p9vector_hw } } } } } */
> > +/* { dg-final { scan-assembler-times {lxvd2x}  0  { target { {
> > powerpc64*le-*-* } && { p9vector_hw } } } } } */
> > +/* { dg-final { scan-assembler-times {lxv}36  { target { {
> > powerpc64*le-*-* } && { p9vector_hw } } } } } */
> 
> This {lxv} matches {lxvd2x} as well.  \m\M in Tcl are like \b\b in
> Perl,
> or \<\> in many other regex dialects.

OK, went and looked that up, didn't realize that was what it was doing.
  

I can change powerpc64*le-*-* to powerpc64le-*-* and leave the rest
alone if you like.

   Carl 

[Bug c++/85823] Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485

[Bug fortran/78797] It is time perhaps to implement -std=f2015

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #8)
> As -std=f2018 will be available in 8.0 and replaces -std=f2015,
> shouldn't this bug be closed?

Yes, gfortran 8 has -std=f2018. Closing.

Re: Auto-generated .rodata contents and __attribute__((section))

[Segher Boessenkool]

On Thu, May 17, 2018 at 06:10:13PM +0200, Michael Matz wrote:
> On Wed, 16 May 2018, Richard Biener wrote:
> > > Are constant pool entries merged at compile time or at link time? I 
> > > would presume it should be done at link time because otherwise you're 
> > > only merging entries within a single compilation unit (which doesn't 
> > > sound that useful in a big project with hundreds of source files), 
> > > right?
> > 
> > constant pool entries are merged at compile time.  There's no such thing
> > as mergeable constant pool sections 
> 
> Actually there is in ELF.  Mergable sections can not only hold strings, 
> but also fixed-size entities (e.g. 4 or 8 byte constants).  Those are 
> merged content-wise at link time and references properly rewritten.  Of 
> course, those still aren't per-function.

It also works correctly in combination with -ffunction-sections,
-fdata-sections, -Wl,--gc-sections.  And not with per-function constant
pools like on arm-linux; I'm not sure how that could ever work.


Segher

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Checking.

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

[Peter Bergner]

On 5/17/18 3:31 PM, Segher Boessenkool wrote:
> On Wed, May 16, 2018 at 12:53:13PM -0700, Carl Love wrote:
>> @@ -27,21 +27,21 @@
>>  /* { dg-final { scan-assembler-times "vmulosb" 1 } } */
>>  
>>  // For LE platforms P9 and later, we generate the lxv insn instead of 
>> lxvd2x.
>> -/* { dg-final { scan-assembler-times {\mlxvd2x\M}  0  { target { { 
>> powerpc64*le-*-* } && { p9vector_hw } } } } } */
>> -/* { dg-final { scan-assembler-times {\mlxv\M}36  { target { { 
>> powerpc64*le-*-* } && { p9vector_hw } } } } } */
>> +/* { dg-final { scan-assembler-times {lxvd2x}  0  { target { { 
>> powerpc64*le-*-* } && { p9vector_hw } } } } } */
>> +/* { dg-final { scan-assembler-times {lxv}36  { target { { 
>> powerpc64*le-*-* } && { p9vector_hw } } } } } */
> 
> This {lxv} matches {lxvd2x} as well.  \m\M in Tcl are like \b\b in Perl,
> or \<\> in many other regex dialects.

The target triplet of powerpc64*le-*-* isn't modified by the patch,
but the '*' in powerpc64*le seems superfluous, so can we just remove it?

Peter

[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris-sparc when parsing a simple character class

[wanyingloo at gmail dot com]

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

--- Comment #2 from Wanying Luo  ---
(In reply to Wanying Luo from comment #0)
> When I ran this test on a Linux machine with GCC 4.9.2, glibc's strxfrm()
> converts 0x80 to 6 bytes.

Pasting my test on Linux with the same version of GCC for completeness.


$ cat test.cpp
#include 
#include 

int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
std::regex("[0-9]");
}

$ echo $LANG
en_US.UTF-8

$ g++ -std=c++11 test.cpp

$ ./a.out 

$ cat more_test.cpp 
#include 
#include 
#include 
#include 

int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
char a[] = { 0x80, '\0' };
printf("%lu\n", strxfrm(NULL, a, 0));
printf("%s\n", strerror(errno));
}

$ g++ -std=c++11 -w more_test.cpp 

$ ./a.out 
6
Success

$ uname -a
Linux d-ubuntu12x64-11 3.2.0-126-generic #169-Ubuntu SMP Fri Mar 31 14:15:21
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/wluo/othello/linux64-packages/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure --prefix=/usr
--with-local-prefix=/usr/local --enable-languages=c,c++,fortran --disable-nls
--disable-libcilkrts --disable-lto --enable-libstdcxx-time
--enable-clocale=generic
--with-stage1-ldflags='-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib64
-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib'
--with-boot-ldflags='-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib64
-L/slowfs/sighome/calebs/working/platform-packages-build/idir/linux64/stage1-packages/lib'
--disable-werror --disable-multiarch --disable-bootstrap
Thread model: posix
gcc version 4.9.2 (GCC)

Business intelligence of Accounting Software

[Pamela Crawford]

Hello,

 

Would you be interested in acquiring newly released Accounting Software
Contact Information?

Our entire list comes with complete contact information including direct
phone numbers and emails.

We also have other specialist such as:

 

Ø  QuickBooks Software Users

Ø  Financial Analytical Applications Users

Ø  Ecommerce Users

Ø  ERP Users 

Ø  Configure Price Quote (CPQ) Users

 

Please let me know the below and I shall get back to you with other list
details accordingly.

Target Specialist___?
Target Geography___?

Hope to hear from you soon.

 

Regards,

 

Pamela Crawford - Marketing Analyst

 

This is an attempt to begin a conversation with you. If you would rather not
hear from us, please respond mentioning UNSUBSCRIBE in the subject line.

If you are not the right person please forward this email to the right
person in your organization.

 

 

[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris-sparc when parsing a simple character class

[wanyingloo at gmail dot com]

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

--- Comment #1 from Wanying Luo  ---
Here's GDB backtrace at the time of crash.


#0  0xf56fe7a0 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xf56a1e90 in raise () from /lib/libc.so.1
#2  0xf567a274 in abort () from /lib/libc.so.1
#3  0xff2f2d70 in __gnu_cxx::__verbose_terminate_handler ()
at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#4  0xff2ef844 in __cxxabiv1::__terminate (handler=0xff2f2bac
<__gnu_cxx::__verbose_terminate_handler()>)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#5  0xff2ef8e8 in std::terminate () at
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#6  0xff2efc68 in __cxxabiv1::__cxa_rethrow () at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:125
#7  0xff29c974 in std::collate::do_transform (this=0xff34d9f8 <(anonymous
namespace)::collate_c>, 
__lo=0x4fb3c "\200", __hi=0x4fb3d "")
at
/tmp/wluo/gcc-4.9.2/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/locale_classes.tcc:245
#8  0xff29c25c in std::collate::transform (this=0xff34d9f8 <(anonymous
namespace)::collate_c>, 
__lo=0x4fb3c "\200", __hi=0x4fb3d "")
at
/tmp/wluo/gcc-4.9.2/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/locale_classes.h:662
#9  0x0002ead4 in std::string std::regex_traits::transform(char*,
char*) const ()
#10 0x0002c634 in std::string
std::regex_traits::transform_primary(char*, char*) const ()
#11 0x000275f8 in std::__detail::_BracketMatcher::_M_apply(char, std::integral_constant) const ()
#12 0x00022bb4 in std::__detail::_BracketMatcher::_M_make_cache(std::integral_constant) ()
#13 0x0001ed70 in std::__detail::_BracketMatcher::_M_ready() ()
#14 0x0001f958 in void std::__detail::_Compiler::_M_insert_bracket_matcher(bool) ()
#15 0x0001c630 in std::__detail::_Compiler::_M_bracket_expression() ()
#16 0x000192e8 in std::__detail::_Compiler::_M_atom()
()
#17 0x00017910 in std::__detail::_Compiler::_M_term()
()
#18 0x00015868 in std::__detail::_Compiler::_M_alternative() ()
#19 0x000141dc in std::__detail::_Compiler::_M_disjunction() ()
#20 0x0001381c in std::__detail::_Compiler::_Compiler(char const*, char const*, std::regex_traits const&,
std::regex_constants::syntax_option_type) ()
#21 0x00013340 in std::shared_ptr
> std::__detail::__compile_nfa(std::regex_traits::char_type const*, std::regex_traits::char_type
const*, std::regex_traits const&,
std::regex_constants::syntax_option_type) ()
#22 0x0001307c in std::basic_regex::basic_regex(char const*, char const*,
std::regex_constants::syntax_option_type) ()
#23 0x00012d84 in std::basic_regex::basic_regex(char const*, std::regex_constants::syntax_option_type) ()
#24 0x000120d0 in main ()

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

[Segher Boessenkool]

Hi!

On Wed, May 16, 2018 at 12:53:13PM -0700, Carl Love wrote:
> diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-12.c 
> b/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> index b0267b5..1f3175f 100644
> --- a/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> @@ -18,7 +18,7 @@ vector char scz;
>  vector unsigned char uca = {0,4,8,1,5,9,2,6,10,3,7,11,15,12,14,13};
>  vector unsigned char ucb = {6,4,8,3,1,9,2,6,10,3,7,11,15,12,14,13};
>  vector unsigned char uc_expected = {3,4,8,2,3,9,2,6,10,3,7,11,15,12,14,13};
> -vector char ucz;
> +vector unsigned char ucz;

Why?  Was this a bug in the test case, does it quieten a warning?

> diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c 
> b/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> index 1e690be..f1eb78f 100644
> --- a/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-do compile { target powerpc64-*-* } } */

This is not correct.  The target triple is the (canonical) name of the
architecture the compiler is built for, but you can do for example
powerpc64-linux-gcc -m32, because we are a biarch target; a typical
way to test is

make -k -jNNN check RUNTESTFLAGS="--target_board=unix'{-m64,-m32}'"

If you want the test to only run on 64-bit (why?), you want e.g.
{ dg-do compile { target powerpc*-*-* && lp64 } } */

> diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c 
> b/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> index 2dd4953..c74c493 100644
> --- a/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile { target { powerpc64le-*-* } } } */
> -/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc64le-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */

This makes no difference, does it?  Please keep it as it was.

> diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c 
> b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> index 2df9fca..85d57c8 100644
> --- a/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> +++ b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-do compile { target powerpc64-*-* } } */
>  /* { dg-require-effective-target powerpc_vsx_ok } */
>  /* { dg-options "-mvsx" } */
>  
> @@ -27,21 +27,21 @@
>  /* { dg-final { scan-assembler-times "vmulosb" 1 } } */
>  
>  // For LE platforms P9 and later, we generate the lxv insn instead of lxvd2x.
> -/* { dg-final { scan-assembler-times {\mlxvd2x\M}  0  { target { { 
> powerpc64*le-*-* } && { p9vector_hw } } } } } */
> -/* { dg-final { scan-assembler-times {\mlxv\M}36  { target { { 
> powerpc64*le-*-* } && { p9vector_hw } } } } } */
> +/* { dg-final { scan-assembler-times {lxvd2x}  0  { target { { 
> powerpc64*le-*-* } && { p9vector_hw } } } } } */
> +/* { dg-final { scan-assembler-times {lxv}36  { target { { 
> powerpc64*le-*-* } && { p9vector_hw } } } } } */

This {lxv} matches {lxvd2x} as well.  \m\M in Tcl are like \b\b in Perl,
or \<\> in many other regex dialects.


Segher

[Bug libstdc++/85824] New: regex constructor crashes under UTF-8 locale on Solaris-sparc when parsing a simple character class

[wanyingloo at gmail dot com]

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

Bug ID: 85824
   Summary: regex constructor crashes under UTF-8 locale on
Solaris-sparc when parsing a simple character class
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wanyingloo at gmail dot com
  Target Milestone: ---

$ cat test.cpp
#include 
#include 

int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
std::regex("[0-9]");
}

$ echo $LANG
en_US.UTF-8

$ g++ -std=c++11 test.cpp

$ ./a.out 
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::append
Abort (core dumped)

$ uname -a
SunOS t-solaris11sparc-02 5.11 11.3 sun4v sparc sun4v Solaris

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/tmp/wluo/othello/solaris-sparc-packages/bin/../libexec/gcc/sparc-sun-solaris2.10/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.9.2/configure --prefix=/usr
--with-local-prefix=/usr/local --enable-languages=c,c++ --disable-nls
--disable-lto --enable-clocale=generic
--with-stage1-ldflags='-L/data00/builds/trprince/platform-packages-build/idir/solaris-sparc/stage1-packages/lib
-static-libgcc -static-libstdc++ -laio -lmd'
--with-boot-ldflags='-L/data00/builds/trprince/platform-packages-build/idir/solaris-sparc/stage1-packages/lib
-static-libgcc -static-libstdc++ -laio -lmd' --disable-werror
--with-libiconv-prefix=/data00/builds/trprince/platform-packages-build/idir/solaris-sparc/stage1-packages
--with-gnu-ld --with-gnu-as --disable-multiarch --disable-bootstrap
Thread model: posix
gcc version 4.9.2 (GCC) 


I can't reproduce it on Linux using the same GCC version. I did some
investigation and it seems to be because regex compiler doesn't account for
implementation-defined behavior of strxfrm(). I ran the following test on the
same Solaris SPARC machine.

$ cat more_test.cpp 
#include 
#include 
#include 
#include 

int main (int argc, char *argv[]) {
setlocale(LC_ALL, "");
char a[] = { 0x80, '\0' };
printf("%lu\n", strxfrm(NULL, a, 0));
printf("%s\n", strerror(errno));
}

$ g++ -std=c++11 -w more_test.cpp 

$ ./a.out 
4294967295
Illegal byte sequence


In libstdc++-v3/include/bits/locale_classes.tcc, do_transform() is defined as
follows:

do_transform(const _CharT* __lo, const _CharT* __hi) const
{
...
  size_t __res = _M_transform(__c, __p, __len);
...
  __ret.append(__c, __res);


When _M_transform() calls strxfrm() and gets -1 when converting 0x80 under the
UTF-8 locale on Solaris SPARC, it simply assigns -1 to __res of type size_t
which creates a very large number. This causes __ret.append(__c, __res) to
crash. I think it would be nice if the code checks errno and issues a better
error message than the one above.

When I ran this test on a Linux machine with GCC 4.9.2, glibc's strxfrm()
converts 0x80 to 6 bytes. I tend to think Solaris SPARC's libc behavior makes
more sense here since 0x80 on its own isn't a valid UTF-8 code point even
though it's a valid UTF-8 code unit. I have no idea why glibc converts it to 6
bytes. In any event, how strxfrm() converts 0x80 under UTF-8 is
implementation-defined, and I'm not sure do_transform() accounts for that. At
the very least, it can be more defensive by checking errno, I think.

[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
  _2 = x.0_1 & -281474976710656;
  if (_2 == -281474976710656)
goto ; [20.24%]

[...]

  x.0_11 = ASSERT_EXPR ;
  x.0_12 = ASSERT_EXPR ;
  x.0_13 = ASSERT_EXPR = -1>;
  y_7 = (unsigned intD.9) x.0_13;

Those ASSERT_EXPR look strange, possibly the last 2 inequalities are inverted.

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[krzysio.kurek at wp dot pl]

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

--- Comment #28 from krzysio.kurek at wp dot pl ---
I mean the relative performance is worse but still Profiled GCC6 is faster than
GCC 7 or GCC 8.

[Bug c++/85823] Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-17
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Seems this never worked, thus not a regression.

[Bug c++/85823] New: Boost.Tribool fails to compile: error: '(tribool::dummy::nonnull != 0)' is not a constant expression

[redi at gcc dot gnu.org]

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

Bug ID: 85823
   Summary: Boost.Tribool fails to compile: error:
'(tribool::dummy::nonnull != 0)' is not a constant
expression
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Reduced from 
https://github.com/boostorg/logic/pull/5#issuecomment-389965834

struct B {
  struct dummy {
void nonnull() { }
  };
  using safe_bool = void (dummy::*)();

  constexpr B() : value(false) {}

  constexpr B(int) : value(true) {}

  constexpr operator safe_bool() const
  {
return value ? ::nonnull : 0;
  }

  bool value;
};

constexpr B operator!(B x)
{
  return x.value ? B() : B(1);
}

constexpr B tb_f{};
static_assert(!tb_f, "");



tribool.cc:25:15: error: non-constant condition for static assertion
 static_assert(!tb_f, "");
   ^
tribool.cc:25:25: error: '(B::dummy::nonnull != 0)' is not a constant
expression
 static_assert(!tb_f, "");
 ^

Cybersecurity Software Users Contact List

[Meghan Hudson]

Hi,

Hope you having a great day!

I just wanted to be aware if you would be interested in acquiring Cybersecurity 
Software Users Contact List for marketing your product or service.

These are the fields that we provide for each contacts: Names, Title, Email, 
Contact Number, Company Name, Company URL, and Company physical location, SIC 
Code, Industry and Company Size (Revenue and Employee).

Kindly review and let me be aware of your interest so that I can get back to 
you with the exact counts and more info regarding the same.

Do let me be aware if you have any questions for me.

Regards,
Meghan Hudson
Database Executive
If you do not wish to receive these emails. Please respond Exit.

Re: [PATCH][AArch64] Unify vec_set patterns, support floating-point vector modes properly

[James Greenhalgh]

On Thu, May 17, 2018 at 09:26:37AM -0500, Kyrill Tkachov wrote:
> 
> On 17/05/18 14:56, Kyrill Tkachov wrote:
> >
> > On 17/05/18 09:46, Kyrill Tkachov wrote:
> >>
> >> On 15/05/18 18:56, Richard Sandiford wrote:
> >>> Kyrill  Tkachov  writes:
>  Hi all,
> 
>  We've a deficiency in our vec_set family of patterns.  We don't
>  support directly loading a vector lane using LD1 for V2DImode and all
>  the vector floating-point modes.  We do do it correctly for the other
>  integer vector modes (V4SI, V8HI etc) though.
> 
>  The alternatives on the relative floating-point patterns only allow a
>  register-to-register INS instruction.  That means if we want to load a
>  value into a vector lane we must first load it into a scalar register
>  and then perform an INS, which is wasteful.
> 
>  There is also an explicit V2DI vec_set expander dangling around for no
>  reason that I can see. It seems to do the exact same things as the
>  other vec_set expanders. This patch removes that.  It now unifies all
>  vec_set expansions into a single "vec_set" define_expand using
>  the catch-all VALL_F16 iterator.
> 
>  I decided to leave two aarch64_simd_vec_set define_insns. One
>  for the integer vector modes (that now include V2DI) and one for the
>  floating-point vector modes. That is so that we can avoid specifying
>  "w,r" alternatives for floating-point modes in case the
>  register-allocator gets confused and starts gratuitously moving
>  registers between the two banks.  So the floating-point pattern only
>  two alternatives, one for SIMD-to-SIMD INS and one for LD1.
> >>> Did you see any cases in which this was necessary?  In some ways it
> >>> seems to run counter to Wilco's recent patches, which tended to remove
> >>> the * markers from the "unnatural" register class and trust the register
> >>> allocator to make a sensible decision.
> >>>
> >>> I think our default position should be trust the allocator here.
> >>> If the consumers all require "w" registers then the RA will surely
> >>> try to use "w" registers if at all possible.  But if the consumers
> >>> don't care then it seems reasonable to offer both, since in those
> >>> cases it doesn't really make much difference whether the payload
> >>> happens to be SF or SI (say).
> >>>
> >>> There are also cases in which the consumer could actively require
> >>> an integer register.  E.g. some code uses unions to bitcast floats
> >>> to ints and then do bitwise arithmetic on them.
> >>>
> >>
> >> Thanks, that makes sense. Honestly, it's been a few months since I worked 
> >> on this patch.
> >> I believe my reluctance to specify that alternative was that it would mean 
> >> merging the integer and
> >> floating-point patterns into one (like the attached version) which would 
> >> put the "w, r" alternative
> >> first for the floating-point case. I guess we should be able to trust the 
> >> allocator to pick
> >> the sensible  alternative though.
> >>
> >
> > With some help from Wilco I can see how this approach will give us 
> > suboptimal code though.
> > If we modify the example from my original post to be:
> > v4sf
> > foo_v4sf (float *a, float *b, float *c, float *d)
> > {
> > v4sf res = { *a, b[2], *c, *d };
> > return res;
> > }
> >
> > The b[2] load will load into a GP register then do an expensive INS into 
> > the SIMD register
> > instead of loading into an FP S-register and then doing a SIMD-to-SIMD INS.
> > The only way I can get it to use the FP load then is to mark the "w, r" 
> > alternative with a '?'
> >
> 
> That patch would look like the attached. Is this preferable?
> For the above example it generates the desired:
> foo_v4sf:
>  ldr s0, [x0]
>  ldr s1, [x1, 8]
>  ins v0.s[1], v1.s[0]
>  ld1 {v0.s}[2], [x2]
>  ld1 {v0.s}[3], [x3]
>  ret
> 
> 
> rather than loading [x1, 8] into a W-reg.

OK,

Thanks,
James

Re: Are the extended algorithms in the header file going to be supported by gcc ?

[Thomas Rodgers]

There is work ongoing to complete C++17 support in libstdc++, this
includes providing support for the C++17 parallel algorithms.

Marco Ippolito writes:

>  Hi,
>
> the good book "C++17 STL Cookbook" in chapter 9 "Parallelism and
> Concurrency" describes some of the 69 algorithms that were extended to
> accept execution policies in order to run parallel on multiple cores. And,
> according to the provided examples, they all greatly simplify some aspects
> of parallelization with the standard algorithms.
>
> I'm using Ubuntu 16.04 with upgraded gcc version 7.2.0 (Ubuntu
> 7.2.0-1ubuntu1~16.04) and the header file  is not present.
>
> In the official gcc documentation: https://gcc.gnu.org/onlinedocs/libstdc++/
> manual/status.html the support to  is flagged as "no" in
> the Table 1.5. C++ 2017 Implementation Status,
> and it seems that it is even not foreseen to be included in the upgraded
> gcc 8 version: https://gcc.gnu.org/projects/cxx-status.html
>
> So, the crucial question about these 69 extended algorithms in the header
> file  is:
> are these extended algorithms going to be supported by the next releases of
> gcc, as they are already supported by Visual Studio, and soon by clang ?
>
> Looking forward to your kind feedback about this extremely important aspect
> of gcc.
> Marco

Re: [PATCH rs6000] Fix PR85698

[Segher Boessenkool]

On Thu, May 17, 2018 at 07:58:20PM +0200, Richard Biener wrote:
> On May 17, 2018 6:04:36 PM GMT+02:00, Segher Boessenkool 
>  wrote:
> >On Thu, May 17, 2018 at 10:42:46AM -0500, Pat Haugen wrote:
> >> The following patch fixes a problem that resulted in incorrect code
> >generation for the CPU2017 benchmark 525.x264_r. The fix correctly
> >checks the "dest" operand, which is the memory operand.
> >> 
> >> Bootstrap/regtest on powerp64le and powerpc64 (-m32/-m64) with no new
> >> regressions. Ok for trunk?
> >
> >Okay.  Thanks!
> 
> Don't forget the branch. 

It's okay for both 7 and 8, too.


Segher


> >> 2018-05-17  Pat Haugen  
> >>Segher Boessenkool  
> >> 
> >>PR target/85698
> >>* config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest
> >operand.
> >> 
> >> testsuite/ChangeLog:
> >> 2018-05-17  Pat Haugen  
> >> 
> >>PR target/85698
> >>* gcc.target/powerpc/pr85698.c: New test.

[Bug ipa/85817] [9 Regression] ICE in expand_call at gcc/calls.c:4291

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from H.J. Lu  ---
*** Bug 85820 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/85820] [9 Regression] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from H.J. Lu  ---
(In reply to prathamesh3492 from comment #1)
> This is most likely dup of PR85817. Could you check if the fix in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817#c1 works ?

Yes, the patch works.  Thanks.

*** This bug has been marked as a duplicate of bug 85817 ***

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-17
Version|unknown |9.0
 Ever confirmed|0   |1

[Bug tree-optimization/85822] New: [8/9 Regression] Maybe wrong code in VRP since r249150

[marxin at gcc dot gnu.org]

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

Bug ID: 85822
   Summary: [8/9 Regression] Maybe wrong code in VRP since r249150
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, ygribov at gcc dot gnu.org
  Target Milestone: ---

I've saw that in qtscript, isolated test-case looks as follows:

$ cat vrp.c
static const long int TagTypeNumber = 0xll;

long int x;

void foo(void)
{
  x = TagTypeNumber + 1;
}

int main(int argc, char **argv)
{
  if (argc > 0)
foo ();

  if ((x & TagTypeNumber) == TagTypeNumber)
  {
unsigned y = (unsigned)x;
__builtin_printf ("v: %u\n", y);
if (y != 1)
  __builtin_abort ();
  }

  return 0;
}

$ gcc -O2 vrp.c && ./a.out 
v: 0
Aborted (core dumped)

$

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

[Toon Moene]

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


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


ChangeLog:

2018-05-17  Toon Moene  

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

OK for trunk and gcc-8 ?

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Index: invoke.texi
===
--- invoke.texi	(revision 260287)
+++ invoke.texi	(working copy)
@@ -8866,7 +8866,14 @@
 for (int j = 0; j < N; j++)
   c[i][j] = c[i][j] + a[i][k]*b[k][j];
 @end smallexample
+This flag is enabled by default at @option{-O3}.
 
+@item -floop-unroll-and-jam
+@opindex floop-unroll-and-jam
+Apply unroll and jam transformations on feasible loops.  In a loop
+nest this unrolls the outer loop by some factor and fuses the resulting
+multiple inner loops.  This flag is enabled by default at @option{-O3}.
+
 @item -ftree-loop-im
 @opindex ftree-loop-im
 Perform loop invariant motion on trees.  This pass moves only invariants that
@@ -10038,12 +10045,6 @@
 Move branches with loop invariant conditions out of the loop, with duplicates
 of the loop on both branches (modified according to result of the condition).
 
-@item -floop-unroll-and-jam
-@opindex floop-unroll-and-jam
-Apply unroll and jam transformations on feasible loops.  In a loop
-nest this unrolls the outer loop by some factor and fuses the resulting
-multiple inner loops.
-
 @item -ffunction-sections
 @itemx -fdata-sections
 @opindex ffunction-sections

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #12 from Martin Sebor  ---
Thanks for the test case.  Here's a slightly reduced version of it:

$ cat pr78969.c && gcc -O2 -S -Wall pr78969.c
void f (int, ...);

char d[4];

void g (unsigned i)
{
  if (i >= 1000 && i < 1)
__builtin_snprintf (d, 4, "%3d", i / 10);   // bogus -Wformat-truncation
  else
f (i / 10 % 10);
}
pr78969.c: In function ‘g’:
pr78969.c:8:32: warning: ‘%3d’ directive output may be truncated writing
between 3 and 9 bytes into a region of size 4 [-Wformat-truncation=]
 __builtin_snprintf (d, 4, "%3d", i / 10);   // bogus -Wformat-truncation
^~~
pr78969.c:8:31: note: directive argument in the range [0, 429496729]
 __builtin_snprintf (d, 4, "%3d", i / 10);   // bogus -Wformat-truncation
   ^
pr78969.c:8:5: note: ‘__builtin_snprintf’ output between 4 and 10 bytes into a
destination of size 4
 __builtin_snprintf (d, 4, "%3d", i / 10);   // bogus -Wformat-truncation
 ^~~~

It does look like the false positive is due to the same underlying limitation
(the range not being reflected accurately outside the VRP pass).  GCC 7 doesn't
warn but GCC 8 does.  That's because in GCC 7 the result of the
get_range_info() function is VR_VARYING for the argument while in GCC 8 it
reports a VR_RANGE of [0, 429496729].  So ironically, the false positive is a
side-effect of the improvement in GCC 8's range tracking.

There is work underway to improve the accuracy of the range information even
further that should reduce the rate of these kinds of false positives.

That being said, a few comments:

1) The problem doesn't affect just -Wstringop-truncation but other warnings as
well, including -Wformat-overflow.  The latter warning, especially, has proven
to be useful enough despite this limitation that removing either from -Wall
doesn't seem a like good solution.
2) The philosophy behind -Wstringop-truncation is based on the assumption that
snprintf() is being called because truncation is possible, and that most
programs aren't prepared to handle it correctly.

In the test case, since truncation isn't possible, calling snprintf() is
unnecessary (and sprintf() would be sufficient -- though calling sprintf with a
fixed-size buffer just big enough for the output would also cause a false
positive).  Otherwise, if truncation were possible, the expectation is that the
caller should detect it by testing the return value from the function and
taking some action (e.g., by aborting).

Until the range improvements I mention above are made, I suggest to assume that
snprintf can truncate and handle the truncation somehow.  In comparison to the
runtime cost of the snprintf call, the overhead of checking the return value
and aborting is negligible.

Are the extended algorithms in the header file going to be supported by gcc ?

[Marco Ippolito]

 Hi,

the good book "C++17 STL Cookbook" in chapter 9 "Parallelism and
Concurrency" describes some of the 69 algorithms that were extended to
accept execution policies in order to run parallel on multiple cores. And,
according to the provided examples, they all greatly simplify some aspects
of parallelization with the standard algorithms.

I'm using Ubuntu 16.04 with upgraded gcc version 7.2.0 (Ubuntu
7.2.0-1ubuntu1~16.04) and the header file  is not present.

In the official gcc documentation: https://gcc.gnu.org/onlinedocs/libstdc++/
manual/status.html the support to  is flagged as "no" in
the Table 1.5. C++ 2017 Implementation Status,
and it seems that it is even not foreseen to be included in the upgraded
gcc 8 version: https://gcc.gnu.org/projects/cxx-status.html

So, the crucial question about these 69 extended algorithms in the header
file  is:
are these extended algorithms going to be supported by the next releases of
gcc, as they are already supported by Visual Studio, and soon by clang ?

Looking forward to your kind feedback about this extremely important aspect
of gcc.
Marco

Re: [PATCH rs6000] Fix PR85698

[Richard Biener]

On May 17, 2018 6:04:36 PM GMT+02:00, Segher Boessenkool 
 wrote:
>On Thu, May 17, 2018 at 10:42:46AM -0500, Pat Haugen wrote:
>> The following patch fixes a problem that resulted in incorrect code
>generation for the CPU2017 benchmark 525.x264_r. The fix correctly
>checks the "dest" operand, which is the memory operand.
>> 
>> Bootstrap/regtest on powerp64le and powerpc64 (-m32/-m64) with no new
>> regressions. Ok for trunk?
>
>Okay.  Thanks!

Don't forget the branch. 

Richard. 

>
>Segher
>
>
>> 2018-05-17  Pat Haugen  
>>  Segher Boessenkool  
>> 
>>  PR target/85698
>>  * config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest
>operand.
>> 
>> testsuite/ChangeLog:
>> 2018-05-17  Pat Haugen  
>> 
>>  PR target/85698
>>  * gcc.target/powerpc/pr85698.c: New test.

[Bug middle-end/41475] common variables cannot be expected to be aligned

[atarasevich at comcast dot net]

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

Andrey Tarasevich  changed:

   What|Removed |Added

 CC||atarasevich at comcast dot net

--- Comment #10 from Andrey Tarasevich  ---
(In reply to Andrew Pinski from comment #8)
> This code is undefined I think (and really it is not valid C90/C99 code).

You are absolutely right - this code is not valid from the point of view of
formal standard C language. It is illegal to provide multiple definitions of
external objects with the same name.

However, this is a popular extension in C implementations with Unix heritage.
So, this entry is about the intended non-standard behavior of GCC
compiler/linker.

Re: PING^1: [PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Mon, May 14, 2018 at 8:00 PM, Martin Sebor  wrote:
> On 05/14/2018 01:10 PM, H.J. Lu wrote:
>>
>> On Mon, May 14, 2018 at 10:40 AM, H.J. Lu  wrote:
>>
>> $ cat c.i
>> struct B { int i; };
>> struct C { struct B b; } __attribute__ ((packed));
>>
>> long* g8 (struct C *p) { return p; }
>> $ gcc -O2 -S c.i -Wno-incompatible-pointer-types
>> c.i: In function ‘g8’:
>> c.i:4:33: warning: taking value of packed 'struct C *' may result in
>> an
>> unaligned pointer value [-Waddress-of-packed-member]


  ^
 That should read "taking address" (not value) but...
>>>
>>>
>>> The value of 'struct C *' is an address. There is no address taken here.
>>>
 ...to help explain the problem I would suggest to mention the expected
 and actual alignment in the warning message.  E.g.,

   storing the address of a packed 'struct C' in 'struct C *' increases
 the
 alignment of the pointer from 1 to 4.
>>>
>>>
>>> I will take a look.
>>>
 (IIUC, the source type and destination type need not be the same so
 including both should be helpful in those cases.)

 Adding a note pointing to the declaration of either the struct or
 the member would help users find it if it's a header far removed
 from the point of use.
>>>
>>>
>>> I will see what I can do.
>>
>>
>> How about this
>>
>> [hjl@gnu-skx-1 pr51628]$ cat n9.i
>> struct B { int i; };
>> struct C { struct B b; } __attribute__ ((packed));
>>
>> long* g8 (struct C *p) { return p; }
>> [hjl@gnu-skx-1 pr51628]$
>> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
>> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n9.i
>> n9.i: In function ‘g8’:
>> n9.i:4:33: warning: returning ‘struct C *’ from a function with
>> incompatible return type ‘long int *’ [-Wincompatible-pointer-types]
>>  long* g8 (struct C *p) { return p; }
>>  ^
>> n9.i:4:33: warning: taking value of packed ‘struct C *’ increases the
>> alignment of the pointer from 1 to 8 [-Waddress-of-packed-member]
>> n9.i:2:8: note: defined here
>>  struct C { struct B b; } __attribute__ ((packed));
>
>
> Mentioning the alignments looks good.
>
> I still find the "taking value" phrasing odd.  I think we would
> describe what's going on as "converting a pointer to a packed C
> to a pointer to C (with an alignment of 8)" so I'd suggest to
> use the term converting instead.

How about this?

[hjl@gnu-skx-1 pr51628]$ cat n12.i
struct B { int i; };
struct C { struct B b; } __attribute__ ((packed));

struct B* g8 (struct C *p) { return p; }
[hjl@gnu-skx-1 pr51628]$ make n12.s
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n12.i
n12.i: In function ‘g8’:
n12.i:4:37: warning: returning ‘struct C *’ from a function with
incompatible return type ‘struct B *’ [-Wincompatible-pointer-types]
 struct B* g8 (struct C *p) { return p; }
 ^
n12.i:4:37: warning: converting a pointer to packed ‘struct C *’
increases the alignment of the pointer to ‘struct B *’ from 1 to 4
[-Waddress-of-packed-member]
n12.i:2:8: note: defined here
 struct C { struct B b; } __attribute__ ((packed));
^
n12.i:1:8: note: defined here
 struct B { int i; };
^
[hjl@gnu-skx-1 pr51628]$

> I also think mentioning both the source and the destination types
> is useful irrespective of -Wincompatible-pointer-types because
> the latter is often suppressed using a cast, as in:
>
>   struct __attribute__ ((packed)) A { int i; };
>   struct B {
> struct A a;
>   } b;
>
>   long *p = (long*)   // -Waddress-of-packed-member
>   int *q = (int*)   // missing warning
>
> If the types above were obfuscated by macros, typedefs, or in
> C++ template parameters, it could be difficult to figure out
> what the type of the member is because neither it nor the name
> of the member appears in the message.

How about this

[hjl@gnu-skx-1 pr51628]$ cat n13.i
struct __attribute__ ((packed)) A { int i; };
struct B {
  struct A a;
} b;

long *p = (long*)
int *q = (int*)
[hjl@gnu-skx-1 pr51628]$ make n13.s
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n13.i
n13.i:6:18: warning: taking address of packed member of ‘struct A’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
 long *p = (long*)
  ^~
n13.i:7:16: warning: taking address of packed member of ‘struct B’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
 int *q = (int*)
^~~~
[hjl@gnu-skx-1 pr51628]$


-- 
H.J.

[Bug libstdc++/85812] [7/8 Regression] make_exception_ptr can leak the allocated exception if construction throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed for 7.4 and 8.2

[Bug libstdc++/85812] [7/8 Regression] make_exception_ptr can leak the allocated exception if construction throws

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu May 17 17:26:44 2018
New Revision: 260331

URL: https://gcc.gnu.org/viewcvs?rev=260331=gcc=rev
Log:
PR libstdc++/85812 fix memory leak in std::make_exception_ptr

PR libstdc++/85812
* libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare.
* libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]:
Refactor to separate non-throwing and throwing implementations.
[__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory
if constructing the object throws.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/libsupc++/cxxabi_init_exception.h
branches/gcc-7-branch/libstdc++-v3/libsupc++/exception_ptr.h

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed for 8.2

[Bug libstdc++/85821] Chrono literal operators do not follow the standard declarataions

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The simple answer is of course "don't do that". Writing 1s works fine, or if
you want to be explicit, std::chrono::seconds(1).

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Mathias Stearn from comment #7)
> > Simply returning an empty exception_ptr is what happened before the PR 64241
> > change, so what we do now retains that behaviour. That might be the main
> > reason for it.
> 
> Silently dropping errors always skeeves me out. I'm not sure if anyone is
> well served by the current behavior. If it were up to me (and I know it
> isn't) I'd make that case call std::terminate() or similar rather than
> returning the "no error" value. That seems consistent with the behavior of
> the __throw* functions, but it is a breaking change. Or even better, since
> gcc seems fine throwing through functions marked noexcept in -fno-exceptions
> TUs, maybe in the (very rare) case where copying/moving an exception throws
> inside an -fno-exceptions TU, just let it bubble out.
> 
> > ::new (__e) _Ex(std::forward<_Ex>(__ex));
> 
> Should that be std::move(__ex)?

That would move from an lvalue if called as:

  E e;
  std::make_exception_ptr(e);

I don't know if that's valid (I sent an email to the LWG reflector about that a
few minutes ago).

> I don't know why, but make_exception_ptr
> takes the exception by value rather than forwarding ref.

Probably so it decays (which "throw e;" will do anyway).

> I guess
> forward<_Ex> is fine either way, and will stay correct if that defect gets
> fixed. It just seemed odd to forward a value so I thought I'd mention it.
> 
> > Mix-and-match works if the function gets inlined.
> 
> Do you think this case warrants a [[gnu::always_inline]]? Given the

Without thinking about it too deeply, no I don't think it should have that. It
could have negative consequences on the optimization of other code around the
call to make_exception_ptr (which might be more important, non-error handling
code, that should be inlined in preference to the error-handling path).

> sensitive nature of error handling, it seems pretty bad if a correct usage
> of make_exception_ptr() could be silently transformed to return the "no
> error" value just by linking in a bad library. Even if that library never
> dynamically executes make_exception_ptr(). I know I'd hate to be called in
> to debug that issue...
> 
> I'm going to go make sure no code we link with uses -fno-exceptions!

Rather than always_inline a better option might be to give it a different
mangled name when exceptions are disabled (or just not declare it at all, but
it might be too late for that as it would be a breaking change). That would
ensure the return-null version never gets chosen by the linker to replace the
real version.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redbeard0531 at gmail dot com]

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

--- Comment #7 from Mathias Stearn  ---
> Simply returning an empty exception_ptr is what happened before the PR 64241
> change, so what we do now retains that behaviour. That might be the main
> reason for it.

Silently dropping errors always skeeves me out. I'm not sure if anyone is well
served by the current behavior. If it were up to me (and I know it isn't) I'd
make that case call std::terminate() or similar rather than returning the "no
error" value. That seems consistent with the behavior of the __throw*
functions, but it is a breaking change. Or even better, since gcc seems fine
throwing through functions marked noexcept in -fno-exceptions TUs, maybe in the
(very rare) case where copying/moving an exception throws inside an
-fno-exceptions TU, just let it bubble out.

> ::new (__e) _Ex(std::forward<_Ex>(__ex));

Should that be std::move(__ex)? I don't know why, but make_exception_ptr takes
the exception by value rather than forwarding ref. I guess forward<_Ex> is fine
either way, and will stay correct if that defect gets fixed. It just seemed odd
to forward a value so I thought I'd mention it.

> Mix-and-match works if the function gets inlined.

Do you think this case warrants a [[gnu::always_inline]]? Given the sensitive
nature of error handling, it seems pretty bad if a correct usage of
make_exception_ptr() could be silently transformed to return the "no error"
value just by linking in a bad library. Even if that library never dynamically
executes make_exception_ptr(). I know I'd hate to be called in to debug that
issue...

I'm going to go make sure no code we link with uses -fno-exceptions!

[Bug libstdc++/85821] New: Chrono literal operators do not follow the standard declarataions

[andreas.molzer at gmx dot de]

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

Bug ID: 85821
   Summary: Chrono literal operators do not follow the standard
declarataions
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreas.molzer at gmx dot de
  Target Milestone: ---

The literal operators provided by std::literals::chrono_literals are missing
their overloads for unsigned long long arguments.  They instead provide a
declaration for long double and a non-standard declaration with template
argument list.  This silently breaks valid code:

#include 
int main() {
using namespace std::chrono_literals;
auto time = operator""s(1ull);
}

Name resolution will only find the single matching overload and convert the
argument to long double.  This will result in a duration with unspecified
representation, in libstdc++ case a long double.  The standard would instead
require the result to be std::chrono::seconds with representation of an
unspecified integral type with a minimum number of bits. 

This can have various additional effects, including decltype(time)::max()
returning an invalid result, so that the normally perfectly valid

std::chrono::seconds::rep max = decltype(time)::max()

will result in undefined behaviour due to the long double maximum value not
fitting inside the unsigned long long.

The following code should be rejected because overload resolution should not be
able to determine a best match:

#include 
int main() {
using namespace std::chrono_literals;
auto time = operator""s(0);  // int, no priority for conversion to ull or
ld
}

[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
OK thanks for following up.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-17
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #6 from Jonathan Wakely  ---
Let's confirm this as a valid enhancement request anyway.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Mathias Stearn from comment #3)
> > My assumption was that if E(...) throws and it can't be caught, it should be
> > treated as any other case when an -fno-exceptions TU calls a throwing
> > function. In this case that would mean calling terminate() due to the
> > noexcept, which seems better than returning a null exception_ptr.
> 
> Simply returning an empty exception_ptr is what happened before the PR 64241
> change, so what we do now retains that behaviour. That might be the main
> reason for it.

Oops, wrong PR number, I meant PR 68297.

Before the PR 64241 change we just returned undefined garbage!

[Bug tree-optimization/85820] [9 Regression] internal compiler error: Segmentation fault

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
This is most likely dup of PR85817. Could you check if the fix in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85817#c1 works ?

Thanks,
Prathamesh

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Mathias Stearn from comment #3)
> My assumption was that if E(...) throws and it can't be caught, it should be
> treated as any other case when an -fno-exceptions TU calls a throwing
> function. In this case that would mean calling terminate() due to the
> noexcept, which seems better than returning a null exception_ptr.

Simply returning an empty exception_ptr is what happened before the PR 64241
change, so what we do now retains that behaviour. That might be the main reason
for it.

It would be possible to use the new throw-less implementation for the
-fno-exceptions case. It would be fine for types with a non-throwing move, at
least:


--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -185,7 +185,7 @@ namespace std
  __exception_ptr::__dest_thunk<_Ex>);
   try
{
-  ::new (__e) _Ex(__ex);
+  ::new (__e) _Ex(std::forward<_Ex>(__ex));
   return exception_ptr(__e);
}
   catch(...)
@@ -203,7 +203,19 @@ namespace std
  return current_exception();
}
 #else // no RTTI and no exceptions
+#if __cplusplus >= 201103L
+  if _GLIBCXX17_CONSTEXPR (std::is_nothrow_move_constructible<_Ex>::value)
+   {
+ void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
+ (void) __cxxabiv1::__cxa_init_primary_exception(
+ __e, const_cast((__ex)),
+ __exception_ptr::__dest_thunk<_Ex>);
+  ::new (__e) _Ex(std::forward<_Ex>(__ex));
+  return exception_ptr(__e);
+   }
+#else
   return exception_ptr();
+#endif
 #endif
 }




> Is that just accepted, implying the the whole program must be compiled with
> either -fexceptions or -fno-exeptions, rather than allowing mix-and-match?
> If so, I guess this whole point is moot.

Mix-and-match works if the function gets inlined.

But if you mix -fexceptions and -fno-exceptions then you do have to accept that
the resulting ODR violations might give surprising or undesirable results.

Re: So what's the status of the Git migration?

[Eric S. Raymond]

Richard Earnshaw (lists) :
> Another year; another release; and still no sign of progress on the git
> migration.
> 
> Any ideas on how much longer this is going to take?
> 
> R.

I'm still working on it.  It's a slow process because the repo is so huge
that full conversions take around 9 hours each,  That means that on
a good day I can test naybe two point changes.  

The current issue - and, I think, the last major one - is that there are
over 150 nid-branch deletes to be resolved.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Pat Haugen  ---
Fixed.

Re: PR83648

[H.J. Lu]

On Mon, May 14, 2018 at 11:11 PM, Prathamesh Kulkarni
 wrote:
> On 12 January 2018 at 18:26, Richard Biener  wrote:
>> On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote:
>>
>>> On 12 January 2018 at 05:02, Jeff Law  wrote:
>>> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
>>> >> On 11 January 2018 at 04:50, Jeff Law  wrote:
>>> >>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>> 
>>>  As Jakub pointed out for the case:
>>>  void *f()
>>>  {
>>>    return __builtin_malloc (0);
>>>  }
>>> 
>>>  The malloc propagation would set f() to malloc.
>>>  However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
>>>  be marked as malloc ?
>>> >>> This seems like a pretty significant concern.   Given:
>>> >>>
>>> >>>
>>> >>>  return  n ? 0 : __builtin_malloc (n);
>>> >>>
>>> >>> Is the function malloc-like enough to allow it to be marked?
>>> >>>
>>> >>> If not, then ISTM we have to be very conservative in what we mark.
>>> >>>
>>> >>> foo (n, m)
>>> >>> {
>>> >>>   return n ? 0 : __builtin_malloc (m);
>>> >>> }
>>> >>>
>>> >>> Is that malloc-like enough to mark?
>>> >> Not sure. Should I make it more conservative by marking it as malloc
>>> >> only if the argument to __builtin_malloc
>>> >> is constant or it's value-range is known not to include 0? And
>>> >> similarly for __builtin_calloc ?
>>> > It looks like the consensus is we don't need to worry about the cases
>>> > above.  So unless Jakub chimes in with a solid reason, don't worry about
>>> > them.
>>> Thanks everyone for the clarification. The attached patch skips on 0 phi 
>>> arg,
>>> and returns false if -fno-delete-null-pointer-checks is passed.
>>>
>>> With the patch, malloc_candidate_p returns true for
>>> return 0;
>>> or
>>> ret = phi<0, 0>
>>> return ret
>>>
>>> which I believe is OK as far as correctness is concerned.
>>> However as Martin points out suggesting malloc attribute for return 0
>>> case is not ideal.
>>> I suppose we can track the return 0 (or when value range of return
>>> value is known not to include 0)
>>> corner case and avoid suggesting malloc for those ?
>>>
>>> Validation in progress.
>>> Is this patch OK for next stage-1 ?
>>
>> Ok.
> I have committed this as r260250 after bootstrap+test on x86_64 on top of 
> trunk.

r260250 caused:

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

-- 
H.J.

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #9 from Pat Haugen  ---
Author: pthaugen
Date: Thu May 17 16:19:16 2018
New Revision: 260329

URL: https://gcc.gnu.org/viewcvs?rev=260329=gcc=rev
Log:
PR target/85698
* config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest
operand.

* gcc.target/powerpc/pr85698.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr85698.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85820] New: [9 Regression] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

Bug ID: 85820
   Summary: [9 Regression] internal compiler error: Segmentation
fault
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r260250 caused:

gfortran  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG
-DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4   wrf_num_bytes_between.o
pack_utils.o module_driver_constants.fppized.o module_domain.fppized.o
module_integrate.fppized.o module_timing.fppized.o module_configure.fppized.o
module_tiles.fppized.o module_machine.fppized.o module_nesting.fppized.o
module_wrf_error.fppized.o module_state_description.fppized.o
module_sm.fppized.o module_io.fppized.o module_dm_stubs.fppized.o
module_quilt_outbuf_ops.fppized.o module_io_quilt.fppized.o module_bc.fppized.o
module_io_wrf.fppized.o module_date_time.fppized.o module_io_domain.fppized.o
module_bc_time_utilities.fppized.o module_model_constants.fppized.o
module_soil_pre.fppized.o module_bl_mrf.fppized.o module_sf_myjsfc.fppized.o
module_bl_myjpbl.fppized.o module_bl_ysu.fppized.o module_cu_bmj.fppized.o
module_mp_kessler.fppized.o module_mp_ncloud5.fppized.o module_ra_sw.fppized.o
module_sf_sfclay.fppized.o module_cu_kf.fppized.o module_cu_kfeta.fppized.o
module_mp_lin.fppized.o module_mp_wsm3.fppized.o module_mp_wsm5.fppized.o
module_mp_wsm6.fppized.o module_surface_driver.fppized.o module_cu_gd.fppized.o
module_sf_sfcdiags.fppized.o module_ra_gsfcsw.fppized.o
module_sf_slab.fppized.o module_sf_noahlsm.fppized.o module_sf_ruclsm.fppized.o
module_mp_ncloud3.fppized.o module_mp_etanew.fppized.o module_ra_rrtm.fppized.o
module_ra_gfdleta.fppized.o module_physics_init.fppized.o
module_physics_addtendc.fppized.o module_solvedebug_em.fppized.o
module_bc_em.fppized.o module_advect_em.fppized.o module_diffusion_em.fppized.o
module_small_step_em.fppized.o module_big_step_utilities_em.fppized.o
module_em.fppized.o module_init_utilities.fppized.o
module_optional_si_input.fppized.o ESMF_Alarm.fppized.o ESMF_Base.fppized.o
ESMF_BaseTime.fppized.o ESMF_Calendar.fppized.o ESMF_Clock.fppized.o
ESMF_Fraction.fppized.o ESMF_Mod.fppized.o ESMF_Time.fppized.o
ESMF_TimeInterval.fppized.o Meat.fppized.o wrf_shutdown.fppized.o
collect_on_comm.o mediation_integrate.fppized.o
mediation_feedback_domain.fppized.o mediation_force_domain.fppized.o
mediation_interp_domain.fppized.o mediation_wrfmain.fppized.o
wrf_auxhist1in.fppized.o wrf_auxhist1out.fppized.o wrf_auxhist2in.fppized.o
wrf_auxhist2out.fppized.o wrf_auxhist3in.fppized.o wrf_auxhist3out.fppized.o
wrf_auxhist4in.fppized.o wrf_auxhist4out.fppized.o wrf_auxhist5in.fppized.o
wrf_auxhist5out.fppized.o wrf_auxinput1in.fppized.o wrf_auxinput1out.fppized.o
wrf_auxinput2in.fppized.o wrf_auxinput2out.fppized.o wrf_auxinput3in.fppized.o
wrf_auxinput3out.fppized.o wrf_auxinput4in.fppized.o wrf_auxinput4out.fppized.o
wrf_auxinput5in.fppized.o wrf_auxinput5out.fppized.o wrf_bdyin.fppized.o
wrf_bdyout.fppized.o wrf_histin.fppized.o wrf_histout.fppized.o
wrf_inputin.fppized.o wrf_inputout.fppized.o wrf_restartin.fppized.o
wrf_restartout.fppized.o couple_or_uncouple_em.fppized.o
interp_domain_em.fppized.o interp_fcn.fppized.o nest_init_utils.fppized.o
set_timekeeping.fppized.o sint.fppized.o solve_interface.fppized.o
start_domain.fppized.o module_pbl_driver.fppized.o
module_radiation_driver.fppized.o module_cumulus_driver.fppized.o
module_microphysics_driver.fppized.o solve_em.fppized.o start_em.fppized.o
internal_header_util.fppized.o io_int.fppized.o init_modules_em.fppized.o
init_modules.fppized.o wrf_io.o field_routines.o wrf.fppized.o netcdf/attr.o
netcdf/dim.o netcdf/error.o netcdf/fort-attio.o netcdf/fort-control.o
netcdf/fort-dim.o netcdf/fort-genatt.o netcdf/fort-geninq.o
netcdf/fort-genvar.o netcdf/fort-lib.o netcdf/fort-misc.o
netcdf/fort-v2compat.o netcdf/fort-var1io.o netcdf/fort-varaio.o
netcdf/fort-vario.o netcdf/fort-varmio.o netcdf/fort-varsio.o netcdf/libvers.o
netcdf/nc.o netcdf/ncx.o netcdf/posixio.o netcdf/putget.o netcdf/string.o
netcdf/v1hpg.o netcdf/v2i.o netcdf/var.o netcdf/typeSizes.o netcdf/netcdf.o
-o wrf
...
during RTL pass: expand
internal_header_util.fppized.f90: In function
'int_get_ti_header_char.constprop':
internal_header_util.fppized.f90:372:1: internal compiler error: Segmentation
fault
DataHandle, dummyData, DummyCount, code )
 ^
0xbb1a4f crash_signal
../../src-trunk/gcc/toplev.c:325
0x7a679b expand_call(tree_node*, rtx_def*, int)
../../src-trunk/gcc/calls.c:4287
0x8b6c7b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 17 16:10:26 2018
New Revision: 260328

URL: https://gcc.gnu.org/viewcvs?rev=260328=gcc=rev
Log:
PR libstdc++/85818 ensure path::preferred_separator is defined

Because path.cc is compiled with -std=gnu++17 the static constexpr
data member is implicitly 'inline' and so no definition gets emitted
unless it gets used in that translation unit. Other translation units
built as C++11 or C++14 still require a namespace-scope definition of
the variable, so mark the definition as used.

PR libstdc++/85818
* src/filesystem/path.cc (path::preferred_separator): Add used
attribute.
* testsuite/experimental/filesystem/path/preferred_separator.cc: New.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/src/filesystem/path.cc

[Bug libstdc++/85812] [7/8 Regression] make_exception_ptr can leak the allocated exception if construction throws

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu May 17 16:10:20 2018
New Revision: 260327

URL: https://gcc.gnu.org/viewcvs?rev=260327=gcc=rev
Log:
PR libstdc++/85812 fix memory leak in std::make_exception_ptr

PR libstdc++/85812
* libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare.
* libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]:
Refactor to separate non-throwing and throwing implementations.
[__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory
if constructing the object throws.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/libsupc++/cxxabi_init_exception.h
branches/gcc-8-branch/libstdc++-v3/libsupc++/exception_ptr.h

Re: Auto-generated .rodata contents and __attribute__((section))

[Michael Matz]

Hi,

On Wed, 16 May 2018, Richard Biener wrote:

> > Are constant pool entries merged at compile time or at link time? I 
> > would presume it should be done at link time because otherwise you're 
> > only merging entries within a single compilation unit (which doesn't 
> > sound that useful in a big project with hundreds of source files), 
> > right?
> 
> constant pool entries are merged at compile time.  There's no such thing
> as mergeable constant pool sections 

Actually there is in ELF.  Mergable sections can not only hold strings, 
but also fixed-size entities (e.g. 4 or 8 byte constants).  Those are 
merged content-wise at link time and references properly rewritten.  Of 
course, those still aren't per-function.


Ciao,
Michael.

Re: [PATCH rs6000] Fix PR85698

[Segher Boessenkool]

On Thu, May 17, 2018 at 10:42:46AM -0500, Pat Haugen wrote:
> The following patch fixes a problem that resulted in incorrect code 
> generation for the CPU2017 benchmark 525.x264_r. The fix correctly checks the 
> "dest" operand, which is the memory operand.
> 
> Bootstrap/regtest on powerp64le and powerpc64 (-m32/-m64) with no new
> regressions. Ok for trunk?

Okay.  Thanks!


Segher


> 2018-05-17  Pat Haugen  
>   Segher Boessenkool  
> 
>   PR target/85698
>   * config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest 
> operand.
> 
> testsuite/ChangeLog:
> 2018-05-17  Pat Haugen  
> 
>   PR target/85698
>   * gcc.target/powerpc/pr85698.c: New test.

[Bug fortran/85816] [8/9 Regression] nested spread fails with "Integer overflow in xmallocarray"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||wrong-code
   Last reconfirmed||2018-05-17
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|nested spread fails with|[8/9 Regression] nested
   |"Integer overflow in|spread fails with "Integer
   |xmallocarray"   |overflow in xmallocarray"
   Target Milestone|--- |8.2
  Known to fail||8.1.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
> Operating system error: Cannot allocate memory
> Integer overflow in xmallocarray

Confirmed at run time.

Caused by revision r257065.

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

[Bin.Cheng]

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

[Bug fortran/82617] Internal compiler error in expand_expr_real_1 when compiling the attached file

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||pault at gcc dot gnu.org
  Component|middle-end  |fortran

--- Comment #4 from Dominique d'Humieres  ---
AFAICT this seems fixed by the patch at
https://gcc.gnu.org/ml/fortran/2018-05/msg00046.html, likely a duplicate of
pr82923.

[PATCH rs6000] Fix PR85698

[Pat Haugen]

The following patch fixes a problem that resulted in incorrect code generation 
for the CPU2017 benchmark 525.x264_r. The fix correctly checks the "dest" 
operand, which is the memory operand.

Bootstrap/regtest on powerp64le and powerpc64 (-m32/-m64) with no new
regressions. Ok for trunk?

-Pat


2018-05-17  Pat Haugen  
Segher Boessenkool  

PR target/85698
* config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest 
operand.

testsuite/ChangeLog:
2018-05-17  Pat Haugen  

PR target/85698
* gcc.target/powerpc/pr85698.c: New test.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 260267)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -20234,7 +20234,7 @@ rs6000_output_move_128bit (rtx operands[
}
 
   else if (TARGET_ALTIVEC && src_vmx_p
-  && altivec_indexed_or_indirect_operand (src, mode))
+  && altivec_indexed_or_indirect_operand (dest, mode))
return "stvx %1,%y0";
 
   else if (TARGET_VSX && src_vsx_p)
Index: gcc/testsuite/gcc.target/powerpc/pr85698.c
===
--- gcc/testsuite/gcc.target/powerpc/pr85698.c  (nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr85698.c  (working copy)
@@ -0,0 +1,79 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vsx_hw } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
+/* { dg-options "-O3 -mcpu=power7" } */
+
+/* PR85698: Incorrect code generated on LE due to use of stxvw4x. */
+
+typedef unsigned char uint8_t;
+typedef short int16_t;
+extern void abort (void);
+extern int memcmp(const void *, const void *, __SIZE_TYPE__);
+
+uint8_t expected[128] =
+{14, 0, 4, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
+ 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 28, 35, 33, 35, 36, 37, 38, 39, 40,
+ 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61, 62, 63, 66, 63, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
+ 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 97, 96,
+ 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113,
+ 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127};
+
+static uint8_t x264_clip_uint8( int x )
+{
+  return x&(~255) ? (-x)>>31 : x;
+}
+void add4x4_idct( uint8_t *p_dst, int16_t dct[16])
+{
+  int16_t d[16];
+  int16_t tmp[16];
+  int i, y, x;
+  for( i = 0; i < 4; i++ )
+{
+  int s02 =  dct[0*4+i] +  dct[2*4+i];
+  int d02 =  dct[0*4+i] -  dct[2*4+i];
+  int s13 =  dct[1*4+i] + (dct[3*4+i]>>1);
+  int d13 = (dct[1*4+i]>>1) -  dct[3*4+i];
+  tmp[i*4+0] = s02 + s13;
+  tmp[i*4+1] = d02 + d13;
+  tmp[i*4+2] = d02 - d13;
+  tmp[i*4+3] = s02 - s13;
+}
+  for( i = 0; i < 4; i++ )
+{
+  int s02 =  tmp[0*4+i] +  tmp[2*4+i];
+  int d02 =  tmp[0*4+i] -  tmp[2*4+i];
+  int s13 =  tmp[1*4+i] + (tmp[3*4+i]>>1);
+  int d13 = (tmp[1*4+i]>>1) -  tmp[3*4+i];
+  d[0*4+i] = ( s02 + s13 + 32 ) >> 6;
+  d[1*4+i] = ( d02 + d13 + 32 ) >> 6;
+  d[2*4+i] = ( d02 - d13 + 32 ) >> 6;
+  d[3*4+i] = ( s02 - s13 + 32 ) >> 6;
+}
+  for( y = 0; y < 4; y++ )
+{
+  for( x = 0; x < 4; x++ )
+p_dst[x] = x264_clip_uint8( p_dst[x] + d[y*4+x] );
+  p_dst += 32;
+}
+}
+
+int main()
+{
+  uint8_t dst[128];
+  int16_t dct[16];
+  int i;
+
+  for (i = 0; i < 16; i++)
+dct[i] = i*10 + i;
+  for (i = 0; i < 128; i++)
+dst[i] = i;
+
+  add4x4_idct(dst, dct);
+
+  if (memcmp (dst, expected, 128))
+abort();
+
+ return 0;
+}
+

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu May 17 15:36:25 2018
New Revision: 260326

URL: https://gcc.gnu.org/viewcvs?rev=260326=gcc=rev
Log:
PR libstdc++/85818 ensure path::preferred_separator is defined

Because path.cc is compiled with -std=gnu++17 the static constexpr
data member is implicitly 'inline' and so no definition gets emitted
unless it gets used in that translation unit. Other translation units
built as C++11 or C++14 still require a namespace-scope definition of
the variable, so mark the definition as used.

PR libstdc++/85818
* src/filesystem/path.cc (path::preferred_separator): Add used
attribute.
* testsuite/experimental/filesystem/path/preferred_separator.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/path.cc

[PATCH] PR libstdc++/85818 ensure path::preferred_separator is defined

[Jonathan Wakely]

Because path.cc is compiled with -std=gnu++17 the static constexpr
data member is implicitly 'inline' and so no definition gets emitted
unless it gets used in that translation unit. Other translation units
built as C++11 or C++14 still require a namespace-scope definition of
the variable, so mark the definition as used.

PR libstdc++/85818
* src/filesystem/path.cc (path::preferred_separator): Add used
attribute.
* testsuite/experimental/filesystem/path/preferred_separator.cc: New.

Tested powerpc64le-linux, committed to trunk. Backport to gcc-8 to
follow.



commit e80e2abad41faf6bd62bd1f08baa86f71714811e
Author: Jonathan Wakely 
Date:   Thu May 17 13:59:00 2018 +0100

PR libstdc++/85818 ensure path::preferred_separator is defined

Because path.cc is compiled with -std=gnu++17 the static constexpr
data member is implicitly 'inline' and so no definition gets emitted
unless it gets used in that translation unit. Other translation units
built as C++11 or C++14 still require a namespace-scope definition of
the variable, so mark the definition as used.

PR libstdc++/85818
* src/filesystem/path.cc (path::preferred_separator): Add used
attribute.
* testsuite/experimental/filesystem/path/preferred_separator.cc: 
New.

diff --git a/libstdc++-v3/src/filesystem/path.cc 
b/libstdc++-v3/src/filesystem/path.cc
index 4d84168d742..899d94e0067 100644
--- a/libstdc++-v3/src/filesystem/path.cc
+++ b/libstdc++-v3/src/filesystem/path.cc
@@ -33,7 +33,7 @@ using fs::path;
 
 fs::filesystem_error::~filesystem_error() = default;
 
-constexpr path::value_type path::preferred_separator;
+constexpr path::value_type path::preferred_separator [[gnu::used]];
 
 path&
 path::remove_filename()
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc
new file mode 100644
index 000..b470e312bb1
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc
@@ -0,0 +1,34 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-O0 -lstdc++fs -std=gnu++11" }
+// { dg-do link { target c++11 } }
+
+#include 
+
+std::experimental::filesystem::path::value_type
+test01()
+{
+  auto* sep = ::experimental::filesystem::path::preferred_separator;
+  return *sep;
+}
+
+int
+main()
+{
+  test01();
+}

[PATCH] PR libstdc++/85812 fix memory leak in std::make_exception_ptr

[Jonathan Wakely]

As the PR points out, the constructor called in the placement new
expression can throw, in which case the allocation would be leaked.

Separating the two implementations makes it much easier to read what
the code is doing.

PR libstdc++/85812
* libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare.
* libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]:
Refactor to separate non-throwing and throwing implementations.
[__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory
if constructing the object throws.

Tested powerpc64le-linux (and also using ASan to verify the fix).
Committed to trunk. Backports to gcc-7 and gcc-8 will follow.


commit 3d02d84556f2be22945d397ed2fb4dbff8a0788e
Author: Jonathan Wakely 
Date:   Thu May 17 13:51:04 2018 +0100

PR libstdc++/85812 fix memory leak in std::make_exception_ptr

PR libstdc++/85812
* libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare.
* libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]:
Refactor to separate non-throwing and throwing implementations.
[__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory
if constructing the object throws.

diff --git a/libstdc++-v3/libsupc++/cxxabi_init_exception.h 
b/libstdc++-v3/libsupc++/cxxabi_init_exception.h
index d973a087f14..e438c1008d9 100644
--- a/libstdc++-v3/libsupc++/cxxabi_init_exception.h
+++ b/libstdc++-v3/libsupc++/cxxabi_init_exception.h
@@ -62,6 +62,9 @@ namespace __cxxabiv1
   void*
   __cxa_allocate_exception(size_t) _GLIBCXX_NOTHROW;
 
+  void
+  __cxa_free_exception(void*) _GLIBCXX_NOTHROW;
+
   // Initialize exception (this is a GNU extension)
   __cxa_refcounted_exception*
   __cxa_init_primary_exception(void *object, std::type_info *tinfo,
diff --git a/libstdc++-v3/libsupc++/exception_ptr.h 
b/libstdc++-v3/libsupc++/exception_ptr.h
index a927327214d..bd355ed880b 100644
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -178,25 +178,31 @@ namespace std
 exception_ptr 
 make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
 {
-#if __cpp_exceptions
+#if __cpp_exceptions && __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI
+  void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
+  (void) __cxxabiv1::__cxa_init_primary_exception(
+ __e, const_cast((__ex)),
+ __exception_ptr::__dest_thunk<_Ex>);
   try
{
-#if __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI
-  void *__e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
-  (void)__cxxabiv1::__cxa_init_primary_exception(
- __e, const_cast((__ex)),
- __exception_ptr::__dest_thunk<_Ex>);
   ::new (__e) _Ex(__ex);
   return exception_ptr(__e);
-#else
+   }
+  catch(...)
+   {
+ __cxxabiv1::__cxa_free_exception(__e);
+ return current_exception();
+   }
+#elif __cpp_exceptions
+  try
+   {
   throw __ex;
-#endif
}
   catch(...)
{
  return current_exception();
}
-#else
+#else // no RTTI and no exceptions
   return exception_ptr();
 #endif
 }

[Bug fortran/82814] ICE from submodule character function

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Paul Thomas  ---
The PR was already fixed on 6- and 7-branches in the course of fixing another
bug. All that was needed was the testcase.

Thanks for the report.

Paul

[Bug fortran/82814] ICE from submodule character function

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Thu May 17 15:31:42 2018
New Revision: 260325

URL: https://gcc.gnu.org/viewcvs?rev=260325=gcc=rev
Log:
2017-05-17  Paul Thomas  

PR fortran/82814
* gfortran.dg/submodule_31.f08: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_31.f08
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog

Re: So what's the status of the Git migration?

[Joseph Myers]

On Thu, 17 May 2018, Richard Earnshaw (lists) wrote:

> Another year; another release; and still no sign of progress on the git
> migration.
> 
> Any ideas on how much longer this is going to take?

See git://thyrsus.com/repositories/gcc-conversion.git for the current 
version of the conversion machinery, including a TODO list (and see also 
http://esr.ibiblio.org/?p=7959 ).

Presumably required work on the GCC side (deciding appropriate policies on 
branch deletion / non-fast-forward pushes, developing hooks / repository 
configuration to implement those policies and send commit mails, writing 
updates to documentation and scripts) could be done in parallel with the 
conversion work, but Jason may already have some of that done anyway.

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

Re: [PATCH][AArch64] Unify vec_set patterns, support floating-point vector modes properly

[Wilco Dijkstra]

Kyrill Tkachov wrote:

> That patch would look like the attached. Is this preferable?
> For the above example it generates the desired:
> foo_v4sf:
>   ldr s0, [x0]
>   ldr s1, [x1, 8]
>   ins v0.s[1], v1.s[0]
>   ld1 {v0.s}[2], [x2]
>   ld1 {v0.s}[3], [x3]
>    ret

Yes that's what I expect. Also with only non-zero offsets we emit:

foo_v2di:
ldr d0, [x0, 8]
ldr d1, [x1, 16]
ins v0.d[1], v1.d[0]
ret

foo_v4sf:
ldr s0, [x0, 4]
ldr s3, [x1, 20]
ldr s2, [x2, 32]
ldr s1, [x3, 80]
ins v0.s[1], v3.s[0]
ins v0.s[2], v2.s[0]
ins v0.s[3], v1.s[0]
ret

The patch looks good now, lots of patterns removed, yet we generate better code!

Wilco

[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Dominique d'Humieres  ---
Duplicate of pr85599.

*** This bug has been marked as a duplicate of bug 85599 ***

[Bug fortran/85599] Prevent short-circuiting of logical expressions for non-pure functions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #30 from Dominique d'Humieres  ---
*** Bug 57160 has been marked as a duplicate of this bug. ***

[Bug fortran/82814] ICE from submodule character function

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Thu May 17 15:17:43 2018
New Revision: 260324

URL: https://gcc.gnu.org/viewcvs?rev=260324=gcc=rev
Log:
2017-05-17  Paul Thomas  

PR fortran/82814
* gfortran.dg/submodule_31.f08: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/submodule_31.f08
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/66694] Failure in function returning an allocated CHARACTER array

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
This PR seems fixed by the patch at
https://gcc.gnu.org/ml/fortran/2018-05/msg00046.html, likely a duplicate of
pr82923.

On darwin the executable hangs due to pr30617.

[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function

[joshua.r.marshall.1991 at gmail dot com]

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

Josh Marshall  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #2 from Josh Marshall  ---
Created attachment 44143
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44143=edit
Example file

I got to making an example, but it seems that this is no longer a problem.  I'm
going to close this one out as invalid.

Re: Rb_tree constructor optimization

[Jonathan Wakely]

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


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



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

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

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

Ok to commit ?


Yes, OK for trunk - thanks.

[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
I confirm I get the ICE on trunk 260152 and on a sanitized version I also get

../../gcc/gcc/tree-ssa-strlen.c:721:11: runtime error: member access
within null pointer of type 'struct strinfo'

Thank you for the very useful reduction, Martin.

[Bug libstdc++/85812] [7/8/9 Regression] make_exception_ptr can leak the allocated exception if construction throws

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 17 15:03:29 2018
New Revision: 260323

URL: https://gcc.gnu.org/viewcvs?rev=260323=gcc=rev
Log:
PR libstdc++/85812 fix memory leak in std::make_exception_ptr

PR libstdc++/85812
* libsupc++/cxxabi_init_exception.h (__cxa_free_exception): Declare.
* libsupc++/exception_ptr.h (make_exception_ptr) [__cpp_exceptions]:
Refactor to separate non-throwing and throwing implementations.
[__cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI]: Deallocate the memory
if constructing the object throws.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/cxxabi_init_exception.h
trunk/libstdc++-v3/libsupc++/exception_ptr.h

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Martin Sebor  ---
That's right, bug 82063 tracks the inability to turn off the warning.  This
report is about the false positive (only).  Hopefully, that will go away once
we fix 85795.

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

[Jason Merrill]

On Thu, May 17, 2018 at 10:27 AM, Paolo Carlini
 wrote:
> PS: maybe better using function_declarator_p?

I think so, yes.  The relevant rule seems to be "The declarator shall
not specify a function or an array.", so let's check for arrays, too.

Jason

Re: [PING] [PATCH] Avoid excessive function type casts with splay-trees

[Bernd Edlinger]

On 05/17/18 15:39, Richard Biener wrote:
> On Thu, May 17, 2018 at 3:21 PM Bernd Edlinger 
> wrote:
> 
>> Ping...
> 
> So this makes all traditional users go through the indirect
> splay_tree_compare_wrapper
> and friends (which is also exported for no good reason?).  And all users
> are traditional
> at the moment.
> 

all except gcc/typed-splay-tree.h which only works if VALUE_TYPE is
compatible with uint_ptr_t but cannot check this requirement.
This one worried me the most.

But not having to rewrite omp-low.c for instance where splay_tree_lookup
and access to n->value are made all the time, made me think it
will not work to rip out the old interface completely.


Bernd.

> So I wonder if it's better to have a complete alternate interface?  I do
> not see many
> users besides gcc, there's a use in bfd elf32-xtensa.c and some uses in
> gdb.  Of course
> disregarding any users outside of SRC.
> 
> Richard.
> 
> 
>> On 05/03/18 22:13, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this is basically the same patch I posted a few months ago,
>>> with a few formatting nits by Jakub fixed.
>>>
>>> Bootstrapped and reg-tested again with current trunk.
>>>
>>> Is it OK for trunk?
>>>
>>>
>>> Bernd.
>>>
>>> On 12/15/17 11:44, Bernd Edlinger wrote:
 Hi,

 when working on the -Wcast-function-type patch I noticed some rather
 ugly and non-portable function type casts that are necessary to
 accomplish
 some actually very simple tasks.

 Often functions taking pointer arguments are called with a different
 signature
 taking uintptr_t arguments, which is IMHO not really safe to do...

 The attached patch adds a context argument to the callback functions
> but
 keeps the existing interface as far as possible.


 Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
 Is it OK for trunk?


 Thanks
 Bernd.

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

[Paolo Carlini]

PS: maybe better using function_declarator_p??? I think I regression 
tested that variant too, at some point.


Paolo.

Re: [PATCH][AArch64] Unify vec_set patterns, support floating-point vector modes properly

[Kyrill Tkachov]

On 17/05/18 14:56, Kyrill Tkachov wrote:


On 17/05/18 09:46, Kyrill Tkachov wrote:


On 15/05/18 18:56, Richard Sandiford wrote:

Kyrill  Tkachov  writes:

Hi all,

We've a deficiency in our vec_set family of patterns.  We don't
support directly loading a vector lane using LD1 for V2DImode and all
the vector floating-point modes.  We do do it correctly for the other
integer vector modes (V4SI, V8HI etc) though.

The alternatives on the relative floating-point patterns only allow a
register-to-register INS instruction.  That means if we want to load a
value into a vector lane we must first load it into a scalar register
and then perform an INS, which is wasteful.

There is also an explicit V2DI vec_set expander dangling around for no
reason that I can see. It seems to do the exact same things as the
other vec_set expanders. This patch removes that.  It now unifies all
vec_set expansions into a single "vec_set" define_expand using
the catch-all VALL_F16 iterator.

I decided to leave two aarch64_simd_vec_set define_insns. One
for the integer vector modes (that now include V2DI) and one for the
floating-point vector modes. That is so that we can avoid specifying
"w,r" alternatives for floating-point modes in case the
register-allocator gets confused and starts gratuitously moving
registers between the two banks.  So the floating-point pattern only
two alternatives, one for SIMD-to-SIMD INS and one for LD1.

Did you see any cases in which this was necessary?  In some ways it
seems to run counter to Wilco's recent patches, which tended to remove
the * markers from the "unnatural" register class and trust the register
allocator to make a sensible decision.

I think our default position should be trust the allocator here.
If the consumers all require "w" registers then the RA will surely
try to use "w" registers if at all possible.  But if the consumers
don't care then it seems reasonable to offer both, since in those
cases it doesn't really make much difference whether the payload
happens to be SF or SI (say).

There are also cases in which the consumer could actively require
an integer register.  E.g. some code uses unions to bitcast floats
to ints and then do bitwise arithmetic on them.



Thanks, that makes sense. Honestly, it's been a few months since I worked on 
this patch.
I believe my reluctance to specify that alternative was that it would mean 
merging the integer and
floating-point patterns into one (like the attached version) which would put the "w, 
r" alternative
first for the floating-point case. I guess we should be able to trust the 
allocator to pick
the sensible  alternative though.



With some help from Wilco I can see how this approach will give us suboptimal 
code though.
If we modify the example from my original post to be:
v4sf
foo_v4sf (float *a, float *b, float *c, float *d)
{
v4sf res = { *a, b[2], *c, *d };
return res;
}

The b[2] load will load into a GP register then do an expensive INS into the 
SIMD register
instead of loading into an FP S-register and then doing a SIMD-to-SIMD INS.
The only way I can get it to use the FP load then is to mark the "w, r" 
alternative with a '?'



That patch would look like the attached. Is this preferable?
For the above example it generates the desired:
foo_v4sf:
ldr s0, [x0]
ldr s1, [x1, 8]
ins v0.s[1], v1.s[0]
ld1 {v0.s}[2], [x2]
ld1 {v0.s}[3], [x3]
ret


rather than loading [x1, 8] into a W-reg.

Thanks,
Kyrill



Kyrill



This version is then made even simpler due to all the vec_set patterns being 
merged into one.
Bootstrapped and tested on aarch64-none-linux-gnu.

Is this ok for trunk?

Thanks,
Kyrill

2018-05-17  Kyrylo Tkachov  

* config/aarch64/aarch64-simd.md (vec_set): Use VALL_F16 mode
iterator.  Delete separate integer-mode vec_set expander.
(aarch64_simd_vec_setv2di): Delete.
(vec_setv2di): Delete.
(aarch64_simd_vec_set): Delete all other patterns with that name.
Use VALL_F16 mode iterator.  Add LD1 alternative and use vwcore for
the "w, r" alternative.

2018-05-17  Kyrylo Tkachov  

* gcc.target/aarch64/vect-init-ld1.c: New test.


With this patch we avoid loading values into scalar registers and then
doing an explicit INS on them to move them into the desired vector
lanes. For example for:

typedef float v4sf __attribute__ ((vector_size (16)));
typedef long long v2di __attribute__ ((vector_size (16)));

v2di
foo_v2di (long long *a, long long *b)
{
v2di res = { *a, *b };
return res;
}

v4sf
foo_v4sf (float *a, float *b, float *c, float *d)
{
v4sf res = { *a, *b, *c, *d };
return res;
}

we currently generate:

foo_v2di:
  ldr d0, [x0]
  ldr x0, [x1]
  ins v0.d[1], x0
  ret

foo_v4sf:
  ldr s0, [x0]
  ldr s3, [x1]
  ldr s2, [x2]
  ldr s1, 

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redbeard0531 at gmail dot com]

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

--- Comment #3 from Mathias Stearn  ---
My assumption was that if E(...) throws and it can't be caught, it should be
treated as any other case when an -fno-exceptions TU calls a throwing function.
In this case that would mean calling terminate() due to the noexcept, which
seems better than returning a null exception_ptr.

However, while testing the behavior of mixing -fno-exceptions TUs with normal
ones, I realized there may be a bigger problem due to ODR violations. In
particular, if you link these TUs without optimizations, one of the asserts
will trip depending on the link order:

// g++ -fno-exceptions -c
#include 
#include 
void no_exceptions() {
assert(!std::make_exception_ptr(1));
}

// g++ -fexceptions
#include 
#include 
void no_exceptions();
int main() {
assert(std::make_exception_ptr(1));
no_exceptions();
}

Is that just accepted, implying the the whole program must be compiled with
either -fexceptions or -fno-exeptions, rather than allowing mix-and-match? If
so, I guess this whole point is moot.

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

[Paolo Carlini]

Hi,

thus I had to revert my first try, when it caused c++/85713. I added two 
testcases for the latter (the second one covering what I learned from 
yet another defective try which I attached to the trail of c++/84588 
yesterday) and finally figured out that the problem was that I was 
incorrectly calling abort_fully_implicit_template while tentatively 
parsing (if you look at the new lambda-generic-85713.C, that made 
impossible correctly parsing 'auto () [5]' as second lambda 
parameter).


Anyway, a few days ago, while looking for a completely different 
solution and comparing to other compilers too, I noticed that, more 
generally, we were missing a check in cp_parser_condition that we aren't 
declaring a function type when we are sure that we are handling a 
declaration: simply adding such a check covers as a special case 
c++/84588 too, and, being the check in cp_parser_condition, it 
automatically covers variants for conditions elsewhere, eg, for, while 
loops: with the patchlet below we handle all of them very similarly to 
clang and icc.


Tested x86_64-linux.

Thanks, Paolo.

//

/cp
2018-05-17  Paolo Carlini  

PR c++/84588
* parser.c (cp_parser_condition): Reject a declaration of
a function type.

/testsuite
2018-05-17  Paolo Carlini  

PR c++/84588
* g++.dg/cpp1y/pr84588.C: New.
* g++.old-deja/g++.jason/cond.C: Adjust.
Index: cp/parser.c
===
--- cp/parser.c (revision 260308)
+++ cp/parser.c (working copy)
@@ -11571,6 +11571,7 @@ cp_parser_condition (cp_parser* parser)
   tree attributes;
   cp_declarator *declarator;
   tree initializer = NULL_TREE;
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
 
   /* Parse the declarator.  */
   declarator = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
@@ -11597,15 +11598,23 @@ cp_parser_condition (cp_parser* parser)
 for sure.  */
   if (cp_parser_parse_definitely (parser))
{
- tree pushed_scope;
+ tree pushed_scope = NULL_TREE;
  bool non_constant_p;
  int flags = LOOKUP_ONLYCONVERTING;
 
  /* Create the declaration.  */
- decl = start_decl (declarator, _specifiers,
-/*initialized_p=*/true,
-attributes, /*prefix_attributes=*/NULL_TREE,
-_scope);
+ if (declarator->kind == cdk_function)
+   {
+ error_at (loc, "a function type is not allowed here");
+ if (parser->fully_implicit_function_template_p)
+   abort_fully_implicit_template (parser);
+ decl = error_mark_node;
+   }
+ else
+   decl = start_decl (declarator, _specifiers,
+  /*initialized_p=*/true,
+  attributes, /*prefix_attributes=*/NULL_TREE,
+  _scope);
 
  /* Parse the initializer.  */
  if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
Index: testsuite/g++.dg/cpp1y/pr84588.C
===
--- testsuite/g++.dg/cpp1y/pr84588.C(nonexistent)
+++ testsuite/g++.dg/cpp1y/pr84588.C(working copy)
@@ -0,0 +1,25 @@
+// { dg-do compile { target c++14 } }
+
+struct a {
+  void b() {}
+  void c(void (*) () = [] {
+  if (a a(int auto) {})  // { dg-error "two or more data types|function 
type" }
+  ;
+  }) {}
+};
+
+struct d {
+  void e() {}
+  void f(void (*) () = [] {
+  for (;d d(int auto) {};)  // { dg-error "two or more data types|function 
type" }
+  ;
+  }) {}
+};
+
+struct g {
+  void h() {}
+  void i(void (*) () = [] {
+  while (g g(int auto) {})  // { dg-error "two or more data types|function 
type" }
+  ;
+  }) {}
+};
Index: testsuite/g++.old-deja/g++.jason/cond.C
===
--- testsuite/g++.old-deja/g++.jason/cond.C (revision 260308)
+++ testsuite/g++.old-deja/g++.jason/cond.C (working copy)
@@ -47,8 +47,7 @@ int main()
   if (struct B * foo = new B)
 ;
 
-  if (int f () = 1)// { dg-warning "extern" "extern" } 
-  // { dg-error "is initialized like a variable" "var" { target *-*-* } .-1 }
+  if (int f () = 1)// { dg-error "function type" } 
 ;
   
   if (int a[2] = {1, 2})   // { dg-error "extended init" "" { target { ! 
c++11 } } }