Re: [Patch v2] Enable math functions linking with static library for LTO

[luoxhu]

On 2019/8/13 10:22, luoxhu wrote:
diff --git a/gcc/testsuite/gcc.dg/pr91287.c 
b/gcc/testsuite/gcc.dg/pr91287.c

new file mode 100644
index 000..c816e0537aa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91287.c
@@ -0,0 +1,40 @@
+/* { dg-do assemble } */
+/* { dg-options "-O2" } */


You don't use -flto here so the testcase doesn't exercise any of the patched
code.  Does it work when you add -flto here?  That is, do
scan-symbol[-not] properly use gcc-nm or the linker plugin?


-flto is needed here to check this patch correctness, my mistake here, 
thanks for catching.  atan2 will exists in pr91287.o even without lto as

pr91287.o has the instruction "bl atan2".
After adding -flto the case also works as symbol is written to pr91287.o.
PS: update other changes in patch attached.

What's more, this test case depends on this patch 
https://www.sourceware.org/ml/binutils/2019-08/msg00113.html.

otherwise nm will report error (use plugin or local gcc-nm is OK):

PASS: gcc.dg/pr91287.c (test for excess errors)
ERROR: gcc.dg/pr91287.c: error executing dg-final: /usr/bin/nm: pr91287.o: 
plugin needed to handle lto object
UNRESOLVED: gcc.dg/pr91287.c: error executing dg-final: /usr/bin/nm: 
pr91287.o: plugin needed to handle lto object


Xionghu

[PATCH, i386]: Add missing *mmx_pinsr{q,d} patterns

[Uros Bizjak]

We can implement these for TARGET_MMX_WITH_SSE and TARGET_SSE4_1.

2019-08-13  Uroš Bizjak  

* config/i386/i386.md (ix86_expand_vector_set) :
Use vec_merge path for TARGET_MMX_WITH_SSE && TARGET_SSE4_1.
: Ditto.
* config/i386/mmx.md (*mmx_pinsrd): New insn pattern.
(*mmx_pinsrb): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/i386-expand.c
===
--- config/i386/i386-expand.c   (revision 274317)
+++ config/i386/i386-expand.c   (working copy)
@@ -14243,8 +14243,13 @@ ix86_expand_vector_set (bool mmx_ok, rtx target, r
 
   switch (mode)
 {
+case E_V2SImode:
+  use_vec_merge = TARGET_MMX_WITH_SSE && TARGET_SSE4_1;
+  if (use_vec_merge)
+   break;
+  /* FALLTHRU */
+
 case E_V2SFmode:
-case E_V2SImode:
   if (mmx_ok)
{
  tmp = gen_reg_rtx (GET_MODE_INNER (mode));
@@ -14409,6 +14414,7 @@ ix86_expand_vector_set (bool mmx_ok, rtx target, r
   break;
 
 case E_V8QImode:
+  use_vec_merge = TARGET_MMX_WITH_SSE && TARGET_SSE4_1;
   break;
 
 case E_V32QImode:
Index: config/i386/mmx.md
===
--- config/i386/mmx.md  (revision 274317)
+++ config/i386/mmx.md  (working copy)
@@ -1394,6 +1394,36 @@
(set_attr "type" "mmxcvt,sselog,sselog")
(set_attr "mode" "DI,TI,TI")])
 
+(define_insn "*mmx_pinsrd"
+  [(set (match_operand:V2SI 0 "register_operand" "=x,Yv")
+(vec_merge:V2SI
+  (vec_duplicate:V2SI
+(match_operand:SI 2 "nonimmediate_operand" "rm,rm"))
+ (match_operand:V2SI 1 "register_operand" "0,Yv")
+  (match_operand:SI 3 "const_int_operand")))]
+  "TARGET_MMX_WITH_SSE && TARGET_SSE4_1
+   && ((unsigned) exact_log2 (INTVAL (operands[3]))
+   < GET_MODE_NUNITS (V2SImode))"
+{
+  operands[3] = GEN_INT (exact_log2 (INTVAL (operands[3])));
+  switch (which_alternative)
+{
+case 1:
+  return "vpinsrd\t{%3, %2, %1, %0|%0, %1, %2, %3}";
+case 0:
+  return "pinsrd\t{%3, %2, %0|%0, %2, %3}";
+default:
+  gcc_unreachable ();
+}
+}
+  [(set_attr "isa" "noavx,avx")
+   (set_attr "prefix_data16" "1")
+   (set_attr "prefix_extra" "1")
+   (set_attr "type" "sselog")
+   (set_attr "length_immediate" "1")
+   (set_attr "prefix" "orig,vex")
+   (set_attr "mode" "TI")])
+
 (define_expand "mmx_pinsrw"
   [(set (match_operand:V4HI 0 "register_operand")
 (vec_merge:V4HI
@@ -1444,6 +1474,42 @@
(set_attr "length_immediate" "1")
(set_attr "mode" "DI,TI,TI")])
 
+(define_insn "*mmx_pinsrb"
+  [(set (match_operand:V8QI 0 "register_operand" "=x,Yv")
+(vec_merge:V8QI
+  (vec_duplicate:V8QI
+(match_operand:QI 2 "nonimmediate_operand" "rm,rm"))
+ (match_operand:V8QI 1 "register_operand" "0,Yv")
+  (match_operand:SI 3 "const_int_operand")))]
+  "TARGET_MMX_WITH_SSE && TARGET_SSE4_1
+   && ((unsigned) exact_log2 (INTVAL (operands[3]))
+   < GET_MODE_NUNITS (V8QImode))"
+{
+  operands[3] = GEN_INT (exact_log2 (INTVAL (operands[3])));
+  switch (which_alternative)
+{
+case 1:
+  if (MEM_P (operands[2]))
+   return "vpinsrb\t{%3, %2, %1, %0|%0, %1, %2, %3}";
+  else
+   return "vpinsrb\t{%3, %k2, %1, %0|%0, %1, %k2, %3}";
+case 0:
+  if (MEM_P (operands[2]))
+   return "pinsrb\t{%3, %2, %0|%0, %2, %3}";
+  else
+   return "pinsrb\t{%3, %k2, %0|%0, %k2, %3}";
+default:
+  gcc_unreachable ();
+}
+}
+  [(set_attr "isa" "noavx,avx")
+   (set_attr "type" "sselog")
+   (set_attr "prefix_data16" "1")
+   (set_attr "prefix_extra" "1")
+   (set_attr "length_immediate" "1")
+   (set_attr "prefix" "orig,vex")
+   (set_attr "mode" "TI")])
+
 (define_insn "mmx_pextrw"
   [(set (match_operand:SI 0 "register_operand" "=r,r")
 (zero_extend:SI

[Bug c++/91431] New: Using class template for containers and iterators rather than defining template only for iterators caused a trouble

[p.hyundeok76 at gmail dot com]

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

Bug ID: 91431
   Summary: Using class template for containers and iterators
rather than defining template only for iterators
caused a trouble
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.hyundeok76 at gmail dot com
  Target Milestone: ---

Created attachment 46705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46705=edit
File processed through `gcc -v -save-temps [MYFILE]`

Version: g++ (GCC) 7.4.0

System type:
Cygwin on Windows 10 Home 64 bit 1903
uname -r shows:
3.0.7(0.338/5/3)

Command used to compile the source code:
g++ bug.cpp -o bug

The compiler output:
bug.cpp: In instantiating of 'class Blob':
bug.cpp:23.19:required here
bug.cpp:11.4: Internal compiler error: in tsubst, at cp/pt.c:13675
> Blob(Iter b, Iter e) {
  ^~~~

Please submit a full bug report,
which preprocessed source if appropriate.
See  for instructions.

The attached is a file processed through a command:
gcc -v -save-temps [MYFILE]

Re: [Patch v2] Enable math functions linking with static library for LTO

[luoxhu]

Hi Richard,

On 2019/8/12 16:51, Richard Biener wrote:

On Mon, Aug 12, 2019 at 8:50 AM luoxhu  wrote:


Hi Richard,
Thanks for your comments, updated the v2 patch as below:
1. Define and use builtin_with_linkage_p.
2. Add comments.
3. Add a testcase.

In LTO mode, if static library and dynamic library contains same
function and both libraries are passed as arguments, linker will link
the function in dynamic library no matter the sequence.  This patch
will output LTO symbol node as UNDEF if BUILT_IN_NORMAL function FNDECL
is a math function, then the function in static library will be linked
first if its sequence is ahead of the dynamic library.


Comments below


gcc/ChangeLog

 2019-08-12  Xiong Hu Luo  

 PR lto/91287
 * builtins.c (builtin_with_linkage_p): New function.
 * builtins.h (builtin_with_linkage_p): New function.
 * symtab.c (write_symbol): Use builtin_with_linkage_p.
 * lto-streamer-out.c (symtab_node::output_to_lto_symbol_table_p):
 Likewise.

gcc/testsuite/ChangeLog

 2019-08-12  Xiong Hu Luo  

 PR lto/91287
 * gcc.dg/pr91287.c: New testcase.
---
  gcc/builtins.c | 89 ++
  gcc/builtins.h |  2 +
  gcc/lto-streamer-out.c |  4 +-
  gcc/symtab.c   | 13 -
  gcc/testsuite/gcc.dg/pr91287.c | 40 +++
  5 files changed, 145 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/pr91287.c

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 695a9d191af..f4dea941a27 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -11244,3 +11244,92 @@ target_char_cst_p (tree t, char *p)
*p = (char)tree_to_uhwi (t);
return true;
  }
+
+/* Return true if DECL is a specified builtin math function.  These functions
+   should have symbol in symbol table to provide linkage with faster version of
+   libraries.  */


The comment should read like

/* Return true if the builtin DECL is implemented in a standard
library.  Otherwise
returns false which doesn't guarantee it is not (thus the list of
handled builtins
below may be incomplete).  */


+bool
+builtin_with_linkage_p (tree decl)
+{
+  if (!decl)
+return false;


Omit this check please.


+  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
+switch (DECL_FUNCTION_CODE (decl))
+{
+  CASE_FLT_FN (BUILT_IN_ACOS):
+  CASE_FLT_FN (BUILT_IN_ACOSH):
+  CASE_FLT_FN (BUILT_IN_ASIN):
+  CASE_FLT_FN (BUILT_IN_ASINH):
+  CASE_FLT_FN (BUILT_IN_ATAN):
+  CASE_FLT_FN (BUILT_IN_ATANH):
+  CASE_FLT_FN (BUILT_IN_ATAN2):
+  CASE_FLT_FN (BUILT_IN_CBRT):
+  CASE_FLT_FN (BUILT_IN_CEIL):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_CEIL):
+  CASE_FLT_FN (BUILT_IN_COPYSIGN):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_COPYSIGN):
+  CASE_FLT_FN (BUILT_IN_COS):
+  CASE_FLT_FN (BUILT_IN_COSH):
+  CASE_FLT_FN (BUILT_IN_ERF):
+  CASE_FLT_FN (BUILT_IN_ERFC):
+  CASE_FLT_FN (BUILT_IN_EXP):
+  CASE_FLT_FN (BUILT_IN_EXP2):
+  CASE_FLT_FN (BUILT_IN_EXPM1):
+  CASE_FLT_FN (BUILT_IN_FABS):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_FABS):
+  CASE_FLT_FN (BUILT_IN_FDIM):
+  CASE_FLT_FN (BUILT_IN_FLOOR):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_FLOOR):
+  CASE_FLT_FN (BUILT_IN_FMA):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_FMA):
+  CASE_FLT_FN (BUILT_IN_FMAX):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_FMAX):
+  CASE_FLT_FN (BUILT_IN_FMIN):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_FMIN):
+  CASE_FLT_FN (BUILT_IN_FMOD):
+  CASE_FLT_FN (BUILT_IN_FREXP):
+  CASE_FLT_FN (BUILT_IN_HYPOT):
+  CASE_FLT_FN (BUILT_IN_ILOGB):
+  CASE_FLT_FN (BUILT_IN_LDEXP):
+  CASE_FLT_FN (BUILT_IN_LGAMMA):
+  CASE_FLT_FN (BUILT_IN_LLRINT):
+  CASE_FLT_FN (BUILT_IN_LLROUND):
+  CASE_FLT_FN (BUILT_IN_LOG):
+  CASE_FLT_FN (BUILT_IN_LOG10):
+  CASE_FLT_FN (BUILT_IN_LOG1P):
+  CASE_FLT_FN (BUILT_IN_LOG2):
+  CASE_FLT_FN (BUILT_IN_LOGB):
+  CASE_FLT_FN (BUILT_IN_LRINT):
+  CASE_FLT_FN (BUILT_IN_LROUND):
+  CASE_FLT_FN (BUILT_IN_MODF):
+  CASE_FLT_FN (BUILT_IN_NAN):
+  CASE_FLT_FN (BUILT_IN_NEARBYINT):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_NEARBYINT):
+  CASE_FLT_FN (BUILT_IN_NEXTAFTER):
+  CASE_FLT_FN (BUILT_IN_NEXTTOWARD):
+  CASE_FLT_FN (BUILT_IN_POW):
+  CASE_FLT_FN (BUILT_IN_REMAINDER):
+  CASE_FLT_FN (BUILT_IN_REMQUO):
+  CASE_FLT_FN (BUILT_IN_RINT):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_RINT):
+  CASE_FLT_FN (BUILT_IN_ROUND):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_ROUND):
+  CASE_FLT_FN (BUILT_IN_SCALBLN):
+  CASE_FLT_FN (BUILT_IN_SCALBN):
+  CASE_FLT_FN (BUILT_IN_SIN):
+  CASE_FLT_FN (BUILT_IN_SINH):
+  CASE_FLT_FN (BUILT_IN_SINCOS):
+  CASE_FLT_FN (BUILT_IN_SQRT):
+  CASE_FLT_FN_FLOATN_NX (BUILT_IN_SQRT):
+  CASE_FLT_FN (BUILT_IN_TAN):
+  CASE_FLT_FN (BUILT_IN_TANH):
+  CASE_FLT_FN 

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jason at gcc dot gnu.org]

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

--- Comment #24 from Jason Merrill  ---
(In reply to Marek Polacek from comment #23)
> Thanks, missed that.  Looks like Jason wants us to fix it retroactively,
> too.  I suppose we should just revert my r264172.

Better to disable the section in build_over_call that implemented the check
removed by this paper:

   /* The implicit move specified in 15.8.3/3 fails "...if the type of
  the first parameter of the selected constructor is not an rvalue
  reference to the object’s type (possibly cv-qualified)" */

I wouldn't remove it entirely until we have a better idea of what gets broken
by this change.

[Bug rtl-optimization/91430] New: ICE in curr_insn_transform, at lra-constraints.c:3962

[novalazy at gmail dot com]

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

Bug ID: 91430
   Summary: ICE in curr_insn_transform, at lra-constraints.c:3962
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: novalazy at gmail dot com
  Target Milestone: ---

Hi, the following test case hits an ICE in gcc 9.1.0 on x86_64.

% cat test.c
register unsigned long a __asm__("r14");
register unsigned long b __asm__("r15");

void test(void)
{
b = a << 4;
}


% gcc -O1 -c test.c
test.c: In function 'test':
test.c:7:1: error: unable to generate reloads for:
7 | }
  | ^
(insn 6 5 9 2 (parallel [
(set (reg/v:DI 43 r15 [ b ])
(ashift:DI (reg/v:DI 42 r14 [ a ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "test.c":6:11 520 {*ashldi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
during RTL pass: reload
test.c:7:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3962


% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.1.0 (GCC)

[PATCH] PR fortran/87993 -- An array can have a kind type inquiry suffix

[Steve Kargl]

The attached patch ahs been regression tested on x86_64-*-freebsd.
It probably borders on obvious, but I'll ask away.  OK to commit?

2019-08-12  Steven G. Kargl  

PR fortran/87993
* expr.c (gfc_simplify_expr):  Simplifcation of an array with a kind
type inquiry suffix yields a constant expression.

2019-08-12  Steven G. Kargl  

PR fortran/87993
* gfortran.dg/pr87993.f90: New test.

-- 
Steve
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(revision 274320)
+++ gcc/fortran/expr.c	(working copy)
@@ -2227,6 +2227,11 @@ gfc_simplify_expr (gfc_expr *p, int type)
   if (!simplify_ref_chain (p->ref, type, ))
 	return false;
 
+  /* If the following conditions hold, we found something like kind type
+	 inquiry of the form a(2)%kind while simplify the ref chain.  */
+  if (p->expr_type == EXPR_CONSTANT && !p->ref && !p->rank && !p->shape)
+	return true;
+
   if (!simplify_constructor (p->value.constructor, type))
 	return false;
 
Index: gcc/testsuite/gfortran.dg/pr87993.f90
===
--- gcc/testsuite/gfortran.dg/pr87993.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr87993.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do run }
+! Code contributed by Gerhard Steinmetz 
+program p
+   integer, parameter :: a(2) = 1
+   integer, parameter :: b = a%kind
+   if (any(a /= 1)) stop 1
+   if (b /= kind(a)) stop 2
+end

[Bug tree-optimization/91425] Ordered compares aren't optimised

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
A more general representation would facilitate implementing 
__builtin_iseqsig (bug 77928).

(As noted in previous discussions, some processors, e.g. MIPS, actually 
have a general comparison operation that can represent all 32 choices of 
which cases the comparison is true for, and whether it raises "invalid" 
for quiet NaNs.  So it would be good to have a clear path through from the 
general representation to selecting a single corresponding instruction on 
such processors.)

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Jeff Law]

On 8/12/19 4:17 PM, Martin Sebor wrote:
> On 8/12/19 2:04 PM, Jeff Law wrote:
>> On 8/9/19 4:14 PM, Martin Sebor wrote:
>>> On 8/9/19 10:58 AM, Jakub Jelinek wrote:
 On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote:
> That said, we should change this code one way or the other.
> There is even less of a guarantee that other compilers support
> writing past the end of arrays that have non-zero size than
> that they recognize the documented zero-length extension.

 We use that everywhere forever, so no.
>>>
>>> Just because some invalid code has been in place "forever" doesn't
>>> mean it cannot be changed.  Relying on undocumented "extensions"
>>> because they just happen to work with the compilers they have been
>>> exposed to is exactly how naive users get in trouble.  Our answer
>>> to reports of "bugs" when the behavior changes is typically: fix
>>> your code.  There's little reason to expect other compiler writers
>>> to be any more accommodating.
>>>
 See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array,
 gimple_statement_with_ops op array just to name a few that are
 everywhere.  Coverity is indeed unhappy about
 that, but it would be with [0] certainly too.  Another option is
 to use maximum possible size where we know it (which is the case of
 rtxes and most tree expressions and gimple stmts, but not e.g.
 CALL_EXPR or GIMPLE_CALL where there is no easy upper bound.
>>>
>>> The solution introduced in C99 is a flexible array.  C++
>>> compilers usually support it as well.  Those that don't are
>>> likely to support the zero-length array (even Visual C++ does).
>>> If there's a chance that some don't support either do you really
>>> think it's safe to assume they will do something sane with
>>> the [1] hack?  If you're concerned that the flexible array syntax
>>> or the zero length array won't compile, add a configure test to
>>> see if it does and use whatever alternative is most appropriate.
>> Given that we require a C++03 compiler to build GCC, I think we can
>> revisit how we represent the trailing array.  But that seems independent
>> of the bulk of this patch.
>>
>> Can we separate this issue from the rest of the patch?
> 
> The updated patch I posted is independent of the trailing
> [1] array hack:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html
I must have dropped this from my queue by accident.  I'll go find it and
give it a looksie as well.

jeff

Re: types for VR_VARYING

[Jeff Law]

On 8/12/19 12:43 PM, Aldy Hernandez wrote:
> This is a fresh re-post of:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html
> 
> Andrew gave me some feedback a week ago, and I obviously don't remember
> what it was because I was about to leave on PTO.  However, I do remember
> I addressed his concerns before getting drunk on rum in tropical islands.
FWIW found a great coffee infused rum while in Kauai last week.  I'm not
a coffee fan, but it was wonderful.  The one bottle we brought back
isn't going to last until Cauldron and I don't think I can get a special
order filled before I leave :(

Their more traditional rums were good as well.  Koloa Rum.  See if you
can get it locally :-)


> 
> This patch adds MIN/MAX values for VR_VARYING.  As was discussed
> earlier, we are only changing VR_VARYING, not VR_UNDEFINED as was the
> original plan.
> 
> As I mentioned earlier, I am tired of re-doing ChangeLogs, so I'll whip
> up the changelog when the review starts.
ACK.



> @@ -150,12 +166,11 @@ vr_values::set_defs_to_varying (gimple *stmt)
>ssa_op_iter i;
>tree def;
>FOR_EACH_SSA_TREE_OPERAND (def, stmt, i, SSA_OP_DEF)
> -{
> -  value_range *vr = get_value_range (def);
> -  /* Avoid writing to vr_const_varying get_value_range may return.  */
> -  if (!vr->varying_p ())
> - vr->set_varying ();
> -}
> +if (value_range_base::supports_type_p (TREE_TYPE (def)))
> +  {
> + value_range *vr = get_value_range (def);
> + vr->set_varying (TREE_TYPE (def));
> +  }
>  }
Is the supports_type_p stuff there to placate the calls from ipa-cp?  I
can live with it in the short term, but it really feels like there
should be something in the ipa-cp client that avoids this silliness.


>  
>  /* Update the value range and equivalence set for variable VAR to

> @@ -1920,7 +1935,7 @@ vr_values::dump_all_value_ranges (FILE *file)
>  vr_values::vr_values () : vrp_value_range_pool ("Tree VRP value ranges")
>  {
>values_propagated = false;
> -  num_vr_values = num_ssa_names;
> +  num_vr_values = num_ssa_names + num_ssa_names / 10;
>vr_value = XCNEWVEC (value_range *, num_vr_values);
>vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names);
>bitmap_obstack_initialize (_equiv_obstack);
My recollection was someone (Richi) proposed 2X for the initial
allocation which should ensure that in all but the most pathological
cases that we never trigger a reallocation.  In terms of "wasted" space,
it shouldn't matter in practice.

So if you could check the old thread and verify that Richi recommended
the 2X initial allocation and if so, make that minor update.

Jeff

Re: enforce canonicalization of value_range's

[Jeff Law]

On 8/12/19 12:48 PM, Aldy Hernandez wrote:
> This is a ping of:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg8.html
> 
> I have addressed the comments Jeff mentioned there.
> 
> This patch goes before the VR_VARYING + types patch, but I can adapt
> either one to come first.  I can even munge them together into one
> patch, if it helps review.
> 
> Tested on x86-64 Linux.
> 
> OK (assuming ChangeLog entries)?
> 
> Aldy
> 
> 
> curr.patch
> 
> commit ea908bdbfc8cdb4bb63e7d42630d01203edbac41
> Author: Aldy Hernandez 
> Date:   Mon Jul 15 18:09:27 2019 +0200
> 
> Enforce canonicalization in value_range.
Per your other message, I'll assume you'll write a suitable ChangeLog
entry before committing :-)


> 
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index 594ee9adc17..de2f39d8487 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -69,23 +69,20 @@ along with GCC; see the file COPYING3.  If not see
>  #include "builtins.h"
>  #include "wide-int-range.h"
>  
> +static bool
> +ranges_from_anti_range (const value_range_base *ar,
> + value_range_base *vr0, value_range_base *vr1,
> + bool handle_pointers = false);
> +
Presumably this was better than moving the implementation earlier.


> +/* Normalize symbolics into constants.  */
> +
> +value_range_base
> +value_range_base::normalize_symbolics () const
> +{
> +  if (varying_p () || undefined_p ())
> +return *this;
> +  tree ttype = type ();
> +  bool min_symbolic = !is_gimple_min_invariant (min ());
> +  bool max_symbolic = !is_gimple_min_invariant (max ());
Sadly "symbolic" is a particularly poor term.  When I think symbolics, I
think SYMBOL_REF, LABEL_REF and the tree equivalents.  They're
*symbols*.  Symbolics in this case are really things like SSA_NAMEs.
Confused the hell out of me briefly.

If we weren't on a path to kill VRP I'd probably suggest a distinct
effort to constify this code.  Some of the changes were a bit confusing
when it looked like we'd dropped a call to set the range of an object.
But those were just local copies, so setting the type/min/max directly
was actually fine.  constification would make this a bit clearer.  But
again, I don't think it's worth the effort given the long term
trajectory for tree-vrp.c.


So where does the handle_pointers stuff matter?   I'm a bit surprised we
have to do anything special for them.


OK.  I don't expect the answers to the minor questions above will
ultimately change anything.

jeff

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[mpolacek at gcc dot gnu.org]

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

--- Comment #23 from Marek Polacek  ---
Thanks, missed that.  Looks like Jason wants us to fix it retroactively, too. 
I suppose we should just revert my r264172.

[Bug fortran/89413] [PDT] ICE in resolve_fl_derived, at fortran/resolve.c:14392

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||janus at gcc dot gnu.org,
   ||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
This seems to have been fixed by Janus in r269658.
Perhaps, this can be closed.

gfcx -c a.f90
a.f90:2:15:

2 |   type :: t5 ()
  |   1
Error: A type parameter list is required at (1)

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #22 from Richard Smith  
---
(In reply to Marek Polacek from comment #20)
> (In reply to Jason Merrill from comment #19)
> > And now P1155/P1825 removes that text, so in C++20 mode the original
> > testcase needs to call the move constructor again.  Marek, I don't see
> > P1825R0 in cxx-status.html, was there a reason not to add it?
> 
> No, I followed clang's table but they're missing that one.  I'll fix that &
> open a PR for P1825R0.

FYI, it is in Clang's table, but I put it in the C++11 features list since it's
a DR and we're considering it to retroactively apply to C++11's addition of
move semantics.

Re: [PATCH] Improve DSE to handle redundant zero initializations.

[Jeff Law]

On 8/12/19 2:14 PM, Matthew Beliveau wrote:
> This patch improves DSE to handle missing optimizations for zero
> initializations.
> 
> Thank you,
> Matthew Beliveau
> 
> 
> DSE.patch
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-08-12  Matthew Beliveau  
> 
>   PR c++/DSE.patch
>   * tree-ssa-dse.c (dse_optimize_redundant_stores): Improved check to
>   catch more redundant zero initalization cases.
>   (dse_dom_walker::dse_optimize_stmt): Improved check to catch more
>   redundant zero initialization cases.
> 
>   * gcc.dg/tree-ssa/redundant-assign-zero-1.c: New test.
>   * gcc.dg/tree-ssa/redundant-assign-zero-2.c: New test.
> 
> @@ -1027,15 +1024,13 @@ dse_dom_walker::dse_optimize_stmt 
> (gimple_stmt_iterator *gsi)
>  {
>bool by_clobber_p = false;
>  
> -  /* First see if this store is a CONSTRUCTOR and if there
> -  are subsequent CONSTRUCTOR stores which are totally
> -  subsumed by this statement.  If so remove the subsequent
> -  CONSTRUCTOR store.
> +  /* Check if this store initalizes zero, or some aggregate of zeros,
> +  and check if there are subsequent stores which are subsumed by this
> +  statement.  If so, remove the subsequent store.
Perhaps...

/* Check if this statement stores zero to a memory location
   and if there is a subsequent store of zero to the same
   memory location.  If so delete the subsequent store.  */


With the ChangeLog nits noted by Marek and the comment fix this is fine
for the trunk.

jeff

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
Created attachment 46704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46704=edit
another untested patch

[Bug fortran/89647] Host associated procedure unable to be used as binding target

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch submitted.

[PATCH] PR fortran/89647 -- Allow host associated procedure to be a binding target

[Steve Kargl]

The attached patch fixes PR fortran/89647, and has been
regression tested on x86_64-*-freebsd.

If a procedure is made accessible by host association, the
that procedure can be used as binding target.  During the
resolution of a type bound procedure, gfortran needs to
check the parent namespace for a procedure before it fails.

2019-08-12  Steven G. Kargl  

PF fortran/89647
resolve.c (resolve_typebound_procedure): Allow host associated 
procedure to be a binding target.  While here, wrap long line.

2019-08-12  Steven G. Kargl  

PF fortran/89647
* gfortran.dg/pr89647.f90: New test.

OK to commit?

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 274320)
+++ gcc/fortran/resolve.c	(working copy)
@@ -13583,14 +13583,34 @@ resolve_typebound_procedure (gfc_symtree* stree)
 }
   else
 {
+  /* If proc has not been resolved at this point, proc->name may 
+	 actually be a USE associated entity. See PR fortran/89647. */
+  if (!proc->resolved
+	  && proc->attr.function == 0 && proc->attr.subroutine == 0)
+	{
+	  gfc_symbol *tmp;
+	  gfc_find_symbol (proc->name, gfc_current_ns->parent, 1, );
+	  if (tmp && tmp->attr.use_assoc)
+	{
+	  proc->module = tmp->module;
+	  proc->attr.proc = tmp->attr.proc;
+	  proc->attr.function = tmp->attr.function;
+	  proc->attr.subroutine = tmp->attr.subroutine;
+	  proc->attr.use_assoc = tmp->attr.use_assoc;
+	  proc->ts = tmp->ts;
+	  proc->result = tmp->result;
+	}
+	}
+
   /* Check for F08:C465.  */
   if ((!proc->attr.subroutine && !proc->attr.function)
 	  || (proc->attr.proc != PROC_MODULE
 	  && proc->attr.if_source != IFSRC_IFBODY)
 	  || proc->attr.abstract)
 	{
-	  gfc_error ("%qs must be a module procedure or an external procedure with"
-		" an explicit interface at %L", proc->name, );
+	  gfc_error ("%qs must be a module procedure or an external "
+		 "procedure with an explicit interface at %L",
+		 proc->name, );
 	  goto error;
 	}
 }
Index: gcc/testsuite/gfortran.dg/pr89647.f90
===
--- gcc/testsuite/gfortran.dg/pr89647.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr89647.f90	(working copy)
@@ -0,0 +1,33 @@
+! { dg-do compile }
+! Code contributed by Ian Harvey  
+  MODULE m1
+IMPLICIT NONE
+PUBLIC :: False
+PUBLIC :: True
+  CONTAINS
+FUNCTION False() RESULT(b)
+  LOGICAL :: b
+  b = .FALSE.
+END FUNCTION False
+
+FUNCTION True() RESULT(b)
+  LOGICAL :: b
+  b = .TRUE.
+END FUNCTION True
+  END MODULE m1
+
+  MODULE m2
+USE m1
+IMPLICIT NONE
+TYPE, ABSTRACT :: t_parent
+CONTAINS
+  PROCEDURE(False), DEFERRED, NOPASS :: Binding
+END TYPE t_parent
+  CONTAINS
+SUBROUTINE s
+  TYPE, EXTENDS(t_parent) :: t_extension
+  CONTAINS
+PROCEDURE, NOPASS :: Binding => True
+  END TYPE t_extension
+END SUBROUTINE s
+  END MODULE m2

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #18 from Brian T. Carcich  ---
Thanks for the fix and your patience.

We got gfortran with this patch to build on a box running Linux 2.6.9 ca.
November 2011, and it solved the problem.

Well done.

Re: [PATCH] PR other/91396 Fix static link error with -fvtable-verify

[Caroline Tice via gcc-patches]

The bootstrap succeeded.

On Mon, Aug 12, 2019 at 11:51 AM Caroline Tice  wrote:
>
> Hi,
>
> This patch is to fix a bug where linking with -fvtable-verify  and
> -static causes the linker to complain about multiple definitions of
> things in the vtv_end*.o files (once from the .o file and once from
> libvtv.a).   (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396).
> The fix is for the GNU_USER_TARGET_ENDFILE_SPEC to only include the
> vtv_end*.o files if we're not doing static linking (and we are using
> -fvtable-verify flags).
>
> Tested this fix by verifying that the test case in the bug compiles
> both with and without -static, and that there were no new regressions
> in the libvtv testsuite.  I'm in the process of doing a full bootstrap
> build with this change.   Assuming the bootstrap passes, is this ok to
> commit?
>
> Index: gcc/config/gnu-user.h
> ===
> --- gcc/config/gnu-user.h (revision 274317)
> +++ gcc/config/gnu-user.h (working copy)
> @@ -73,9 +73,9 @@
> GNU userspace "finalizer" file, `crtn.o'.  */
>
>  #define GNU_USER_TARGET_ENDFILE_SPEC \
> -  "%{fvtable-verify=none:%s; \
> +  "%{!static:%{fvtable-verify=none:%s; \
>   fvtable-verify=preinit:vtv_end_preinit.o%s; \
> - fvtable-verify=std:vtv_end.o%s} \
> + fvtable-verify=std:vtv_end.o%s}} \
> %{static:crtend.o%s; \
>   shared|static-pie|" PIE_SPEC ":crtendS.o%s; \
>   :crtend.o%s} " \
>
> ChangeLog entry:
>
> 2019-08-12  Caroline Tice  
>
> PR other/91396
> * config/gnu-user.h (GNU_USER_TARGET_ENDFILE_SPEC): Only add the
> vtv_end.o or vtv_end_preinit.o files if !static.

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Martin Sebor]

On 8/12/19 2:04 PM, Jeff Law wrote:

On 8/9/19 4:14 PM, Martin Sebor wrote:

On 8/9/19 10:58 AM, Jakub Jelinek wrote:

On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote:

That said, we should change this code one way or the other.
There is even less of a guarantee that other compilers support
writing past the end of arrays that have non-zero size than
that they recognize the documented zero-length extension.


We use that everywhere forever, so no.


Just because some invalid code has been in place "forever" doesn't
mean it cannot be changed.  Relying on undocumented "extensions"
because they just happen to work with the compilers they have been
exposed to is exactly how naive users get in trouble.  Our answer
to reports of "bugs" when the behavior changes is typically: fix
your code.  There's little reason to expect other compiler writers
to be any more accommodating.


See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array,
gimple_statement_with_ops op array just to name a few that are
everywhere.  Coverity is indeed unhappy about
that, but it would be with [0] certainly too.  Another option is
to use maximum possible size where we know it (which is the case of
rtxes and most tree expressions and gimple stmts, but not e.g.
CALL_EXPR or GIMPLE_CALL where there is no easy upper bound.


The solution introduced in C99 is a flexible array.  C++
compilers usually support it as well.  Those that don't are
likely to support the zero-length array (even Visual C++ does).
If there's a chance that some don't support either do you really
think it's safe to assume they will do something sane with
the [1] hack?  If you're concerned that the flexible array syntax
or the zero length array won't compile, add a configure test to
see if it does and use whatever alternative is most appropriate.

Given that we require a C++03 compiler to build GCC, I think we can
revisit how we represent the trailing array.  But that seems independent
of the bulk of this patch.

Can we separate this issue from the rest of the patch?


The updated patch I posted is independent of the trailing
[1] array hack:

  https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html

Martin

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Jeff Law]

On 8/9/19 10:17 AM, Martin Sebor wrote:
> GCC 9 optimizes a subset of expression of the form
> (0 == strcmp(a, b)) based on the length and/or size of
> the arguments but it doesn't take advantage of all
> the opportunities there.  For example in the following,
> although it folds the first test to false it doesn't fold
> the second one:
> 
>   char a[4];
> 
>   void f (void)
>   {
> if (strlen (a) > 3)   // folded to false by GCC 8+
>   abort ();
> 
> if (strcmp (a, "1234") == 0)   // folded by patched GCC
>   abort ();
> }
> 
> The attached patch extends the strcmp optimization added in
> GCC 9 to also handle the latter cases (among others).  Testing
> the enhancement with several other sizable code bases besides
> GCC (Binutils/GDB, the Linux kernel, and LLVM) shows that code
> like this is rare.  After thinking about it I decided it's more
> likely a bug than a significant optimization opportunity, so
> I introduced a new warning to point it out: -Wstring-compare
> (enabled in -Wextra).
> 
> Besides this enhancement, the patch also improves the current
> optimization to fold strcmp calls with conditional arguments
> such as in:
> 
>   void f (char *s, int i)
>   {
> strcpy (s, "12");
> if (strcmp (s, i ? "123" : "1234") == 0)   // folded
>   abort ();
>   }
> 
> Martin
> 
> PS The diff looks like the changes are more extensive than they
> actually are.
> 
> gcc-90879.diff
> 
> PR tree-optimization/90879 - fold zero-equality of strcmp between a longer 
> string and a smaller array
> 
> gcc/c-family/ChangeLog:
> 
>   PR tree-optimization/90879
>   * c.opt (-Wstring-compare): New option.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/90879
>   * gcc.dg/Wstring-compare-2.c: New test.
>   * gcc.dg/Wstring-compare.c: New test.
>   * gcc.dg/strcmpopt_3.c: Scan the optmized dump instead of strlen.
>   * gcc.dg/strcmpopt_6.c: New test.
>   * gcc.dg/strlenopt-65.c: Remove uinnecessary declarations, add
>   test cases.
>   * gcc.dg/strlenopt-66.c: Run it.
>   * gcc.dg/strlenopt-67.c: New test.
>   * gcc.dg/strlenopt-68.c: New test.
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/90879
>   * builtins.c (check_access): Avoid using maxbound when null.
>   * calls.c (maybe_warn_nonstring_arg): Adjust to get_range_strlen change.
>   * doc/invoke.texi (-Wstring-compare): Document new warning option.
>   * gengtype-state.c (state_ident_st): Use a zero-length array instead.
>   (state_token_st): Same.  Make last.
>   (state_ident_by_name): Allocate enough space for terminating nul.
>   * gimple-fold.c (get_range_strlen_tree): Make setting maxbound
>   conditional.
>   (get_range_strlen): Overwrite initial maxbound when non-null.
>   * gimple-ssa-sprintf.c (get_string_length): Adjust to get_range_strlen
>   change.
>   * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Same.
>   (used_only_for_zero_equality): New function.
>   (handle_builtin_memcmp): Call it.
>   (determine_min_objsize): Return an integer instead of tree.
>   (get_len_or_size, strxcmp_eqz_result): New functions.
>   (maybe_warn_pointless_strcmp): New function.
>   (handle_builtin_string_cmp): Call it.  Fold zero-equality of strcmp
>   between a longer string and a smaller array.
> 
> diff --git a/gcc/gengtype-state.c b/gcc/gengtype-state.c
> index 03f40694ec6..80a8b57e9a2 100644
> --- a/gcc/gengtype-state.c
> +++ b/gcc/gengtype-state.c
> @@ -79,6 +79,14 @@ enum state_token_en
>STOK_NAME /* hash-consed name or identifier.  */
>  };
>  
> +/* Suppress warning: ISO C forbids zero-size array for stok_string
> +   below.  The arrays are treated as flexible array members but in
> +   otherwise an empty struct or as a member of a union cannot be
> +   declared as such.  They must have zero size to keep GCC from
> +   assuming their bound reflect their size.  */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wpedantic"
> +
>  
>  /* Structure and hash-table used to share identifiers or names.  */
>  struct state_ident_st
> @@ -86,11 +94,10 @@ struct state_ident_st
>/* TODO: We could improve the parser by reserving identifiers for
>   state keywords and adding a keyword number for them.  That would
>   mean adding another field in this state_ident_st struct.  */
> -  char stid_name[1]; /* actually bigger & null terminated */
> +  char stid_name[0]; /* actually bigger & null terminated */
>  };
>  static htab_t state_ident_tab;
>  
> -
>  /* The state_token_st structure is for lexical tokens in the read
> state file.  The stok_kind field discriminates the union.  Tokens
> are allocated by peek_state_token which calls read_a_state_token
> @@ -110,14 +117,15 @@ struct state_token_st
>union  /* discriminated by stok_kind! 
> */
>{
>  int stok_num;/* when 

[Bug fortran/47191] Misleading error message if part-ref starts with DATA

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Seems I forgot to close this.

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 47191, which changed state.

Bug 47191 Summary: Misleading error message if part-ref starts with DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47191

   What|Removed |Added

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

Patch to support extended characters in C/C++ identifiers

[Lewis Hyatt]

Hello-

The attached patch for libcpp adds support for extended characters (e.g. UTF-8)
in identifiers. A preliminary version of the patch was posted on PR c/67224 as
Comment 26 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c26) and
discussed with Joseph Myers. Here is an updated patch incorporating all
feedback received so far. I hope it is suitable now; please let me know if I
can do anything else to make it ready for you to apply. I am happy to work on
it further, whatever is needed. I can't easily test on anything other than
x86_64-linux though. I did bootstrap all languages and run all tests on that
platform, everything was good.

The (relatively short) changes to libcpp are included inline here. I attached
the test cases as a gzipped patch to avoid any problems with the encoding (the
test cases contain some invalid UTF-8 and also other encodings such as latin-1
as part of the testing).

Thanks for taking a look at it!

-Lewis

libcpp/ChangeLog

PR c/67224
* charset.c (_cpp_valid_utf8): New function to help lex UTF-8 tokens.
* internal.h (_cpp_valid_utf8): Declare.
* lex.c (forms_identifier_p): Use it to recognize UTF-8 identifiers.
(_cpp_lex_direct): Handle UTF-8 in identifiers and CPP_OTHER tokens.
Do all work in "default" case to avoid slowing down typical code paths.
Also handle $ and UCN in the default case for consistency.

gcc/testsuite/ChangeLog

PR c/67224
* c-c++-common/cpp/ucnid-2011-1-utf8.c: New test.
* g++.dg/cpp/ucnid-1-utf8.C: New test.
* g++.dg/cpp/ucnid-2-utf8.C: New test.
* g++.dg/cpp/ucnid-3-utf8.C: New test.
* g++.dg/cpp/ucnid-4-utf8.C: New test.
* g++.dg/other/ucnid-1-utf8.C: New test.
* gcc.dg/cpp/ucnid-1-utf8.c: New test.
* gcc.dg/cpp/ucnid-10-utf8.c: New test.
* gcc.dg/cpp/ucnid-11-utf8.c: New test.
* gcc.dg/cpp/ucnid-12-utf8.c: New test.
* gcc.dg/cpp/ucnid-13-utf8.c: New test.
* gcc.dg/cpp/ucnid-14-utf8.c: New test.
* gcc.dg/cpp/ucnid-15-utf8.c: New test.
* gcc.dg/cpp/ucnid-2-utf8.c: New test.
* gcc.dg/cpp/ucnid-3-utf8.c: New test.
* gcc.dg/cpp/ucnid-4-utf8.c: New test.
* gcc.dg/cpp/ucnid-6-utf8.c: New test.
* gcc.dg/cpp/ucnid-7-utf8.c: New test.
* gcc.dg/cpp/ucnid-9-utf8.c: New test.
* gcc.dg/ucnid-1-utf8.c: New test.
* gcc.dg/ucnid-10-utf8.c: New test.
* gcc.dg/ucnid-11-utf8.c: New test.
* gcc.dg/ucnid-12-utf8.c: New test.
* gcc.dg/ucnid-13-utf8.c: New test.
* gcc.dg/ucnid-14-utf8.c: New test.
* gcc.dg/ucnid-15-utf8.c: New test.
* gcc.dg/ucnid-16-utf8.c: New test.
* gcc.dg/ucnid-2-utf8.c: New test.
* gcc.dg/ucnid-3-utf8.c: New test.
* gcc.dg/ucnid-4-utf8.c: New test.
* gcc.dg/ucnid-5-utf8.c: New test.
* gcc.dg/ucnid-6-utf8.c: New test.
* gcc.dg/ucnid-7-utf8.c: New test.
* gcc.dg/ucnid-8-utf8.c: New test.
* gcc.dg/ucnid-9-utf8.c: New test.
diff --git a/libcpp/charset.c b/libcpp/charset.c
index 8a0e5cbb29b..4f1bee96cee 100644
--- a/libcpp/charset.c
+++ b/libcpp/charset.c
@@ -1198,6 +1198,84 @@ convert_ucn (cpp_reader *pfile, const uchar *from, const uchar *limit,
   return from;
 }
 
+/*  Performs a similar task as _cpp_valid_ucn, but parses UTF-8-encoded
+extended characters rather than UCNs.  If the return value is TRUE, then a
+character was successfully decoded and stored in *CP; *PSTR has been
+updated to point one past the valid UTF-8 sequence.  Diagnostics may have
+been emitted if the character parsed is not allowed in the current context.
+If the return value is FALSE, then *PSTR has not been modified and *CP may
+equal 0, to indicate that *PSTR does not form a valid UTF-8 sequence, or it
+may, when processing an identifier in C mode, equal a codepoint that was
+validly encoded but is not allowed to appear in an identifier.  In either
+case, no diagnostic is emitted, and the return value of FALSE should cause
+a new token to be formed.
+
+Unlike _cpp_valid_ucn, this will never be called when lexing a string; only
+a potential identifier, or a CPP_OTHER token.  NST is unused in the latter
+case.
+
+As in _cpp_valid_ucn, IDENTIFIER_POS is 0 when not in an identifier, 1 for
+the start of an identifier, or 2 otherwise.  */
+
+extern bool
+_cpp_valid_utf8 (cpp_reader *pfile,
+		 const uchar **pstr,
+		 const uchar *limit,
+		 int identifier_pos,
+		 struct normalize_state *nst,
+		 cppchar_t *cp)
+{
+  const uchar *base = *pstr;
+  size_t inbytesleft = limit - base;
+  if (one_utf8_to_cppchar (pstr, , cp))
+{
+  /* No diagnostic here as this byte will rather become a
+	 new token.  */
+  *cp = 0;
+  return false;
+}
+
+  if (identifier_pos)
+{
+  switch (ucn_valid_in_identifier (pfile, *cp, nst))
+	{
+
+	case 0:
+	  /* In C++, this is an 

Re: [PATCH] fixincludes breaks mingw64 build

[Gerald Pfeifer]

On Tue, 11 Jun 2019, Bruce Korb wrote:
> I should probably update the e-address as well. Yes, I still receive
> gnu.org email, but not daily. As infrequent as monthly. Can I do
> something to auto-forward it to an e-address I process daily?

You can log in to fencepost.gnu.org and edit /com/mailer/aliases 
there; that is pretty straightforward once you're logged in.

> Finally, my gcc sources are also years out of date, so if someone is
> willing to tweak the docs for me, it'd save some bother. :) 

Let me know how you'd like to see fixincludes/README updated
(current version attached) and I'll take care.

> I'm actually retired now and spend more time with a camera than 
> with code.

Enjoy!

Gerald
GCC MAINTAINER INFORMATION
==

If you are having some problem with a system header that is either
broken by the manufacturer, or is broken by the fixinclude process,
then you will need to alter or add information to the include fix
definitions file, ``inclhack.def''.  Please also send relevant
information to gcc-b...@gcc.gnu.org, gcc-patches@gcc.gnu.org and,
please, to me:  bk...@gnu.org.

To make your fix, you will need to do several things:

1.  Obtain access to the AutoGen program on some platform.  It does
not have to be your build platform, but it is more convenient.

2.  Edit "inclhack.def" to reflect the changes you need to make.
See below for information on how to make those changes.

3.  Run the "genfixes" shell script to produce a new copy of
the "fixincl.x" file.

4.  Rebuild the compiler and check the header causing the issue.
Make sure it is now properly handled.  Add tests to the
"test_text" entry(ies) that validate your fix.  This will
help ensure that future fixes won't negate your work.
Do *NOT* specify test text for "wrap" or "replacement" fixes.
There is no real possibility that these fixes will fail.
If they do, you will surely know straight away.

NOTE:  "test_text" is interpreted by the shell as it gets
copied into the test header.  THEREFORE you must quote
dollar sign characters and back quotes -- unless you mean
for them to be interpreted by the shell.

e.g. the math_huge_val_from_dbl_max test_text needs to
put text into both float.h and math.h, so it includes a
back-quoted script to add text to float.h.

5.  Go into the fixincludes build directory and type, "make check".
You are guaranteed to have issues printed out as a result.
Look at the diffs produced.  Make sure you have not clobbered
the proper functioning of a different fix.  Make sure your
fix is properly tested and it does what it is supposed to do.

6.  Now that you have the right things happening, synchronize the
$(srcdir)/tests/base directory with the $(builddir)/tests/res
directory.  The output of "make check" will be some diffs that
should give you some hints about what to do.

7.  Rerun "make check" and verify that there are no issues left.


MAKING CHANGES TO INCLHACK.DEF
==

0.  If you are not the fixincludes maintainer, please send that
person email about any changes you may want to make.  Thanks!

1.  Every fix must have a "hackname" that is compatible with C syntax
for variable names and is unique without regard to alphabetic case.
Please keep them alphabetical by this name.  :-)

2.  If the problem is known to exist only in certain files, then
identify the files with "files = " entries.  If you use fnmatch(3C)
wild card characters in a "files" entry, be certain that the first
"files" entry has no such character.  Otherwise, the "make check"
machinery will attempt to create files with those characters in the
name.  That is inconvenient.

3.  It is relatively expensive to fire off a process to fix a source
file, therefore write apply tests to avoid unnecessary fix
processes.  The preferred apply tests are "select", "bypass", "mach"
"sum", and "c-test" because they are performed internally:

* select - Run a regex on the contents of the file being considered.
   All such regex-es must match.  Matching is done with
   extended regular expressions.

* bypass - Run a regex on the contents of the file being considered.
   No such regex may match.

* sum- Select a specific version of a file that has a matching
   check sum.  The BSD version of checksum ["sum(1BSD)"]
   is used.  Each "sum" entry should contain exactly three
   space separated tokens:  the sum, some number and the
   basename of the file.  The "some number" is ignored.
   If there are multiple "sum" entries, only one needs to
   match in order to pass.  For example:

   sum = '1234 3 foobar.h';

   specifies that the "foobar.h" header in any directory
   will match if it has the checksum 1234.

* c_test - 

Re: Expansion of narrowing math built-ins into power instructions

[Segher Boessenkool]

On Mon, Aug 12, 2019 at 09:20:18PM +, Joseph Myers wrote:
> On Mon, 12 Aug 2019, Segher Boessenkool wrote:
> 
> > (define_insn "add_truncdfsf3"
> >   [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
> > (float_truncate:SF
> >   (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
> >(match_operand:DF 2 "gpc_reg_operand" "d,wa"]
> 
> That sort of pattern is incorrect for a fused operation such as fadd, 
> because combine could match it for code that is supposed to do separate 
> addition and narrowing conversion.  The RTL needs to be something that 
> does *not* match the combination of separate operations (just as fma has 
> its own RTL, and a separate pass is responsible for converting separate 
> operations to fused ones in the -ffp-contract=fast case where it's 
> permitted).

Ugh, we allow disabling contraction, I forgot.  Rats.


Segher

Re: Expansion of narrowing math built-ins into power instructions

[Joseph Myers]

On Mon, 12 Aug 2019, Segher Boessenkool wrote:

> (define_insn "add_truncdfsf3"
>   [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
>   (float_truncate:SF
> (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
>  (match_operand:DF 2 "gpc_reg_operand" "d,wa"]

That sort of pattern is incorrect for a fused operation such as fadd, 
because combine could match it for code that is supposed to do separate 
addition and narrowing conversion.  The RTL needs to be something that 
does *not* match the combination of separate operations (just as fma has 
its own RTL, and a separate pass is responsible for converting separate 
operations to fused ones in the -ffp-contract=fast case where it's 
permitted).

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

Re: [MSP430][PATCH 2/2] Read MCU data from external file

[Jeff Law]

On 8/8/19 6:17 AM, Jozef Lawrynowicz wrote:
> This patch extends the MCU data handling so that MCU data can be provided
> in an external file (devices.csv). This means the compiler doesn't have to be
> updated and rebuilt to support new devices when they are released.
> 
> TI distribute devices.csv with other support files (header files, linker
> scripts) on their website. I have also tested that a program builds 
> successfully
> for every MCU and the correct hwmult library is passed to the linker.
> I also built the msp430 cross compiler using a trunk build of native GCC to
> ensure all the error and warning messages added by my code are correct, as
> checked by -Wformat-diag.
> 
> 
> 0002-MSP430-Devices-2-Read-MCU-data-from-external-devices.patch
> 
> From 6f67cdd282f2351d7450e343314beeaa745f0159 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Tue, 6 Aug 2019 10:52:54 +0100
> Subject: [PATCH 2/2] MSP430: Devices [2]: Read MCU data from external
>  devices.csv file, if it exists
> 
> gcc/ChangeLog:
> 
> 2019-08-XX  Jozef Lawrynowicz  
> 
>   * gcc/config/msp430/driver-msp430.c (msp430_set_driver_var): New.
>   * gcc/config/msp430/msp430-devices.c (canonicalize_path_dirsep): New.
>   (msp430_check_path_for_devices): New.
>   (parse_devices_csv_1): New.
>   (parse_devices_csv): New.
>   (msp430_extract_mcu_data): Try to find devices.csv and search for the
>   MCU data in devices.csv before using the hard-coded data.
>   Warn if devices.csv isn't found and the MCU wasn't found in the
>   hard-coded data either.
>   * gcc/config/msp430/msp430.h (DRIVER_SELF_SPECS): Call
>   msp430_set_driver_var for -mno-warn-devices-csv and -mdevices-csv-loc.
>   Search for devices.csv on -I and -L paths.
>   (EXTRA_SPEC_FUNCTIONS): Add msp430_check_path_for_devices and
>   msp430_set_driver_var.
>   * gcc/config/msp430/msp430.opt: Add -mwarn-devices-csv and
>   -mdevices-csv-loc=.
>   * gcc/doc/invoke.texi (-mmcu): Document that -I and -L paths are
>   searched for devices.csv.
>   (mwarn-devices-csv): Document option.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-08-XX  Jozef Lawrynowicz  
> 
>   * gcc.target/msp430/msp430.exp (msp430_device_permutations_runtest):
>   Handle csv-* and bad-devices-* tests.
>   * gcc.target/msp430/devices/README: Document how bad-devices-* tests
>   work.
>   * gcc.target/msp430/devices/bad-devices-1.c: New test.
>   * gcc.target/msp430/devices/bad-devices-2.c: Likewise.
>   * gcc.target/msp430/devices/bad-devices-3.c: Likewise.
>   * gcc.target/msp430/devices/bad-devices-4.c: Likewise.
>   * gcc.target/msp430/devices/bad-devices-5.c: Likewise.
>   * gcc.target/msp430/devices/bad-devices-6.c: Likewise.
>   * gcc.target/msp430/devices/csv-device-order.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_00.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_01.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_02.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_04.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_08.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_10.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_11.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_12.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_14.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_18.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_20.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_21.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_22.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_24.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430_28.c: Likewise.
>   * gcc.target/msp430/devices/csv-msp430fr5969.c: Likewise.
>   * gcc.target/msp430/devices/hard-foo.c: Likewise.
>   * gcc.target/msp430/devices/bad-devices-1.csv: New test support file.
>   * gcc.target/msp430/devices/bad-devices-2.csv: Likewise.
>   * gcc.target/msp430/devices/bad-devices-3.csv: Likewise.
>   * gcc.target/msp430/devices/bad-devices-4.csv: Likewise.
>   * gcc.target/msp430/devices/bad-devices-5.csv: Likewise.
>   * gcc.target/msp430/devices/bad-devices-6.csv: Likewise.
>   * gcc.target/msp430/devices/devices.csv: Likewise.
> ---
So it's good we don't have to do updates when a new devices.csv is
released -- except when we devices require new multilibs, but I don't
offhand see a sensible way to deal with that.

OK.

jeff

[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.3

--- Comment #4 from Jason Merrill  ---
Fixed for 9.3/10.

[Bug c++/91378] [9 regression] [C++17] ICE in type_dependent_expression_p with noexcept and deduced return type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for GCC 9.3/10.

Re: [MSP430][PATCH 1/2] Consolidate handling of hard-coded MCU data

[Jeff Law]

On 8/8/19 6:14 AM, Jozef Lawrynowicz wrote:
> This patch improves the handling of MCU data by consolidating multiple
> copies of hard-coded MCU data into a single location, and adds a new function
> to be used as a single entry point for the extraction of MCU data for the
> selected MCU.
> 
> This ensures the data is only extracted once per invocation of the
> driver/compiler, whilst previously, the data for the MCU is extracted each 
> time
> it is needed.
> 
> Some notes:
> - The GNU assembler doesn't do anything with the -mmcu option beyond setting 
> up
>   the CPU ISA, so if the GCC driver passes it the -mcpu option, which it will
>   always do if -mmcu is specified, then it is redundant to also pass it -mmcu.
> - The indenting in some places (e.g. msp430_select_hwmult_lib) looks wrong in
>   the patched file, but to make the diff a lot easier to read I have kept the
>   indenting the same as it was before. I can fix this after the patch is
>   accepted.
FWIW, another way to address the indentation issue is with the diff -b
option which says to ignore whitespace differences.

Regardless, yes, please clean up any indentation issues.


> 
> 
> 0001-MSP430-Devices-1-Consolidate-handling-of-hard-coded-.patch
> 
> From cd131b07e0447d104c99317e7ac37c2420c1bf6e Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Wed, 31 Jul 2019 22:53:50 +0100
> Subject: [PATCH 1/2] MSP430: Devices [1]: Consolidate handling of hard-coded
>  MCU data
> 
> gcc/ChangeLog:
> 
> 2019-08-XX  Jozef Lawrynowicz  
> 
>   * gcc/config.gcc (msp430*-*-*): Add msp430-devices.o to extra_objs and
>   extra_gcc_objs.
>   * gcc/config/msp430/driver-msp430.c: Remove msp430_mcu_data.
>   (msp430_select_cpu): New spec function.
>   (msp430_select_hwmult_lib): Use msp430_extract_mcu_data to extract
>   MCU data.
>   * gcc/config/msp430/msp430-devices.c: New file.
>   * gcc/config/msp430/msp430-devices.h: New file.
>   * gcc/config/msp430/msp430.c: Remove msp430_mcu_data.
>   (msp430_option_override): Use msp430_extract_mcu_data to extract
>   MCU data.
>   (msp430_use_f5_series_hwmult): Likewise.
>   (use_32bit_hwmult): Likewise.
>   (msp430_no_hwmult): Likewise.
>   * gcc/config/msp430/msp430.h (ASM_SPEC): Don't pass -mmcu to the
>   assembler.
>   (DRIVER_SELF_SPECS): Call msp430_select_cpu if -mmcu is used without
>   and -mcpu option.
>   (EXTRA_SPEC_FUNCTIONS): Add msp430_select_cpu.
>   * gcc/config/msp430/t-msp430: Add rule to build msp430-devices.o.
>   Remove hard-coded MCU multilib data.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-08-XX  Jozef Lawrynowicz  
> 
>   * gcc.target/msp430/msp430.exp
>   (check_effective_target_msp430_430_selected): New.
>   (check_effective_target_msp430_430x_selected): New.
>   (check_effective_target_msp430_mlarge_selected): New.
>   (check_effective_target_msp430_hwmul_not_none): New.
>   (check_effective_target_msp430_hwmul_not_16bit): New.
>   (check_effective_target_msp430_hwmul_not_32bit): New.
>   (check_effective_target_msp430_hwmul_not_f5): New.
>   (msp430_get_opts): New.
>   (msp430_device_permutations_runtest): New.
>   * gcc.target/msp430/devices/README: New file.
>   * gcc.target/msp430/devices-main.c: New test.
>   * gcc.target/msp430/devices/hard-cc430f5123.c: Likewise.
>   * gcc.target/msp430/devices/hard-foo.c: Likewise.
>   * gcc.target/msp430/devices/hard-msp430afe253.c: Likewise.
>   * gcc.target/msp430/devices/hard-msp430cg4616.c: Likewise.
>   * gcc.target/msp430/devices/hard-msp430f4783.c: Likewise.
>   * gcc.target/msp430/devices/hard-rf430frl154h_rom.c: Likewise.
Presumably we aren't supporting switching the selected mcu via
attributes on a per-function basis?

> +/* Main entry point to load the MCU data for the given -mmcu into
> +   extracted_mcu_data.  hard_msp430_mcu_data (initialized at the bottom of 
> this
> +   file) is searched for the MCU name.
> +   This function only needs to be executed once, but it can be first called
> +   from a number of different locations.  */
> +void
> +msp430_extract_mcu_data (const char * mcu_name)
> +{
> +  static int executed = 0;
> +  int i;
> +  if (mcu_name == NULL || executed == 1)
> +return;
> +  executed = 1;
> +  /* FIXME: This array is alpha sorted - we could use a binary search.  */
> +  for (i = ARRAY_SIZE (hard_msp430_mcu_data); i--;)
> +if (strcasecmp (mcu_name, hard_msp430_mcu_data[i].name) == 0)
> +  {
> + extracted_mcu_data = hard_msp430_mcu_data[i];
> + break;
> +  }
I guess we only run this once, so the linear search isn't a serious
compile-time issue?

Assuming we don't care about switching the selected mcu within a
compilation unit, OK for the trunk.

jeff

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jason at gcc dot gnu.org]

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

--- Comment #21 from Jason Merrill  ---
(In reply to Jason Merrill from comment #19)
> And now P1155/P1825 removes that text, so in C++20 mode the original
> testcase needs to call the move constructor again.

Actually, it's a DR, so not just C++20 mode.

[Bug c++/91429] New: Conditional explicit not respected with out-of-line definition

[barry.revzin at gmail dot com]

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

Bug ID: 91429
   Summary: Conditional explicit not respected with out-of-line
definition
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from StackOverflow (https://stackoverflow.com/q/57467490/2069064):

using size_t = decltype(sizeof(0));

struct Str {
template 
explicit(N > 7) Str(char const ()[N]);
};

#ifdef OUT_OF_LINE
template 
Str::Str(char const()[N]) { }
#endif

Str a = "short";
Str b = "not so short";

As-is, gcc correctly rejects the construction of b (since that constructor is
explicit). But with -DOUT_OF_LINE, gcc accepts.

Re: [PATCH] PR fortran/91414: Improved PRNG

[Steve Kargl]

On Sun, Aug 11, 2019 at 12:37:49PM +0300, Janne Blomqvist wrote:
> Update the PRNG from xorshift1024* to xoshiro256** by the same
> author. For details see
> 
> http://prng.di.unimi.it/
> 
> and the paper at
> 
> https://arxiv.org/abs/1805.01407
> 
> Also the seeding is slightly improved, by reading only 8 bytes from
> the operating system and using the simple splitmix64 PRNG to fill in
> the rest of the PRNG state (as recommended by the xoshiro author),
> instead of reading the entire state from the OS.
> 
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
> 

Looks good to me.

-- 
Steve

[Bug testsuite/91422] Illegal Fortran in testsuite/libgomp.oacc-fortran/routine-7.f90

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug 12 20:21:37 2019
New Revision: 274320

URL: https://gcc.gnu.org/viewcvs?rev=274320=gcc=rev
Log:
2019-08-12  Thomas Koenig  

PR fortran/91424
* frontend-passes.c (do_subscript): Do not warn for an
expression a second time.  Do not warn about a zero-trip loop.
(doloop_warn): Also look at contained namespaces.

2019-08-12  Thomas Koenig  

PR fortran/91424
* gfortran.dg/do_subscript_3.f90: New test.
* gfortran.dg/do_subscript_4.f90: New test.
* gfortran.dg/pr70754.f90: Use indices that to not overflow.

2019-08-12  Thomas Koenig  

PR fortran/91422
* testsuite/libgomp.oacc-fortran/routine-7.f90: Correct array
dimension.


Added:
trunk/gcc/testsuite/gfortran.dg/do_subscript_3.f90
trunk/gcc/testsuite/gfortran.dg/do_subscript_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr70754.f90
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-fortran/routine-7.f90

[Bug fortran/91424] Extend warnings about DO loops

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug 12 20:21:37 2019
New Revision: 274320

URL: https://gcc.gnu.org/viewcvs?rev=274320=gcc=rev
Log:
2019-08-12  Thomas Koenig  

PR fortran/91424
* frontend-passes.c (do_subscript): Do not warn for an
expression a second time.  Do not warn about a zero-trip loop.
(doloop_warn): Also look at contained namespaces.

2019-08-12  Thomas Koenig  

PR fortran/91424
* gfortran.dg/do_subscript_3.f90: New test.
* gfortran.dg/do_subscript_4.f90: New test.
* gfortran.dg/pr70754.f90: Use indices that to not overflow.

2019-08-12  Thomas Koenig  

PR fortran/91422
* testsuite/libgomp.oacc-fortran/routine-7.f90: Correct array
dimension.


Added:
trunk/gcc/testsuite/gfortran.dg/do_subscript_3.f90
trunk/gcc/testsuite/gfortran.dg/do_subscript_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr70754.f90
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-fortran/routine-7.f90

Re: [PATCH] Improve DSE to handle redundant zero initializations.

[Marek Polacek]

I have no comments on the patch itself, but...

On Mon, Aug 12, 2019 at 04:14:40PM -0400, Matthew Beliveau wrote:
> 2019-08-12  Matthew Beliveau  
> 
>   PR c++/DSE.patch

Please drop this.

>   * tree-ssa-dse.c (dse_optimize_redundant_stores): Improved check to
>   catch more redundant zero initalization cases.
>   (dse_dom_walker::dse_optimize_stmt): Improved check to catch more
>   redundant zero initialization cases.

The second entry should just say "Likewise."

Also, no need to CC Jason on non-C++ patches.

Marek

Re: [Patch, DWARF] Ignore address spaces for get_nearest_type_subqualifiers

[Jeff Law]

On 8/6/19 1:58 AM, senthilkumar.selva...@microchip.com wrote:
> Hi,
> 
>   r254484 explicitly added previously ignored address space 
>   qualifiers, when
>   emitting DWARF dies for types.
> 
>   Adding address spaces to cv_qual_mask, however, breaks
>   nearest_type_subqualifier, which uses the number of bits set 
>   (i.e
>   popcount_hwi) to find the type variant that has the largest 
>   strict subset of a
>   given type's qualifiers. Address spaces are simply represented 
>   as 16 bits, and
>   therefore the number of set bits there has no relevance when 
>   finding
>   nearest_type_subqualifier. This also causes 
>   gcc.target/avr/pr52472.c to ICE.
> 
>   This patch fixes that by excluding address space quals from 
>   cv_qual_mask.
>   Bootstrap and reg test for x86_64-linux in progress. Ok to 
>   commit to trunk
>   if the tests pass?
> 
> Regards
> Senthil
> 
> gcc/ChangeLog:
> 
> 2019-08-06  Senthil Kumar Selvaraj 
> 
> 
>   * dwarf2out.c (modified_type_die): CLEAR_QUAL_ADDR_SPACE from
> cv_qual_mask before calling get_nearest_type_subqualifiers.
> 
> 
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index aa7fd7eb465..157c970d729 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -13295,8 +13295,9 @@ modified_type_die (tree type, int 
> cv_quals, bool reverse,
>/* Determine a lesser qualified type that most closely 
>matches
>this one.  Then generate DW_TAG_* entries for the remaining
>qualifiers.  */
> +  int nearest_qual_mask = CLEAR_QUAL_ADDR_SPACE 
> (cv_qual_mask);
>sub_quals = get_nearest_type_subqualifiers (type, cv_quals,
> -   cv_qual_mask);
> +   nearest_qual_mask);
>if (sub_quals && use_debug_types)
>   {
> bool needed = false;
Is there some reason we couldn't initialize nearest_qual_mask in the
same place we initialize cv_qual_mask and just not include the address
space qualifiers?  ie something like this:

  const int cv_qual_mask = (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE
| TYPE_QUAL_RESTRICT | TYPE_QUAL_ATOMIC |
ENCODE_QUAL_ADDR_SPACE(~0U));
  const int nearest_qual_mask = (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE
| TYPE_QUAL_RESTRICT | TYPE_QUAL_ATOMIC);


I realize your approach would handle any qualifier outside of the
address space bits.  But it may be better in this code to be explicit
about what we handle and what we don't.

Thoughts?

jeff

[PATCH] Improve DSE to handle redundant zero initializations.

[Matthew Beliveau]

This patch improves DSE to handle missing optimizations for zero
initializations.

Thank you,
Matthew Beliveau
Bootstrapped/regtested on x86_64-linux, ok for trunk?

2019-08-12  Matthew Beliveau  

	PR c++/DSE.patch
	* tree-ssa-dse.c (dse_optimize_redundant_stores): Improved check to
	catch more redundant zero initalization cases.
	(dse_dom_walker::dse_optimize_stmt): Improved check to catch more
	redundant zero initialization cases.

	* gcc.dg/tree-ssa/redundant-assign-zero-1.c: New test.
	* gcc.dg/tree-ssa/redundant-assign-zero-2.c: New test.

diff --git gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-1.c gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-1.c
new file mode 100644
index 000..b8d01d1644b
--- /dev/null
+++ gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-1.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse-details" } */
+
+void blah (char *);
+
+void bar ()
+{
+  char a[256] = "";
+  a[3] = 0; 
+  blah (a);
+}
+
+/* { dg-final { scan-tree-dump-times "Deleted redundant store" 1 "dse1"} } */
diff --git gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-2.c gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-2.c
new file mode 100644
index 000..8cefa6f0cb7
--- /dev/null
+++ gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-2.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse-details" } */
+
+#include 
+
+void blahd (double *);
+
+void fubar ()
+{
+  double d;
+  double *x = 
+
+  memset (, 0 , sizeof d);
+  *x = 0.0;
+  blahd (x);
+}
+
+/* { dg-final { scan-tree-dump-times "Deleted redundant store" 1 "dse1"} } */
diff --git gcc/tree-ssa-dse.c gcc/tree-ssa-dse.c
index 5b7c4fc6d1a..dcaeb8edbfe 100644
--- gcc/tree-ssa-dse.c
+++ gcc/tree-ssa-dse.c
@@ -628,11 +628,8 @@ dse_optimize_redundant_stores (gimple *stmt)
   tree fndecl;
   if ((is_gimple_assign (use_stmt)
 	   && gimple_vdef (use_stmt)
-	   && ((gimple_assign_rhs_code (use_stmt) == CONSTRUCTOR
-	&& CONSTRUCTOR_NELTS (gimple_assign_rhs1 (use_stmt)) == 0
-	&& !gimple_clobber_p (stmt))
-	   || (gimple_assign_rhs_code (use_stmt) == INTEGER_CST
-		   && integer_zerop (gimple_assign_rhs1 (use_stmt)
+	   && initializer_zerop (gimple_op (use_stmt, 1), NULL)
+	   && !gimple_clobber_p (stmt))
 	  || (gimple_call_builtin_p (use_stmt, BUILT_IN_NORMAL)
 	  && (fndecl = gimple_call_fndecl (use_stmt)) != NULL
 	  && (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_MEMSET
@@ -1027,15 +1024,13 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator *gsi)
 {
   bool by_clobber_p = false;
 
-  /* First see if this store is a CONSTRUCTOR and if there
-	 are subsequent CONSTRUCTOR stores which are totally
-	 subsumed by this statement.  If so remove the subsequent
-	 CONSTRUCTOR store.
+  /* Check if this store initalizes zero, or some aggregate of zeros,
+	 and check if there are subsequent stores which are subsumed by this
+	 statement.  If so, remove the subsequent store.
 
 	 This will tend to make fewer calls into memset with longer
 	 arguments.  */
-  if (gimple_assign_rhs_code (stmt) == CONSTRUCTOR
-	  && CONSTRUCTOR_NELTS (gimple_assign_rhs1 (stmt)) == 0
+  if (initializer_zerop (gimple_op (stmt, 1), NULL)
 	  && !gimple_clobber_p (stmt))
 	dse_optimize_redundant_stores (stmt);
 

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch.  Thanks for the bug report.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[kargl at gcc dot gnu.org]

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

--- Comment #16 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug 12 20:09:00 2019
New Revision: 274319

URL: https://gcc.gnu.org/viewcvs?rev=274319=gcc=rev
Log:
2019-08-12  Steven G. Kargl  

PR fortran/91359
* trans-decl.c (gfc_generate_return): Ensure something is returned
from a function.

2019-08-12  Steven G. Kargl  

PR fortran/91359
* gfortran.dg/pr91359_1.f: New test.
* gfortran.dg/pr91359_2.f: Ditto.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91359_1.f
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91359_2.f
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

Re: [C++ PATCH] Adjust -Wsequence-point for C++17 changes (PR c++/91415)

[Jeff Law]

On 8/12/19 8:48 AM, Jakub Jelinek wrote:
> Hi!
> 
> The following patch adds some tweaks for -Wsequence-point warning for C++17
> and later.  In particular, stop warning about no sequence point in between
> <<, >>, ., -> and [] expressions, where E1 is in C++17 sequenced before E2.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> As mentioned in the PR, this is just part of the needed changes, I've tried
> to adjust handling of MODIFY_EXPR, but didn't figure out exactly what needs
> to be done, and .* / ->* aren't handled either, and CALL_EXPR needs probably
> some verification too.
> 
> 2019-08-12  Jakub Jelinek  
> 
>   PR c++/91415
>   * c-common.c (verify_tree): For LSHIFT_EXPR, RSHIFT_EXPR,
>   COMPONENT_REF and ARRAY_REF in cxx_dialect >= cxx17 mode handle it
>   like COMPOUND_EXPR rather than normal expression.
> 
>   * g++.dg/warn/sequence-pt-4.C: New test.
OK
jeff

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Jeff Law]

On 8/9/19 4:14 PM, Martin Sebor wrote:
> On 8/9/19 10:58 AM, Jakub Jelinek wrote:
>> On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote:
>>> That said, we should change this code one way or the other.
>>> There is even less of a guarantee that other compilers support
>>> writing past the end of arrays that have non-zero size than
>>> that they recognize the documented zero-length extension.
>>
>> We use that everywhere forever, so no.
> 
> Just because some invalid code has been in place "forever" doesn't
> mean it cannot be changed.  Relying on undocumented "extensions"
> because they just happen to work with the compilers they have been
> exposed to is exactly how naive users get in trouble.  Our answer
> to reports of "bugs" when the behavior changes is typically: fix
> your code.  There's little reason to expect other compiler writers
> to be any more accommodating.
> 
>> See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array,
>> gimple_statement_with_ops op array just to name a few that are
>> everywhere.  Coverity is indeed unhappy about
>> that, but it would be with [0] certainly too.  Another option is
>> to use maximum possible size where we know it (which is the case of
>> rtxes and most tree expressions and gimple stmts, but not e.g.
>> CALL_EXPR or GIMPLE_CALL where there is no easy upper bound.
> 
> The solution introduced in C99 is a flexible array.  C++
> compilers usually support it as well.  Those that don't are
> likely to support the zero-length array (even Visual C++ does).
> If there's a chance that some don't support either do you really
> think it's safe to assume they will do something sane with
> the [1] hack?  If you're concerned that the flexible array syntax
> or the zero length array won't compile, add a configure test to
> see if it does and use whatever alternative is most appropriate.
Given that we require a C++03 compiler to build GCC, I think we can
revisit how we represent the trailing array.  But that seems independent
of the bulk of this patch.

Can we separate this issue from the rest of the patch?

jeff

Re: [patch, fortran] Some corrections for DO loop index warnings

[Steve Kargl]

On Mon, Aug 12, 2019 at 05:18:18PM +0200, Thomas Koenig wrote:
> Hello world,
> 
> the attached patch fixes three problems with DO loop index warnings:
> 
> - DO loops in contained procedures were not checked
> 
> - Zero-trip loops gave a false positive
> 
> - DO loops in blocks gave the same warning twice
> 
> plus it fixes the resulting fallout from the test suite.
> 
> Regression-tested.  OK for trunk?  I also think that this is something
> that could be safely backported to gcc-9.
> 

Ok.  If it regression cleanly on gcc9, go ahead an commit there as well.

-- 
Steve

Re: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

[Jeff Law]

On 8/9/19 5:42 PM, Martin Sebor wrote:
>>> @@ -3408,7 +3457,13 @@ static bool
>>>   }
>>>       gimple *stmt = SSA_NAME_DEF_STMT (exp);
>>> -  if (gimple_code (stmt) != GIMPLE_PHI)
>>> +  if (gimple_assign_single_p (stmt))
>>> +    {
>>> +  tree rhs = gimple_assign_rhs1 (stmt);
>>> +  return count_nonzero_bytes (rhs, offset, nbytes, lenrange,
>>> nulterm,
>>> +  allnul, allnonnul, snlim);
>>> +    }
>>> +  else if (gimple_code (stmt) != GIMPLE_PHI)
>>>   return false;
>> What cases are you handling here?  Are there any cases where a single
>> operand expression on the RHS affects the result.  For example, if we've
>> got a NOP_EXPR which zero extends RHS?  Does that change the nonzero
>> bytes in a way that is significant?
>>
>> I'm not opposed to handling single operand objects here, I'm just
>> concerned that we're being very lenient in just stripping away the
>> operator and looking at the underlying object.
> 
> I remember adding the code because of a test failure but not
> the specifics anymore.  No tests fail with it removed so it
> may not be needed.  As you know, I've been juggling a few
> enhancements in this area and copying code between them as
> I need it so it's possible that I copied too much, or that
> some other change has obviated it, or also that the test
> failed somewhere else and I forgot to copy the test along
> with the code  I'll remove it until it's needed.
Let's pull it for now.  If we come across the need again, we can
obviously revisit with a testcase.


> 
>>> @@ -3795,7 +3824,14 @@ handle_store (gimple_stmt_iterator *gsi)
>>>   }
>>>     else
>>>   si->nonzero_chars = build_int_cst (size_type_node, offset);
>>> -  si->full_string_p = full_string_p;
>>> +
>>> +  /* Set FULL_STRING_P only if the length of the strings being
>>> + written is the same, and clear it if the strings have
>>> + different lengths.  In the latter case the length stored
>>> + in si->NONZERO_CHARS becomes the lower bound.
>>> + FIXME: Handle the upper bound of the length if possible.  */
>>> +  si->full_string_p = full_string_p && lenrange[0] == lenrange[1];
>> So there seems to be a disconnect between the comment and the code.
>>
>> The comment indicates you care about the lengths of the two strings
>> being the same.  But what you're really comparing when the lenrange[0]
>> == lenrange[1] test is that the min and max of RHS are the same.
> 
> The comment tries to make clear that all the arrays on the RHS
> of the assignment must have the same length in order to set
> FULL_STRING_P.  Like here where LENRANGE = { 4, 4, 4 }:
> 
>   void f (char *s)
>   {
>     if (__builtin_strlen (s) != 2)
>   return;
> 
>     *(int*)a = i ? 0x : 0x;
>   }
> 
> but not here where LENRANGE = { 1, 4, 4 }:
> 
>     *(int*)a = i < 0 ? 0x : i ? 0x0022 : 0x3300;
> 
> If the bounds of the range of lengths of all the strings on
> the RHS are the same they're all the same length.
> 
> I'm open to phrasing it better.
Oh, I think I see what I was missing.  In the case where RHS is a
conditional (or perhaps a SSA_NAME which was set from a PHI) LENRANGE
will have the min/max/# bytes for the RHS was a whole, not just a single
component of the RHS.


>> It generally looks reasonable, so I think we just need to reach a
>> conclusion on the gimple_assign_single_p cases we're trying to handle
>> and the possible mismatch between the comment and the code.
> 
> Do you want me to post another revision with
> the gimple_assign_single_p test removed?
I think remove that hunk, bootstrap, test, commit and post for archival
purposes.  I do not think another round of review is necessary.

jeff

[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
*be

[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-12
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
(In reply to Barry Revzin from comment #0)
> Can you please provide a warning for this erroneous usage?

Yes, I think this ought to me feasible to add to finish_if_stmt_cond.

[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete

[asorenji at gmail dot com]

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

--- Comment #4 from Aso Renji  ---
(In reply to Jonathan Wakely from comment #3)
> But it's not enabled by -Wall7
> 
> Maybe QtCreator should be fixed instead.

Hmm, compile output in QtCreator:
g++ -c -pipe -g -Wall -W -fPIC -DQT_QML_DEBUG -I../test -I.
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o ../test/main.cpp

I try ran this in console and don't get any warning. But Qt itself show
"warning: 'Test' has virtual functions but non-virtual destructor". So, you
right, this is problem in QtCreator.

[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|10.0|9.3

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 9-branch and trunk.

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078
Bug 89078 depends on bug 42546, which changed state.

Bug 42546 Summary: ALLOCATED statement typo in the docs and for scalar variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546

   What|Removed |Added

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

[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug 12 19:48:37 2019
New Revision: 274318

URL: https://gcc.gnu.org/viewcvs?rev=274318=gcc=rev
Log:
2019-08-01  Steven G. Kargl  

PR fortran/42546
* check.c(gfc_check_allocated): Add comment pointing to ...
* intrinsic.c(sort_actual): ... the checking done here.

2019-08-01  Steven G. Kargl  

PR fortran/42546
* gfortran.dg/allocated_1.f90: New test.
* gfortran.dg/allocated_2.f90: Ditto.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/allocated_1.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/allocated_2.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/check.c
branches/gcc-9-branch/gcc/fortran/intrinsic.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91428] New: Please warn on if constexpr (std::is_constant_evaluated())

[barry.revzin at gmail dot com]

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

Bug ID: 91428
   Summary: Please warn on if constexpr
(std::is_constant_evaluated())
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

A very common user error with std::is_constant_evaluated is to write this:

#include 

constexpr int foo(int i) {
if constexpr (std::is_constant_evaluated()) {
return 42;
} else {
return i;
}
}

That is, check if we're in the middle of constant evaluation with "if
constexpr" instead of plain "if". This is the intuitive check to do, but
unfortunately, since the condition here is manifestly constant evaluated, the
result of check is unconditionally true. gcc implements this correctly - the
above function is exactly equivalent to "return 42;" - but that's unlikely to
be what the user intended the program to do. They likely intended to write:

constexpr int foo(int i) {
if (std::is_constant_evaluated()) {
return 42;
} else {
return i;
}
}

Can you please provide a warning for this erroneous usage?

Re: [PATCH] Teach mklog to reference PRs.

[Pedro Alves]

On 8/12/19 8:34 PM, Pedro Alves wrote:
> Let me share my 2c -- the format GDB uses doesn't affect most GCC forks

I meant most GCC folks.

Thanks,
Pedro Alves

Re: [PATCH] Teach mklog to reference PRs.

[Pedro Alves]

On 8/1/19 4:01 PM, Jakub Jelinek wrote:
> You can easily tweak the script to handle the other way too.
> Looking around, different people have different style, some people don't
> post the date/name/email lines at all, others do, some people post them
> multiple times, once for each ChangeLog, others just once, and for the
> latter case, some people post gcc/, etc. prefixes before the entries
> afterwards, while others don't, and others do it only conditionally
> (e.g. when the number of ChangeLog files is too high or it isn't immediately
> obvious which ones they are for, say one entry for gcc and one for
> gcc/testsuite ChangeLog, or similarly for gcc/cp and gcc/testsuite etc.
> isn't hard to figure out and is just noise.
> So, either we have multiple options for mklog, so that people if they prefer
> some other style don't have to rewrite it all the time, or have one style we
> want to recommend.  If the latter, I think it is better to have a style that
> is perhaps automatically parseable by a script, on the other side for
> readers of the mailing list should minimize unnecessary cruft and
> redundancies.  For that I think the email line just once, then empty line,
> then PR lines and/or line with short summary as some people use, then
> the dirnames of ChangeLog entries (but no ChangeLog, that is always the
> case) and actual entries sounds best to me.

Let me share my 2c -- the format GDB uses doesn't affect most GCC forks
of course, though uniformity across GNU tools is a good thing to have
in my opinion, to ease sharing tooling and ease moving between projects.

"email just once" assumes that you have a single author or set of authors
for the whole patch.  But if you have a patch that includes entries by
different authors, then you have to have multiple ChangeLog "blocks" each
with its author/email line, ending up where you didn't want to to begin
with, anyway, like:

-MM-DD  John Doe  

gcc/
* ...

-MM-DD  Joe Shmoe  

gcc/testsuite/
* ...


With the "email line per ChangeLog file entry" style, there's
no exception to the rule, it all just always looks the same, like:

gcc/
-MM-DD  John Doe  

* ...

gcc/testsuite/
-MM-DD  Joe Shmoe  

* ...

This isn't your everyday patch, of course, but it does
show up here and there.

IMHO, saving a few characters/bytes doesn't justify the simplicity
of just having a full entry per ChangeLog file.

FWIW, this is the style used by GDB, as documented at the end
of section 9, at
.


"In your patch email you should also specify which changelog is being modified. 
Before the line containing the date and your name/email, add a line with the 
path to the changelog. If there are multiple components being updated with 
multiple changelog edits, split these into sections, one for each changelog:

gdb/ChangeLog:
2013-12-12  John Doe  

PR gdb/
* breakpoint.c (handle_some_event): Remove reference to foo.  Call
bar.
* configure.ac (build_warnings): Do not use -Wformat-nonliteral
with -Wno-format.
* configure: Regenerate.
* NEWS: Mention awesome feature.

gdb/testsuite/ChangeLog:
2013-12-12  John Doe  

PR gdb/
* Makefile: Test changes for awesome feature.
"


Pedro Alves

[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4

[iains at gcc dot gnu.org]

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

--- Comment #31 from Iain Sandoe  ---
(In reply to Matt Thompson from comment #30)
> (In reply to Matt Thompson from comment #28)
> > (In reply to Iain Sandoe from comment #27)
> > > That's fine - essentially, you're building them from source and therefore
> > > don't need to worry about --with-gmp= configure options etc.
> > > 
> > > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.
> > 
> > Well, it looks like download_prerequisites might be behind the times:
> > 
> > gmp='gmp-6.1.0.tar.bz2'
> > mpfr='mpfr-3.1.4.tar.bz2'
> > mpc='mpc-1.0.3.tar.gz'
> > isl='isl-0.18.tar.bz2'
> > 
> > I'm going to try and download the newest versions of all these and build
> > with them. Maybe that'll help (though I don't see much/any C++ in them...).
> 
> Yeah. Didn't help. Still, it was a fun exercise.

That was a long shot to solve your problem; was mainly documenting what I've
done that worked.

> If GCC was on github, I'd make a pull request to update the
> download_prerequisites script, though. Unless there's a good reason to use
> these version?

AFAIK, the pre-reqs are the minimum versions and there's nothing to sop one
from deciding to use newer (keeping the minimum to the lowest practical is
advantageous in compatibility).  Updating any GCC dependency has wide
ramifications - many folks might just use the version installed on their system
(if it's Linux) - on Darwin we care somewhat less, since we have to build them
anyway.



I've started a 9.2 build/install/test cycle with xcode10.2 toolchain as the
bootstrap - will post the results here later/tomorrow.

[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
But it's not enabled by -Wall7

Maybe QtCreator should be fixed instead.

[Bug preprocessor/84864] Issues with large line numbers >= 2^31

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-12
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
ASSIGNED due to assignee

[Bug c++/49129] confusing diagnostic for missing semi-colon after member template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
ASSIGNED due to assignee

[Bug c++/85004] ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
ASSIGNED since there's an assignee

[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-12
 CC||wilson at gcc dot gnu.org
 Ever confirmed|0   |1

[wwwdocs] Add missing C++20 feature

[Marek Polacek]

I missed this one.  As a sign of repentance, I'll aim to address it this week.

Applying to CVS.

Index: cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.96
diff -u -r1.96 cxx-status.html
--- cxx-status.html 7 Aug 2019 14:34:01 -   1.96
+++ cxx-status.html 12 Aug 2019 18:55:03 -
@@ -422,6 +422,12 @@
   No (https://gcc.gnu.org/PR91360;>PR91360)
   
 
+
+  More implicit moves (merge P0527R1 and P1155R3)
+  http://wg21.link/p1825r0;>P1825R0
+  No (https://gcc.gnu.org/PR91427;>PR91427)
+  
+
   
 
   C++17 Support in GCC

[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Martin Liška from comment #7)
> David: Can the bug be marked as resolved?

WAITING on a reply

[PATCH] PR other/91396 Fix static link error with -fvtable-verify

[Caroline Tice via gcc-patches]

Hi,

This patch is to fix a bug where linking with -fvtable-verify  and
-static causes the linker to complain about multiple definitions of
things in the vtv_end*.o files (once from the .o file and once from
libvtv.a).   (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396).
The fix is for the GNU_USER_TARGET_ENDFILE_SPEC to only include the
vtv_end*.o files if we're not doing static linking (and we are using
-fvtable-verify flags).

Tested this fix by verifying that the test case in the bug compiles
both with and without -static, and that there were no new regressions
in the libvtv testsuite.  I'm in the process of doing a full bootstrap
build with this change.   Assuming the bootstrap passes, is this ok to
commit?

Index: gcc/config/gnu-user.h
===
--- gcc/config/gnu-user.h (revision 274317)
+++ gcc/config/gnu-user.h (working copy)
@@ -73,9 +73,9 @@
GNU userspace "finalizer" file, `crtn.o'.  */

 #define GNU_USER_TARGET_ENDFILE_SPEC \
-  "%{fvtable-verify=none:%s; \
+  "%{!static:%{fvtable-verify=none:%s; \
  fvtable-verify=preinit:vtv_end_preinit.o%s; \
- fvtable-verify=std:vtv_end.o%s} \
+ fvtable-verify=std:vtv_end.o%s}} \
%{static:crtend.o%s; \
  shared|static-pie|" PIE_SPEC ":crtendS.o%s; \
  :crtend.o%s} " \

ChangeLog entry:

2019-08-12  Caroline Tice  

PR other/91396
* config/gnu-user.h (GNU_USER_TARGET_ENDFILE_SPEC): Only add the
vtv_end.o or vtv_end_preinit.o files if !static.

[Bug c++/91427] Implement P1825R0, Merged wording for P0527R1 and P1155R3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-12
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I'll probably work on it since it reverts my fix for bug 87150, but not
assigning quite yet.

[Bug c++/91427] New: Implement P1825R0, Merged wording for P0527R1 and P1155R3

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91427
   Summary: Implement P1825R0, Merged wording for P0527R1 and
P1155R3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Tracker PR to implement C++20 P1825R0.

Also see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150#c19

[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4

[matthew.thompson at nasa dot gov]

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

--- Comment #30 from Matt Thompson  ---
(In reply to Matt Thompson from comment #28)
> (In reply to Iain Sandoe from comment #27)
> > That's fine - essentially, you're building them from source and therefore
> > don't need to worry about --with-gmp= configure options etc.
> > 
> > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.
> 
> Well, it looks like download_prerequisites might be behind the times:
> 
> gmp='gmp-6.1.0.tar.bz2'
> mpfr='mpfr-3.1.4.tar.bz2'
> mpc='mpc-1.0.3.tar.gz'
> isl='isl-0.18.tar.bz2'
> 
> I'm going to try and download the newest versions of all these and build
> with them. Maybe that'll help (though I don't see much/any C++ in them...).

Yeah. Didn't help. Still, it was a fun exercise.

If GCC was on github, I'd make a pull request to update the
download_prerequisites script, though. Unless there's a good reason to use
these version?

enforce canonicalization of value_range's

[Aldy Hernandez]

This is a ping of:

https://gcc.gnu.org/ml/gcc-patches/2019-07/msg8.html

I have addressed the comments Jeff mentioned there.

This patch goes before the VR_VARYING + types patch, but I can adapt 
either one to come first.  I can even munge them together into one 
patch, if it helps review.


Tested on x86-64 Linux.

OK (assuming ChangeLog entries)?

Aldy

commit ea908bdbfc8cdb4bb63e7d42630d01203edbac41
Author: Aldy Hernandez 
Date:   Mon Jul 15 18:09:27 2019 +0200

Enforce canonicalization in value_range.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 594ee9adc17..de2f39d8487 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -69,23 +69,20 @@ along with GCC; see the file COPYING3.  If not see
 #include "builtins.h"
 #include "wide-int-range.h"
 
+static bool
+ranges_from_anti_range (const value_range_base *ar,
+			value_range_base *vr0, value_range_base *vr1,
+			bool handle_pointers = false);
+
 /* Set of SSA names found live during the RPO traversal of the function
for still active basic-blocks.  */
 static sbitmap *live;
 
-void
-value_range_base::set (enum value_range_kind kind, tree min, tree max)
-{
-  m_kind = kind;
-  m_min = min;
-  m_max = max;
-  if (flag_checking)
-check ();
-}
-
 void
 value_range::set_equiv (bitmap equiv)
 {
+  if (undefined_p () || varying_p ())
+equiv = NULL;
   /* Since updating the equivalence set involves deep copying the
  bitmaps, only do it if absolutely necessary.
 
@@ -261,7 +258,8 @@ value_range_base::constant_p () const
 void
 value_range_base::set_undefined ()
 {
-  set (VR_UNDEFINED, NULL, NULL);
+  m_kind = VR_UNDEFINED;
+  m_min = m_max = NULL;
 }
 
 void
@@ -273,7 +271,8 @@ value_range::set_undefined ()
 void
 value_range_base::set_varying ()
 {
-  set (VR_VARYING, NULL, NULL);
+  m_kind = VR_VARYING;
+  m_min = m_max = NULL;
 }
 
 void
@@ -324,6 +323,24 @@ value_range::equiv_add (const_tree var,
 bool
 value_range_base::singleton_p (tree *result) const
 {
+  if (m_kind == VR_ANTI_RANGE)
+{
+  if (nonzero_p ())
+	{
+	  if (TYPE_PRECISION (type ()) == 1)
+	{
+	  if (result)
+		*result = m_max;
+	  return true;
+	}
+	  return false;
+	}
+
+  value_range_base vr0, vr1;
+  return (ranges_from_anti_range (this, , , true)
+	  && vr1.undefined_p ()
+	  && vr0.singleton_p (result));
+}
   if (m_kind == VR_RANGE
   && vrp_operand_equal_p (min (), max ())
   && is_gimple_min_invariant (min ()))
@@ -499,23 +516,28 @@ static assert_locus **asserts_for;
 /* Return the maximum value for TYPE.  */
 
 tree
-vrp_val_max (const_tree type)
+vrp_val_max (const_tree type, bool handle_pointers)
 {
-  if (!INTEGRAL_TYPE_P (type))
-return NULL_TREE;
-
-  return TYPE_MAX_VALUE (type);
+  if (INTEGRAL_TYPE_P (type))
+return TYPE_MAX_VALUE (type);
+  if (POINTER_TYPE_P (type) && handle_pointers)
+{
+  wide_int max = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
+  return wide_int_to_tree (const_cast (type), max);
+}
+  return NULL_TREE;
 }
 
 /* Return the minimum value for TYPE.  */
 
 tree
-vrp_val_min (const_tree type)
+vrp_val_min (const_tree type, bool handle_pointers)
 {
-  if (!INTEGRAL_TYPE_P (type))
-return NULL_TREE;
-
-  return TYPE_MIN_VALUE (type);
+  if (INTEGRAL_TYPE_P (type))
+return TYPE_MIN_VALUE (type);
+  if (POINTER_TYPE_P (type) && handle_pointers)
+return build_zero_cst (const_cast (type));
+  return NULL_TREE;
 }
 
 /* Return whether VAL is equal to the maximum value of its type.
@@ -626,8 +648,7 @@ intersect_range_with_nonzero_bits (enum value_range_kind vr_type,
extract ranges from var + CST op limit.  */
 
 void
-value_range_base::set_and_canonicalize (enum value_range_kind kind,
-	tree min, tree max)
+value_range_base::set (enum value_range_kind kind, tree min, tree max)
 {
   /* Use the canonical setters for VR_UNDEFINED and VR_VARYING.  */
   if (kind == VR_UNDEFINED)
@@ -645,7 +666,9 @@ value_range_base::set_and_canonicalize (enum value_range_kind kind,
   if (TREE_CODE (min) != INTEGER_CST
   || TREE_CODE (max) != INTEGER_CST)
 {
-  set (kind, min, max);
+  m_kind = kind;
+  m_min = min;
+  m_max = max;
   return;
 }
 
@@ -681,12 +704,13 @@ value_range_base::set_and_canonicalize (enum value_range_kind kind,
   kind = kind == VR_RANGE ? VR_ANTI_RANGE : VR_RANGE;
 }
 
+  tree type = TREE_TYPE (min);
+
   /* Anti-ranges that can be represented as ranges should be so.  */
   if (kind == VR_ANTI_RANGE)
 {
   /* For -fstrict-enums we may receive out-of-range ranges so consider
  values < -INF and values > INF as -INF/INF as well.  */
-  tree type = TREE_TYPE (min);
   bool is_min = (INTEGRAL_TYPE_P (type)
 		 && tree_int_cst_compare (min, TYPE_MIN_VALUE (type)) <= 0);
   bool is_max = (INTEGRAL_TYPE_P (type)
@@ -729,22 +753,37 @@ value_range_base::set_and_canonicalize (enum value_range_kind kind,
 }
 }
 
+  /* Normalize [MIN, MAX] into 

types for VR_VARYING

[Aldy Hernandez]

This is a fresh re-post of:

https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html

Andrew gave me some feedback a week ago, and I obviously don't remember 
what it was because I was about to leave on PTO.  However, I do remember 
I addressed his concerns before getting drunk on rum in tropical islands.


This patch adds MIN/MAX values for VR_VARYING.  As was discussed 
earlier, we are only changing VR_VARYING, not VR_UNDEFINED as was the 
original plan.


As I mentioned earlier, I am tired of re-doing ChangeLogs, so I'll whip 
up the changelog when the review starts.


Tested on x86-64 Linux.

OK?

Aldy
commit dad943a48ff2fccc203bf11839b7e3016e44dfe1
Author: Aldy Hernandez 
Date:   Mon Jul 22 10:04:43 2019 +0200

Add type to VR_VARYING.

diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index 4c68af847e1..0184703a13c 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -251,13 +251,18 @@ evrp_range_analyzer::record_ranges_from_phis (basic_block bb)
   if (virtual_operand_p (lhs))
 	continue;
 
+  /* Skips floats and other things we can't represent in a
+	 range.  */
+  if (!value_range_base::supports_type_p (TREE_TYPE (lhs)))
+	continue;
+
   value_range vr_result;
   bool interesting = stmt_interesting_for_vrp (phi);
   if (!has_unvisited_preds && interesting)
 	vr_values->extract_range_from_phi_node (phi, _result);
   else
 	{
-	  vr_result.set_varying ();
+	  vr_result.set_varying (TREE_TYPE (lhs));
 	  /* When we have an unvisited executable predecessor we can't
 	 use PHI arg ranges which may be still UNDEFINED but have
 	 to use VARYING for them.  But we can still resort to
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 69c00a9c5a5..859ad3fbaf5 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -977,7 +977,12 @@ ipcp_vr_lattice::set_to_bottom ()
 {
   if (m_vr.varying_p ())
 return false;
-  m_vr.set_varying ();
+  /* ?? We create all sorts of VARYING ranges for floats, structures,
+ and other types which we cannot handle as ranges.  We should
+ probably avoid handling them throughout the pass, but it's easier
+ to create a sensible VARYING here and let the lattice
+ propagate.  */
+  m_vr.set_varying (integer_type_node);
   return true;
 }
 
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 785227df690..43bca63da09 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -182,8 +182,10 @@ record_temporary_equivalences_from_phis (edge e,
 	new_vr->deep_copy (vr_values->get_value_range (src));
 	  else if (TREE_CODE (src) == INTEGER_CST)
 	new_vr->set (src);
+	  else if (value_range_base::supports_type_p (TREE_TYPE (src)))
+	new_vr->set_varying (TREE_TYPE (src));
 	  else
-	new_vr->set_varying ();
+	new_vr->set_undefined ();
 
 	  /* This is a temporary range for DST, so push it.  */
 	  evrp_range_analyzer->push_value_range (dst, new_vr);
diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
index 8b80bce8945..3911db9c26e 100644
--- a/gcc/tree-ssanames.c
+++ b/gcc/tree-ssanames.c
@@ -440,14 +440,16 @@ get_range_info (const_tree name, value_range_base )
   wide_int wmin, wmax;
   enum value_range_kind kind = get_range_info (name, , );
 
-  if (kind == VR_VARYING || kind == VR_UNDEFINED)
-min = max = NULL;
+  if (kind == VR_VARYING)
+vr.set_varying (TREE_TYPE (name));
+  else if (kind == VR_UNDEFINED)
+vr.set_undefined ();
   else
 {
   min = wide_int_to_tree (TREE_TYPE (name), wmin);
   max = wide_int_to_tree (TREE_TYPE (name), wmax);
+  vr.set (kind, min, max);
 }
-  vr.set (kind, min, max);
   return kind;
 }
 
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index de2f39d8487..e215b032f78 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -186,9 +186,11 @@ value_range_base::check ()
 	break;
   }
 case VR_UNDEFINED:
-case VR_VARYING:
   gcc_assert (!min () && !max ());
   break;
+case VR_VARYING:
+  gcc_assert (m_min && m_max);
+  break;
 default:
   gcc_unreachable ();
 }
@@ -214,6 +216,10 @@ value_range::check ()
 bool
 value_range_base::equal_p (const value_range_base ) const
 {
+  /* Ignore types for undefined.  All undefines are equal.  */
+  if (undefined_p ())
+return m_kind == other.m_kind;
+
   return (m_kind == other.m_kind
 	  && vrp_operand_equal_p (m_min, other.m_min)
 	  && vrp_operand_equal_p (m_max, other.m_max));
@@ -269,16 +275,19 @@ value_range::set_undefined ()
 }
 
 void
-value_range_base::set_varying ()
+value_range_base::set_varying (tree type)
 {
+  gcc_assert (supports_type_p (type));
   m_kind = VR_VARYING;
-  m_min = m_max = NULL;
+  m_min = vrp_val_min (type, true);
+  m_max = vrp_val_max (type, true);
 }
 
 void
-value_range::set_varying ()
+value_range::set_varying (tree type)
 {
-  set (VR_VARYING, NULL, NULL, NULL);
+  value_range_base::set_varying (type);
+  equiv_clear ();
 }
 
 /* Return TRUE if it is possible 

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[mpolacek at gcc dot gnu.org]

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

--- Comment #20 from Marek Polacek  ---
(In reply to Jason Merrill from comment #19)
> And now P1155/P1825 removes that text, so in C++20 mode the original
> testcase needs to call the move constructor again.  Marek, I don't see
> P1825R0 in cxx-status.html, was there a reason not to add it?

No, I followed clang's table but they're missing that one.  I'll fix that &
open a PR for P1825R0.

[Bug other/61257] configure should check if sys/sdt.h is usable, not just checking the existance of the header

[tromey at gcc dot gnu.org]

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

--- Comment #6 from Tom Tromey  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Sergei Trofimovich from comment #3)
> > (In reply to Sergei Trofimovich from comment #2)
> > > Having explicit flags like --enable-systemtap / --disable-systemtap (glibc
> > > has those) would fix the issue.
> > 
> > Proposed upstream as:
> > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00578.html
> > 
> > To clarify: it's not a complete fix for this bug. Only a way to disable
> > support manually.
> 
> I'll take this as confirmation. Also now that I've seen the actual code in
> this patch, I can say that my previous comment (comment #1) no longer
> applies, since the script is just doing `test -f` instead of
> AC_CHECK_HEADERS.

IIRC that's because it has to check target headers, but AC_CHECK_HEADERS
checks host headers.  Maybe there's some other way to do it, I don't know.

It's fine to really check the header, but I would say the scenario in
comment #2 has to fall under "don't do this".  That said, a --enable
flag or whatever also seems fine to me.

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
And now P1155/P1825 removes that text, so in C++20 mode the original testcase
needs to call the move constructor again.  Marek, I don't see P1825R0 in
cxx-status.html, was there a reason not to add it?

Re: Expansion of narrowing math built-ins into power instructions

[Segher Boessenkool]

On Mon, Aug 12, 2019 at 11:01:11PM +0530, Tejas Joshi wrote:
> I have the following code in my rs6000.md (I haven't used new TARGET_* yet) :
> 
> (define_expand "add_truncdfsf3"
>   [(set (match_operand:SF 0 "gpc_reg_operand")
>(float_truncate:SF
>(plus:DF (match_operand:DF 1 "gpc_reg_operand")
> (match_operand:DF 2 "gpc_reg_operand"]
>   "TARGET_HARD_FLOAT"
>   "")
> 
> (define_insn "*add_truncdfsf3_fpr"
>   [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
>(float_truncate:SF
>(plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
> (match_operand:DF 2 "gpc_reg_operand" "d,wa"]
>   "TARGET_HARD_FLOAT"
>   "@
>fadds %0,%1,%2
>xsaddsp %x0,%x1,%x2"
>   [(set_attr "type" "fp")])

Those look fine.  You can also merge them into one:

(define_insn "add_truncdfsf3"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
(float_truncate:SF
  (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
   (match_operand:DF 2 "gpc_reg_operand" "d,wa"]
  "TARGET_HARD_FLOAT"
  "@
   fadds %0,%1,%2
   xsaddsp %x0,%x1,%x2"
  [(set_attr "type" "fp")])

> with following optab in optabs.def :
> 
> OPTAB_CD(fadd_optab, "add_trunc$b$a3") (what is the
> difference between $b$a and $a$b?)

Which of the two modes becomes $a and which becomes $b?  It depends on
the definition of fadd_optab what order is expected, I think.


Segher

[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete

[asorenji at gmail dot com]

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

--- Comment #2 from Aso Renji  ---
(In reply to Jonathan Wakely from comment #1)
> Is there a reason you need to use -Wnon-virtual-dtor ?

QtCreator with -Wall as default compile option. Yes, I can set custom compile
options, or use #pragma GCC diagnostic ignored "-Wnon-virtual-dtor". But it's
not very convenient.

[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Mon Aug 12 17:46:37 2019
New Revision: 274317

URL: https://gcc.gnu.org/viewcvs?rev=274317=gcc=rev
Log:
PR c++/88095, CTAD for literal operator templates per P0732

This patch fixes PR c++/88095: class nontype template parameter UDL string
literals doesn't accepts deduction placeholder

It also addresses a latent issue; literal operator templates with template
parameter packs of literal class type were previously accepted.  The patch
corrects this and adds a test (udlit-class-nttp-neg.C).

This fix is needed for one of the char8_t remediation approaches documented
in P1423, and may be helpful for existing code bases impacted by the char8_t
changes adopted via P0482 for C++20.

gcc/cp/ChangeLog:

2019-08-02  Tom Honermann  

* parser.c (cp_parser_template_declaration_after_parameters): Enable
class template argument deduction for non-type template parameters
in literal operator templates.

gcc/testsuite/ChangeLog:

2019-08-02  Tom Honermann  

PR c++/88095
* g++.dg/cpp2a/udlit-class-nttp-ctad.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-ctad-neg.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-ctad-neg2.C: New test.
* g++.dg/cpp2a/udlit-class-nttp.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-neg.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-neg2.C: New test.

Added:
   
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad-neg.C
   
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad-neg2.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-neg.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-neg2.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/parser.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91378] [9 regression] [C++17] ICE in type_dependent_expression_p with noexcept and deduced return type

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Aug 12 17:46:32 2019
New Revision: 274316

URL: https://gcc.gnu.org/viewcvs?rev=274316=gcc=rev
Log:
PR c++/91378 - ICE with noexcept and auto return type.

Here, since the call to g is not type-dependent, we call mark_used on it to
determine its return type.  This also wants to instantiate the
noexcept-expression.  But since nothing in maybe_instantiate_noexcept was
calling push_to_top_level, we substituted b.i with processing_template_decl
set, so we left it unresolved for later access checking.  As a result, the
type of C::g remained instantiation-dependent, leading to an ICE in
type_dependent_expression_p on the assert that the type of a function
template with no dependent template arguments must be non-dependent.

* pt.c (maybe_instantiate_noexcept): push_to_top_level.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/auto-fn56.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/pt.c

[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Aug 12 17:46:25 2019
New Revision: 274315

URL: https://gcc.gnu.org/viewcvs?rev=274315=gcc=rev
Log:
PR c++/90538 - multiple expansions of capture packs

Previously, with init-capture the type of the closure field was a
DECLTYPE_TYPE of the initializer.  But since each time we tsubst a lambda we
get a different lambda, that meant that if the initializer is a lambda, we'd
end up with different closure types in the field and initializer after
substitution (PR 87322).  We dealt with this by remembering the lambda
instantiation within each pack expansion element, using
local_specialization_stack to separate the elements.  But that broke this
testcase, because it lost lambda capture proxies that also use
local_specializations.

So, this patch removes the local_specializations changes from that patch and
fixes 87322 differently, by giving init-capture fields 'auto' type and doing
deduction later.  There's a bit of a kludge to get the right number of
fields by pretending that 'auto...' uses the parameter packs from the
initializer, but it does the trick.

* cp-tree.h (DECLTYPE_FOR_INIT_CAPTURE): Remove.
* lambda.c (add_capture): Copy parameter packs from init.
(lambda_capture_field_type): Always use auto for init-capture.
* pt.c (uses_parameter_packs): Return tree.
(tsubst) [DECLTYPE_TYPE]: Remove init-capture handling.
(gen_elem_of_pack_expansion_instantiation): Don't push
local_specialization_stack.
(prepend_one_capture): New.
(tsubst_lambda_expr): Use it.  Don't touch local_specializations.
(do_auto_deduction): Avoid redundant error.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic9.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/cp-tree.h
branches/gcc-9-branch/gcc/cp/lambda.c
branches/gcc-9-branch/gcc/cp/pt.c
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/range-for19.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/lambda-init16.C

[Bug c++/91423] address-of-packed-member when taking packed struct member by value

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Vec size = s.size;

you are invoking the copy constructor here ...
Which means you are taking the address (implicitly).

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hi,
I have the following code in my rs6000.md (I haven't used new TARGET_* yet) :

(define_expand "add_truncdfsf3"
  [(set (match_operand:SF 0 "gpc_reg_operand")
   (float_truncate:SF
   (plus:DF (match_operand:DF 1 "gpc_reg_operand")
(match_operand:DF 2 "gpc_reg_operand"]
  "TARGET_HARD_FLOAT"
  "")

(define_insn "*add_truncdfsf3_fpr"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
   (float_truncate:SF
   (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
(match_operand:DF 2 "gpc_reg_operand" "d,wa"]
  "TARGET_HARD_FLOAT"
  "@
   fadds %0,%1,%2
   xsaddsp %x0,%x1,%x2"
  [(set_attr "type" "fp")])

with following optab in optabs.def :

OPTAB_CD(fadd_optab, "add_trunc$b$a3") (what is the
difference between $b$a and $a$b?)

I have also tried adding fadd, add_truncdfsf3 in rs6000-builtin.def,
examined rtl dumps multiple times but couldn't get fadd to be
exapanded. What am I missing here?

Thanks,
Tejas

On Sun, 11 Aug 2019 at 22:29, Segher Boessenkool
 wrote:
>
> Hi Tejas,
>
> On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> > +(define_expand "add_truncdfsf3"
> > +  [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand"))
> > + (plus:DF (match_operand:DF 1 "gpc_reg_operand")
> > +  (match_operand:DF 2 "gpc_reg_operand")))]
> > +  "TARGET_HARD_FLOAT"
> > +  "")
>
> float_extend on the LHS is never correct.  I think the following should
> work, never mind that it looks like it does double rounding, because it
> doesn't (famous last words ;-) ):
>
> (define_expand "add_truncdfsf3"
>   [(set (match_operand:SF 0 "gpc_reg_operand")
> (float_truncate:SF
>   (plus:DF (match_operand:DF 1 "gpc_reg_operand")
>(match_operand:DF 2 "gpc_reg_operand"]
>   "TARGET_HARD_FLOAT"
>   "")
>
> > +(define_insn "*add_truncdfsf3_fpr"
> > +  [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand" "="))
> > + (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%")
> > +  (match_operand:DF 2 "gpc_reg_operand" "")))]
> > +  "TARGET_HARD_FLOAT"
> > +  "fadd %0,%1,%2"
> > +  [(set_attr "type" "fp")])
>
> The constraints should be "f", "%d", "d", respectively.   says to
> display something for the mode in a mode iterator.  There is no mode
> iterator here.  (In what you copied this from, there was SFDF).
>
> You want to output "fadds", not "fadd".
>
> Maybe it is easier to immediately write the VSX scalar version for this
> as well?  That's xsaddsp.  Oh, and you need to restrict all of this to
> more recent CPUs, we'll have to do some new TARGET_* flag for that I
> think.
>
> Finally: please send patches to gcc-patches@ (not gcc@).
>
> Thanks,
>
>
> Segher

[Bug c++/91418] Nested class of templated class cannot declare parent class friend

[harald at gigawatt dot nl]

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

--- Comment #5 from Harald van Dijk  ---
(In reply to Darrell Wright from comment #4)
> The weird part is, other than compilers don't agree, but the lookup finds it
> if you put the template argument in

The idea there seems to be that `class A;` declares a local or nested class,
but `A;`, `class A;`, `class ::A;` do not, and `friend` does not change
that.

This is not something I can find support for in the standard though.

Re: [PATCH][AArch64] Increase default function alignment

[James Greenhalgh]

On Fri, May 31, 2019 at 12:52:32PM +0100, Wilco Dijkstra wrote:
> With -mcpu=generic the function alignment is currently 8, however almost all
> supported cores prefer 16 or higher, so increase the default to 16:12.
> This gives ~0.2% performance increase on SPECINT2017, while codesize is 0.12%
> larger.

OK.

Thanks,
James

> ChangeLog:
> 2019-05-31  Wilco Dijkstra  
> 
>   * config/aarch64/aarch64.c (generic_tunings): Set function alignment to 
> 16.
> 
> --
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
> 0023cb37bbae5afe9387840c1bb6b43586d4fac2..ed1422af6aab5e3c6eeea37ec57e69b64092a0ab
>  100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -693,7 +693,7 @@ static const struct tune_params generic_tunings =
>4, /* memmov_cost  */
>2, /* issue_rate  */
>(AARCH64_FUSE_AES_AESMC), /* fusible_ops  */
> -  "8",   /* function_align.  */
> +  "16:12",   /* function_align.  */
>"4",   /* jump_align.  */
>"8",   /* loop_align.  */
>2, /* int_reassoc_width.  */
> 

Re: [PATCH][aarch64] Use neoversen1 tuning struct for -mcpu=cortex-a76

[James Greenhalgh]

On Tue, Jul 30, 2019 at 05:59:15PM +0100, Kyrill Tkachov wrote:
> Hi all,
> 
> The neoversen1 tuning struct gives better performance on the Cortex-A76, 
> so use that.
> The only difference from the current tuning is the function and label 
> alignment settings.
> 
> This gives about 1.3% improvement on SPEC2006 int and 0.3% on SPEC2006 fp.
> 
> Tested on aarch64-none-elf.
> 
> Ok for trunk?

OK.

Thanks,
James

> Thanks,
> Kyrill
> 
> 2019-07-31  Kyrylo Tkachov  
> 
>      * config/aarch64/aarch64-cores.def (cortex-a76): Use neoversen1 tuning
>      struct.
> 

Re: [PATCH][AArch64] Fix PR81800

[James Greenhalgh]

On Tue, May 28, 2019 at 06:11:29PM +0100, Wilco Dijkstra wrote:
> PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions.
> The previous change for PR81800 didn't fix this: when lrint is disabled
> in the backend, the midend will simply use llrint.  This actually makes
> things worse since llrint now also ignores FE_INVALID exceptions!
> The fix is to disable lrint/llrint on double if the size of a long is
> smaller (ie. ilp32).
> 
> Passes regress and bootstrap on AArch64. OK for commit?

OK.

Thanks,
James

> 
> ChangeLog
> 2018-11-13  Wilco Dijkstra
> 
> gcc/
>   PR target/81800
>   * gcc/config/aarch64/aarch64.md (lrint): Disable lrint pattern if GPF
>   operand is larger than a long int.
> 
> testsuite/
>   PR target/81800
>   * gcc.target/aarch64/no-inline-lrint_3.c: New test.
> 
> --
> 
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> 5a1894063a1ed2db1cc947c9c449d48808ed96ae..f08cd0930b3fc6527fbca218ad3c464f1ead0103
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -6304,7 +6304,7 @@ (define_expand "lrint2"
>[(match_operand:GPI 0 "register_operand")
> (match_operand:GPF 1 "register_operand")]
>"TARGET_FLOAT
> -   && ((GET_MODE_SIZE (mode) <= GET_MODE_SIZE (mode))
> +   && ((GET_MODE_BITSIZE (mode) <= LONG_TYPE_SIZE)
> || !flag_trapping_math || flag_fp_int_builtin_inexact)"
>  {
>rtx cvt = gen_reg_rtx (mode);
> diff --git a/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c 
> b/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c
> new file mode 100644
> index 
> ..ca772cb999e7b6cfbd3f080111d3eb479d43f47b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c
> @@ -0,0 +1,17 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O3 -fno-math-errno -fno-fp-int-builtin-inexact" } */
> +
> +#define TEST(name, float_type, int_type, fn) void f_##name (float_type x) \
> +{  \
> +  volatile int_type   b = __builtin_##fn (x);
>   \
> +}
> +
> +TEST (dld, double, long, lrint)
> +TEST (flf, float , long, lrintf)
> +
> +TEST (did, double, int, lrint)
> +TEST (fif, float , int, lrintf)
> +
> +/* { dg-final { scan-assembler-times "fcvtzs\tw\[0-9\]+, \[d,s\]\[0-9\]+" 2 
> } } */
> +/* { dg-final { scan-assembler-times "bl\tlrint" 2 } } */
> 

[Bug fortran/91424] Extend warnings about DO loops

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Eric Gallager from comment #2)

> - the "2" location marker is a different color from the "1" location marker,
> if you have colorized output

That is now PR 91426.

Re: [PATCH] Add generic support for "noinit" attribute

[Jozef Lawrynowicz]

Hi,

On Tue, 30 Jul 2019 15:35:23 +0200
Christophe Lyon  wrote:

> Hi,
> 
> Thanks for the useful feedback.
> 
> 
> On Tue, 16 Jul 2019 at 11:54, Richard Sandiford
>  wrote:
> >
> > Thanks for doing this in a generic way.
> >
> > Christophe Lyon  writes:  
> > > @@ -2224,6 +2234,50 @@ handle_weak_attribute (tree *node, tree name,
> > >return NULL_TREE;
> > >  }
> > >
> > > +/* Handle a "noinit" attribute; arguments as in struct
> > > +   attribute_spec.handler.  Check whether the attribute is allowed
> > > +   here and add the attribute to the variable decl tree or otherwise
> > > +   issue a diagnostic.  This function checks NODE is of the expected
> > > +   type and issues diagnostics otherwise using NAME.  If it is not of
> > > +   the expected type *NO_ADD_ATTRS will be set to true.  */
> > > +
> > > +static tree
> > > +handle_noinit_attribute (tree * node,
> > > +   tree   name,
> > > +   tree   args,
> > > +   intflags ATTRIBUTE_UNUSED,
> > > +   bool *no_add_attrs)
> > > +{
> > > +  const char *message = NULL;
> > > +
> > > +  gcc_assert (DECL_P (*node));
> > > +  gcc_assert (args == NULL);
> > > +
> > > +  if (TREE_CODE (*node) != VAR_DECL)
> > > +message = G_("%qE attribute only applies to variables");
> > > +
> > > +  /* Check that it's possible for the variable to have a section.  */
> > > +  if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
> > > +  && DECL_SECTION_NAME (*node))
> > > +message = G_("%qE attribute cannot be applied to variables "
> > > +  "with specific sections");
> > > +
> > > +  /* If this var is thought to be common, then change this.  Common
> > > + variables are assigned to sections before the backend has a
> > > + chance to process them.  */
> > > +  if (DECL_COMMON (*node))
> > > +DECL_COMMON (*node) = 0;
> > > +
> > > +  if (message)
> > > +{
> > > +  warning (OPT_Wattributes, message, name);
> > > +  *no_add_attrs = true;
> > > +}
> > > +
> > > +  return NULL_TREE;
> > > +}  
> >
> > This might cause us to clear DECL_COMMON even when rejecting the
> > attribute.  Also, the first message should win over the others
> > (e.g. for a function in a particular section).
> >
> > So I think the "/* Check that it's possible ..." should be an else-if
> > and the DECL_COMMON stuff should be specific to !message.  
> 
> You are right, thanks.
> 
> Jozef, this is true for msp430_data_attr() too. I'll let you update it.
> 
> >
> > Since this is specific to ELF targets, I think we should also
> > warn if !targetm.have_switchable_bss_sections.
> >  
> OK
> 
> > > @@ -2338,6 +2336,8 @@ msp430_select_section (tree decl, int reloc, 
> > > unsigned HOST_WIDE_INT align)
> > >  {
> > >if (TREE_CODE (decl) == FUNCTION_DECL)
> > >   return text_section;
> > > +  /* FIXME: ATTR_NOINIT is handled generically in
> > > +  default_elf_select_section.  */
> > >else if (has_attr (ATTR_NOINIT, decl))
> > >   return noinit_section;
> > >else if (has_attr (ATTR_PERSIST, decl))  
> >
> > I guess adding a FIXME is OK.  It's very tempting to remove
> > the noinit stuff and use default_elf_select_section instead of
> > default_select_section, but I realise that'd be difficult to test.  
> 
> I added that as suggested by Jozef, it's best if he handles the
> change you propose, I guess he can do proper testing.

BTW, regarding this, I have rearranged msp430_select_section in the attached WIP
patch, so that it will use default_elf_select_section to handle "noinit". Once
your patch is applied, I'll submit some variant of this patch.

Still, better leave the FIXME in, and I'll remove it in my patch.

Likewise for all the other fixes required in msp430.c, once this patch is
applied, I'll fix those up.

Thanks,
Jozef

> 
> 
> > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > > index f2619e1..850153e 100644
> > > --- a/gcc/doc/extend.texi
> > > +++ b/gcc/doc/extend.texi
> > > @@ -7129,6 +7129,12 @@ The @code{visibility} attribute is described in
> > >  The @code{weak} attribute is described in
> > >  @ref{Common Function Attributes}.
> > >
> > > +@item noinit
> > > +@cindex @code{noinit} variable attribute
> > > +Any data with the @code{noinit} attribute will not be initialized by
> > > +the C runtime startup code, or the program loader.  Not initializing
> > > +data in this way can reduce program startup times.
> > > +
> > >  @end table
> > >
> > >  @node ARC Variable Attributes  
> >
> > Would be good to mention that the attribute is specific to ELF targets.
> > (Yeah, we don't seem to do that consistently for other attributes.)
> > It might also be worth saying that it requires specific linker support.  
> OK, done.
> 
> >  
> > > diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c 
> > > b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > > new file mode 100644
> > > index 000..f33c0d0
> > > --- /dev/null
> 

[Bug fortran/91426] New: Different colors for errors with multiple locations

[tkoenig at gcc dot gnu.org]

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

Bug ID: 91426
   Summary: Different colors for errors with multiple locations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following program

program main
10 continue
10 continue
end

yields

label.f90:2:2:

2 | 10 continue
  |  1
3 | 10 continue
  |  2
Error: Duplicate statement label 10 at (1) and (2)

as it should. However (not visible here), the first marker (1) is red,
and the second one (2) is green.  Expected behavior is that they should
be the same color.

Re: [AArch64] Add a "y" constraint for V0-V7

[James Greenhalgh]

On Wed, Aug 07, 2019 at 07:19:12PM +0100, Richard Sandiford wrote:
> Some indexed SVE FCMLA operations have a 3-bit register field that
> requires one of Z0-Z7.  This patch adds a public "y" constraint for that.
> 
> The patch also documents "x", which is again intended to be a public
> constraint.
> 
> Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
> OK to install?


I had the vague recollection that 'y' already meant something... I'm
guessing you already checked, but just in case, please check.

Otherwise, this is OK.

Thanks,
James


> 
> Richard
> 
> 
> 2019-08-07  Richard Sandiford  
> 
> gcc/
>   * doc/md.texi: Document the x and y constraints for AArch64.
>   * config/aarch64/aarch64.h (FP_LO8_REGNUM_P): New macro.
>   (FP_LO8_REGS): New reg_class.
>   (REG_CLASS_NAMES, REG_CLASS_CONTENTS): Add an entry for FP_LO8_REGS.
>   * config/aarch64/aarch64.c (aarch64_hard_regno_nregs)
>   (aarch64_regno_regclass, aarch64_class_max_nregs): Handle FP_LO8_REGS.
>   * config/aarch64/predicates.md (aarch64_simd_register): Use
>   FP_REGNUM_P instead of checking the classes manually.
>   * config/aarch64/constraints.md (y): New constraint.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/asm-x-constraint-1.c: New test.
>   * gcc.target/aarch64/asm-y-constraint-1.c: Likewise.
> 

Re: [AArch64] Make aarch64_classify_vector_mode use a switch statement

[James Greenhalgh]

On Wed, Aug 07, 2019 at 07:24:18PM +0100, Richard Sandiford wrote:
> aarch64_classify_vector_mode used properties of a mode to test whether
> the mode was a single Advanced SIMD vector, a single SVE vector, or a
> tuple of SVE vectors.  That works well for current trunk and is simpler
> than checking for modes by name.
> 
> However, for the ACLE and for planned autovec improvements, we also
> need partial SVE vector modes that hold:
> 
> - half of the available 32-bit elements
> - a half or quarter of the available 16-bit elements
> - a half, quarter, or eighth of the available 8-bit elements
> 
> These should be packed in memory and unpacked in registers.  E.g.
> VNx2SI has half the number of elements of VNx4SI, and so is half the
> size in memory.  When stored in registers, each VNx2SI element occupies
> the low 32 bits of a VNx2DI element, with the upper bits being undefined.
> 
> The upshot is that:
> 
>   GET_MODE_SIZE (VNx4SImode) == 2 * GET_MODE_SIZE (VNx2SImode)
> 
> since GET_MODE_SIZE must always be the memory size.  This in turn means
> that for fixed-length SVE, some partial modes can have the same size as
> Advanced SIMD modes.  We then need to be specific about which mode we're
> dealing with.
> 
> This patch prepares for that by switching based on the mode instead
> of querying properties.
> 
> A later patch makes sure that Advanced SIMD modes always win over
> partial SVE vector modes in normal queries.
> 
> Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
> OK to install?

OK.

Thanks,
James

> 
> Richard
> 
> 
> 2019-08-07  Richard Sandiford  
> 
> gcc/
>   * config/aarch64/aarch64.c (aarch64_classify_vector_mode): Switch
>   based on the mode instead of testing properties of it.

[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Intrinsics now implemented for GCC 10+, keeping open for some optimizations.

Re: [AArch64] Make the complete mnemonic

[James Greenhalgh]

On Wed, Aug 07, 2019 at 08:23:48PM +0100, Richard Sandiford wrote:
> The Advanced SIMD and SVE permute patterns both split the permute
> operation into a base name and a hilo suffix.  That works well, but it
> means that for "@" patterns, we need to pass the permute code twice,
> once for the base name and once for the suffix.
> 
> Having a unified name avoids that and also makes the definitions
> slightly simpler.
> 
> Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
> OK to install?

OK.

Thanks,
James

> 
> 2019-08-07  Richard Sandiford  
> 
> gcc/
>   * config/aarch64/iterators.md (perm_insn): Include the "1"/"2" suffix.
>   (perm_hilo): Remove UNSPEC_ZIP*, UNSEPC_TRN* and UNSPEC_UZP*.
>   * config/aarch64/aarch64-simd.md
>   (aarch64_): Rename to..
>   (aarch64_): ...this and remove perm_hilo
>   from the asm template.
>   * config/aarch64/aarch64-sve.md
>   (aarch64_): Rename to..
>   (aarch64_): ...this and remove perm_hilo
>   from the asm template.
>   (aarch64_): Rename to..
>   (aarch64_): ...this and remove perm_hilo
>   from the asm template.
>   * config/aarch64/aarch64-simd-builtins.def: Update comment.

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug 12 16:41:27 2019
New Revision: 274314

URL: https://gcc.gnu.org/viewcvs?rev=274314=gcc=rev
Log:
PR libstdc++/90361 add missing macro definition

The src/c++17/string-inst.cc file needs to override the default string
ABI so that it still contains the expected symbols even when the library
is configured with --with-default-libstdcxx-abi=gcc4-compatible.

PR libstdc++/90361
* src/c++17/string-inst.cc: Use _GLIBCXX_USE_CXX11_ABI=1 by default.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/string-inst.cc

[Bug c/69558] [7/8 Regression] glib2 warning pragmas stopped working

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Target Milestone|9.3 |8.5

--- Comment #30 from Eric Gallager  ---
(In reply to Bernd Edlinger from comment #29)
> Hm, the target milestone is wrong. I believe this was fixed in gcc-9

changing it to something starting in 8 then

[PATCH] PR libstdc++/90361 add missing macro definition

[Jonathan Wakely]

The src/c++17/string-inst.cc file needs to override the default string
ABI so that it still contains the expected symbols even when the library
is configured with --with-default-libstdcxx-abi=gcc4-compatible.

PR libstdc++/90361
* src/c++17/string-inst.cc: Use _GLIBCXX_USE_CXX11_ABI=1 by default.

Tested x86_64-linux, committed to trunk.


commit 5225243411b6c5ffb5c30e558b25721450337c01
Author: Jonathan Wakely 
Date:   Mon Aug 12 17:16:55 2019 +0100

PR libstdc++/90361 add missing macro definition

The src/c++17/string-inst.cc file needs to override the default string
ABI so that it still contains the expected symbols even when the library
is configured with --with-default-libstdcxx-abi=gcc4-compatible.

PR libstdc++/90361
* src/c++17/string-inst.cc: Use _GLIBCXX_USE_CXX11_ABI=1 by default.

diff --git a/libstdc++-v3/src/c++17/string-inst.cc 
b/libstdc++-v3/src/c++17/string-inst.cc
index c095a90587e..4dc0a9ca449 100644
--- a/libstdc++-v3/src/c++17/string-inst.cc
+++ b/libstdc++-v3/src/c++17/string-inst.cc
@@ -26,6 +26,12 @@
 // ISO C++ 14882:2017 24  Strings library
 //
 
+#ifndef _GLIBCXX_USE_CXX11_ABI
+// Instantiations in this file use the new SSO std::string ABI unless included
+// by another file which defines _GLIBCXX_USE_CXX11_ABI=0.
+# define _GLIBCXX_USE_CXX11_ABI 1
+#endif
+
 #include 
 
 namespace std _GLIBCXX_VISIBILITY(default)

[Bug c++/77711] Add fix-it hints for missing parentheses in member function call

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.3 |10.0

[Bug fortran/91424] Extend warnings about DO loops

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
(In reply to Eric Gallager from comment #2)
> Also:
> - there's no option flag controlling the warning

That one is by design.  There is no way that this can even
be valid code.

> - the "2" location marker is a different color from the "1" location marker,
> if you have colorized output

How would I change that?

Re: [PATCH] Teach mklog to reference PRs.

[Marek Polacek]

On Mon, Aug 12, 2019 at 10:27:46AM -0600, Martin Sebor wrote:
> FWIW, another feature I find useful that mklog doesn't seem to have
> is one that strips the context details from testsuite ChangeLogs.
> Hardly anyone bothers to mention the functions, macros, types, or
> variables they changed in tests, so having the script strip it from
> the ChangeLog entry (unless some special option is used for the few
> of us who really want to mention it) would reduce the work one has
> to put in to edit the templates.

Perhaps it could have an option to avoid generating ChangeLog entries for
testsuite/* altogether:
https://gcc.gnu.org/codingconventions.html#ChangeLogs

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[Bug fortran/91424] Extend warnings about DO loops

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
Also:
- there's no option flag controlling the warning
- the "2" location marker is a different color from the "1" location marker, if
you have colorized output

Re: [PATCH] Teach mklog to reference PRs.

[Martin Sebor]

On 8/2/19 12:04 AM, Martin Liška wrote:

On 8/2/19 7:45 AM, Martin Liška wrote:

I agree with that approach.


I'm sending an example how it would look like for something
bigger:

$ git diff 
e8a3be407068bfb9c82f0f6656b30d26cc2f484a~15..e8a3be407068bfb9c82f0f6656b30d26cc2f484a > 
patch && ./contrib/mklog patch > changelog.txt

Thoughts?


I didn't know about mklog at first and I wrote my own script
to do the same thing, so I think the enhancement is useful.

My script also inserts the PR string like your patch but without
any special options it does it by a) extracting the PR number
from the patch name (my naming convention for patch files is
-.diff, such as gcc-12345.diff), and b) querying
Bugzilla for the component name of the bug (additional bug ids
can be passed to the script on the command line).  I would
consider switching to mklog if it had this feature plus the one
below.

To answer your question above, I have yet another script to apply
both a patch and insert the ChangeLogs.  The script expects each
ChangeLog entry at the top of the patch to be introduced by
the directory prefix, like so (separated by blank lines):

PR c/12345 - title of the C bug from Bugzilla
PR c/23456 - title of the other C bug from Bugzilla
PR c++/34567 - title of the C++ bug from Bugzilla

gcc/ChangeLog:

PR c/12345
* foo.c (blah): Make blah better.

gcc/c/ChangeLog:

PR c/12345
PR c/23456
* bar.c (blah): Some C change.

gcc/cp/ChangeLog:

PR c/12345
PR c++/34567
* bar.c (blah): Some other change.

Here's an example of the format from one of my recent patches:
  https://gcc.gnu.org/ml/gcc-patches/2019-08/msg0.html

The script extracts each block between the .../ChangeLog: lines,
adds it at the top of the ChangeLog file, and then takes the whole
thing and makes it the SVN description that I then pass as
an argument to svn ci -F.

The format you ask about would let me come pretty close to doing
that.  What it wouldn't let me do is use different bugs for
different components in the same commit.  It doesn't happen often
to me so it wouldn't a big deal but it might be something to think
about in case it happens more commonly to others.  I would have
to massage my applypatch.sh script to adjust to the slightly
different format but that should be easy.

FWIW, another feature I find useful that mklog doesn't seem to have
is one that strips the context details from testsuite ChangeLogs.
Hardly anyone bothers to mention the functions, macros, types, or
variables they changed in tests, so having the script strip it from
the ChangeLog entry (unless some special option is used for the few
of us who really want to mention it) would reduce the work one has
to put in to edit the templates.

Martin

[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4

[matthew.thompson at nasa dot gov]

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

--- Comment #29 from Matt Thompson  ---
Also, this did seem to build GCC:

CC="/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/gcc
--sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
CXX="/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/g++
--sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
../gcc-9.2.0/configure
--prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0-820loaded
--enable-languages=c,c++,fortran
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee
configure.log

So if nothing else, I have a way around the clang issue. I'll inform you on the
updated prerequisites build.

[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4

[matthew.thompson at nasa dot gov]

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

--- Comment #28 from Matt Thompson  ---
(In reply to Iain Sandoe from comment #27)
> That's fine - essentially, you're building them from source and therefore
> don't need to worry about --with-gmp= configure options etc.
> 
> For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.

Well, it looks like download_prerequisites might be behind the times:

gmp='gmp-6.1.0.tar.bz2'
mpfr='mpfr-3.1.4.tar.bz2'
mpc='mpc-1.0.3.tar.gz'
isl='isl-0.18.tar.bz2'

I'm going to try and download the newest versions of all these and build with
them. Maybe that'll help (though I don't see much/any C++ in them...).