Re: [PATCH] PR fortran/91785 -- Set locus for inquiry parameter

[Jerry DeLisle]

On 10/1/19 5:06 PM, Steve Kargl wrote:

The attached patch has been tested on x86_64-*-freebsd.
OK to commit?



Ok Steve,

Thanks,

Jerry

The patch prevents an ICE by setting the locus of an
inquiry parameter.

2019-10-01  Steven G. Kargl  

Re: [PATCH] PR fortran/91784 -- Simplify EXPR_OP in conversion of constants

[Jerry DeLisle]

On 10/1/19 4:46 PM, Steve Kargl wrote:

The attached patch has been tested on x86_64-*-freebsd.
OK to commmit?


OK, thanks Steve.



In a previous patch, I specialized the simplfication of
an EXPR_OP to the case of an inserted parenthesis.  This
was too restrictive as evidenced by the new test case.
The patch simply does a simplification of an expression.
  
2019-10-01  Steven G. Kargl  


PR fortran/91784
* simplify.c (gfc_convert_constant): Simplify expression if the
expression type is EXPR_OP.

2019-10-01  Steven G. Kargl  

PR fortran/91784
* gfortran.dg/pr91784.f90: New test.

Re: [PATCH] PR fortran/91942 -- Inquiry parameter cannot be IO tag

[Jerry DeLisle]

On 10/1/19 4:10 PM, Steve Kargl wrote:

The attached patch has been tested on x86_64-*-freebsd.
OK to commit?



OK Steve, thanks,

Jerry

Re: RFC: Followup to PR91593

[Jerry DeLisle]

On 10/1/19 12:40 PM, Martin Sebor wrote:

On 9/30/19 9:40 PM, Jerry DeLisle wrote:

Copying gcc list for additional thoughts on a possible bogus warning.

On 9/29/19 9:02 AM, Jerry DeLisle wrote:


--- snip ---


In case it helps, the warning is for the access:

   # .MEM_68 = VDEF <.MEM_71>
   MEM[(char *)_86] = 0;

where _86 is set to

   _86 = _buf + _43;

and _43 has the range [136, 17179869176].  (The warning needs to
be enhanced a bit to mention the accessed object in this case.)
itoa_buf's DECL_SIZE_UNIT evaluates to 129.

The call to btoa_big in write_b:

   p = btoa_big (source, itoa_buf, len, );

is made with len > 16.  If len > sizeof itoa_buf  / 8 then it does
look like btoa_big would write past the end of itoa_buf because it
writes len * 8 bytes into it.  I don't know if the function can be
called with len that large but if not, adding this just above
the call suppresses the warning.

   if (len > sizeof itoa_buf / 8)
 __builtin_unreachable ();

Martin



Thanks Martin, this does help me understand why the warning. Yes, len cannot be 
greater than 16. I decided to just use memset in write_b where the buffer is 
created to avoid the assignment that triggers the warning. Your suggestion may 
likewise work. In my comments describing the warning as bogus, by bogus, I mean 
"not applicable" to the situation.


I notice many warnings flying by when building gcc/gfortran. My preference would 
be to clear as many off as possible so that we can actually notice warnings when 
they are applicable and not miss them among a crowd of warnings.


I don't know if this makes sense to anyone and I do appreciate your response.

Jerry

[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Oct  2 02:35:14 2019
New Revision: 276439

URL: https://gcc.gnu.org/viewcvs?rev=276439=gcc=rev
Log:
2019-10-01  Jerry DeLisle  

PR libfortran/91593
* io/read.c (read_decimal): Cast constant to size_t to turn off
a bogus warning.
* io/write.c (btoa_big): Use memset in lieu of setting the null
byte in a string buffer to turn off a bogus warning.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/read.c
trunk/libgfortran/io/write.c

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-02
 Ever confirmed|0   |1

--- Comment #10 from Oleg Endo  ---
(In reply to Zavadovsky Yan from comment #9)
> 
> Checked GCC 8.2 + your patch and crosstool-ng to build toolchain(using same
> config as I've used while reporting bug).
> 
> At least it works on attached main.cpp.
> Got no assert when run on our STiH237-based board.

OK, thanks for confirming it.  I think the fabs instruction is affected in the
same way.


I have to think about how to integrate this fix.  We can set it as a default
behavior for all FPU-capable SH4 variants, but that will pessimize it for
everything.

The other option is to enable this only for your specific CPU (ST-40), which
would require you to use the -m4-300 option, not the -m4 option.  I would
recommend you to use -m4-300 as it will also enable some other features which
will generate better code than running plain SH4 code with -m4.

If we tie this fix to -m4-300, if you're building a linux system, you will need
to build the compiler with -m4-300 as a default, instead of -m4.  If not doing
linux with a generic sh-elf bare-metal compiler, you'd need to specify -m4-300
when compiling all the software.  Would that be feasible for you?

[Bug c/91961] __has_attribute expands macro argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66970,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80005

--- Comment #3 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #2)
> There's bug 80005 for expansion of __has_include arguments.

yeah that's the one I was thinking of, too

Handle :: tokens in C for C2x

[Joseph Myers]

As part of adding [[]]-style attributes, C2x adds the token :: for use
in scoped attribute names.

This patch adds corresponding support for that token in C to GCC.  The
token is supported both for C2x and for older gnu* standards (on the
basis that extensions are normally supported in older gnu* versions;
people will expect to be able to use [[]] attributes, before C2x is
the default, without needing to use -std=gnu2x).

There are no cases in older C standards where the token : can be
followed by a token starting with : in syntactically valid sources;
the only cases the :: token could break in older standard C thus are
ones involving concatenation of pp-tokens where the result does not
end up as tokens (e.g., gets stringized).  In GNU C extensions, the
main case where :: might appear in existing sources is in asm
statements, and the C parser is thus made to handle it like two
consecutive : tokens, which the C++ parser already does.  A limited
test of various positionings of :: in asm statements is added to the
testsuite (in particular, to cover the syntax error when :: means too
many colons but a single : would be OK), but existing tests cover a
variety of styles there anyway.

Technically there are cases in Objective-C and OpenMP for which this
also changes how previously valid code is lexed: the objc-selector-arg
syntax allows multiple consecutive : tokens (although I don't think
they are particularly useful there), while OpenMP syntax includes
array section syntax such as [:] which, before :: was a token, could
also be written as [::> (there might be other OpenMP cases potentially
affected, I didn't check all the OpenMP syntax in detail).  I don't
think either of those cases affects the basis for supporting the ::
token in all -std=gnu* modes, or that there is any obvious need to
special-case handling of CPP_SCOPE tokens for those constructs the way
there is for asm statements.

cpp_avoid_paste, which determines when spaces need adding between
tokens in preprocessed output where there wouldn't otherwise be
whitespace between them (e.g. if stringized), already inserts space
between : and : unconditionally, rather than only for C++, so no
change is needed there (but a C2x test is added that such space is
indeed inserted).

Bootstrapped with no regressions on x86-64-pc-linux-gnu.  Applied to
mainline.

gcc/c:
2019-10-02  Joseph Myers  

* c-parser.c (c_parser_asm_statement): Handle CPP_SCOPE like two
CPP_COLON tokens.

gcc/testsuite:
2019-10-02  Joseph Myers  

* gcc.dg/asm-scope-1.c, gcc.dg/cpp/c11-scope-1.c,
gcc.dg/cpp/c17-scope-1.c, gcc.dg/cpp/c2x-scope-1.c,
gcc.dg/cpp/c2x-scope-2.c, gcc.dg/cpp/c90-scope-1.c,
gcc.dg/cpp/c94-scope-1.c, gcc.dg/cpp/c99-scope-1.c,
gcc.dg/cpp/gnu11-scope-1.c, gcc.dg/cpp/gnu17-scope-1.c,
gcc.dg/cpp/gnu89-scope-1.c, gcc.dg/cpp/gnu99-scope-1.c: New tests.

libcpp:
2019-10-02  Joseph Myers  

* include/cpplib.h (struct cpp_options): Add member scope.
* init.c (struct lang_flags, lang_defaults): Likewise.
(cpp_set_lang): Set scope member of pfile.
* lex.c (_cpp_lex_direct): Test CPP_OPTION (pfile, scope) not
CPP_OPTION (pfile, cplusplus) for creating CPP_SCOPE tokens.

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c(revision 276414)
+++ gcc/c/c-parser.c(working copy)
@@ -6411,8 +6411,10 @@
 
The form with asm-goto-operands is valid if and only if the
asm-qualifier-list contains goto, and is the only allowed form in that case.
-   Duplicate asm-qualifiers are not allowed.  */
+   Duplicate asm-qualifiers are not allowed.
 
+   The :: token is considered equivalent to two consecutive : tokens.  */
+
 static tree
 c_parser_asm_statement (c_parser *parser)
 {
@@ -6509,11 +6511,21 @@
   nsections = 3 + is_goto;
   for (section = 0; section < nsections; ++section)
 {
-  if (!c_parser_require (parser, CPP_COLON,
-is_goto
-? G_("expected %<:%>")
-: G_("expected %<:%> or %<)%>"),
-UNKNOWN_LOCATION, is_goto))
+  if (c_parser_next_token_is (parser, CPP_SCOPE))
+   {
+ ++section;
+ if (section == nsections)
+   {
+ c_parser_error (parser, "expected %<)%>");
+ goto error_close_paren;
+   }
+ c_parser_consume_token (parser);
+   }
+  else if (!c_parser_require (parser, CPP_COLON,
+ is_goto
+ ? G_("expected %<:%>")
+ : G_("expected %<:%> or %<)%>"),
+ UNKNOWN_LOCATION, is_goto))
goto error_close_paren;
 
   /* Once past any colon, we're no longer a simple asm.  */
@@ -6520,6 +6532,7 @@
   simple = false;
 
   if ((!c_parser_next_token_is (parser, CPP_COLON)
+  

[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.3

Re: RTL alternative selection question

[Segher Boessenkool]

On Tue, Oct 01, 2019 at 01:12:06PM +0100, Andrew Stubbs wrote:
> On 23/09/2019 15:39, Andrew Stubbs wrote:
> >On 23/09/2019 15:15, Segher Boessenkool wrote:
> >>On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
> >>>   [(set (match_operand:DI 0 "register_operand"  "=Sg,v")
> >>> (ashift:DI
> >>>   (match_operand:DI 1 "gcn_alu_operand" " Sg,v")
> >>>   (match_operand:SI 2 "gcn_alu_operand" " Sg,v")))
> >>>    (clobber (match_scratch:BI 3 
> >>>"=cs,X"))]
> >>
> >>>Unfortunately, the compiler (almost?) exclusively selects the second
> >>>alternative, even when this means moving the values from one register
> >>>file to the other, and then back again.
> >>>
> >>>The problem is that the scalar instruction clobbers the CC register,
> >>>which results in a "reject++" for that alternative in the LRA dump.
> >>
> >>What kind of reject?  It prints a reason, too.
> >
> >  0 Non input pseudo reload: reject++
> 
> Apparently I was confused by operand "0" versus alternative "0". That 
> message did occur, but it wasn't the only one. Here's all of it:
> 
>  0 Non input pseudo reload: reject++
>  3 Scratch win: reject+=2
>alt=0,overall=9,losers=1,rld_nregs=2
>alt=1,overall=6,losers=1,rld_nregs=2
> 
> I don't understand why the "reject++" occurs, but presumably has to do 
> with the "Sg" register availability somehow?

operands[0] (the output) needed a reload, apparently.

[ snip ]

> Unfortunately, removing the "Scratch win" penalty alone is not enough 
> for LRA to select the first alternative -- at least, no in my testcase 
> -- so I need to understand the "non input pseudo reload" issue as well. 
> I can see why it fires for alt0, but not why it does not fire for alt1.

The reload it decided to do there was for operands[1] or operands[2]?


Segher

[PATCH] PR fortran/91785 -- Set locus for inquiry parameter

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.
OK to commit?

The patch prevents an ICE by setting the locus of an
inquiry parameter.

2019-10-01  Steven G. Kargl  Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c	(revision 276426)
+++ gcc/fortran/primary.c	(working copy)
@@ -2331,6 +2331,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 
 
   if (tmp && tmp->type == REF_INQUIRY)
 	{
+	  if (!primary->where.lb || !primary->where.nextc)
+	primary->where = gfc_current_locus;
 	  gfc_simplify_expr (primary, 0);
 
 	  if (primary->expr_type == EXPR_CONSTANT)
Index: gcc/testsuite/gfortran.dg/pr91785.f90
===
--- gcc/testsuite/gfortran.dg/pr91785.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91785.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/91785
+! Code contributed by Gerhard Steinmetz
+program p
+   complex :: a(*)   ! { dg-error "Assumed size array at" }
+   real :: b(2)
+   b = a%im  ! { dg-error "upper bound in the last dimension" }
+end

Re: [PATCH], V4, patch #4.1: Enable prefixed/pc-rel addressing (revised)

[Segher Boessenkool]

Hi Mike,

On Mon, Sep 30, 2019 at 10:12:54AM -0400, Michael Meissner wrote:
> I needed
> to add a second memory constraint ('eM') that prevents using a prefixed
> address.

Do we need both em and eM?  Do we ever want to allow prefixed insns but not
pcrel?  Or, alternatively, this only uses eM for some insns where the "p"
prefix trick won't work (because there are multiple insns in the template);
we could solve that some other way (by inserting the p's manually for
example).

But what should inline asm users do wrt prefixed/pcrel memory?  Should
they not use prefixed memory at all?  That means for asm we should always
disallow prefixed for "m".

Having both em and eM names is a bit confusing (which is what?)  The eM
one should not be documented in the user manual, probably.

Maybe just using wY here will work just as well?  That is also not ideal
of course, but we already have that one anyway.

> 4) In the previous patch, I missed setting the prefixed size and non prefixed
> size for mov_ppc64 in the insn.  This pattern is used for moving PTImode
> in GPR registers (on non-VSX systems, it would move TImode also).  By the time
> it gets to final, it will have been split, but it is still useful to get the
> sizes correct before the mode is split.

So that is a separate patch?  Please send it as one, then?

> +  /* The LWA instruction uses the DS-form format where the bottom two bits of
> + the offset must be 0.  The prefixed PLWA does not have this
> + restriction.  */
> +  if (TARGET_PREFIXED_ADDR
> +  && address_is_prefixed (addr, DImode, NON_PREFIXED_DS))
> +return true;

Should TARGET_PREFIXED_ADDR be part of address_is_prefixed, instead of
part of all its callers?

> +;; Return 1 if op is a memory operand that is not prefixed.
> +(define_predicate "non_prefixed_memory"
> +  (match_code "mem")
> +{
> +  if (!memory_operand (op, mode))
> +return false;
> +
> +  enum insn_form iform
> += address_to_insn_form (XEXP (op, 0), mode, NON_PREFIXED_DEFAULT);
> +
> +  return (iform != INSN_FORM_PREFIXED_NUMERIC
> +  && iform != INSN_FORM_PCREL_LOCAL
> +  && iform != INSN_FORM_BAD);
> +})
> +
> +(define_predicate "non_pcrel_memory"
> +  (match_code "mem")
> +{
> +  if (!memory_operand (op, mode))
> +return false;
> +
> +  enum insn_form iform
> += address_to_insn_form (XEXP (op, 0), mode, NON_PREFIXED_DEFAULT);
> +
> +  return (iform != INSN_FORM_PCREL_EXTERNAL
> +  && iform != INSN_FORM_PCREL_LOCAL
> +  && iform != INSN_FORM_BAD);
> +})

Why does non_prefixed_memory not check INSN_FORM_PCREL_EXTERNAL?  Why does
non_prefixed_memory not use non_pcrel_memory, instead of open-coding it?

What is INSN_FORM_BAD about, in both functions?

> +;; Return 1 if op is either a register operand or a memory operand that does
> +;; not use a PC-relative address.
> +(define_predicate "reg_or_non_pcrel_memory"
> +  (match_code "reg,subreg,mem")
> +{
> +  if (REG_P (op) || SUBREG_P (op))
> +return register_operand (op, mode);
> +
> +  return non_pcrel_memory (op, mode);
> +})

Why do we need this predicate?  Should it use register_operand like this,
or should it use gpc_reg_operand?

> +  bool pcrel_p = TARGET_PCREL && pcrel_local_address (addr, Pmode);

Similar as above: should TARGET_PCREL be part of pcrel_local_address?

> @@ -6860,6 +6904,12 @@ rs6000_split_vec_extract_var (rtx dest,
>   systems.  */
>if (MEM_P (src))
>  {
> +  /* If this is a PC-relative address, we would need another register to
> +  hold the address of the vector along with the variable offset.  The
> +  callers should use reg_or_non_pcrel_memory to make sure we don't
> +  get a PC-relative address here.  */

I don't understand this comment, nor the problem.  Please expand?

> +  /* Allow prefixed instructions if supported.  If the bottom two bits of the
> + offset are non-zero, we could use a prefixed instruction (which does not
> + have the DS-form constraint that the traditional instruction had) 
> instead
> + of forcing the unaligned offset to a GPR.  */
> +  if (address_is_prefixed (addr, mode, NON_PREFIXED_DS))
> +return true;

Here (and for DQ) you aren't testing TARGET_PREFIXED?

> @@ -7371,7 +7435,7 @@ mem_operand_gpr (rtx op, machine_mode mo
> causes a wrap, so test only the low 16 bits.  */
>  offset = ((offset & 0x) ^ 0x8000) - 0x8000;
>  
> -  return offset + 0x8000 < 0x1u - extra;
> +  return SIGNED_16BIT_OFFSET_EXTRA_P (offset, extra);

This is a separate patch (and pre-approved).

> @@ -7404,7 +7475,7 @@ mem_operand_ds_form (rtx op, machine_mod
> causes a wrap, so test only the low 16 bits.  */
>  offset = ((offset & 0x) ^ 0x8000) - 0x8000;
>  
> -  return offset + 0x8000 < 0x1u - extra;
> +  return SIGNED_16BIT_OFFSET_EXTRA_P (offset, extra);

Together with this.

> -  offset += 0x8000;
> -  return offset < 0x1 - extra;
> +  if (TARGET_PREFIXED_ADDR)
> +return 

[PATCH] PR fortran/91784 -- Simplify EXPR_OP in conversion of constants

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.
OK to commmit?

In a previous patch, I specialized the simplfication of
an EXPR_OP to the case of an inserted parenthesis.  This
was too restrictive as evidenced by the new test case.
The patch simply does a simplification of an expression.
 
2019-10-01  Steven G. Kargl  

PR fortran/91784
* simplify.c (gfc_convert_constant): Simplify expression if the
expression type is EXPR_OP.

2019-10-01  Steven G. Kargl  

PR fortran/91784
* gfortran.dg/pr91784.f90: New test.

-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 276426)
+++ gcc/fortran/simplify.c	(working copy)
@@ -8508,10 +8508,10 @@ gfc_convert_constant (gfc_expr *e, bt type, int kind)
 	{
 	  if (c->expr->expr_type == EXPR_ARRAY)
 		tmp = gfc_convert_constant (c->expr, type, kind);
-	  else if (c->expr->expr_type == EXPR_OP
-		   && c->expr->value.op.op == INTRINSIC_PARENTHESES)
+	  else if (c->expr->expr_type == EXPR_OP)
 		{
-		  gfc_simplify_expr (c->expr, 1);
+		  if (!gfc_simplify_expr (c->expr, 1))
+		return _bad_expr;
 		  tmp = f (c->expr, kind);
 		}
 	  else
Index: gcc/testsuite/gfortran.dg/pr91784.f90
===
--- gcc/testsuite/gfortran.dg/pr91784.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91784.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do run }
+! PR fortran/91784
+! Code originally contributed by Gerhard Steinmetz
+program p
+   complex :: x(1)
+   x = (1.0, 2.0) * [real :: -(3.0 + 4.0)]
+   if (int(real(x(1))) /= -7) stop 1
+   if (int(aimag(x(1))) /= -14) stop 2
+end

Modifying types during optimization

[Gary Oblock]

I'm working on structure reorganization optimizations and one of the
things that needs to happen is that pointers to arrays of structures
need to be modified into either being an integer of a structure depending
on which optimization is required.

I'm seeing something similar happening in omp-low.c where the code in
install_var_field and fixup_child_record_type both seem to rebuild the
entire type from scratch if a field is either added or modified. Wouldn't
it be possible simply modify the field(s) in question and rerun layout_type?

I suspect the answer will be no but reasons as to why that wouldn't work
will probably be equally valuable to me.

Thanks,

Gary Oblock

[PATCH] PR fortran/91942 -- Inquiry parameter cannot be IO tag

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.
OK to commit?

If an inquiry parameter cannot appear in a file IO statement
as a tag (see new testcase).  The patch re-arranges the code
to prevent an ICE due to 'result->symtree = NULL;', checks
for a constant in a variable definition context, and takes
a different exit route to get better error messages.

2019-10-01  Steven G. Kargl  

PR fortran/91942
* io.c (match_vtag): Check for non-NULL result->symtree.
(match_out_tag): Check for invalid constant due to inquiry parameter.
(match_filepos): Instead of a syntax error, go to cleanup to get better
error messages.


2019-10-01  Steven G. Kargl  

PR fortran/91942
* gfortran.dg/pr91587.f90: Update dg-error regex.
* gfortran.dg/pr91942.f90: New test.
-- 
Steve
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c	(revision 276426)
+++ gcc/fortran/io.c	(working copy)
@@ -1482,25 +1482,30 @@ match_vtag (const io_tag *tag, gfc_expr **v)
   return MATCH_ERROR;
 }
 
-  if (result->symtree->n.sym->attr.intent == INTENT_IN)
+  if (result->symtree)
 {
-  gfc_error ("Variable %s cannot be INTENT(IN) at %C", tag->name);
-  gfc_free_expr (result);
-  return MATCH_ERROR;
-}
+  bool impure;
 
-  bool impure = gfc_impure_variable (result->symtree->n.sym);
-  if (impure && gfc_pure (NULL))
-{
-  gfc_error ("Variable %s cannot be assigned in PURE procedure at %C",
-		 tag->name);
-  gfc_free_expr (result);
-  return MATCH_ERROR;
-}
+  if (result->symtree->n.sym->attr.intent == INTENT_IN)
+	{
+	  gfc_error ("Variable %s cannot be INTENT(IN) at %C", tag->name);
+	  gfc_free_expr (result);
+	  return MATCH_ERROR;
+	}
 
-  if (impure)
-gfc_unset_implicit_pure (NULL);
+  impure = gfc_impure_variable (result->symtree->n.sym);
+  if (impure && gfc_pure (NULL))
+	{
+	  gfc_error ("Variable %s cannot be assigned in PURE procedure at %C",
+		 tag->name);
+	  gfc_free_expr (result);
+	  return MATCH_ERROR;
+	}
 
+  if (impure)
+	gfc_unset_implicit_pure (NULL);
+}
+
   *v = result;
   return MATCH_YES;
 }
@@ -1515,8 +1520,17 @@ match_out_tag (const io_tag *tag, gfc_expr **result)
 
   m = match_vtag (tag, result);
   if (m == MATCH_YES)
-gfc_check_do_variable ((*result)->symtree);
+{
+  if ((*result)->symtree)
+	gfc_check_do_variable ((*result)->symtree);
 
+  if ((*result)->expr_type == EXPR_CONSTANT)
+	{
+	  gfc_error ("Expecting a variable at %L", &(*result)->where);
+	  return MATCH_ERROR;
+	}
+}
+
   return m;
 }
 
@@ -2845,7 +2859,7 @@ match_filepos (gfc_statement st, gfc_exec_op op)
 
   m = match_file_element (fp);
   if (m == MATCH_ERROR)
-goto syntax;
+goto cleanup;
   if (m == MATCH_NO)
 {
   m = gfc_match_expr (>unit);
Index: gcc/testsuite/gfortran.dg/pr91587.f90
===
--- gcc/testsuite/gfortran.dg/pr91587.f90	(revision 276426)
+++ gcc/testsuite/gfortran.dg/pr91587.f90	(working copy)
@@ -2,9 +2,9 @@
 ! PR fortran/91587
 ! Code contributed by Gerhard Steinmetz
 program p
-   backspace(err=!)  ! { dg-error "Syntax error in" }
-   flush(err=!)  ! { dg-error "Syntax error in" }
-   rewind(err=!) ! { dg-error "Syntax error in" }
+   backspace(err=!)  ! { dg-error "Invalid value for" }
+   flush(err=!)  ! { dg-error "Invalid value for" }
+   rewind(err=!) ! { dg-error "Invalid value for" }
 end
 
 subroutine bar   ! An other matcher runs, and gives a different error.
Index: gcc/testsuite/gfortran.dg/pr91942.f90
===
--- gcc/testsuite/gfortran.dg/pr91942.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91942.f90	(working copy)
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! PR fortran/91942
+! Code contributed by Gerhard Steinmetz
+program p
+   integer :: i
+   backspace (iostat=i%kind) ! { dg-error "Expecting a variable at" }
+   endfile (iostat=i%kind) ! { dg-error "Expecting END PROGRAM" }
+   flush (iostat=i%kind) ! { dg-error "Expecting a variable at" }
+   rewind (iostat=i%kind) ! { dg-error "Expecting a variable at" }
+end

[Bug c++/69531] Implement CWG 1307; Differently bounded array parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
 Blocks||91364
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
Will be fixed as part of P0388R4.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91364
[Bug 91364] Implement P0388R4: Permit conversions to arrays of unknown bound

Re: [LRA] Don't make eliminable registers live (PR91957)

[Jeff Law]

On 10/1/19 4:39 PM, Richard Sandiford wrote:
> One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html
> was to strengthen the sanity check in lra_assigns so that it checks
> whether reg_renumber is consistent with the whole conflict set.
> This duly tripped on csky for a pseudo that had been allocated
> to the eliminated frame pointer.  (csky doesn't have a separate
> hard frame pointer.)
> 
> lra-lives uses:
> 
> /* Set of hard regs (except eliminable ones) currently live.  */
> static HARD_REG_SET hard_regs_live;
> 
> to track the set of live directly-referenced hard registers, and it
> correctly implements the exclusion when setting up the initial set:
> 
>   hard_regs_live &= ~eliminable_regset;
> 
> But later calls to make_hard_regno_live and make_hard_regno_dead
> would process eliminable registers like other registers, recording
> conflicts for them and potentially making them live.  (Note that
> after r266086, make_hard_regno_dead adds conflicts for registers
> that are already marked dead.)  I think this would have had the
> effect of pessimising targets without a separate hard frame pointer.
> 
> Tested on aarch64-linux-gnu (where it probably doesn't do much)
> and against the testcase on csky-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2019-10-01  Richard Sandiford  
> 
> gcc/
>   PR middle-end/91957
>   * lra-lives.c (make_hard_regno_dead): Don't record conflicts for
>   eliminable registers.
>   (make_hard_regno_live): Likewise, and don't make them live.
OK
jeff

[LRA] Don't make eliminable registers live (PR91957)

[Richard Sandiford]

One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html
was to strengthen the sanity check in lra_assigns so that it checks
whether reg_renumber is consistent with the whole conflict set.
This duly tripped on csky for a pseudo that had been allocated
to the eliminated frame pointer.  (csky doesn't have a separate
hard frame pointer.)

lra-lives uses:

/* Set of hard regs (except eliminable ones) currently live.  */
static HARD_REG_SET hard_regs_live;

to track the set of live directly-referenced hard registers, and it
correctly implements the exclusion when setting up the initial set:

  hard_regs_live &= ~eliminable_regset;

But later calls to make_hard_regno_live and make_hard_regno_dead
would process eliminable registers like other registers, recording
conflicts for them and potentially making them live.  (Note that
after r266086, make_hard_regno_dead adds conflicts for registers
that are already marked dead.)  I think this would have had the
effect of pessimising targets without a separate hard frame pointer.

Tested on aarch64-linux-gnu (where it probably doesn't do much)
and against the testcase on csky-linux-gnu.  OK to install?

Richard


2019-10-01  Richard Sandiford  

gcc/
PR middle-end/91957
* lra-lives.c (make_hard_regno_dead): Don't record conflicts for
eliminable registers.
(make_hard_regno_live): Likewise, and don't make them live.

Index: gcc/lra-lives.c
===
--- gcc/lra-lives.c 2019-10-01 09:55:35.146088630 +0100
+++ gcc/lra-lives.c 2019-10-01 23:36:02.545946185 +0100
@@ -281,7 +281,8 @@ update_pseudo_point (int regno, int poin
 make_hard_regno_live (int regno)
 {
   lra_assert (HARD_REGISTER_NUM_P (regno));
-  if (TEST_HARD_REG_BIT (hard_regs_live, regno))
+  if (TEST_HARD_REG_BIT (hard_regs_live, regno)
+  || TEST_HARD_REG_BIT (eliminable_regset, regno))
 return;
   SET_HARD_REG_BIT (hard_regs_live, regno);
   sparseset_set_bit (start_living, regno);
@@ -295,6 +296,9 @@ make_hard_regno_live (int regno)
 static void
 make_hard_regno_dead (int regno)
 {
+  if (TEST_HARD_REG_BIT (eliminable_regset, regno))
+return;
+
   lra_assert (HARD_REGISTER_NUM_P (regno));
   unsigned int i;
   EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i)

Re: [PATCH] Fix PR fortran/91716

[Steve Kargl]

On Tue, Oct 01, 2019 at 07:58:37PM +, Bernd Edlinger wrote:
> On 9/13/19 12:16 PM, Janne Blomqvist wrote:
> > On Fri, Sep 13, 2019 at 1:07 PM Bernd Edlinger
> >  wrote:
> >>
> >> Hi,
> >>
> >> this fixes a test case where a short string constant is put in a larger 
> >> memory object.
> >>
> >> The consistency check in varasm.c is failed because both types should 
> >> agree.
> >>
> >> Since the failed assertion is just a gcc_checking_assert I think a 
> >> back-port of this fix
> >> to the gcc-9 branch will not be necessary.
> >>
> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> >> Is it OK for trunk?
> >>
> >> Thanks
> >> Bernd.
> > 
> > Ok.
> > 
> 
> Well, I have mistakenly assumed that this triggers only a "checking" assert,
> but it turned out that is not the case, as written in last comment in the BZ,
> immediately after that gcc_checking_assert, there is a gcc_assert, and also
> an ICE in the gcc-9 branch.  The same patch fixes also the second problem,
> and survives reg-bootstrap and testing on x86_64-pc-linux-gnu as expected.
> 
> 
> So I would like to ask at this time, if it is also OK for gcc-9 ?
> 
> 

If you're backporting a patch from trunk to 9-branch, then
I think it is ok to commit.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

[RFC][Fortran,patch] %C error diagnostic location

[Tobias Burnus]

Hi all,

my feeling is that %C locations are always off by one, e.g., showing the 
(1) under the last white-space character before the place where the 
error occurred – the match starts at the character after the 
gfc_current_location.


That bothered my for a while – but today, I was wondering whether one 
shouldn't simply bump the %C location by one – such that it shows at the 
first wrong character and not at the last okay character.


What do you think?


Another observation (unfixed): If gfortran buffers the error, the %C 
does not seem to get resolved at gfc_{error,warning} time but at the 
time when the buffer is flushed – which will have a reset error location.


Cheers,

Tobias


	* error (error_print, gfc_format_decoder): Fix off-by one issue with %C.

diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index a0ce7a6b190..815cae9d7e7 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -618,12 +618,18 @@ error_print (const char *type, const char *format0, va_list argp)
 	  {
 		l2 = loc;
 		arg[pos].u.stringval = "(2)";
+		/* Point %C first offending character not the last good one. */
+		if (arg[pos].type == TYPE_CURRENTLOC)
+		  l2->nextc++;
 	  }
 	else
 	  {
 		l1 = loc;
 		have_l1 = 1;
 		arg[pos].u.stringval = "(1)";
+		/* Point %C first offending character not the last good one. */
+		if (arg[pos].type == TYPE_CURRENTLOC)
+		  l1->nextc++;
 	  }
 	break;
 
@@ -963,6 +969,9 @@ gfc_format_decoder (pretty_printer *pp, text_info *text, const char *spec,
 	  loc = va_arg (*text->args_ptr, locus *);
 	gcc_assert (loc->nextc - loc->lb->line >= 0);
 	unsigned int offset = loc->nextc - loc->lb->line;
+	if (*spec == 'C')
+	  /* Point %C first offending character not the last good one. */
+	  offset++;
 	/* If location[0] != UNKNOWN_LOCATION means that we already
 	   processed one of %C/%L.  */
 	int loc_num = text->get_location (0) == UNKNOWN_LOCATION ? 0 : 1;
@@ -1400,7 +1409,7 @@ gfc_internal_error (const char *gmsgid, ...)
 void
 gfc_clear_error (void)
 {
-  error_buffer.flag = 0;
+  error_buffer.flag = false;
   warnings_not_errors = false;
   gfc_clear_pp_buffer (pp_error_buffer);
 }

[committed] Support prefixes in diagnostic_show_locus

[David Malcolm]

Previously, diagnostic_show_locus saved and restored the pretty_printer's
prefix, clearing it for the duration of the call.

I have a patch kit in development that can benefit from applying a prefix
to the output of d_s_l, so this patch adds support to d_s_l for printing
such prefixes.

It moves the save and restore of the pp's prefix from d_s_l to all of its
callers, and updates diagnostic-show-locus.c to properly handle prefixes.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as r276433.

gcc/c-family/ChangeLog:
* c-opts.c (c_diagnostic_finalizer): Temporarily clear prefix when
calling diagnostic_show_locus, rather than destroying it afterwards.

gcc/ChangeLog:
* diagnostic-show-locus.c (layout::print_gap_in_line_numbering):
Call pp_emit_prefix.
(layout::print_source_line): Likewise.
(layout::start_annotation_line): Likewise.
(diagnostic_show_locus): Remove call to temporarily clear the
prefix.
(selftest::test_one_liner_fixit_remove): Add test coverage for the
interaction of pp_set_prefix with rulers and fix-it hints.
* diagnostic.c (default_diagnostic_finalizer): Temporarily clear
prefix when calling diagnostic_show_locus, rather than destroying
it afterwards.
(print_parseable_fixits): Temporarily clear prefix.
* pretty-print.c (pp_format): Save and restore line_length, rather
than assuming it is zero.
(pp_output_formatted_text): Remove assertion that line_length is
zero.

gcc/fortran/ChangeLog:
* error.c (gfc_diagnostic_starter): Clear the prefix before
calling diagnostic_show_locus.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic_group_plugin.c (test_begin_group_cb):
Clear the prefix before emitting the "END GROUP" line.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
(custom_diagnostic_finalizer): Temporarily clear prefix when
calling diagnostic_show_locus, rather than destroying it
afterwards.
---
 gcc/c-family/c-opts.c  |  4 +-
 gcc/diagnostic-show-locus.c| 96 +++---
 gcc/diagnostic.c   |  9 +-
 gcc/fortran/error.c|  1 +
 gcc/pretty-print.c |  4 +-
 .../gcc.dg/plugin/diagnostic_group_plugin.c|  1 +
 .../plugin/diagnostic_plugin_test_show_locus.c |  5 +-
 7 files changed, 101 insertions(+), 19 deletions(-)

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 23ab4cf..949d96a 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -168,11 +168,13 @@ c_diagnostic_finalizer (diagnostic_context *context,
diagnostic_info *diagnostic,
diagnostic_t)
 {
+  char *saved_prefix = pp_take_prefix (context->printer);
+  pp_set_prefix (context->printer, NULL);
   diagnostic_show_locus (context, diagnostic->richloc, diagnostic->kind);
   /* By default print macro expansion contexts in the diagnostic
  finalizer -- for tokens resulting from macro expansion.  */
   virt_loc_aware_diagnostic_finalizer (context, diagnostic);
-  pp_destroy_prefix (context->printer);
+  pp_set_prefix (context->printer, saved_prefix);
   pp_flush (context->printer);
 }
 
diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index 42146c5..0cce82f 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -1039,6 +1039,8 @@ layout::print_gap_in_line_numbering ()
 {
   gcc_assert (m_show_line_numbers_p);
 
+  pp_emit_prefix (m_pp);
+
   for (int i = 0; i < m_linenum_width + 1; i++)
 pp_character (m_pp, '.');
 
@@ -1266,6 +1268,8 @@ layout::print_source_line (linenum_type row, const char 
*line, int line_width,
   line_width);
   line += m_x_offset;
 
+  pp_emit_prefix (m_pp);
+
   if (m_show_line_numbers_p)
 {
   int width = num_digits (row);
@@ -1346,6 +1350,7 @@ layout::should_print_annotation_line_p (linenum_type row) 
const
 void
 layout::start_annotation_line (char margin_char) const
 {
+  pp_emit_prefix (m_pp);
   if (m_show_line_numbers_p)
 {
   /* Print the margin.  If MARGIN_CHAR != ' ', then print up to 3
@@ -2297,9 +2302,6 @@ diagnostic_show_locus (diagnostic_context * context,
 
   context->last_location = loc;
 
-  char *saved_prefix = pp_take_prefix (context->printer);
-  pp_set_prefix (context->printer, NULL);
-
   layout layout (context, richloc, diagnostic_kind);
   for (int line_span_idx = 0; line_span_idx < layout.get_num_line_spans ();
line_span_idx++)
@@ -2329,8 +2331,6 @@ diagnostic_show_locus (diagnostic_context * context,
   row <= last_line; row++)
layout.print_line (row);
 }
-
-  pp_set_prefix (context->printer, saved_prefix);
 }
 
 #if CHECKING_P
@@ -2463,23 +2463,93 @@ 

Re: [C++ PATCH] PR c++/91369 - Implement P0784R7: constexpr new

[Jason Merrill]

On 9/27/19 4:31 PM, Jakub Jelinek wrote:

Hi!

The following patch attempts to implement P0784R7, which includes constexpr
destructors and constexpr new/delete/new[]/delete[].

::operator new is allowed during constexpr evaluation and returns address of
an artificial VAR_DECL with special name.  At this point we don't really
know the type of the heap storage, just size.  Later on when we encounter
cast to the corresponding pointer type, we change the name of the var and
type to match the type from the new expression (for new[] we need to do
further stuff as at the point where build_new_1 is called, we might not know
the exact array size, but we shall know that during the constexpr
evaluation, and cookie handling also complicates it a little bit).
When we first store into such heap objects, a ctor is created for them on
the fly.  Finally, ::operator delete marks those heap VAR_DECLs as deleted
and cxx_eval_outermost_constant_expr checks if everything that has been
allocated has been also deallocated and verifies addresses of those heap
vars aren't leaking into the return value.

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

2019-09-27  Jakub Jelinek  

PR c++/91369 - Implement P0784R7: constexpr new
c-family/
* c-cppbuiltin.c (c_cpp_builtins): Predefine
__cpp_constexpr_dynamic_alloc=201907 for -std=c++2a.
cp/
* cp-tree.h (enum cp_tree_index): Add CPTI_HEAP_UNINIT_IDENTIFIER,
CPTI_HEAP_IDENTIFIER and CPTI_HEAP_DELETED_IDENTIFIER.
(heap_uninit_identifier, heap_identifier, heap_deleted_identifier):
Define.
(type_has_constexpr_destructor, cxx_constant_dtor): Declare.
* class.c (type_maybe_constexpr_default_constructor): Make static.
(type_maybe_constexpr_destructor, type_has_constexpr_destructor): New
functions.
(finalize_literal_type_property): For c++2a, don't clear
CLASSTYPE_LITERAL_P for types without trivial destructors unless they
have non-constexpr destructors.
(explain_non_literal_class): For c++2a, complain about non-constexpr
destructors rather than about non-trivial destructors.
* constexpr.c: Include stor-layout.h.
(struct constexpr_ctx): Add heap_vars field.
(cxx_eval_call_expression): For c++2a allow calls to replaceable
global allocation functions, for new return address of a heap uninit
var, for delete record its deletion.
(initialized_type): Handle destructors for c++2a.
(cxx_fold_indirect_ref): Also handle array fields in structures.
(non_const_var_error): Add auto_diagnostic_group sentinel.  Emit
special diagnostics for heap variables.
(cxx_eval_store_expression): Create ctor for heap variables on the
first write.  Formatting fix.  Handle const_object_being_modified
with array type.
(cxx_eval_loop_expr): Initialize jump_target if NULL.
(cxx_eval_constant_expression) : If not skipping
upon entry to body, run cleanup with the same *jump_target as it
started to run the cleanup even if the body returns, breaks or
continues.
: Formatting fix.  On cast of replaceable global
allocation function to some pointer type, adjust the type of
the heap variable and change name from heap_uninit_identifier
to heap_identifier.
(find_heap_var_refs): New function.
(cxx_eval_outermost_constant_expr): Add constexpr_dtor argument,
handle evaluation of constexpr dtors and add tracking of heap
variables.  Use tf_no_cleanup for get_target_expr_with_sfinae.
(cxx_constant_value): Adjust cxx_eval_outermost_constant_expr caller.
(cxx_constant_dtor): New function.
(maybe_constant_value, fold_non_dependent_expr_template,
maybe_constant_init_1): Adjust cxx_eval_outermost_constant_expr
callers.
(potential_constant_expression_1): Ignore clobbers.  Allow
COND_EXPR_IS_VEC_DELETE for c++2a.  Allow CLEANUP_STMT.
* decl.c (initialize_predefined_identifiers): Add heap identifiers.
(cp_finish_decl): Don't clear TREE_READONLY for constexpr variables
with non-trivial, but constexpr destructors.
(register_dtor_fn): For constexpr variables with constexpr non-trivial
destructors call cxx_constant_dtor instead of adding destructor calls
at runtime.
(expand_static_init): For constexpr variables with constexpr
non-trivial destructors call cxx_maybe_build_cleanup.
(grokdeclarator): Allow constexpr destructors for c++2a.  Formatting
fix.
(cxx_maybe_build_cleanup): For constexpr variables with constexpr
non-trivial destructors call cxx_constant_dtor instead of adding
destructor calls at runtime.
* init.c: Include stor-layout.h.
(build_new_1): For c++2a and new[], add cast around the alloc call
to help constexpr 

Re: [SVE] PR91532

[Prathamesh Kulkarni]

On Wed, 2 Oct 2019 at 01:08, Jeff Law  wrote:
>
> On 10/1/19 12:40 AM, Richard Biener wrote:
> > On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
> >
> >> On Wed, 25 Sep 2019 at 23:44, Richard Biener  wrote:
> >>>
> >>> On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
> >>>
>  On Fri, 20 Sep 2019 at 15:20, Jeff Law  wrote:
> >
> > On 9/19/19 10:19 AM, Prathamesh Kulkarni wrote:
> >> Hi,
> >> For PR91532, the dead store is trivially deleted if we place dse pass
> >> between ifcvt and vect. Would it be OK to add another instance of dse 
> >> there ?
> >> Or should we add an ad-hoc "basic-block dse" sub-pass to ifcvt that
> >> will clean up the dead store ?
> > I'd hesitate to add another DSE pass.  If there's one nearby could we
> > move the existing pass?
>  Well I think the nearest one is just after pass_warn_restrict. Not
>  sure if it's a good
>  idea to move it up from there ?
> >>>
> >>> You'll need it inbetween ifcvt and vect so it would be disabled
> >>> w/o vectorization, so no, that doesn't work.
> >>>
> >>> ifcvt already invokes SEME region value-numbering so if we had
> >>> MESE region DSE it could use that.  Not sure if you feel like
> >>> refactoring DSE to work on regions - it currently uses a DOM
> >>> walk which isn't suited for that.
> >>>
> >>> if-conversion has a little "local" dead predicate compute removal
> >>> thingy (not that I like that), eventually it can be enhanced to
> >>> do the DSE you want?  Eventually it should be moved after the local
> >>> CSE invocation though.
> >> Hi,
> >> Thanks for the suggestions.
> >> For now, would it be OK to do "dse" on loop header in
> >> tree_if_conversion, as in the attached patch ?
> >> The patch does local dse in a new function ifcvt_local_dse instead of
> >> ifcvt_local_dce, because it needed to be done after RPO VN which
> >> eliminates:
> >> Removing dead stmt _ifc__62 = *_55;
> >> and makes the following store dead:
> >> *_55 = _ifc__61;
> >
> > I suggested trying to move ifcvt_local_dce after RPO VN, you could
> > try that as independent patch (pre-approved).
> >
> > I don't mind the extra walk though.
> >
> > What I see as possible issue is that dse_classify_store walks virtual
> > uses and I'm not sure if the loop exit is a natural boundary for
> > such walk (eventually the loop header virtual PHI is reached but
> > there may also be a loop-closed PHI for the virtual operand,
> > but not necessarily).  So the question is whether to add a
> > "stop at" argument to dse_classify_store specifying the virtual
> > use the walk should stop at?
> I think we want to stop at the block boundary -- aren't the cases we
> care about here local to a block?
This version restricts walking in dse_classify_store to basic-block if
bb_only is true,
and removes dead stores in ifcvt_local_dce instead of separate walk.
Does it look OK ?

Thanks,
Prathamesh
>
> jeff
diff --git a/gcc/tree-if-conv.c b/gcc/tree-if-conv.c
index 822aae5b83f..11df055ccf4 100644
--- a/gcc/tree-if-conv.c
+++ b/gcc/tree-if-conv.c
@@ -120,6 +120,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "fold-const.h"
 #include "tree-ssa-sccvn.h"
 #include "tree-cfgcleanup.h"
+#include "tree-ssa-dse.h"
 
 /* Only handle PHIs with no more arguments unless we are asked to by
simd pragma.  */
@@ -2960,6 +2961,18 @@ ifcvt_local_dce (basic_block bb)
   while (!gsi_end_p (gsi))
 {
   stmt = gsi_stmt (gsi);
+  if (gimple_store_p (stmt))
+{
+  tree lhs = gimple_get_lhs (stmt);
+  ao_ref write;
+  ao_ref_init (, lhs);
+  if (dse_classify_store (, stmt, false, NULL, NULL, true)
+  == DSE_STORE_DEAD)
+delete_dead_or_redundant_assignment (, "dead");
+	  gsi_next ();
+	  continue;
+	}
+
   if (gimple_plf (stmt, GF_PLF_2))
 	{
 	  gsi_next ();
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index ba67884a825..7148654b7d9 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "alias.h"
 #include "tree-ssa-loop.h"
+#include "tree-ssa-dse.h"
 
 /* This file implements dead store elimination.
 
@@ -76,21 +77,13 @@ along with GCC; see the file COPYING3.  If not see
fact, they are the same transformation applied to different views of
the CFG.  */
 
-static void delete_dead_or_redundant_assignment (gimple_stmt_iterator *, const char *);
+void delete_dead_or_redundant_assignment (gimple_stmt_iterator *, const char *);
 static void delete_dead_or_redundant_call (gimple_stmt_iterator *, const char *);
 
 /* Bitmap of blocks that have had EH statements cleaned.  We should
remove their dead edges eventually.  */
 static bitmap need_eh_cleanup;
 
-/* Return value from dse_classify_store */
-enum dse_store_status
-{
-  DSE_STORE_LIVE,
-  DSE_STORE_MAYBE_PARTIAL_DEAD,
-  DSE_STORE_DEAD
-};
-
 /* STMT is a statement that may write into memory.  Analyze it 

Re: [PATCH] Use movmem optab to attempt inline expansion of __builtin_memmove()

[Jeff Law]

On 9/27/19 12:23 PM, Aaron Sawdey wrote:
> This is the third piece of my effort to improve inline expansion of memmove. 
> The
> first two parts I posted back in June fixed the names of the optab entries
> involved so that optab cpymem is used for memcpy() and optab movmem is used 
> for
> memmove(). This piece adds support for actually attempting to invoke the 
> movmem
> optab to do inline expansion of __builtin_memmove().
> 
> Because what needs to be done for memmove() is very similar to memcpy(), I 
> have
> just added a bool parm "might_overlap" to several of the functions involved so
> the same functions can handle both. The name might_overlap comes from the fact
> that if we still have a memmove() call at expand, this means
> gimple_fold_builtin_memory_op() was not able to prove that the source and
> destination do not overlap.
> 
> There are a few places where might_overlap gets used to keep us from trying to
> use the by-pieces infrastructure or generate a copy loop, as neither of those
> things will work correctly if source and destination overlap.
> 
> I've restructured things slightly in emit_block_move_hints() so that we can
> try the pattern first if we already know that by-pieces won't work. This way
> we can bail out immediately in the might_overlap case.
> 
> Bootstrap/regtest passed on ppc64le, in progress on x86_64. If everything 
> passes,
> is this ok for trunk?
> 
> 
> 2019-09-27  Aaron Sawdey 
> 
>   * builtins.c (expand_builtin_memory_copy_args): Add might_overlap parm.
>   (expand_builtin_memcpy): Use might_overlap parm.
>   (expand_builtin_mempcpy_args): Use might_overlap parm.
>   (expand_builtin_memmove): Call expand_builtin_memory_copy_args.
>   (expand_builtin_memory_copy_args): Add might_overlap parm.
>   * expr.c (emit_block_move_via_cpymem): Rename to
>   emit_block_move_via_pattern, add might_overlap parm, use cpymem
>   or movmem optab as appropriate.
>   (emit_block_move_hints): Add might_overlap parm, do the right
>   thing for might_overlap==true.
>   * expr.h (emit_block_move_hints): Update prototype.
> 
> 
> 
> 
> Index: gcc/builtins.c
> ===
> --- gcc/builtins.c(revision 276131)
> +++ gcc/builtins.c(working copy)
> @@ -3894,10 +3897,11 @@
>   _max_size);
>src_str = c_getstr (src);
> 
> -  /* If SRC is a string constant and block move would be done
> - by pieces, we can avoid loading the string from memory
> - and only stored the computed constants.  */
> -  if (src_str
> +  /* If SRC is a string constant and block move would be done by
> + pieces, we can avoid loading the string from memory and only
> + stored the computed constants.  I'm not sure if the by pieces
> + method works if src/dest are overlapping, so avoid that case.  */
> +  if (src_str && !might_overlap
I don't think you need the check here.  c_getstr, when it returns
somethign useful is going to be returning a string constant.  Think read
only literals here.  I'm pretty sure overlap isn't going to be possible.

>&& CONST_INT_P (len_rtx)
>&& (unsigned HOST_WIDE_INT) INTVAL (len_rtx) <= strlen (src_str) + 1
>&& can_store_by_pieces (INTVAL (len_rtx), builtin_memcpy_read_str,
> @@ -3922,7 +3926,7 @@
>&& (retmode == RETURN_BEGIN || target == const0_rtx))
>  method = BLOCK_OP_TAILCALL;
>bool use_mempcpy_call = (targetm.libc_has_fast_function (BUILT_IN_MEMPCPY)
> -&& retmode == RETURN_END
> +&& retmode == RETURN_END && !might_overlap
Put the && !might_overlap on its own line for readability.


> Index: gcc/expr.c
> ===
> --- gcc/expr.c(revision 276131)
> +++ gcc/expr.c(working copy)
> @@ -1622,13 +1624,29 @@
>set_mem_size (y, const_size);
>  }
> 
> -  if (CONST_INT_P (size) && can_move_by_pieces (INTVAL (size), align))
> +  bool pieces_ok = can_move_by_pieces (INTVAL (size), align);
> +  bool pattern_ok = false;
> +
> +  if (!CONST_INT_P (size) || !pieces_ok || might_overlap)
> +{
> +  pattern_ok =
> + emit_block_move_via_pattern (x, y, size, align,
> +  expected_align, expected_size,
> +  min_size, max_size, probable_max_size,
> +  might_overlap);
> +  if (!pattern_ok && might_overlap)
> + {
> +   /* Do not try any of the other methods below as they are not safe
> +  for overlapping moves.  */
> +   *is_move_done = false;
> +   return retval;
> + }
> +}
> +
> +  if (pattern_ok) ;
Drop the semi-colon down to its own line like

if (whatever)
  ;
else if (...)
  something
else if (...)
  something else

With the changes noted above, this is fine for th trunk.

jeff

[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6

[ebotcazou at gcc dot gnu.org]

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

--- Comment #22 from Eric Botcazou  ---
> Funny how the fix for the gcc-8.3.0 branch was a backport of this patch!

Nothing funny though, just an analysis of the behavior of the GCC 8 compiler
with a testcase that triggers a failure; the original testcase linked to here
didn't.
We cannot make changes on a release branch without a testcase, that's the rule.

> Have some manners next time.

Lecturing people doesn't make you right...

Re: [PATCH] Do not check call type compatibility when cloning cgraph edges

[Jeff Law]

On 9/30/19 3:30 AM, Martin Jambor wrote:
> Hi,
> 
> when looking into PR 70929 and thus looking at what
> gimple_check_call_matching_types and gimple_check_call_args (both in
> cgraph.c) do, I noticed that they get invoked a lot when cloning cgraph
> edges when code is being copied as part of inlining transformation, only
> to have their result overwritten by the value from the original edge.
> (They also fail a lot during that time because since call redirection has
> not taken place yet, the arguments are actually expected not to match.)
> 
> The following patch avoids that by adding a simple parameter to various
> create_edge methods which indicate that we are cloning and the call
> statement should therefore not be examined.  For consistency reasons I
> unfortunately also had to change the meaning of the last parameter of
> create_indirect_edge but there is only one place where it is called with
> value of the parameter specified and its intent has always been to
> behave differently when cloning.
> 
> Bootstrapped and tested on x86_64-linux.  OK for trunk?
> 
> Thanks,
> 
> Martin
> 
> 
> 
> 2019-09-27  Martin Jambor  
> 
>   * cgraph.c (symbol_table::create_edge): New parameter cloning_p,
>   do not compute some stuff when set.
>   (cgraph_node::create_edge): Likewise.
>   (cgraph_node::create_indirect_edge): Renamed last parameter to
>   coning_p and flipped its meaning, don't even calculate
>   inline_failed when set.
>   * cgraph.h (cgraph_node::create_edge): Add new parameter.
>   (symbol_tablecreate_edge): Likewise.
>   (cgraph_node::create_indirect_edge): Rename last parameter, flip
>   the default value.
>   * cgraphclones.c (cgraph_edge::clone): Pass true cloning_p to all
>   call graph edge creating functions.
OK
jeff
> ---

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
r276251

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-01
 CC||mpolacek at gcc dot gnu.org
Summary|ice in build_target_expr,   |[10 Regression] ice in
   |at cp/tree.c:488|build_target_expr, at
   ||cp/tree.c:488
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c/91961] __has_attribute expands macro argument

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
There's bug 80005 for expansion of __has_include arguments.

[Bug c/91961] __has_attribute expands macro argument

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I thought I had saw this before but I can't seem to find it right now.

[Bug c++/91962] New: ice in build_target_expr, at cp/tree.c:488

[dcb314 at hotmail dot com]

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

Bug ID: 91962
   Summary: ice in build_target_expr, at cp/tree.c:488
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ source code:

template  class b {
public:
  void c(const a &);
};
class B {
  void d();
  b e;
};
long f;
void B::d() { e.c((int *)f); }

on recent gcc trunk, produces this:

/home/dcb/creduce/dcbTest/bug542.cc: In member function ‘void B::d()’:
/home/dcb/creduce/dcbTest/bug542.cc:10:27: internal compiler error: in
build_target_expr, at cp/tree.c:488
   10 | void B::d() { e.c((int *)f); }
  |   ^
0x6700c2 build_target_expr
../../trunk/gcc/cp/tree.c:488
0x8ce7b3 convert_like_real
../../trunk/gcc/cp/call.c:7467
0x8d37f1 build_over_call
../../trunk/gcc/cp/call.c:8401
0x8cc2c7 build_new_method_call_1
../../trunk/gcc/cp/call.c:9887

The problem first seems to occur sometime between revision
276250 and 276350.

[Bug middle-end/91957] [10 Regression] ICE in lra_assign building libgcc for csky-linux-gnuabiv2 soft-float

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-01
  Component|target  |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Tested a patch.  Like Andrew says, it seems to be a latent bug
exposed by the stronger assert.

[PATCH] Make some new algorithms work in parallel mode

[Jonathan Wakely]

Tested x86_64-linux (normal and parallel modes), committed to trunk.

commit 92d5df45f3e62d31bebcdea9c1568b0877d0fe0e
Author: Jonathan Wakely 
Date:   Tue Oct 1 20:34:22 2019 +0100

Make some new algorithms work in parallel mode

* include/experimental/algorithm (experimental::sample): Qualify call
to __sample correctly.
* include/parallel/algo.h (sample, for_each_n): Add using-declarations
for algorithms that don't have parallel implementations.

diff --git a/libstdc++-v3/include/experimental/algorithm b/libstdc++-v3/include/experimental/algorithm
index 8ba212c5132..f036a713ef3 100644
--- a/libstdc++-v3/include/experimental/algorithm
+++ b/libstdc++-v3/include/experimental/algorithm
@@ -77,9 +77,9 @@ inline namespace fundamentals_v2
 		"sample size must be an integer type");
 
   typename iterator_traits<_PopulationIterator>::difference_type __d = __n;
-  return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
-			   __d,
-			   std::forward<_UniformRandomNumberGenerator>(__g));
+  return _GLIBCXX_STD_A::
+	__sample(__first, __last, __pop_cat{}, __out, __samp_cat{}, __d,
+		 std::forward<_UniformRandomNumberGenerator>(__g));
 }
 
   template= 201703L
+  using _GLIBCXX_STD_A::for_each_n;
+  using _GLIBCXX_STD_A::sample;
+#endif
 } // end namespace
 } // end namespace
 

[PATCH] Make some parallel mode algorithms usable in constexpr contexts

[Jonathan Wakely]

Tested x86_64-linux (normal and parallel modes), committed to trunk.

Most algos still aren't constexpr in parallel mode, this just fixes
the ones needed by std::array.


commit 9b07c6cfd553566a3ebdbab72b12e007d4912bf1
Author: Jonathan Wakely 
Date:   Tue Oct 1 20:33:08 2019 +0100

Make some parallel mode algorithms usable in constexpr contexts

This makes the __parallel::equal and __parallel:lexicographical_compare
algorithms usable in constant expressions, by dispatching to the
sequential algorithm when calling during constant evaluation.

* include/parallel/algobase.h (equal, lexicographical_compare): Add
_GLIBCXX20_CONSTEXPR and dispatch to sequential algorithm when being
constant evaluated.
* include/parallel/algorithmfwd.h (equal, lexicographical_compare):
Add _GLIBCXX20_CONSTEXPR.

diff --git a/libstdc++-v3/include/parallel/algobase.h b/libstdc++-v3/include/parallel/algobase.h
index 829eb11306b..d78bdc961a1 100644
--- a/libstdc++-v3/include/parallel/algobase.h
+++ b/libstdc++-v3/include/parallel/algobase.h
@@ -214,19 +214,31 @@ namespace __parallel
 
   // Public interface
   template
+_GLIBCXX20_CONSTEXPR
 inline bool
 equal(_IIter1 __begin1, _IIter1 __end1, _IIter2 __begin2)
 {
+#if __cplusplus > 201703L
+  if (std::is_constant_evaluated())
+	return _GLIBCXX_STD_A::equal(__begin1, __end1, __begin2);
+#endif
+
   return __gnu_parallel::mismatch(__begin1, __end1, __begin2).first
   == __end1;
 }
 
   // Public interface
   template
+_GLIBCXX20_CONSTEXPR
 inline bool
 equal(_IIter1 __begin1, _IIter1 __end1, _IIter2 __begin2, 
   _Predicate __pred)
 {
+#if __cplusplus > 201703L
+  if (std::is_constant_evaluated())
+	return _GLIBCXX_STD_A::equal(__begin1, __end1, __begin2, __pred);
+#endif
+
   return __gnu_parallel::mismatch(__begin1, __end1, __begin2, __pred).first
   == __end1;
 }
@@ -286,9 +298,15 @@ namespace __parallel
 }
 
   template
+_GLIBCXX20_CONSTEXPR
 inline bool
 equal(_IIter1 __begin1, _IIter1 __end1, _IIter2 __begin2, _IIter2 __end2)
 {
+#if __cplusplus > 201703L
+  if (std::is_constant_evaluated())
+	return _GLIBCXX_STD_A::equal(__begin1, __end1, __begin2, __end2);
+#endif
+
   typedef __gnu_parallel::_EqualTo<
 	typename std::iterator_traits<_IIter1>::value_type,
 	typename std::iterator_traits<_IIter2>::value_type> _EqualTo;
@@ -299,15 +317,22 @@ namespace __parallel
 }
 
   template
+_GLIBCXX20_CONSTEXPR
 inline bool
 equal(_IIter1 __begin1, _IIter1 __end1,
 	  _IIter2 __begin2, _IIter2 __end2, _BinaryPredicate __binary_pred)
 {
+#if __cplusplus > 201703L
+  if (std::is_constant_evaluated())
+	return _GLIBCXX_STD_A::equal(__begin1, __end1, __begin2, __end2,
+ __binary_pred);
+#endif
+
   return __equal_switch(__begin1, __end1, __begin2, __end2, __binary_pred,
 			std::__iterator_category(__begin1),
 			std::__iterator_category(__begin2));
 }
-#endif
+#endif // C++14
 
   // Sequential fallback
   template
@@ -391,10 +416,17 @@ namespace __parallel
 
   // Public interface
   template
+_GLIBCXX20_CONSTEXPR
 inline bool
 lexicographical_compare(_IIter1 __begin1, _IIter1 __end1,
 _IIter2 __begin2, _IIter2 __end2)
 {
+#if __cplusplus > 201703L
+  if (std::is_constant_evaluated())
+	return _GLIBCXX_STD_A::lexicographical_compare(__begin1, __end1,
+		   __begin2, __end2);
+#endif
+
   typedef iterator_traits<_IIter1> _TraitsType1;
   typedef typename _TraitsType1::value_type _ValueType1;
   typedef typename _TraitsType1::iterator_category _IteratorCategory1;
@@ -411,11 +443,19 @@ namespace __parallel
 
   // Public interface
   template
+_GLIBCXX20_CONSTEXPR
 inline bool
 lexicographical_compare(_IIter1 __begin1, _IIter1 __end1,
 _IIter2 __begin2, _IIter2 __end2,
 _Predicate __pred)
 {
+#if __cplusplus > 201703L
+  if (std::is_constant_evaluated())
+	return _GLIBCXX_STD_A::lexicographical_compare(__begin1, __end1,
+		   __begin2, __end2,
+		   __pred);
+#endif
+
   typedef iterator_traits<_IIter1> _TraitsType1;
   typedef typename _TraitsType1::iterator_category _IteratorCategory1;
 
diff --git a/libstdc++-v3/include/parallel/algorithmfwd.h b/libstdc++-v3/include/parallel/algorithmfwd.h
index a6d03a50cfc..a227ebac2a3 100644
--- a/libstdc++-v3/include/parallel/algorithmfwd.h
+++ b/libstdc++-v3/include/parallel/algorithmfwd.h
@@ -130,10 +130,12 @@ namespace __parallel
   __gnu_parallel::sequential_tag);
 
   template
+_GLIBCXX20_CONSTEXPR
 bool
 equal(_IIter1, _IIter1, _IIter2);
 
   template
+_GLIBCXX20_CONSTEXPR
 bool
 equal(_IIter1, _IIter1, _IIter2, _Predicate);
 
@@ -285,10 +287,12 @@ namespace __parallel
 

[PATCH] Disable tests that aren't valid in parallel mode

[Jonathan Wakely]

Tested x86_64-linux (normal and parallel modes), committed to trunk.
commit b11c8f480fe1cd5696ec1a8f0db481c5f45429b8
Author: Jonathan Wakely 
Date:   Tue Oct 1 20:31:51 2019 +0100

Disable tests that aren't valid in parallel mode

Tests that depend on debug mode can't be tested in parallel mode.

* testsuite/17_intro/using_namespace_std_tr1_neg.cc: Skip test for
parallel mode.
* testsuite/20_util/hash/84998.cc: Likewise.
* testsuite/23_containers/deque/types/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/forward_list/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/list/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/map/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/multimap/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/multiset/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/set/pmr_typedefs_debug.cc: Likewise.
* testsuite/23_containers/unordered_map/pmr_typedefs_debug.cc:
Likewise.
* testsuite/23_containers/unordered_multimap/pmr_typedefs_debug.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/pmr_typedefs_debug.cc:
Likewise.
* testsuite/23_containers/unordered_set/pmr_typedefs_debug.cc:
Likewise.
* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
Likewise.
* testsuite/23_containers/vector/types/pmr_typedefs_debug.cc: Likewise.
* testsuite/25_algorithms/binary_search/partitioned.cc: Likewise.
* testsuite/25_algorithms/copy/86658.cc: Likewise.
* testsuite/25_algorithms/equal_range/partitioned.cc: Likewise.
* testsuite/25_algorithms/lexicographical_compare/71545.cc: Likewise.
* testsuite/25_algorithms/lower_bound/partitioned.cc: Likewise.
* testsuite/25_algorithms/upper_bound/partitioned.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/17_intro/using_namespace_std_tr1_neg.cc b/libstdc++-v3/testsuite/17_intro/using_namespace_std_tr1_neg.cc
index 31242760179..bdc41507424 100644
--- a/libstdc++-v3/testsuite/17_intro/using_namespace_std_tr1_neg.cc
+++ b/libstdc++-v3/testsuite/17_intro/using_namespace_std_tr1_neg.cc
@@ -18,7 +18,7 @@
 // .
 
 // NB: parallel-mode uses TR1 bits...
-#undef _GLIBCXX_PARALLEL
+// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PARALLEL" } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/hash/84998.cc b/libstdc++-v3/testsuite/20_util/hash/84998.cc
index 1cf57e9073c..b00df223415 100644
--- a/libstdc++-v3/testsuite/20_util/hash/84998.cc
+++ b/libstdc++-v3/testsuite/20_util/hash/84998.cc
@@ -17,6 +17,7 @@
 
 // { dg-options "-D_GLIBCXX_DEBUG" }
 // { dg-do compile { target c++11 } }
+// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PARALLEL" } }
 
 // PR libstdc++/84998
 
diff --git a/libstdc++-v3/testsuite/23_containers/deque/types/pmr_typedefs_debug.cc b/libstdc++-v3/testsuite/23_containers/deque/types/pmr_typedefs_debug.cc
index ac96584a6e0..9bee219b58f 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/types/pmr_typedefs_debug.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/types/pmr_typedefs_debug.cc
@@ -17,6 +17,7 @@
 
 // { dg-options "-std=gnu++17 -D_GLIBCXX_DEBUG" }
 // { dg-do compile { target c++17 } }
+// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PARALLEL" } }
 
 #include 
 static_assert(std::is_same_v<
diff --git a/libstdc++-v3/testsuite/23_containers/forward_list/pmr_typedefs_debug.cc b/libstdc++-v3/testsuite/23_containers/forward_list/pmr_typedefs_debug.cc
index 7df01d530f8..66138ba830c 100644
--- a/libstdc++-v3/testsuite/23_containers/forward_list/pmr_typedefs_debug.cc
+++ b/libstdc++-v3/testsuite/23_containers/forward_list/pmr_typedefs_debug.cc
@@ -17,6 +17,7 @@
 
 // { dg-options "-std=gnu++17 -D_GLIBCXX_DEBUG" }
 // { dg-do compile { target c++17 } }
+// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PARALLEL" } }
 
 #include 
 static_assert(std::is_same_v<
diff --git a/libstdc++-v3/testsuite/23_containers/list/pmr_typedefs_debug.cc b/libstdc++-v3/testsuite/23_containers/list/pmr_typedefs_debug.cc
index d59f8c41d1d..b1bb271aa1c 100644
--- a/libstdc++-v3/testsuite/23_containers/list/pmr_typedefs_debug.cc
+++ b/libstdc++-v3/testsuite/23_containers/list/pmr_typedefs_debug.cc
@@ -17,6 +17,7 @@
 
 // { dg-options "-std=gnu++17 -D_GLIBCXX_DEBUG" }
 // { dg-do compile { target c++17 } }
+// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PARALLEL" } }
 
 #include 
 static_assert(std::is_same_v<
diff --git a/libstdc++-v3/testsuite/23_containers/map/pmr_typedefs_debug.cc b/libstdc++-v3/testsuite/23_containers/map/pmr_typedefs_debug.cc
index d06673027e5..c959b6957ed 100644
--- a/libstdc++-v3/testsuite/23_containers/map/pmr_typedefs_debug.cc
+++ b/libstdc++-v3/testsuite/23_containers/map/pmr_typedefs_debug.cc
@@ -17,6 

[PATCH] Fix non-reserved names in Parallel Mode headers

[Jonathan Wakely]

* include/parallel/algo.h: Replace non-reserved names.
* include/parallel/multiway_merge.h: Likewise.
* include/parallel/multiway_mergesort.h: Likewise.
* include/parallel/numericfwd.h: Likewise.
* testsuite/17_intro/names.cc: Add RAI to test macros.

Tested x86_64-linux (normal and parallel modes), committed to trunk.


commit 37e8a3375e8238a98d2a3624f701f40ea6a8fed3
Author: Jonathan Wakely 
Date:   Tue Oct 1 16:25:07 2019 +0100

Fix non-reserved names in Parallel Mode headers

* include/parallel/algo.h: Replace non-reserved names.
* include/parallel/multiway_merge.h: Likewise.
* include/parallel/multiway_mergesort.h: Likewise.
* include/parallel/numericfwd.h: Likewise.
* testsuite/17_intro/names.cc: Add RAI to test macros.

diff --git a/libstdc++-v3/include/parallel/algo.h 
b/libstdc++-v3/include/parallel/algo.h
index dc6971f5dd4..afa325bb4af 100644
--- a/libstdc++-v3/include/parallel/algo.h
+++ b/libstdc++-v3/include/parallel/algo.h
@@ -311,11 +311,11 @@ namespace __parallel
 { return _GLIBCXX_STD_A::unique_copy(__begin, __last, __out, __pred); }
 
   // Parallel unique_copy for random access iterators
-  template
-RandomAccessOutputIterator
+_RandomAccessOutputIterator
 __unique_copy_switch(_RAIter __begin, _RAIter __last,
-RandomAccessOutputIterator __out, _Predicate __pred,
+_RandomAccessOutputIterator __out, _Predicate __pred,
 random_access_iterator_tag, random_access_iterator_tag)
 {
   if (_GLIBCXX_PARALLEL_CONDITION(
diff --git a/libstdc++-v3/include/parallel/multiway_merge.h 
b/libstdc++-v3/include/parallel/multiway_merge.h
index 6bdf08b4704..c5f85881ace 100644
--- a/libstdc++-v3/include/parallel/multiway_merge.h
+++ b/libstdc++-v3/include/parallel/multiway_merge.h
@@ -232,7 +232,7 @@ namespace __gnu_parallel
*
* @return End iterator of output sequence.
*/
-  template class iterator,
+  template class iterator,
typename _RAIterIterator,
typename _RAIter3,
typename _DifferenceTp,
@@ -351,7 +351,7 @@ namespace __gnu_parallel
*
* @return End iterator of output sequence.
*/
-  template class iterator,
+  template class iterator,
typename _RAIterIterator,
typename _RAIter3,
typename _DifferenceTp,
@@ -641,8 +641,8 @@ namespace __gnu_parallel
   /** @brief Multi-way merging procedure for a high branching factor,
* requiring sentinels to exist.
*
-   * @tparam UnguardedLoserTree _Loser Tree variant to use for the unguarded
-   *   merging.
+   * @tparam _UnguardedLoserTree Loser Tree variant to use for the unguarded
+   *merging.
*
* @param __seqs_begin Begin iterator of iterator pair input sequence.
* @param __seqs_end End iterator of iterator pair input sequence.
@@ -653,7 +653,7 @@ namespace __gnu_parallel
*
* @return End iterator of output sequence.
*/
-  template
+  __target_end = multiway_merge_loser_tree_unguarded<_UnguardedLoserTree>
(__seqs_begin, __seqs_end, __target, __sentinel, __length, __comp);
 
 #if _GLIBCXX_PARALLEL_ASSERTIONS
diff --git a/libstdc++-v3/include/parallel/multiway_mergesort.h 
b/libstdc++-v3/include/parallel/multiway_mergesort.h
index d39fc9abc19..d382a2c92f6 100644
--- a/libstdc++-v3/include/parallel/multiway_mergesort.h
+++ b/libstdc++-v3/include/parallel/multiway_mergesort.h
@@ -264,19 +264,19 @@ namespace __gnu_parallel
   { __gnu_sequential::sort(__begin, __end, __comp); }
 };
 
-  template
+  typename _DiffType>
 struct __possibly_stable_multiway_merge
 { };
 
-  template
-struct __possibly_stable_multiway_merge
 {
-  void operator()(const Seq_RAIter& __seqs_begin,
- const Seq_RAIter& __seqs_end,
+  void operator()(const _Seq_RAIter& __seqs_begin,
+ const _Seq_RAIter& __seqs_end,
  const _RAIter& __target,
  _Compare& __comp,
  _DiffType __length_am) const
@@ -284,13 +284,13 @@ namespace __gnu_parallel
  __length_am, __comp, sequential_tag()); }
 };
 
-  template
-struct __possibly_stable_multiway_merge
 {
-  void operator()(const Seq_RAIter& __seqs_begin,
-  const Seq_RAIter& __seqs_end,
+  void operator()(const _Seq_RAIter& __seqs_begin,
+  const _Seq_RAIter& __seqs_end,
   const _RAIter& __target,
   _Compare& __comp,
   _DiffType __length_am) const
diff --git a/libstdc++-v3/include/parallel/numericfwd.h 
b/libstdc++-v3/include/parallel/numericfwd.h
index a9b8a2b1ea6..a1b1dc7571b 100644
--- a/libstdc++-v3/include/parallel/numericfwd.h
+++ b/libstdc++-v3/include/parallel/numericfwd.h
@@ -149,17 +149,17 @@ 

[Bug c/91961] New: __has_attribute expands macro argument

[msebor at gcc dot gnu.org]

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

Bug ID: 91961
   Summary: __has_attribute expands macro argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing my patch for pr66970 against Clang I noticed a difference in how
the two compilers deal with macro arguments to the __has_attribute (and
__has_builtin) operators: Clang doesn't expand macros while GCC does.  I can
see arguments for either approach so this is just to record the difference and,
ultimately, the decision to either stick with the GCC behavior that's been in
place presumably since 2014 (when r217292 added __has_attribute) or change it
to follow what Clang does, and the rationale for it.

$ (set -x; cat b.c; clang -S b.c; gcc -S -Wall b.c)
+ cat b.c
#define NORETURN noreturn

#if !__has_attribute (noreturn)
#  error "__has_attribute (noreturn) failed"
#endif

#if !__has_attribute (NORETURN)
#  error "__has_attribute (NORETURN) failed"
#endif

+ clang -S b.c
b.c:8:4: error: "__has_attribute (NORETURN) failed"
#  error "__has_attribute (NORETURN) failed"
   ^
1 error generated.
+ gcc -S -Wall b.c
$

[Bug fortran/91959] [8/9/10 Regression] Accepts invalid variable declaration %x

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.3

--- Comment #2 from kargl at gcc dot gnu.org ---
I have patch, but need to do some testing.

[Bug fortran/91959] [8/9/10 Regression] Accepts invalid variable declaration %x

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-01
 Ever confirmed|0   |1

Re: [PATCH] IPA-CP release transformation summary (PR jit/91928)

[Jeff Law]

On 10/1/19 4:11 AM, Andrea Corallo wrote:
> Martin Jambor writes:
> 
>> Hi,
>>
>> On Mon, Sep 30 2019, Andrea Corallo wrote:
>>> Hi all,
>>> I'd like to submit this patch.
>>> It release the ipa cp transformation summary after functions being expanded.
>>> This is to fix the compiler when used with libgccjit on subsequent
>>> compilations (every new compilation should have a clean transformation
>>> summary).
>> if this is a general problem then I think we should instead add another
>> hook to class ipa_opt_pass_d to free transformation summary, call it for
>> all IPA passes at the appropriate time and implement it for IPA-CP. That
>> way it will work for all IPA passes which might have a transformation
>> summary.
>>
>> Martin
>>
>>
>>> Bootstrap on arm64 and X86-64.
>>>
>>> Bests
>>>   Andrea
>>>
>>> gcc/ChangeLog
>>> 2019-??-??  Andrea Corallo  
>>>
>>> * cgraphunit.c (expand_all_functions): Release ipcp_transformation_sum
>>> when finished.
>>> * ipa-prop.c (ipcp_free_transformation_sum): New function.
>>> * ipa-prop.h (ipcp_free_transformation_sum): Add declaration.
> Hi,
> actually looking around in order to implement the suggestions I realized
> that already some code was put in place in toplev::finalize calling
> then ipa_cp_c_finalize exactly for this purpose.
> 
> I've updated the patch accordingly.
> 
> Bootstraped on aarch64.
> 
> Is it okay for trunk?
> 
> Bests
>   Andrea
> 
> gcc/ChangeLog
> 2019-??-??  Andrea Corallo  
> 
>   * ipa-cp.c (ipa_cp_c_finalize): Release ipcp_transformation_sum.
>   * ipa-prop.c (ipcp_free_transformation_sum): New function.
>   * ipa-prop.h (ipcp_free_transformation_sum): Add declaration.
OK for the trunk.

jeff

[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information

[alisdairm at me dot com]

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

Alisdair Meredith  changed:

   What|Removed |Added

 CC||alisdairm at me dot com

--- Comment #3 from Alisdair Meredith  ---
*** Bug 91958 has been marked as a duplicate of this bug. ***

[Bug c++/91958] type info does not respect 'noexcept' on C++17 function types

[alisdairm at me dot com]

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

Alisdair Meredith  changed:

   What|Removed |Added

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

--- Comment #2 from Alisdair Meredith  ---
Confirmed that looks like a dupe.  Sorry, I did try searching for existing
issues before filing, but clearly not very well :(

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

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

[Jeff Law]

On 9/28/19 8:14 PM, Oleg Endo wrote:
> Hi,
> 
> I've been dragging this patch along with me for a while.
> At the moment, I don't have the resources to fully test it as requested
> by Ian in the PR discussion.
> 
> So I would like to ask for general comments on this one and hope that
> folks with bigger automated test setups can run the patch through their
> machinery for little endian targets.
> 
> 
> Summary of the story:
> 
> I've noticed this issue on the RX on GCC 6, but it seems it's been
> there forever.
> 
> On RX, fp-bit is used for software floating point emulation.  The RX
> target also uses "MS bit-field" layout by default.  This means that
> code like
> 
> struct
> {
>   fractype fraction:FRACBITS __attribute__ ((packed));
>   unsigned int exp:EXPBITS __attribute__ ((packed));
>   unsigned int sign:1 __attribute__ ((packed));
> } bits;
> 
> will result in sizeof (bits) != 8
> 
> For some reason, this bit-field style declaration is used only for
> FLOAT_BIT_ORDER_MISMATCH, which generally seems to be set for little
> endian targets.  In other cases (i.e. big endian) open coded bit field
> extraction and packing is used on the base integer type, like
> 
>  fraction = src->value_raw & fractype)1) << FRACBITS) - 1);
>  exp = ((int)(src->value_raw >> FRACBITS)) & ((1 << EXPBITS) - 1);
>  sign = ((int)(src->value_raw >> (FRACBITS + EXPBITS))) & 1;
> 
> This works of course regardless of the bit-field packing layout of the
> target.
> 
> Joseph suggested to pack the struct bit, which would fix the issue.  
> https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01651.html
> 
> However, I would like to propose to remove the special case of
> FLOAT_BIT_ORDER_MISMATCH altogether as in the attached patch.
> 
> Any comments?
> 
> Cheers,
> Oleg
> 
> 
> 
> libgcc/ChangeLog
> 
>   PR libgcc/77804
>   * fp-bit.h: Remove FLOAT_BIT_ORDER_MISMATCH.
>   * fp-bit.c (pack_d, unpack_d): Remove special cases for 
>   FLOAT_BIT_ORDER_MISMATCH.
>   * config/arc/t-arc: Remove FLOAT_BIT_ORDER_MISMATCH.
> 
So the ask is to just test this on some LE targets?  I can do that :-)

I'll throw it in.  Analysis will be slightly more difficult than usual
as we've got some fallout from Richard S's work, but it's certainly do-able.

Jeff

ps.  ANd yes, I've got a request to the build farm folks to get a
jenkins instance on the build farm.  Once that's in place I can have my
tester start publishing results that everyone can see.

[Bug target/91957] [10 Regression] ICE in lra_assign building libgcc for csky-linux-gnuabiv2 soft-float

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #1 from Andrew Pinski  ---
The change also removed for flag_ipa_ra which means there could be a latent
target bug floating around beforehand.

Does before the patches adding -fno-ipa-ra cause an ICE?

[Bug c++/91950] -Wreturn-type false positive due to CWG 1766

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #2)
> I think this is actually a dup of another bug that asked the same thing, but
> I forget its number...

There are dozens of them, because nobody understands how enums work in C++.

I keep meaning to write a FAQ entry.

[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6

[mattst88 at gmail dot com]

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

--- Comment #21 from Matt Turner  ---
(In reply to Eric Botcazou from comment #16)
> > I believe the Known to work field is wrong and gcc-8.3.0 has this bug as
> > well.
> 
> No, the field is correct and you're wrong.

Funny how the fix for the gcc-8.3.0 branch was a backport of this patch!

Have some manners next time.

Re: [PATCH] Help compiler detect invalid code

[François Dumont]

On 9/27/19 1:24 PM, Jonathan Wakely wrote:

On 20/09/19 07:08 +0200, François Dumont wrote:
I already realized that previous patch will be too controversial to 
be accepted.


In this new version I just implement a real memmove in __memmove so 


A real memmove doesn't just work backwards, it needs to detect any
overlaps and work forwards *or* backwards, as needed.
ok, good to know, I understand now why using __builtin_memcopy didn't 
show any performance enhancement when I tested it !


I think your change will break this case:

#include 

constexpr int f(int i, int j, int k)
{
 int arr[5] = { 0, 0, i, j, k };
 std::move(arr+2, arr+5, arr);
 return arr[0] + arr[1] + arr[2];
}

static_assert( f(1, 2, 3) == 6 );

This is valid because std::move only requires that the result iterator
is not in the input range, but it's OK for the two ranges to overlap.

I haven't tested it, but I think with your change the array will end
up containing {3, 2, 3, 2, 3} instead of {1, 2, 3, 2, 3}.

Indeed, I've added a std::move constexpr test in this new proposal which 
demonstrate that.


C++ Standard clearly states that [copy|move]_backward is done backward. 
So in this new proposal I propose to add a __memcopy used in copy/move 
and keep __memmove for *_backward algos. Both are using 
__builtin_memmove as before.



    * include/bits/stl_algobase.h (__memmove): Return void, loop as long as
    __n != 0.
    (__memcopy): New.
    (__copy_move<_IsMove, true, 
std::random_access_iterator_tag>::__copy_m):

    Adapt to use latter.
    (__copy_move_backward_a): Remove std::is_constant_evaluated block.
    * testsuite/25_algorithms/copy/constexpr.cc (test): Add check on copied
    values.
    * testsuite/25_algorithms/copy_backward/constexpr.cc (test): Likewise
    and rename in test1.
    (test2): New.
    * testsuite/25_algorithms/copy/constexpr_neg.cc: New.
    * testsuite/25_algorithms/copy_backward/constexpr.cc: New.
    * testsuite/25_algorithms/equal/constexpr_neg.cc: New.
    * testsuite/25_algorithms/move/constexpr.cc: New.
    * testsuite/25_algorithms/move/constexpr_neg.cc: New.

Tested under Linux x86_64.

Ok to commit ?

François

Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h	(révision 276259)
+++ include/bits/stl_algobase.h	(copie de travail)
@@ -78,18 +78,18 @@
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /*
-   * A constexpr wrapper for __builtin_memmove.
+   * A constexpr wrapper for memcopy.
* @param __num The number of elements of type _Tp (not bytes).
*/
   template
 _GLIBCXX14_CONSTEXPR
-inline void*
-__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
+inline void
+__memcopy(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
 {
 #ifdef __cpp_lib_is_constant_evaluated
   if (std::is_constant_evaluated())
 	{
-	  for(; __num > 0; --__num)
+	  for (; __num != 0; --__num)
 	{
 	  if constexpr (_IsMove)
 		*__dst = std::move(*__src);
@@ -98,15 +98,40 @@
 	  ++__src;
 	  ++__dst;
 	}
-	  return __dst;
 	}
   else
 #endif
-	return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
-  return __dst;
+	__builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
 }
 
   /*
+   * A constexpr wrapper for memmove.
+   * @param __num The number of elements of type _Tp (not bytes).
+   */
+  template
+_GLIBCXX14_CONSTEXPR
+inline void
+__memmove(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
+{
+#ifdef __cpp_lib_is_constant_evaluated
+  if (std::is_constant_evaluated())
+	{
+	  __dst += __num;
+	  __src += __num;
+	  for (; __num != 0; --__num)
+	{
+	  if constexpr (_IsMove)
+		*--__dst = std::move(*--__src);
+	  else
+		*--__dst = *--__src;
+	}
+	}
+  else
+#endif
+	__builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
+}
+
+  /*
* A constexpr wrapper for __builtin_memcmp.
* @param __num The number of elements of type _Tp (not bytes).
*/
@@ -446,7 +471,7 @@
 #endif
 	  const ptrdiff_t _Num = __last - __first;
 	  if (_Num)
-	std::__memmove<_IsMove>(__result, __first, _Num);
+	std::__memcopy<_IsMove>(__result, __first, _Num);
 	  return __result + _Num;
 	}
 };
@@ -676,12 +701,6 @@
 			 && __is_pointer<_BI2>::__value
 			 && __are_same<_ValueType1, _ValueType2>::__value);
 
-#ifdef __cpp_lib_is_constant_evaluated
-  if (std::is_constant_evaluated())
-	return std::__copy_move_backward::__copy_move_b(__first, __last,
-			__result);
-#endif
   return std::__copy_move_backward<_IsMove, __simple,
    _Category>::__copy_move_b(__first,
  __last,
Index: testsuite/25_algorithms/copy/constexpr.cc
===
--- testsuite/25_algorithms/copy/constexpr.cc	(révision 276259)
+++ testsuite/25_algorithms/copy/constexpr.cc	(copie de travail)
@@ -24,12 +24,12 @@
 constexpr bool
 test()
 {
-  constexpr std::array ca0{{0, 1, 2, 3, 4, 5, 

[committed, obvious] Regenerate `liboffloadmic/plugin/configure' for `uclinuxfdpiceabi'

[Maciej W. Rozycki]

Regenerate `liboffloadmic/plugin/configure' for r275564 ("[ARM/FDPIC v6 
02/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure 
scripts") too.

liboffloadmic/
* plugin/configure: Regenerate.
---
On Sun, 29 Sep 2019, Christophe Lyon wrote:

> > A change made with r275564 ("[ARM/FDPIC v6 02/24] [ARM] FDPIC: Handle
> > arm*-*-uclinuxfdpiceabi in configure scripts") to libtool.m4 has not
> > regenerated all the `configure' scripts affected.  Fix it.
> >
> 
> Oops sorry!
> I knew I forgot something

 No worries.  Here's another one, which I missed as I only checked top 
level subdirectories.

  Maciej
---
 liboffloadmic/plugin/configure |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

gcc-configure-uclinux-regen-more.diff
Index: gcc/liboffloadmic/plugin/configure
===
--- gcc.orig/liboffloadmic/plugin/configure
+++ gcc/liboffloadmic/plugin/configure
@@ -5746,7 +5746,7 @@ irix5* | irix6* | nonstopux*)
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -8825,7 +8825,7 @@ _LT_EOF
   archive_expsym_cmds='sed "s,^,_," $export_symbols 
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags ${wl}-h,$soname 
${wl}--retain-symbols-file,$output_objdir/$soname.expsym 
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
   ;;
 
-gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
+gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   tmp_diet=no
   if test "$host_os" = linux-dietlibc; then
case $cc_basename in
@@ -10356,7 +10356,12 @@ linux*oldld* | linux*aout* | linux*coff*
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+
+# uclinux* changes (here and below) have been submitted to the libtool
+# project, but have not yet been accepted: they are GCC-local changes
+# for the time being.  (See
+# https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -11045,7 +11050,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11048 "configure"
+#line 11053 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11151,7 +11156,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11154 "configure"
+#line 11159 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14016,7 +14021,12 @@ linux*oldld* | linux*aout* | linux*coff*
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+
+# uclinux* changes (here and below) have been submitted to the libtool
+# project, but have not yet been accepted: they are GCC-local changes
+# for the time being.  (See
+# https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no

Re: [PATCH] Fix PR fortran/91716

[Bernd Edlinger]

On 9/13/19 12:16 PM, Janne Blomqvist wrote:
> On Fri, Sep 13, 2019 at 1:07 PM Bernd Edlinger
>  wrote:
>>
>> Hi,
>>
>> this fixes a test case where a short string constant is put in a larger 
>> memory object.
>>
>> The consistency check in varasm.c is failed because both types should agree.
>>
>> Since the failed assertion is just a gcc_checking_assert I think a back-port 
>> of this fix
>> to the gcc-9 branch will not be necessary.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
> 
> Ok.
> 

Well, I have mistakenly assumed that this triggers only a "checking" assert,
but it turned out that is not the case, as written in last comment in the BZ,
immediately after that gcc_checking_assert, there is a gcc_assert, and also
an ICE in the gcc-9 branch.  The same patch fixes also the second problem,
and survives reg-bootstrap and testing on x86_64-pc-linux-gnu as expected.


So I would like to ask at this time, if it is also OK for gcc-9 ?


Thanks
Bernd.

[Bug c++/91958] type info does not respect 'noexcept' on C++17 function types

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
PR 83534 ? (it could also be related to bug 67772, but it is a bit further)

Re: [PATCH] Come up with json::integer_number and use it in GCOV.

[Jeff Law]

On 9/18/19 2:04 AM, Martin Liška wrote:
> PING^4
> 
> Just note that the author of the JSON implementation
> in GCC is fine with the patch ;)
OK if this is still pending :-)
jeff

[Bug fortran/91960] New: ICE: backend decl for module variable 'j' already exists

[gs...@t-online.de]

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

Bug ID: 91960
   Summary: ICE: backend decl for module variable 'j' already
exists
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gfortran-5,
with undefined variable j :


$ cat z1.f90
module m
   integer :: i, j
   integer, parameter :: a(3) = [1, 2, 3]
   integer, parameter :: b(3) = [(a(j), i=1,3)]
end


$ gfortran-10-20190929 -c z1.f90
f951: internal compiler error: backend decl for module variable 'j' already
exists
0x621b49 gfc_report_diagnostic
../../gcc/fortran/error.c:776
0x62323a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1391
0x6f48f5 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5231
0x6b3f22 do_traverse_symtree
../../gcc/fortran/symbol.c:4165
0x6f4e8b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5749
0x6cfc4c gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2224
0x67e641 translate_all_program_units
../../gcc/fortran/parse.c:6241
0x67e641 gfc_parse_file()
../../gcc/fortran/parse.c:6493
0x6c89af gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c++/91953] [8/9/10 Regression] G++ rejects lambda with constexpr variable

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #2)
> This boils down to
> struct S {};
> 
> void
> foo (S s)
> {
>   constexpr S x = s;
> }
> which GCC 7 as well as clang accepted, but GCC 8+ rejects.

I think it should be accepted, since S is empty, there's no actual
lvalue-to-rvalue conversion involved.

It works with
using S = decltype(nullptr);

and this works too since GCC 7:

struct A { } a;
constexpr int f (A a) { return 42; }
constexpr int i = f(a);

Re: RFC: Followup to PR91593

[Martin Sebor]

On 9/30/19 9:40 PM, Jerry DeLisle wrote:

Copying gcc list for additional thoughts on a possible bogus warning.

On 9/29/19 9:02 AM, Jerry DeLisle wrote:

Hi all,


--- snip ---


diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fc046efbe34 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1031,7 +1031,7 @@ btoa_big (const char *s, char *buffer, int len, 
GFC_UINTEGER_LARGEST *n)

    else
  {
    const char *p = s + len - 1;
-  for (i = 0; i < len; i++)
+  for (i = 0; i < len - 1; i++)
  {
    char c = *p;



--- snip ---

The first attempt to fix (above) is completely off.  I have tried 
various combinations of code changes and I am beginning to think the 
warning is bogus:


In function ‘btoa_big’,
     inlined from ‘write_b’ at 
../../../trunk/libgfortran/io/write.c:1217:11:
../../../trunk/libgfortran/io/write.c:1052:6: warning: writing 1 byte 
into a region of size 0 [-Wstringop-overflow=]

  1052 |   *q = '\0';
   |   ~~~^~


In case it helps, the warning is for the access:

  # .MEM_68 = VDEF <.MEM_71>
  MEM[(char *)_86] = 0;

where _86 is set to

  _86 = _buf + _43;

and _43 has the range [136, 17179869176].  (The warning needs to
be enhanced a bit to mention the accessed object in this case.)
itoa_buf's DECL_SIZE_UNIT evaluates to 129.

The call to btoa_big in write_b:

  p = btoa_big (source, itoa_buf, len, );

is made with len > 16.  If len > sizeof itoa_buf  / 8 then it does
look like btoa_big would write past the end of itoa_buf because it
writes len * 8 bytes into it.  I don't know if the function can be
called with len that large but if not, adding this just above
the call suppresses the warning.

  if (len > sizeof itoa_buf / 8)
__builtin_unreachable ();

Martin

Using gdb I have watched the pointer address stored in q and the setting 
of the string of bytes doing the binary to ascii conversion. I have also 
checked the length of the buffer being used and its is what I would 
expect with length of 129.


However, the warning only goes away if I add an additional 8 bytes to 
the buffer (suspicious).


So doing the following eliminates the warning:

diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fd0e46851e4 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1204,7 +1204,7 @@ void
  write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int 
len)

  {
    const char *p;
-  char itoa_buf[GFC_BTOA_BUF_SIZE];
+  char itoa_buf[GFC_BTOA_BUF_SIZE + 8];
    GFC_UINTEGER_LARGEST n = 0;

    if (len > (int) sizeof (GFC_UINTEGER_LARGEST))

Any suggestions? I am certainly not seeing it.

Regards,

Jerry

Re: syncing the GCC vax port, atomic issue

[Jeff Law]

On 9/21/19 12:27 PM, Paul Koning wrote:
> 
> 
>> On Sep 20, 2019, at 9:18 PM, co...@sdf.org wrote:
>>
>> On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
>>> Introducing the reversed jbb* patterns doesn't seem to help with the
>>> original issue. It crashes building libatomic.
>>
>> My loose understanding of what is going on:
>> - GCC emits this atomic in expand.
>> - When cleaning up, it looks for optimizations.
>> - It decides this is a branch to another branch situation, so maybe
>>  can be improved.
>> - This fails to output an instruction for unrelated reasons.
>> - Hit an assert.
>>
>> I don't think that we should be trying to combine regular branch +
>> atomic branch in very generic code.
>> My guess is that, if it didn't crash now, it might emit a different kind
>> of branch which loses the atomic qualities, and result in wrong code.
> 
> Or it might leave the atomic branch, in a place where it isn't really wanted.
> 
> I wonder if this could be avoided by representing the atomic branch by an 
> UNSPEC rather than by a branch, since it isn't a "normal branch" that GCC 
> knows about.
If the atomic branch is special from an architectural standpoint, then
that may be advisable.

Jeff

Re: syncing the GCC vax port, atomic issue

[Jeff Law]

On 9/20/19 7:18 PM, co...@sdf.org wrote:
> On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
>> Introducing the reversed jbb* patterns doesn't seem to help with the
>> original issue. It crashes building libatomic.
> 
> My loose understanding of what is going on:
> - GCC emits this atomic in expand.
> - When cleaning up, it looks for optimizations.
> - It decides this is a branch to another branch situation, so maybe
>   can be improved.
> - This fails to output an instruction for unrelated reasons.
> - Hit an assert.
> 
> I don't think that we should be trying to combine regular branch +
> atomic branch in very generic code.
I can see how you might think that, but the way the RTL optimizers work,
particularly the combiner is it tries to smash together two or more
insns that are related by dataflow into a single insn (I'm
over-simplifying, but it's good enough for this discussion).

That's an inherent design decision for the combiner, it's not likely to
change.   If you want to prevent the combiner from doing that, you have
to use UNSPECs

Jeff

Re: RFC: Followup to PR91593

[Martin Sebor]

On 9/30/19 9:40 PM, Jerry DeLisle wrote:

Copying gcc list for additional thoughts on a possible bogus warning.

On 9/29/19 9:02 AM, Jerry DeLisle wrote:

Hi all,


--- snip ---


diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fc046efbe34 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1031,7 +1031,7 @@ btoa_big (const char *s, char *buffer, int len, 
GFC_UINTEGER_LARGEST *n)

    else
  {
    const char *p = s + len - 1;
-  for (i = 0; i < len; i++)
+  for (i = 0; i < len - 1; i++)
  {
    char c = *p;



--- snip ---

The first attempt to fix (above) is completely off.  I have tried 
various combinations of code changes and I am beginning to think the 
warning is bogus:


In function ‘btoa_big’,
     inlined from ‘write_b’ at 
../../../trunk/libgfortran/io/write.c:1217:11:
../../../trunk/libgfortran/io/write.c:1052:6: warning: writing 1 byte 
into a region of size 0 [-Wstringop-overflow=]

  1052 |   *q = '\0';
   |   ~~~^~


In case it helps, the warning is for the access:

  # .MEM_68 = VDEF <.MEM_71>
  MEM[(char *)_86] = 0;

where _86 is set to

  _86 = _buf + _43;

and _43 has the range [136, 17179869176].  (The warning needs to
be enhanced a bit to mention the accessed object in this case.)
itoa_buf's DECL_SIZE_UNIT evaluates to 129.

The call to btoa_big in write_b:

  p = btoa_big (source, itoa_buf, len, );

is made with len > 16.  If len > sizeof itoa_buf  / 8 then it does
look like btoa_big would write past the end of itoa_buf because it
writes len * 8 bytes into it.  I don't know if the function can be
called with len that large but if not, adding this just above
the call suppresses the warning.

  if (len > sizeof itoa_buf / 8)
__builtin_unreachable ();

Martin

Using gdb I have watched the pointer address stored in q and the setting 
of the string of bytes doing the binary to ascii conversion. I have also 
checked the length of the buffer being used and its is what I would 
expect with length of 129.


However, the warning only goes away if I add an additional 8 bytes to 
the buffer (suspicious).


So doing the following eliminates the warning:

diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fd0e46851e4 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1204,7 +1204,7 @@ void
  write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int 
len)

  {
    const char *p;
-  char itoa_buf[GFC_BTOA_BUF_SIZE];
+  char itoa_buf[GFC_BTOA_BUF_SIZE + 8];
    GFC_UINTEGER_LARGEST n = 0;

    if (len > (int) sizeof (GFC_UINTEGER_LARGEST))

Any suggestions? I am certainly not seeing it.

Regards,

Jerry

[Bug fortran/91959] [8/9/10 Regression] Accepts invalid variable declaration %x

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from G. Steinmetz  ---

Variants, if necessary at all :


program p
   character(3) :: %a = 'abc'
   print *, a
end


program p
   double precision :: %a = 1.0d0
   print *, a
end


program p
   integer :: %a = 1
   print *, a
end


program p
   logical :: %a = .true.
   print *, a
end


program p
   real :: %a = 1.0
   print *, a
end


program p
   type t
  integer :: n
   end type
   type(t) :: %a
   a = t(1)
   print *, a
end


program p
   type t
  integer :: n
   end type
   class(t), allocatable :: %a
   a = t(1)
   print *, a%n
end


program p
   complex :: %a = (0.0, 1.0)
   print *, a
end

Re: [SVE] PR91532

[Jeff Law]

On 10/1/19 12:40 AM, Richard Biener wrote:
> On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
> 
>> On Wed, 25 Sep 2019 at 23:44, Richard Biener  wrote:
>>>
>>> On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
>>>
 On Fri, 20 Sep 2019 at 15:20, Jeff Law  wrote:
>
> On 9/19/19 10:19 AM, Prathamesh Kulkarni wrote:
>> Hi,
>> For PR91532, the dead store is trivially deleted if we place dse pass
>> between ifcvt and vect. Would it be OK to add another instance of dse 
>> there ?
>> Or should we add an ad-hoc "basic-block dse" sub-pass to ifcvt that
>> will clean up the dead store ?
> I'd hesitate to add another DSE pass.  If there's one nearby could we
> move the existing pass?
 Well I think the nearest one is just after pass_warn_restrict. Not
 sure if it's a good
 idea to move it up from there ?
>>>
>>> You'll need it inbetween ifcvt and vect so it would be disabled
>>> w/o vectorization, so no, that doesn't work.
>>>
>>> ifcvt already invokes SEME region value-numbering so if we had
>>> MESE region DSE it could use that.  Not sure if you feel like
>>> refactoring DSE to work on regions - it currently uses a DOM
>>> walk which isn't suited for that.
>>>
>>> if-conversion has a little "local" dead predicate compute removal
>>> thingy (not that I like that), eventually it can be enhanced to
>>> do the DSE you want?  Eventually it should be moved after the local
>>> CSE invocation though.
>> Hi,
>> Thanks for the suggestions.
>> For now, would it be OK to do "dse" on loop header in
>> tree_if_conversion, as in the attached patch ?
>> The patch does local dse in a new function ifcvt_local_dse instead of
>> ifcvt_local_dce, because it needed to be done after RPO VN which
>> eliminates:
>> Removing dead stmt _ifc__62 = *_55;
>> and makes the following store dead:
>> *_55 = _ifc__61;
> 
> I suggested trying to move ifcvt_local_dce after RPO VN, you could
> try that as independent patch (pre-approved).
> 
> I don't mind the extra walk though.
> 
> What I see as possible issue is that dse_classify_store walks virtual
> uses and I'm not sure if the loop exit is a natural boundary for
> such walk (eventually the loop header virtual PHI is reached but
> there may also be a loop-closed PHI for the virtual operand,
> but not necessarily).  So the question is whether to add a
> "stop at" argument to dse_classify_store specifying the virtual
> use the walk should stop at?
I think we want to stop at the block boundary -- aren't the cases we
care about here local to a block?

jeff

[Bug fortran/91959] New: [8/9/10 Regression] Accepts invalid variable declaration %x

[gs...@t-online.de]

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

Bug ID: 91959
   Summary: [8/9/10 Regression] Accepts invalid variable
declaration %x
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Starting with gcc-8 (before 20180525) :


$ cat z1.f90
program p
   implicit none
   integer :: %a
   a = 1
   print *, a
end


$ cat z2.f90
program p
   implicit none
   type t
  integer :: %n
   end type
   type(t) :: %a
   a = t(1)
   print *, a
   a%n = 2
   print *, a
end



$ gfortran-7 -c z1.f90
z1.f90:3:15:

integer :: %a
   1
Error: Invalid character in name at (1)
z1.f90:4:4:

a = 1
1
Error: Symbol 'a' at (1) has no IMPLICIT type


$ gfortran-10-20190929 -c z1.f90
$ gfortran-10-20190929 -std=f2008 z1.f90 && ./a.out
   1


$ gfortran-10-20190929 z2.f90 && ./a.out
   1
   2

Re: [PATCH] [MIPS] Fix PR target/91769

[Jeff Law]

On 9/25/19 1:16 AM, Dragan Mladjenovic wrote:
> From: "Dragan Mladjenovic" 
> 
> This fixes the issue by checking that addr's base reg is not part of dest
> multiword reg instead just checking the first reg of dest.
> 
> gcc/ChangeLog:
> 
> 2019-09-25  Dragan Mladjenovic  
> 
>   PR target/91769
>   * config/mips/mips.c (mips_split_move): Use reg_overlap_mentioned_p
>   instead of REGNO equality check on addr.reg.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-09-25  Dragan Mladjenovic  
> 
>   PR target/91769
>   * gcc.target/mips/pr91769.c: New test.
OK.  This would seem fine to backport to gcc-9 as well.  I don't think
gcc-8 had this code.

Sorry for introducing the problem (this looks like mine :(

jeff

Re: [EXTERNAL]Re: [RFC/PATCH v2][PR89245] Check REG_CALL_DECL note during the tail-merging

[Jeff Law]

On 9/6/19 4:23 AM, Dragan Mladjenovic wrote:
> On 24.07.2019. 20:57, Jeff Law wrote:
>> On 7/17/19 2:29 AM, Dragan Mladjenovic wrote:
>>>
>>>
>>> On 09.07.2019. 23:21, Jeff Law wrote:
 On 7/9/19 2:06 PM, Dragan Mladjenovic wrote:
> This patch prevents merging of CALL instructions that that have different
> REG_CALL_DECL notes attached to them.
>
> On most architectures this is not an important distinction. Usually 
> instruction patterns
> for calls to different functions reference different SYMBOL_REF-s, so 
> they won't match.
> On MIPS PIC calls get split into an got_load/*call_internal pair where 
> the latter represents
> indirect register call w/o SYMBOL_REF attached (until machine_reorg 
> pass). The bugzilla issue
> had such two internal_call-s merged despite the fact that they had 
> different register usage
> information assigned by ipa-ra.
>
> As per comment form Richard Sandiford, this version compares reg usage 
> for both call
> instruction instead of shallow comparing the notes. Tests updated 
> accordingly.
>
> gcc/ChangeLog:
>
> 2019-07-09  Dragan Mladjenovic  
>
>   * cfgcleanup.c (old_insns_match_p): Check if used hard regs set is equal
>   for both call instructions.
>
> gcc/testsuite/ChangeLog:
>
> 2019-07-09  Dragan Mladjenovic  
>
>   * gcc.target/mips/cfgcleanup-jalr1.c: New test.
>   * gcc.target/mips/cfgcleanup-jalr2.c: New test.
>   * gcc.target/mips/cfgcleanup-jalr3.c: New test.
 THanks.  I've installed this on the trunk.

 jeff
>>> Thanks. Can this be back-ported to active branches also. This issue
>>> seems to be there > since gcc6 if not gcc5.
>> I've asked Matthew to handle the backport.  I'm going to be on PTO the
>> next couple weeks.
>>
>> jeff
>>
> 
> Hi,
> 
> Sorry, I forgot to check up on this patch. Is it still ok for me to try 
> to backport it to gcc 9 and gcc 8 branches?
Yes, this would be fine to backport to gcc-8 and gcc-9 branches.  I'd
expect it to be pretty easy as I don't think old_insns_match_p has
changed much.

Jeff

[Bug target/85401] segfault building code for VAX

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Tue Oct  1 19:25:31 2019
New Revision: 276426

URL: https://gcc.gnu.org/viewcvs?rev=276426=gcc=rev
Log:
PR target/85401
* ira-color.c (allocno_copy_cost_saving): Call
ira_init_register_move_cost_if_necessary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c

Re: [ping][PR target/85401] initialize the move cost table before using it

[Jeff Law]

On 9/30/19 2:45 PM, co...@sdf.org wrote:
> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
>> Yes, the patch is mostly ok.  You can commit it into the trunk after
>> applying changes mentioned below. If you do not have a write access, let me
>> know I'll commit the patch by myself.
> 
> I don't have commit access. It would be nice if you committed it :)
I took care of the nits and committed the patch.


> 
>> It would be nice to add a small test too.  But it is not obligatory for this
>> case as the patch is obvious and it might be hard to create a small test to
>> reproduce the bug.
> 
> I have the C code that produces this failure. I can creduce it, but I'm
> not sure there's a relationship between it and the bug.
> Doing unrelated changes (adding instruction scheduling) to vax also hid it.
> 
> Is this kind of test still valuable?
Often they are.

jeff

[Bug fortran/91864] [9/10 Regression] ICE in gfc_check_do_variable, at fortran/parse.c:4405

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

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

[Bug fortran/91864] [9/10 Regression] ICE in gfc_check_do_variable, at fortran/parse.c:4405

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct  1 19:21:05 2019
New Revision: 276425

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

PR fortran/91864
* gcc/fortran/io.c (match_io_element): An inquiry parameter cannot be
read into.
* gcc/fortran/match.c (gfc_match_allocate): An inquiry parameter 
can be neither an allocate-object nor stat variable.
(gfc_match_deallocate): An inquiry parameter cannot be deallocated.

2019-10-01 Steven G. Kargl  

PR fortran/91864
* gcc/testsuite/gfortran.dg/pr91864.f90

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91864.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/io.c
branches/gcc-9-branch/gcc/fortran/match.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

Re: [PATCH 2/2] libada: Respect `--enable-version-specific-runtime-libs'

[Maciej W. Rozycki]

On Fri, 27 Sep 2019, Arnaud Charlet wrote:

> >  Shall I amend the change description anyhow then?  I know it has not (as 
> > yet, as discussed at the GNU Tools Cauldron recently) been enforced for 
> > the GCC project (unlike with e.g. glibc), however I mean to use it whole 
> > as the commit message, which is what I have been doing for quite a while 
> > now, because I recognise the value of change descriptions for future 
> > repository examination.
> 
> Sure, add any needed clarification.

 I have added this:

This lets one have `libgnarl-10.so' and `libgnat-10.so' installed in say
/usr/lib and /usr/$(target_alias)/lib for a native and a cross-build
respectively, rather than in /usr/lib/gcc/$(target_alias)/10.0.0/adalib.

and committed the change now.

  Maciej

Re: [01/32] Add function_abi.{h,cc}

[Bernd Edlinger]

Hi,

I am currently trying to implement -Wshadow=local, and
this patch triggers a build-failure with -Wshadow=local
since i is a parameter that is the regno.
But it is also used as loop variable,
so I think this introduces probably a bug:

> @@ -728,7 +731,11 @@ globalize_reg (tree decl, int i)
>   appropriate regs_invalidated_by_call bit, even if it's already
>   set in fixed_regs.  */
>if (i != STACK_POINTER_REGNUM)
> -SET_HARD_REG_BIT (regs_invalidated_by_call, i);
> +{
> +  SET_HARD_REG_BIT (regs_invalidated_by_call, i);
> +  for (unsigned int i = 0; i < NUM_ABI_IDS; ++i)
> + function_abis[i].add_full_reg_clobber (i);
> +}


I would think you meant:

for (unsigned int j = 0; j < NUM_ABI_IDS; ++j)
  function_abis[j].add_full_reg_clobber (i);

Right?

Thanks
Bernd.

Re: state of play/strategy for including Modula-2 into the trunk (licence queries)

[Gaius Mulley]

ah no - lto builds fine.  But with make profiledbootstrap
it errors out with:

gm2/gm2-libs-boot/pthdummy.o: In function `pth_init':
/home/gaius/GM2/graft-trunk/build-lto-trunk/gcc/../../gcc-versionno/gcc/gm2/gm2-libs-ch/pthdummy.c:48:
 undefined reference to `__gcov_indirect_call'

the positive is that again I'm focused back onto replacing libpth 

regards,
Gaius


From: Matthias Klose 
Sent: 01 October 2019 13:46
To: Gaius Mulley ; gcc@gcc.gnu.org 

Subject: Re: state of play/strategy for including Modula-2 into the trunk 
(licence queries)

On 30.09.19 18:46, Gaius Mulley wrote:
> again is this sensible?  Are there [obvious] issues I've missed?

does the profiled LTO build now work? I didn't check recently myself.

Matthias

[Bug fortran/91802] ICE in mio_name_expr_t, at fortran/module.c:2141

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Actually close bug!

[Bug fortran/91802] ICE in mio_name_expr_t, at fortran/module.c:2141

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |9.3

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

[Bug fortran/91802] ICE in mio_name_expr_t, at fortran/module.c:2141

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct  1 18:58:01 2019
New Revision: 276423

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

Backport of r276254+276265
PR fortran/91802
* decl.c (attr_decl1): Check if rank+corank > 15.

2019-10-01  Steven G. Kargl  

PR fortran/91802
* gfortran.dg/pr91802.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91802.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

Re: [PATCH] Add some hash_map_safe_* functions like vec_safe_*.

[Jason Merrill]

On 10/1/19 3:34 AM, Richard Biener wrote:

On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill  wrote:


My comments accidentally got lost.

Several places in the front-end (and elsewhere) use the same lazy
allocation pattern for hash_maps, and this patch replaces them with
hash_map_safe_* functions like vec_safe_*.  They don't provide a way
to specify an initial size, but I don't think that's a significant
issue.

Tested x86_64-pc-linux-gnu.  OK for trunk?


You are using create_ggc but the new functions do not indicate that ggc
allocation is done.
It's then also incomplete with not having a non-ggc variant
of them?  Maybe I'm missing something.


Ah, I had been thinking that this lazy pattern would only be used with 
ggc, but I see that I was wrong.  How's this?


Incidentally, now I see another C++11 feature I'd like to be able to 
use: default template arguments for function templates.


commit c091a74dc7b1550d7dd633dbde7ed7931cd4b025
Author: Jason Merrill 
Date:   Mon Sep 30 13:17:27 2019 -0400

Add some hash_map_safe_* functions like vec_safe_*.

gcc/
* hash-map.h (default_hash_map_size): New variable.
(create_ggc): Use it as default argument.
(hash_map_maybe_create, hash_map_safe_get)
(hash_map_safe_get_or_insert, hash_map_safe_put): New fns.
gcc/cp/
* constexpr.c (maybe_initialize_fundef_copies_table): Remove.
(get_fundef_copy): Use hash_map_safe_get_or_insert.
* cp-objcp-common.c (cp_get_debug_type): Use hash_map_safe_*.
* decl.c (store_decomp_type): Remove.
(cp_finish_decomp): Use hash_map_safe_put.
* init.c (get_nsdmi): Use hash_map_safe_*.
* pt.c (store_defaulted_ttp, lookup_defaulted_ttp): Remove.
(add_defaults_to_ttp): Use hash_map_safe_*.

diff --git a/gcc/hash-map.h b/gcc/hash-map.h
index ba20fe79f23..ce98d3431c3 100644
--- a/gcc/hash-map.h
+++ b/gcc/hash-map.h
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  If not see
removed.  Objects of hash_map type are copy-constructible but not
assignable.  */
 
+const size_t default_hash_map_size = 13;
 template,
 			Value> */>
@@ -129,7 +130,7 @@ class GTY((user)) hash_map
   };
 
 public:
-  explicit hash_map (size_t n = 13, bool ggc = false,
+  explicit hash_map (size_t n = default_hash_map_size, bool ggc = false,
 		 bool sanitize_eq_and_hash = true,
 		 bool gather_mem_stats = GATHER_STATISTICS
 		 CXX_MEM_STAT_INFO)
@@ -146,7 +147,7 @@ public:
 	   HASH_MAP_ORIGIN PASS_MEM_STAT) {}
 
   /* Create a hash_map in ggc memory.  */
-  static hash_map *create_ggc (size_t size,
+  static hash_map *create_ggc (size_t size = default_hash_map_size,
 			   bool gather_mem_stats = GATHER_STATISTICS
 			   CXX_MEM_STAT_INFO)
 {
@@ -326,4 +327,43 @@ gt_pch_nx (hash_map *h, gt_pointer_operator op, void *cookie)
   op (>m_table.m_entries, cookie);
 }
 
+enum hm_alloc { hm_heap = false, hm_ggc = true };
+template
+inline hash_map *
+hash_map_maybe_create (hash_map *)
+{
+  if (!h)
+{
+  if (ggc)
+	h = hash_map::create_ggc (size);
+  else
+	h = new hash_map (size);
+}
+  return h;
+}
+
+/* Like h->get, but handles null h.  */
+template
+inline V*
+hash_map_safe_get (hash_map *h, const K& k)
+{
+  return h ? h->get (k) : NULL;
+}
+
+/* Like h->get, but handles null h.  */
+template
+inline V&
+hash_map_safe_get_or_insert (hash_map *, const K& k, bool *e = NULL)
+{
+  return hash_map_maybe_create (h)->get_or_insert (k, e);
+}
+
+/* Like h->put, but handles null h.  */
+template
+inline bool
+hash_map_safe_put (hash_map *, const K& k, const V& v)
+{
+  return hash_map_maybe_create (h)->put (k, v);
+}
+
 #endif
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index cb5484f4b72..6366872695a 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1098,15 +1098,6 @@ maybe_initialize_constexpr_call_table (void)
 
 static GTY(()) hash_map *fundef_copies_table;
 
-/* Initialize FUNDEF_COPIES_TABLE if it's not initialized.  */
-
-static void
-maybe_initialize_fundef_copies_table ()
-{
-  if (fundef_copies_table == NULL)
-fundef_copies_table = hash_map::create_ggc (101);
-}
-
 /* Reuse a copy or create a new unshared copy of the function FUN.
Return this copy.  We use a TREE_LIST whose PURPOSE is body, VALUE
is parms, TYPE is result.  */
@@ -1114,11 +1105,10 @@ maybe_initialize_fundef_copies_table ()
 static tree
 get_fundef_copy (constexpr_fundef *fundef)
 {
-  maybe_initialize_fundef_copies_table ();
-
   tree copy;
   bool existed;
-  tree *slot = _copies_table->get_or_insert (fundef->decl, );
+  tree *slot = &(hash_map_safe_get_or_insert
+		 (fundef_copies_table, fundef->decl, ));
 
   if (!existed)
 {
diff --git a/gcc/cp/cp-objcp-common.c b/gcc/cp/cp-objcp-common.c
index 4369a5b5570..990e3f04db9 100644
--- a/gcc/cp/cp-objcp-common.c
+++ b/gcc/cp/cp-objcp-common.c
@@ -145,11 +145,9 @@ 

[Bug c++/91950] -Wreturn-type false positive due to CWG 1766

[john.boyer at tutanota dot com]

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

--- Comment #3 from John Boyer  ---
Actually, I believe Jonathan is correct. I misread the CWG. The "range" of an
enum class has nothing to do with how many enumerators it has.

[committed v3 1/2] libada: Remove racy duplicate gnatlib installation

[Maciej W. Rozycki]

For some reason, presumably historical, the `install-gnatlib' target for 
the default multilib is invoked twice, once via the `ada.install-common' 
target in `gcc/ada/gcc-interface/Make-lang.in' invoked from gcc/ and 
again via the `install-libada' target in libada/.

Apart from doing the same twice this is actually harmful in sufficiently 
parallelized `make' invocation, as the removal of old files performed 
within the `install-gnatlib' recipe in the former case actually races 
with the installation of new files done in the latter case, causing the 
recipe to fail and abort, however non-fatally, having not completed the 
installation of all the built files needed for the newly-built compiler 
to work correctly.

This can be observed with a native `x86_64-linux-gnu' bootstrap:

make[4]: Entering directory '.../gcc/ada'
rm -rf .../lib/gcc/x86_64-linux-gnu/10.0.0/adalib
rm: cannot remove '.../lib/gcc/x86_64-linux-gnu/10.0.0/adalib': Directory not 
empty
make[4]: *** [gcc-interface/Makefile:512: install-gnatlib] Error 1
make[4]: Leaving directory '.../gcc/ada'
make[3]: *** [.../gcc/ada/gcc-interface/Make-lang.in:853: install-gnatlib] 
Error 2
make[2]: [.../gcc/ada/gcc-interface/Make-lang.in:829: ada.install-common] Error 
2 (ignored)

which then causes missing files to be reported when an attempt is made 
to use the newly-installed non-functional compiler to build a 
`riscv-linux-gnu' cross-compiler:

(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )
error: "ada.ali" not found, "ada.ads" must be compiled
error: "s-memory.ali" not found, "s-memory.adb" must be compiled
gnatmake: *** bind failed.
/bin/sh: ./xsinfo: No such file or directory
make[2]: *** [.../gcc/ada/Make-generated.in:45: ada/sinfo.h] Error 127
make[2]: Leaving directory '.../gcc'
make[1]: *** [Makefile:4369: all-gcc] Error 2
make[1]: Leaving directory '...'
make: *** [Makefile:965: all] Error 2

Depending on timing `.../lib/gcc/x86_64-linux-gnu/10.0.0/adainclude' may
cause an installation failure instead and the resulting compiler may be 
non-functional in a different way.

Only invoke `install-gnatlib' from within gcc/ then if a legacy build 
process is being used with libada disabled and gnatlib built manually 
with `make -C gcc gnatlib'.

gcc/
* Makefile.in (gnat_install_lib): New variable.
* configure.ac: Substitute it.
* configure: Regenerate.

gcc/ada/
* gcc-interface/Make-lang.in (ada.install-common): Split into...
(gnat-install-tools, gnat-install-lib): ... these.
---
On Tue, 1 Oct 2019, Arnaud Charlet wrote:

> >  I have verified this change by running my combined build process where a 
> > native `x86_64-linux-gnu' configuration is built first and then used to 
> > build a `riscv64-linux-gnu' cross-compiler, both with `--disable-libada' 
> > specified, without and with this patch applied.  I have added `make -C gcc 
> > gnatlib && make -C gcc gnattools' as an extra build step before `make 
> > install'.
> > 
> >  This has run up to failing to find `riscv64-linux-gnu' system headers in 
> > `make -C gcc gnatlib' as noted above, at which point the installation 
> > trees had both the same contents, including `x86_64-linux-gnu' gnatlib 
> > development files and static libraries as well as gnattools in particular.
> 
> Can you also please do a native build with --disable-libada and
> make -C gcc gnatlib && make -C gcc gnattools && make install
> ?

 I had actually done that already, as described in the first paragraph 
quoted above.

> Once successful, the change is OK, thanks for the extra work.

 Here's the final version I have committed then, with the small adjustment 
mentioned earlier on and having brought the formatting of the commit 
description broken in v2 back to order.  Thank you for your review.

  Maciej

Changes from v1:

- gnatlib installation now retained in gcc/ada/gcc-interface/Make-lang.in 
  and instead invoked iff `--disable-libada' has been requested at the top 
  level.

Changes from v2:

- use an ordering dependency only between `gnat-install-lib' and
  `gnat-install-tools'.
---
 gcc/Makefile.in|4 
 gcc/ada/gcc-interface/Make-lang.in |5 -
 gcc/configure  |   15 +--
 gcc/configure.ac   |   10 ++
 4 files changed, 31 insertions(+), 3 deletions(-)

gcc-lang-no-install-gnatlib.diff
Index: gcc/gcc/Makefile.in
===
--- gcc.orig/gcc/Makefile.in
+++ gcc/gcc/Makefile.in
@@ -1706,6 +1706,10 @@ $(FULL_DRIVER_NAME): ./xgcc
 # language hooks, generated by configure
 @language_hooks@
 
+# Wire in install-gnatlib invocation with `make install' for a configuration
+# with top-level libada disabled.
+gnat_install_lib = @gnat_install_lib@
+
 # per-language makefile fragments
 ifneq ($(LANG_MAKEFRAGS),)
 include $(LANG_MAKEFRAGS)
Index: gcc/gcc/ada/gcc-interface/Make-lang.in

[Bug fortran/91714] Accepts type statement without delimiter in free form

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.3

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

[Bug c++/91958] New: type info does not respect 'noexcept' on C++17 function types

[alisdairm at me dot com]

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

Bug ID: 91958
   Summary: type info does not respect 'noexcept' on C++17
function types
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

The following program should compile and run without error when built as C++17
or later.  However, current versions of g++ will terminate throwing the
exception:

#include 

int main() {
if (typeid(int()) == typeid(int() noexcept)) {
   throw "noexcept does not affect typeid";
}
}


This program compiles and runs to completion (as expected) with Clang and Intel
icc (my EDG proxy).

[Bug fortran/91714] Accepts type statement without delimiter in free form

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct  1 18:37:53 2019
New Revision: 276421

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

PR fortran/91714
* decl.c (gfc_match_decl_type_spec):  Issue errors for a few
mangled types.

2019-10-01  Steven G. Kargl  

PR fortran/91714
* gfortran.dg/dec_type_print_3.f90: Update dg-error regex.
* gfortran.dg/pr91714.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91714.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/dec_type_print_3.f90

Re: [PATCH 2/2][GCC][RFC][middle-end]: Add complex number arithmetic patterns to SLP pattern matcher.

[Toon Moene]

On 10/1/19 1:39 PM, Tamar Christina wrote:


The patterns work by looking at the sequence produced after GCC lowers complex
numbers.  As such they would match any normal operation that does the same
computations.


Thanks - I didn't understand Ramana's comments during the GNU Tools 
Cauldron about this feature, but now I do.


Can't wait to put my (upcoming) ThunderX hardware to work on this (plus 
that I have to teach *a lot* of 30-year+ Fortran programmers that you do 
not have to lower COMPLEX arithmetic yourself, because the compiler will 
do this optimally for you ...).


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #23 from Jan Hubicka  ---
I think C++ FE person is needed here, so I am unassigning myself for now.

[Bug c++/91950] -Wreturn-type false positive due to CWG 1766

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I think this is actually a dup of another bug that asked the same thing, but I
forget its number...

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at gcc dot gnu.org]

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

--- Comment #22 from Jan Hubicka  ---
Hi,
I have commited patch that avoids the ICE while producing warning.
However I wonder why C++ FE is silent here
$ cat 2.ii
extern "C" {
struct {
} admbaserest_;
}

We probably could warn about two things
 1) using extern "C" for anonymous types seems pointless since you can not
legally bind them anyway
 2) declaring public symbol with anonymous type seems wrong.
We could also make C++ FE to do right thing for LTO and do not declare extern
"C" anonymous types as being anonymous to the middle-end, but perhaps we just
want the codebases to be fixed anyway and with warning it should be easy to do
so?

Honza

FIX ICE building cactusBSSN

[Jan Hubicka]

Hi,
sorry for taking so long to get to this.  This patch fixes the ICE which
happens when we try to output warning about anonymous type.
As Jason explains in the PR log the warning is correct and I think we
should warn at compile time when parsing 
$ cat 2.ii
extern "C" {
struct {
} admbaserest_;
}
as there seems to be no way to use admbaserest_ from other translation
unit in standard conforming way?

Honza

PR lto/91222
* ipa-devirt.c (warn_types_mismatch): Do not ICE when anonymous type
is matched with non-C++ type
* g++.dg/lto/odr-6_0.C: New testcase.
* g++.dg/lto/odr-6_1.c: New testcase.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 276272)
+++ ipa-devirt.c(working copy)
@@ -992,14 +992,14 @@ warn_types_mismatch (tree t1, tree t2, l
  std::swap (t1, t2);
  std::swap (loc_t1, loc_t2);
}
-  gcc_assert (TYPE_NAME (t1) && TYPE_NAME (t2)
- && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL
- && TREE_CODE (TYPE_NAME (t2)) == TYPE_DECL);
+  gcc_assert (TYPE_NAME (t1)
+ && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL);
   tree n1 = TYPE_NAME (t1);
-  tree n2 = TYPE_NAME (t2);
+  tree n2 = TYPE_NAME (t2) ? TYPE_NAME (t2) : NULL;
+
   if (TREE_CODE (n1) == TYPE_DECL)
n1 = DECL_NAME (n1);
-  if (TREE_CODE (n2) == TYPE_DECL)
+  if (n2 && TREE_CODE (n2) == TYPE_DECL)
n2 = DECL_NAME (n2);
   /* Most of the time, the type names will match, do not be unnecesarily
  verbose.  */
Index: testsuite/g++.dg/lto/odr-6_0.C
===
--- testsuite/g++.dg/lto/odr-6_0.C  (nonexistent)
+++ testsuite/g++.dg/lto/odr-6_0.C  (working copy)
@@ -0,0 +1,8 @@
+// { dg-lto-do link }
+extern "C" {
+struct {  // { dg-lto-message "" 2 }
+} admbaserest_;
+}
+int main()
+{
+}
Index: testsuite/g++.dg/lto/odr-6_1.c
===
--- testsuite/g++.dg/lto/odr-6_1.c  (nonexistent)
+++ testsuite/g++.dg/lto/odr-6_1.c  (working copy)
@@ -0,0 +1,4 @@
+struct {} admbaserest_; // { dg-lto-message "type of " 2 }
+
+
+

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at gcc dot gnu.org]

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

--- Comment #21 from Jan Hubicka  ---
Author: hubicka
Date: Tue Oct  1 18:21:31 2019
New Revision: 276420

URL: https://gcc.gnu.org/viewcvs?rev=276420=gcc=rev
Log:
PR lto/91222
* ipa-devirt.c (warn_types_mismatch): Do not ICE when anonymous type
is matched with non-C++ type
* g++.dg/lto/odr-6_0.C: New testcase.
* g++.dg/lto/odr-6_1.c: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/odr-6_0.C
trunk/gcc/testsuite/g++.dg/lto/odr-6_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91641] [9/10 Regression] ICE in gfc_conv_is_contiguous_expr, at fortran/trans-intrinsic.c:2857

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug middle-end/26241] [7/8/9/10 Regression] None of the IPA passes are documented in passes.texi

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||luoxhu at cn dot ibm.com

--- Comment #19 from Eric Gallager  ---
Xiong Hu Luo has submitted a patch to fix this bug on gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01682.html

Conversation crosses month boundary in the archives here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg8.html

[Bug fortran/91641] [9/10 Regression] ICE in gfc_conv_is_contiguous_expr, at fortran/trans-intrinsic.c:2857

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct  1 18:16:36 2019
New Revision: 276419

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

PR fortran/91641
* check.c (gfc_check_is_contiguous): null() cannot be an actual
argument to is_contiguous().

2019-10-01  Steven G. Kargl  

PR fortran/91641
* gfortran.dg/pr91641.f90: New test.

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

Re: [PATCH] add __has_builtin (PR 66970)

[Martin Sebor]

On 10/1/19 11:38 AM, Jakub Jelinek wrote:

On Tue, Oct 01, 2019 at 11:16:10AM -0600, Martin Sebor wrote:

Attached is an implementation of the __has_builtin special
preprocessor operator/macro analogous to __has_attribute and
(hopefully) compatible with the synonymous Clang feature (I
couldn't actually find tests for it in the Clang test suite
but if someone points me at them I'll verify it).


For the __builtin_*/__sync_*/__atomic_* etc. builtins whether something
is a builtin or not is quite clear, basically whether if using the right
operands for it will compile and do something.
For the library functions, what does it mean that something is a builtin
though?  In some cases we have them in the builtin tables only
to have some predefined attributes for them, in other cases because the
compiler is aware of some of their special properties, in other cases that
the compiler will sometimes optimize them into something else or inline them
and at other times keep them as a library calls, in some cases only for the
compiler to be able to emit calls to those routines in generated code,
in other cases to always optimize them/inline them and never emit the
library function (which perhaps doesn't exist).
I believe that for some builtins like stpcpy we treat them as builtins only
if we see them prototyped first.
And then for C++ with namespaces and symbol lookup rules, whether something
is or isn't a builtin depends not just on the identifier, but namespace too
and maybe argument types too.

So, what do we want __has_builtin to mean for those?

Say, do we want __has_builtin (_exit) just because we have it in the tables
to 1) add noreturn/nothrow/leaf attributes to it 2) consider it in branch
prediction heuristics, but otherwise don't do anything special with it?


As I understand it from the Clang manual and my limited testing, 
__has_builtin is supposed to evaluate to true if the argument is

recognized as the name of a built-in function or function-like
operator.

The number of arguments to the built-in or their types are not
considered in this context (or even available).  Neither are
other declarations of the same symbol.

The intent is simply to determine whether the name can be used
but not how or to what effect.

This is similar to other such queries like __has_attribute which
also doesn't consider the number of attribute operands, or what
the attribute can apply to, or what its effect might be.  Likewise
for __has_include which evaluates to true when the referenced
header can be found by an #include directive without implying
that #including it will not trigger errors for what's in
the header.

Martin

PS As an example, this complete test case passes with both
compilers unless abs is disabled with -fno-builtin.

  #if !__has_builtin (abs)
  # error "__has_builtin (abs) --> false"
  #endif

Ditto if abs is declared as a different symbol first, effectively
preventing the built-in abs from being used.

Re: [patch] range-ops contribution

[Jeff Law]

On 10/1/19 11:11 AM, Aldy Hernandez wrote:
> Hi folks.
> 
> Here is my official submission of the range-ops part of the ranger to
> mainline.
> 
> I realize that I could have split this patch up into 2-3 separate ones,
> but I don't want to run into the chicken-and-egg scenario of last time,
> where I had 4 inter-connected patches that were hard to review
> independently.
It might have helped a bit, but it was pretty easy to find the mapping
from bits in wide-int-range.cc into range-op.cc -- the comments were
copied :-)

> 
> A few notes that may help in reviewing.
> 
> The range-ops proper is in range-op.*.
> 
> The range.* files are separate files containing some simple auxiliary
> functions that will have irange and value_range_base counterparts.  Our
> development branch will have #define value_range_base irange, and some
> auxiliary glue, but none of that will be in trunk.  As promised, trunk
> is all value_range_base.
> 
> * The changes to tree-vrp.* are:
> 
> 1. New constructors to align the irange and value_range_base APIs.  We
> discussed this a few months ago, and these were the agreed upon changes
> to the API.
Right.

> 
> 2. Extracting the symbolic handling of PLUS/MINUS and POINTER_PLUS_EXPR
> into separate functions (extract_range_from_plus_minus_expr and
> extract_range_from_pointer_plus_expr).
In retrospect we should have broken down that function in the old vrp
code.  I suspect that function started out relatively small and just
kept expanding over time into the horrid mess that became.

THere were a number of places where you ended up pulling code from two
existing locations into a single point in range-ops.  But again, it was
just a matter of finding the multiple original source points and mapping
then into their new location in range-ops.cc, using the copied comments
as a guide.

> 
> 3. New range_fold_unary_expr and range_fold_binary_expr functions. These
> are the VRP entry point into range-ops.  They normalize symbolics and do
> some minor pre-shuffling before calling range-ops to do the actual range
> operation.
Right.  I see these as primarily an adapter between existing code and
the new range ops.

> 
> (I have some minor shuffling of these two functions that I'd like to
> post as separate clean-ups, but I didn't want to pollute this patchset
> with them: Fedora taking forever to test and all.)
Works for me.


> 5. Removing the wide-int-range.* files.  Most of the code is now
> in-lined into range-op.cc with the exception of
> wide_int_range_set_zero_nonzero_bits which has been moved into tree-vrp.c.
Right.  Largely follows from #2 above.

> 
> I think that's all!
> 
> For testing this patchset, I left the old extract_*ary_expr_code in, and
> added comparison code that trapped if there were any differences between
> what VRP was getting and what range-ops calculated.  I found no
> regressions in either a full bootstrap/tests (all languages), or with a
> full Fedora build.  As a bonus, we found quite a few cases where
> range-ops was getting better results.
So to provide a bit more info here.  We ran tests back in the spring
which resulted in various bugfixes/improvements.  Aldy asked me to
re-run with their more recent branch.  That run exposed one very clear
ranger bug which Aldy fixed prior to submitting this patch as well as
several cases where the results differed.  We verified each and every
one of them was a case where Ranger was getting better results.

> (Note: At the last minute, Jeff found one regression in the multi-day
> Fedora build.  I will fix this as a follow-up.  BTW, it does not cause
> any regressions in a bootstrap or GCC test-run, just a discrepancy on
> one specific corner case between VRP and range-ops.)
Right.  WHat happened was there was a package that failed to build due
to the Fortran front-end getting tighter in its handling of argument
checking.  Once that (and various other issues related to using a gcc-10
snapshot) was worked around I rebuilt the failing packages.  That in
turn exposed another case where ranger and vrp differed in their results
(it's a MULT+overflow case IIRC)  ANyway, I'm leaving it to you to
analyze :-)


[ ... ]

> 
> The attached patch is based off of trunk from a few weeks ago.  If
> approved, I will merge and re-test again with latest trunk.  I won't
> however, test all of Fedora :-P.
Agreed, I don't think that's necessary.  FWIW, using a month-old branch
for testing was amazingly helpful in other respects.  We found ~100
packages that need updating for gcc-10 as well as a few bugs unrelated
to Ranger.  I've actually got Sunday's snapshot spinning now and fully
expect to be spinning Fedora builds with snapshots for the next several
months.  So I don't expect a Fedora build just to test after ranger
integration, but instead that it'll "just happen" on a subsequent snapshot.

> 
> May I be so bold as to suggest that if there are minor suggestions that
> arise from this review, that they be done as follow-ups?  I'd like to
> get 

compatibility of structs/unions/enums in the middle end

[Uecker, Martin]

Hi,

I have a proposal for making changes to the rules for
compatibility of tagged types in C2X  (N2366). This was
received with interest by WG14, so there is a chance
that this could get accepted into C2X.

In particular, the idea is to make structs (+ unions, enums)
with the same tag and the same members compatible. The
current C standards says that such structs are compatible
between different TUs but not inside the same TU, which
is very strange and - as pointed out by Joseph
in DR314 - this leads to "interesting" scenarios
where types across different TU cannot be partitioned
into equivalence classes in a consistent way.

The new rules would fix these inconsistencies and also
make some useful programming patterns possible: E.g. one
could declare structs/union/enums types in a macro so
that another invocation produces a compatible type.
For example:

#define MAYBE(T) struct foo_##T { _Bool flag; T value }; 

MAYBE(int) x = { true, 0 };
MAYBE(int) y = x;


I am working on a patch for GCC which adds this as an
optional feature. So far, I have a working patch to the
C front end which changes the concept of type compatibility
to match the proposed model. It uses the existing code
for type compatibility, so is relatively simple.

The question is now how this should interact with the
middle end. So far, I have to insert some VIEW_CONVERT_EXPR
to avoid "useless type conversion" errors during gimple
verification. 

I am also wonder how to make TBAA do the right thing
for the new rules. Currently, GCC assumes 's1p' and 's2p'
cannot alias in the following example and outputs '2'
in 'f', but this would not be true anymore according
to the proposal. 


#include 

typedef struct { int i; } st1;
typedef struct { int i; } st2;

void f(void* s1v, void* s2v)
{
  st1 *s1p = s1v;
  st2 *s2p = s2v;
  s1p->i = 2;
  s2p->i = 3;
  printf("f: s1p->i = %i\n", s1p->i);
}

int main()
{
  st1 s = { .i = 1 };
  f(, );
  printf("s.i = %i\n", s.i);
}

BTW: According to current rules when 'f' is
moved into a different TU, there is no UB.
As both 'st1'
and 'st2' in one TU are compatible
to both 'st1' and 'st2' in the other TU there
is no UB. Still, GCC
incorrectly assumes that
's1p' and 's1p' do not alias.


I would appreciate any information about how to
approach this.

Best,
Martin

[Bug target/88630] Incorrect float negating together with convertion to int on SH4

[zavadovsky.yan at gmail dot com]

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

--- Comment #9 from Zavadovsky Yan  ---
>Can you try it out please and see
>if it fixes the issue on your hardware?

Checked GCC 8.2 + your patch and crosstool-ng to build toolchain(using same
config as I've used while reporting bug).

At least it works on attached main.cpp.
Got no assert when run on our STiH237-based board.

Re: [PATCH] add __has_builtin (PR 66970)

[Jakub Jelinek]

On Tue, Oct 01, 2019 at 11:16:10AM -0600, Martin Sebor wrote:
> Attached is an implementation of the __has_builtin special
> preprocessor operator/macro analogous to __has_attribute and
> (hopefully) compatible with the synonymous Clang feature (I
> couldn't actually find tests for it in the Clang test suite
> but if someone points me at them I'll verify it).

For the __builtin_*/__sync_*/__atomic_* etc. builtins whether something
is a builtin or not is quite clear, basically whether if using the right
operands for it will compile and do something.
For the library functions, what does it mean that something is a builtin
though?  In some cases we have them in the builtin tables only
to have some predefined attributes for them, in other cases because the
compiler is aware of some of their special properties, in other cases that
the compiler will sometimes optimize them into something else or inline them
and at other times keep them as a library calls, in some cases only for the
compiler to be able to emit calls to those routines in generated code,
in other cases to always optimize them/inline them and never emit the
library function (which perhaps doesn't exist).
I believe that for some builtins like stpcpy we treat them as builtins only
if we see them prototyped first.
And then for C++ with namespaces and symbol lookup rules, whether something
is or isn't a builtin depends not just on the identifier, but namespace too
and maybe argument types too.

So, what do we want __has_builtin to mean for those?

Say, do we want __has_builtin (_exit) just because we have it in the tables
to 1) add noreturn/nothrow/leaf attributes to it 2) consider it in branch
prediction heuristics, but otherwise don't do anything special with it?

Jakub

[Bug c++/88562] Incorrect pointer incrementing on SH4

[zavadovsky.yan at gmail dot com]

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

--- Comment #12 from Zavadovsky Yan  ---
I've checked this patch locally on our STiH237 hardware.
Using GCC 8.2 built by crosstool-ng.

It works!

[Bug middle-end/91957] New: [10 Regression] ICE in lra_assign building libgcc for csky-linux-gnuabiv2 soft-float

[jsm28 at gcc dot gnu.org]

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

Bug ID: 91957
   Summary: [10 Regression] ICE in lra_assign building libgcc for
csky-linux-gnuabiv2 soft-float
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: csky*-*-*

Created attachment 46988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46988=edit
preprocessed source

The function-ABI changes (r276306 is OK, r276339 fails) appear to have
introduced an ICE building libgcc for csky-linux-gnuabiv2 soft-float (configure
options: --disable-multilib).  Preprocessed source attached.  Compile with -O2.
 ICE seen with current sources (r276417) is as follows.  In the hard-float
case, libgcc builds OK but there is a similar ICE building glibc, which I guess
has the same cause so I haven't filed a separate bug for it.

/scratch/jmyers/glibc/many10/src/gcc/libgcc/libgcc2.c: In function '__mulsc3':
/scratch/jmyers/glibc/many10/src/gcc/libgcc/libgcc2.c:2030:1: internal compiler
error: in lra_assign, at lra-assigns.c:1647
 2030 | }
  | ^
0x9feabc lra_assign(bool&)
/scratch/jmyers/glibc/many10/src/gcc/gcc/lra-assigns.c:1647
0x9f9314 lra(_IO_FILE*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/lra.c:2482
0x9ad1f1 do_reload
/scratch/jmyers/glibc/many10/src/gcc/gcc/ira.c:5511
0x9ad1f1 execute
/scratch/jmyers/glibc/many10/src/gcc/gcc/ira.c:5697
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/91956] New: [10 Regression] ICE: verify_cgraph_node failed (error: comdat-local function called by __ct .isra outside its comdat)

[asolokha at gmx dot com]

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

Bug ID: 91956
   Summary: [10 Regression] ICE: verify_cgraph_node failed (error:
comdat-local function called by __ct .isra outside its
comdat)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-10.0.0-alpha20190929 snapshot (r276272) ICEs when compiling
gcc/testsuite/g++.dg/cpp0x/dc5.C w/ -Os -fno-strict-aliasing -fno-tree-fre
-fno-tree-vrp:

% g++-10.0.0-alpha20190929 -Os -fno-strict-aliasing -fno-tree-fre -fno-tree-vrp
-c gcc/testsuite/g++.dg/cpp0x/dc5.C
gcc/testsuite/g++.dg/cpp0x/dc5.C:27:1: error: comdat-local function called by
__ct .isra outside its comdat
   27 | }
  | ^
_ZN1DC4Ei.part.0/40 (D::D(int)) @0x7fd918be85a0
  Type: function definition analyzed
  Visibility: comdat_group:_ZN1DC5Ei artificial
  Same comdat group as: _ZN1DC4Ei/13
  References: _ZTT1D/18 (addr)
  Referring: 
  Availability: local
  Function flags: count:1073741824 (estimated locally) first_run:1 body local
split_part optimize_size
  Called by: __ct .isra/41 (719407024 (estimated locally),0.67 per call) 
  Calls: 
during IPA pass: sra
gcc/testsuite/g++.dg/cpp0x/dc5.C:27:1: internal compiler error:
verify_cgraph_node failed
0xb81d0d cgraph_node::verify_node()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cgraph.c:3428
0xb7543c symtab_node::verify()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/symtab.c:1268
0xb769b0 symtab_node::verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/symtab.c:1288
0xdcdf8a symtab_node::checking_verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cgraph.h:647
0xdcdf8a symbol_table::remove_unreachable_nodes(_IO_FILE*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/ipa.c:667
0xec2da4 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/passes.c:2051

[Bug c++/91953] [8/9/10 Regression] G++ rejects lambda with constexpr variable

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
template
struct integral_constant
{
  static constexpr _Tp value = __v;
  typedef _Tp value_type;
  typedef integral_constant<_Tp, __v> type;
  constexpr operator value_type() const noexcept { return value; }
  constexpr value_type operator()() const noexcept { return value; }
};
auto f = [](auto value)
{
  constexpr auto i = value;
  return i;
};

void
foo ()
{
  f (integral_constant{});
}

So, shall value be constexpr because integral_constant is an empty class?
This boils down to
struct S {};

void
foo (S s)
{
  constexpr S x = s;
}
which GCC 7 as well as clang accepted, but GCC 8+ rejects.

[Bug c/66970] Add __has_builtin() macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |10.0

--- Comment #22 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html

[PATCH] add __has_builtin (PR 66970)

[Martin Sebor]

Attached is an implementation of the __has_builtin special
preprocessor operator/macro analogous to __has_attribute and
(hopefully) compatible with the synonymous Clang feature (I
couldn't actually find tests for it in the Clang test suite
but if someone points me at them I'll verify it).

Tested on x86_64-linux.

Martin

PS I couldn't find an existing API to test whether a reserved
symbol like __builtin_offsetof is a function-like built-in so
I hardwired the tests for C and C++ into the new names_builtin_p
functions.  I don't like this very much because the next time
such an operator is added there is nothing to remind us to update
the functions.  Adding a flag to the c_common_reswords array would
solve the problem but at the expense of a linear search through
it.  Does anyone have a suggestion for how to do this better?
PR c/66970 - Add __has_builtin() macro

gcc/ChangeLog:
	PR c/66970
	* doc/cpp.texi (__has_builtin): Document.
	* doc/extend.texi (__builtin_frob_return_addr): Correct spelling.

gcc/c/ChangeLog:

	PR c/66970
	* c-decl.c (names_builtin_p): Define a new function.

gcc/c-family/ChangeLog:

	PR c/66970
	* c-common.c (c_common_nodes_and_builtins): Call c_define_builtins
	even when only preprocessing.
	* c-common.h (names_builtin_p): Declare new function.
	* c-lex.c (init_c_lex): Set has_builtin.
	(c_common_has_builtin): Define a new function.
	* c-ppoutput.c (init_pp_output): Set has_builtin.

gcc/cp/ChangeLog:

	PR c/66970
	* cp-objcp-common.c (names_builtin_p): Define new function.

gcc/testsuite/ChangeLog:

	PR c/66970
	* c-c++-common/cpp/has-builtin-2.c: New test.
	* c-c++-common/cpp/has-builtin-3.c: New test.
	* c-c++-common/cpp/has-builtin.c: New test.

libcpp/ChangeLog:

	PR c/66970
	* include/cpplib.h (cpp_builtin_type): Add BT_HAS_BUILTIN.
	(cpp_callbacks::has_builtin): Declare new member.
	* init.c (builtin_array): Add an element for BT_HAS_BUILTIN.
	(cpp_init_special_builtins): Handle BT_HAS_BUILTIN.
	* macro.c (_cpp_builtin_macro_text): Same.
	* traditional.c: Same.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 7169813d0f2..cd664566249 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -4467,8 +4467,7 @@ c_common_nodes_and_builtins (void)
   va_list_ref_type_node = build_reference_type (va_list_type_node);
 }
 
-  if (!flag_preprocess_only)
-c_define_builtins (va_list_ref_type_node, va_list_arg_type_node);
+  c_define_builtins (va_list_ref_type_node, va_list_arg_type_node);
 
   main_identifier_node = get_identifier ("main");
 
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 1e13aaa16fc..ad1bc6c3628 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -801,6 +801,7 @@ extern void c_register_addr_space (const char *str, addr_space_t as);
 extern bool in_late_binary_op;
 extern const char *c_addr_space_name (addr_space_t as);
 extern tree identifier_global_value (tree);
+extern bool names_builtin_p (const char *);
 extern tree c_linkage_bindings (tree);
 extern void record_builtin_type (enum rid, const char *, tree);
 extern tree build_void_list_node (void);
@@ -1022,6 +1023,7 @@ extern bool c_cpp_diagnostic (cpp_reader *, enum cpp_diagnostic_level,
 			  const char *, va_list *)
  ATTRIBUTE_GCC_DIAG(5,0);
 extern int c_common_has_attribute (cpp_reader *);
+extern int c_common_has_builtin (cpp_reader *);
 
 extern bool parse_optimize_options (tree, bool);
 
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index e3c602fbb8d..61ecbb23569 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -81,6 +81,7 @@ init_c_lex (void)
   cb->valid_pch = c_common_valid_pch;
   cb->read_pch = c_common_read_pch;
   cb->has_attribute = c_common_has_attribute;
+  cb->has_builtin = c_common_has_builtin;
   cb->get_source_date_epoch = cb_get_source_date_epoch;
   cb->get_suggestion = cb_get_suggestion;
   cb->remap_filename = remap_macro_filename;
@@ -385,6 +386,58 @@ c_common_has_attribute (cpp_reader *pfile)
 
   return result;
 }
+
+/* Callback for has_builtin.  */
+
+int
+c_common_has_builtin (cpp_reader *pfile)
+{
+  const cpp_token *token = get_token_no_padding (pfile);
+  if (token->type != CPP_OPEN_PAREN)
+{
+  cpp_error (pfile, CPP_DL_ERROR,
+		 "missing '(' after \"__has_builtin\"");
+  return 0;
+}
+
+  const char *name = "";
+  token = get_token_no_padding (pfile);
+  if (token->type == CPP_NAME)
+{
+  name = (const char *) cpp_token_as_text (pfile, token);
+  token = get_token_no_padding (pfile);
+  if (token->type != CPP_CLOSE_PAREN)
+	{
+	  cpp_error (pfile, CPP_DL_ERROR,
+		 "expected ')' after \"%s\"", name);
+	  name = "";
+	}
+}
+  else
+{
+  cpp_error (pfile, CPP_DL_ERROR,
+		 "macro \"__has_builtin\" requires an identifier");
+  if (token->type == CPP_CLOSE_PAREN)
+	return 0;
+}
+
+  /* Consume tokens up to the closing parenthesis, including any nested
+ pairs of parentheses, to avoid confusing redundant 

[tree-if-conv.c] Move call to ifcvt_local_dce after rpo vn

[Prathamesh Kulkarni]

Hi,
The attached patch is committed to trunk after bootstrap+test on
x86_64-unknown-linux-gnu.
Pre-approved by Richard.

Thanks,
Prathamesh
Index: ChangeLog
===
--- ChangeLog	(revision 276416)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2019-10-01  Prathamesh Kulkarni  
+
+	* tree-if-conv.c (tree_if_conversion): Move call to ifcvt_local_dce
+	after local CSE.
+
 2019-10-01  Jan Hubicka  
 
 	* doc/invoke.texi (early-inlining-insns-O2): Document.
Index: tree-if-conv.c
===
--- tree-if-conv.c	(revision 276416)
+++ tree-if-conv.c	(working copy)
@@ -3060,9 +3060,6 @@
  on-the-fly.  */
   combine_blocks (loop);
 
-  /* Delete dead predicate computations.  */
-  ifcvt_local_dce (loop->header);
-
   /* Perform local CSE, this esp. helps the vectorizer analysis if loads
  and stores are involved.  CSE only the loop body, not the entry
  PHIs, those are to be kept in sync with the non-if-converted copy.
@@ -3071,6 +3068,9 @@
   bitmap_set_bit (exit_bbs, single_exit (loop)->dest->index);
   bitmap_set_bit (exit_bbs, loop->latch->index);
   todo |= do_rpo_vn (cfun, loop_preheader_edge (loop), exit_bbs);
+
+  /* Delete dead predicate computations.  */
+  ifcvt_local_dce (loop->header);
   BITMAP_FREE (exit_bbs);
 
   todo |= TODO_cleanup_cfg;