[PATCH, committed] PR93234 INQUIRE on pre-assigned files of ROUND and SIGN properties

[Jerry]

Committed as obvious after regression testing.

The master branch has been updated by Jerry DeLisle :

https://gcc.gnu.org/g:e2947cfa2d1d4da13bb298b4f36cd745b007d88d

commit r10-6060-ge2947cfa2d1d4da13bb298b4f36cd745b007d88d
Author: Jerry DeLisle 
Date:   Fri Jan 17 19:36:03 2020 -0800

PR93234 INQUIRE on pre-assigned files of ROUND and SIGN properties

PR libfortran/93234
* io/unit.c (set_internal_unit): Set round and sign flags
correctly.

* gfortran.dg/inquire_pre.f90: New test.

Update branching and branch closing instructions for move to git.

[Joseph Myers]

update_version_svn has been replaced by update_version_git.  The
scripts directory in ~gccadmin is now a symlink into a gcc-checkout
directory.  Various commands using SVN are replaced by git commands
and instructions for updating the old git mirror are removed.
Instructions for adding a new basepoint tag are added.

Committed.

diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html
index f8a3ddfa..80e81ecd 100644
--- a/htdocs/branch-closing.html
+++ b/htdocs/branch-closing.html
@@ -16,16 +16,16 @@
 Inform the g...@gcc.gnu.org list that the branch is being
 closed.
 
-On trunk, edit IGNORE_BRANCHES
-in maintainer-scripts/update_version_svn to stop nightly
+On master, edit IGNORE_BRANCHES
+in maintainer-scripts/update_version_git to stop nightly
 version updates from touching the branch.  Remove the entry
 in maintainer-scripts/crontab that creates snapshots from
 the branch.  Optionally, remove any code
 in maintainer-scripts/gcc_release that is only relevant
 to snapshots from that branch or older branches (for example, if
 directories listed in the script were removed or renamed after that
-branch).  Check in those changes.  Run svn update in
-the scripts directory of the gccadmin account, and then
+branch).  Check in and push those changes.  Run git pull in
+the gcc-checkout directory of the gccadmin account, and then
 actually install the updated crontab there.
 
 For every open bug whose summary contains the version number of
diff --git a/htdocs/branching.html b/htdocs/branching.html
index 5eb6e73a..a9dafdd3 100644
--- a/htdocs/branching.html
+++ b/htdocs/branching.html
@@ -13,11 +13,11 @@
 Preparations
 
 
-Execute the following commands, substituting appropriate version 
+Execute the following command, in a checkout of master, substituting 
appropriate version 
 numbers:
 
 
-svn cp svn+ssh://gcc.gnu.org/svn/gcc/trunk 
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_5-branch
+git push origin master:releases/gcc-10
 
 
 
@@ -26,15 +26,12 @@ svn cp svn+ssh://gcc.gnu.org/svn/gcc/trunk 
svn+ssh://gcc.gnu.org/svn/gcc/branche
 prerelease instead of experimental.
 
 Update the file gcc/BASE-VER on the mainline, to use
-the next major release number (e.g., 3.2 instead of 3.1).
-
-Update the GIT mirror by running on gcc.gnu.org the
-following command, substituting appropriate version
-numbers:
+the next major release number (e.g., 11 instead of 10).  Immediately
+after pushing that change, create the basepoint tag for the next release:
 
 
-$ cd /git/gcc.git/.git
-$ git symbolic-ref refs/heads/gcc-4_7-branch refs/remotes/gcc-4_7-branch
+git tag -a -m "GCC 11 basepoint" basepoints/gcc-11
+git push origin tag basepoints/gcc-11
 
 
 
@@ -64,7 +61,7 @@ release branch, the current release series, and active 
development
 Update maintainer-scripts/crontab on the mainline by
 adding an entry to make snapshots of the new branch and adjusting the
 version number of the mainline snapshots.
-Run svn update in the scripts directory of
+Run git pull in the gcc-checkout directory of
 the gccadmin account, and then actually install the updated crontab
 there.
 

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

[PATCH] Fix PR 93242: patchable-function-entry broken on MIPS

[apinski]

From: Andrew Pinski 

On MIPS, .set noreorder/reorder needs to emitted around
the nop.  The template for the nop instruction uses %(/%) to
do that.  But default_print_patchable_function_entry uses
fprintf rather than output_asm_insn to output the instruction.

This fixes the problem by using output_asm_insn to emit the nop
instruction.

OK?  Bootstrapped and tested on x86_64-linux-gnu and built a full
mips toolchain also.

Thanks,
Andrew Pinski

ChangeLog:

* targhooks.c (default_print_patchable_function_entry): Use
output_asm_insn to emit the nop instruction.

Change-Id: I9d7cff2fc227a41461b9068e3af1fd3a5a9c059b
---
 gcc/targhooks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 4819bb8..415c21b 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1822,7 +1822,7 @@ default_print_patchable_function_entry (FILE *file,
 
   unsigned i;
   for (i = 0; i < patch_area_size; ++i)
-fprintf (file, "\t%s\n", nop_templ);
+output_asm_insn (nop_templ, NULL);
 }
 
 bool
-- 
1.8.3.1

[wwwdocs] Refer to Git (not SVN) to obtain current sources.

[Gerald Pfeifer]

Pushed.

Gerald
---
 htdocs/snapshots.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/snapshots.html b/htdocs/snapshots.html
index 3c491b00..80d61e27 100644
--- a/htdocs/snapshots.html
+++ b/htdocs/snapshots.html
@@ -11,7 +11,7 @@
 
 GCC Snapshots
 
-We recommend that you use SVN to access our
+We recommend that you use Git to access our
 current development sources.
 
 We also make regular snapshots available for download from our
-- 
2.24.1

Re: [PATCH] arm: fix rtl checking bootstrap (PR target/93312)

[Jeff Law]

On Fri, 2020-01-17 at 20:15 +0100, Jakub Jelinek wrote:
> Hi!
> 
> As reported in PR93312, the:
> > > > > > > * config/arm/arm.c (clear_operation_p): New function.
> change broke RTL checking bootstrap.
> 
> On the testcase from the PR (which is distilled from libgcc2.c, so I think
> we don't need to add it into testsuite) we ICE because SET_DEST (elt) is
> not a REG, but SUBREG.  The code uses REGNO on it, which is invalid, but
> only stores it into a variable, then performs REG_P (reg) check,
> determines it is not a REG and bails early.
> 
> The following patch just moves the regno variable initialization after that
> check, it isn't used in between.  And, as a small optimization, because
> reg doesn't change, doesn't use REGNO (reg) a second time to set last_regno.
> 
> Ok for trunk if it passes bootstrap/regtest?
> 
> 2020-01-17  Jakub Jelinek  
> 
>   PR target/93312
>   * config/arm/arm.c (clear_operation_p): Don't use REGNO until
>   after checking the argument is a REG.  Don't use REGNO (reg)
>   again to set last_regno, reuse regno variable instead.
OK
jeff
> 

Re: [PATCH] Fix noreorder symbol partitioning reversion.

[Jeff Law]

On Thu, 2020-01-16 at 20:43 +0100, Martin Liška wrote:
> Hi.
> 
> The patch is fixes a regression in libgcrypt package where
> we incorrectly forget to stream out a definition of a no-reorder symbol.
> It's caused by LTO balanced map reversion, where we do not revert
> also best_noreorder_pos.
> 
> It's pre-approved patch by Honza and I'm going to install it.
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Thanks,
> Martin
> 
> 
> gcc/lto/ChangeLog:
> 
> 2020-01-16  Martin Liska  
> 
>   * lto-partition.c (lto_balanced_map): Remember
>   best_noreorder_pos and then restore to it
>   when we revert.
Thank you!  That addressed several niggling failures.

jeff
> 

Re: [PATCH] testsuite: Unbreak compat.exp testing with alt compiler (PR testsuite/93294)

[Jeff Law]

On Thu, 2020-01-16 at 18:01 +0100, Jakub Jelinek wrote:
> Hi!
> 
> The PR87488 changes include:
>   * lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-urls=never.
> Unfortunately, this broke all the compat.exp etc. compatibility testing with
> alternate compilers, because those compilers (likely) don't understand this
> new option and thus all alt compilations FAIL and everything that needs it
> is then UNRESOLVED.
> 
> Fixed thusly, by handling it like -fdiagnostics-color=never and other
> similar options.
> 
> Tested on x86_64-linux, ok for trunk?
> 
> 2020-01-16  Jakub Jelinek  
> 
>   PR testsuite/93294
>   * lib/c-compat.exp (compat-use-alt-compiler): Handle
>   -fdiagnostics-urls=never similarly to -fdiagnostics-color=never.
>   (compat_setup_dfp): Likewise.
OK
jeff
> 

[PATCH] Fix target/93119 (aarch64): ICE with traditional TLS support on ILP32

[apinski]

From: Andrew Pinski 

The problem here was g:23b88fda665d2f995c was not a complete fix
for supporting tranditional TLS on ILP32.

So the problem here is a couple of things, first __tls_get_addr
call will return a C pointer value so we need to use ptr_mode
when we are creating the call.  Then we need to convert
back that register to the correct mode, either zero extending
it or just creating a move instruction.
Also symbol_ref can either be in SImode or DImode.  So we need to
allow both modes.

Built and tested on aarch64-linux-gnu with no regressions.
Also built a full toolchain (including glibc) defaulting to traditional
TLS that targets ilp32 and lp64.

OK?

Thanks,
Andrew Pinski

ChangeLog:
* config/aarch64/aarch64.md (tlsgd_small_): Have operand 0 as PTR mode.
Have operand 1 as being modeless, it can be P mode.
(*tlsgd_small_): Likewise.
* config/aarch64/aarch64.c (aarch64_load_symref_appropriately)
: Call gen_tlsgd_small_* with a ptr_mode
register.  Convert that register back to dest using convert_mode.

Change-Id: I76826350d6bace0b731f21df1f125e9122da843f
---
 gcc/config/aarch64/aarch64.c   | 18 ++
 gcc/config/aarch64/aarch64.md  |  8 
 gcc/testsuite/gcc.target/aarch64/pr93119.c | 10 ++
 3 files changed, 28 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr93119.c

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c26ac0db942..6c825459dc6 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2607,19 +2607,29 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
 case SYMBOL_SMALL_TLSGD:
   {
rtx_insn *insns;
-   machine_mode mode = GET_MODE (dest);
-   rtx result = gen_rtx_REG (mode, R0_REGNUM);
+   /* The return type of __tls_get_addr is the C pointer type
+  so use ptr_mode.  */
+   rtx result = gen_rtx_REG (ptr_mode, R0_REGNUM);
+   rtx tmp_reg = dest;
+
+   if (GET_MODE (dest) != ptr_mode)
+ tmp_reg = can_create_pseudo_p () ? gen_reg_rtx (ptr_mode) : result;
 
start_sequence ();
-   if (TARGET_ILP32)
+   if (ptr_mode == SImode)
  aarch64_emit_call_insn (gen_tlsgd_small_si (result, imm));
else
  aarch64_emit_call_insn (gen_tlsgd_small_di (result, imm));
+
insns = get_insns ();
end_sequence ();
 
RTL_CONST_CALL_P (insns) = 1;
-   emit_libcall_block (insns, dest, result, imm);
+   emit_libcall_block (insns, tmp_reg, result, imm);
+   /* Convert back to the mode of the dest, adding a zero-extend as
+  needed. */
+   if (dest != tmp_reg)
+ convert_move (dest, tmp_reg, true);
return;
   }
 
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 86c2cdfc797..55dde54b16a 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -6755,10 +6755,10 @@ (define_insn "aarch64_load_tp_hard"
 ;; instructions in the TLS stubs, in order to enable linker relaxation.
 ;; Therefore we treat the stubs as an atomic sequence.
 (define_expand "tlsgd_small_"
- [(parallel [(set (match_operand 0 "register_operand")
+ [(parallel [(set (match_operand:PTR 0 "register_operand")
   (call (mem:DI (match_dup 2)) (const_int 1)))
 (unspec:DI [(const_int 0)] UNSPEC_CALLEE_ABI)
-(unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref")] 
UNSPEC_GOTSMALLTLS)
+(unspec:DI [(match_operand 1 "aarch64_valid_symref")] 
UNSPEC_GOTSMALLTLS)
 (clobber (reg:DI LR_REGNUM))])]
  ""
 {
@@ -6766,10 +6766,10 @@ (define_expand "tlsgd_small_"
 })
 
 (define_insn "*tlsgd_small_"
-  [(set (match_operand 0 "register_operand" "")
+  [(set (match_operand:PTR 0 "register_operand" "")
(call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
(unspec:DI [(const_int 0)] UNSPEC_CALLEE_ABI)
-   (unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "S")] 
UNSPEC_GOTSMALLTLS)
+   (unspec:DI [(match_operand 1 "aarch64_valid_symref" "S")] 
UNSPEC_GOTSMALLTLS)
(clobber (reg:DI LR_REGNUM))
   ]
   ""
diff --git a/gcc/testsuite/gcc.target/aarch64/pr93119.c 
b/gcc/testsuite/gcc.target/aarch64/pr93119.c
new file mode 100644
index 000..93fa80e10b6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr93119.c
@@ -0,0 +1,10 @@
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-mtls-dialect=trad -fpic" } */
+
+__thread int g_tlsdata;
+
+int func1()
+{
+  g_tlsdata++;
+  return g_tlsdata;
+}
-- 
2.17.1

[PATCH] ipa-profile.c: reset call_sums state within ipa-profile.c (PR ipa/93315)

[David Malcolm]

> > On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote:
> > On 2020/1/10 19:08, Jan Hubicka wrote:
> > > OK. You will need to do the obvious updates for Martin's patch
> > > which turned some member functions into static functions.
> > > 
> > > Honza
> > 
> > Thanks a lot!  Rebased & updated, will commit below patch shortly
> > when git push is ready.
> > 
> > 
> > v8:
> >  1. Rebase to master with Martin's static function (r280043) comments
> > merge.
> > Boostrap/testsuite/SPEC2017 tested pass on Power8-LE.
> >  2. TODO:
> > 2.1. C++ devirt for multiple speculative call targets.
> > 2.2. ipa-icf ipa_merge_profiles refine with COMDAT inline
> > testcase.
> 
> [...]
> 
> > diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
> 
> [...]
> 
> > +static ipa_profile_call_summaries *call_sums = NULL;
> 
> [...]
>  
> >  static void
> >  ipa_profile_generate_summary (void)
> > @@ -169,7 +261,10 @@ ipa_profile_generate_summary (void)
> >basic_block bb;
> >  
> >hash_table hashtable (10);
> > -  
> > +
> > +  gcc_checking_assert (!call_sums);
> > +  call_sums = new ipa_profile_call_summaries (symtab);
> > +
> 
> [...]
> 
> Unfortunately, this assertion is failing for most of the testcases in
> jit.dg, reducing the number of PASS results in jit.sum from 10473 down
> to 3254 in my builds.
> 
> 
> Counter-intuitively, "jit" is not in --enable-languages=all (as it also
> needs --enable-host-shared at configure time, which slows down the
> built compiler code).
> 
> 
> The jit code expects to be able to invoke the compiler code more than
> once within the same process, purging all state.
> 
> It looks like this "call_sums" state needs deleting and resetting to
> NULL after the compiler has run (or else we'll likely get an ICE due to
> using old symtab/call summaries in subsequent in-process runs of the
> compiler).
> 
> Is there a natural place to do that within the IPA hooks?  
> 
> 
> Alternatively the following patch seems to fix things (not yet fully
> tested though); hopefully it seems sane.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; fixes
the issue with jit.sum.

OK for master?

gcc/ChangeLog:
PR ipa/93315
* ipa-profile.c (ipa_profile_c_finalize): New function.
* toplev.c (toplev::finalize): Call it.
* toplev.h (ipa_profile_c_finalize): New decl.
---
 gcc/ipa-profile.c | 10 ++
 gcc/toplev.c  |  1 +
 gcc/toplev.h  |  2 ++
 3 files changed, 13 insertions(+)

diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index 03272f20987..5f7621b1432 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -1070,3 +1070,13 @@ make_pass_ipa_profile (gcc::context *ctxt)
 {
   return new pass_ipa_profile (ctxt);
 }
+
+/* Reset all state within ipa-profile.c so that we can rerun the compiler
+   within the same process.  For use by toplev::finalize.  */
+
+void
+ipa_profile_c_finalize ()
+{
+  delete call_sums;
+  call_sums = NULL;
+}
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 4c8be502c71..ca0515583c7 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -2453,6 +2453,7 @@ toplev::finalize (void)
   this_target_rtl->target_specific_initialized = false;
 
   /* Needs to be called before cgraph_c_finalize since it uses symtab.  */
+  ipa_profile_c_finalize ();
   ipa_reference_c_finalize ();
   ipa_fnsummary_c_finalize ();
 
diff --git a/gcc/toplev.h b/gcc/toplev.h
index d6c316962b0..10611691608 100644
--- a/gcc/toplev.h
+++ b/gcc/toplev.h
@@ -103,4 +103,6 @@ extern void parse_alignment_opts (void);
 
 extern void initialize_rtl (void);
 
+extern void ipa_profile_c_finalize (void);
+
 #endif /* ! GCC_TOPLEV_H */
-- 
2.21.0

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

[Steve Kargl]

On Fri, Jan 17, 2020 at 11:20:06PM +0100, Thomas Koenig wrote:
> Am 17.01.20 um 15:42 schrieb Steve Kargl:
> > Gfortran probably should not try to guess what the user
> > thought s/he wanted.  The generic "Syntax error" would
> > seem to apply here.  To me, foo(1)%a looks much more like
> > an array reference rather than a function reference.
> 
> OK, so here's a patch which does just that.
> 
> The error message low looks like
> 
> function_reference_1.f90:9:8:
> 
>  9 | print *, foo(1)%a ! { dg-error "Syntax error" }
>|1
> Error: Syntax error in expression at (1)
> 
> The location information is a bit off, but in the absence of location
> information for the reference (which we do not collect), I think this
> is the best I can do.
> 
> So, OK for trunk (with the old ChangeLog)?
> 

It's fine with me.  May want to give Tobias a chance to comment.

> +  if (expr->ref)
> +{
> +  gfc_error ("Syntax error in expression at %L", >where);

I assume that %C puts the locus at the end of the line.  I haven't
spent to much time trying to understand expressions in an output IO
list, but as you state, it seems that gfortran loose the locus.

-- 
Steve

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

[Thomas Koenig]

Am 17.01.20 um 15:42 schrieb Steve Kargl:

Gfortran probably should not try to guess what the user
thought s/he wanted.  The generic "Syntax error" would
seem to apply here.  To me, foo(1)%a looks much more like
an array reference rather than a function reference.


OK, so here's a patch which does just that.

The error message low looks like

function_reference_1.f90:9:8:

9 | print *, foo(1)%a ! { dg-error "Syntax error" }
  |1
Error: Syntax error in expression at (1)

The location information is a bit off, but in the absence of location
information for the reference (which we do not collect), I think this
is the best I can do.

So, OK for trunk (with the old ChangeLog)?

Regards

Thomas
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6f2a4c4d65a..a846677b770 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -3129,6 +3129,12 @@ resolve_function (gfc_expr *expr)
 	  || sym->intmod_sym_id == GFC_ISYM_CAF_SEND))
 return true;
 
+  if (expr->ref)
+{
+  gfc_error ("Syntax error in expression at %L", >where);
+  return false;
+}
+
   if (sym && sym->attr.intrinsic
   && !gfc_resolve_intrinsic (sym, >where))
 return false;
diff --git a/gcc/testsuite/gfortran.dg/function_reference_1.f90 b/gcc/testsuite/gfortran.dg/function_reference_1.f90
new file mode 100644
index 000..1b7f4809c5c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/function_reference_1.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR 44960 - this was erroneusly accepted.
+! Original test case by Daniel Franke.
+
+type t
+  integer :: a
+end type t
+type(t) :: foo
+print *, foo(1)%a ! { dg-error "Syntax error" }
+end
+
! { dg-do compile }
! PR 44960 - this was erroneusly accepted.
! Original test case by Daniel Franke.

type t
  integer :: a
end type t
type(t) :: foo
print *, foo(1)%a ! { dg-error "Syntax error" }
end

Re: [PATCH] analyzer: fix pattern-test-2.c (PR 93291)

[Jakub Jelinek]

On Fri, Jan 17, 2020 at 05:01:24PM -0500, David Malcolm wrote:
> Is there a way to force the use of this optimization at -O2, or is it
> always going to be target dependent?

You could try --param logical-op-non-short-circuit=0 ,
--param logical-op-non-short-circuit=1 and/or -mbranch-cost= (the last one
only on selected targets that do support that option).

Jakub

[PATCH] RFC: testsuite: add minimium version to dg-require-dot (PR analyzer/93293)

[David Malcolm]

I ran into difficulties with the Graphviz format changing from under
me during an upgrade, where the new version of "dot" would reject .dot
files generated by the analyzer.

The analyzer testsuite has a dot-output.c test that attempts to check
that the generated .dot can be handled by dot, with a dg-require-dot
gating the test.

Unfortunately older versions of dot can't handle the newer generated
output, leading to FAILs from the test.

(I'm also not convinced that newer graphviz versions can always
handle the output from the other passes)

I'd like to automatically verify that the dot output is actually
viewable.

The following patch attempts to add version-checking to dg-require-dot,
rejecting the test as unsupported if dot on the host is earlier than
version 2.40

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, FWIW.

But presumably I should do some kind of feature-testing rather than
version-testing.  I don't think I can embed the .dot input into a dg
directive.  Perhaps have dg-require-dot be passed a relative path to a
feature-test .dot file in the testsuite source directory, and if it can
handle that, then dg-require-dot returns 1 and allows the test to occur?

Thoughts?

gcc/testsuite/ChangeLog:
PR analyzer/93293
* gcc.dg/analyzer/dot-output.c (dg-require-dot): Add "2.40" to
argument.
* lib/target-supports-dg.exp (dg-require-dot): Add argument.
* lib/target-supports.exp (parse_version_string): New.
(check_dot_available): Add args and parse them for a minimum
required version.  Attempt to parse the output of dot -V.
Compare them.
---
 gcc/testsuite/gcc.dg/analyzer/dot-output.c |  2 +-
 gcc/testsuite/lib/target-supports-dg.exp   |  5 +-
 gcc/testsuite/lib/target-supports.exp  | 67 +-
 3 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/dot-output.c 
b/gcc/testsuite/gcc.dg/analyzer/dot-output.c
index 25cb31f2d89..628bbda8d34 100644
--- a/gcc/testsuite/gcc.dg/analyzer/dot-output.c
+++ b/gcc/testsuite/gcc.dg/analyzer/dot-output.c
@@ -1,7 +1,7 @@
 /* Verify that the various .dot output files from the analyzer are readable
by .dot.  */
 
-/* { dg-require-dot "" } */
+/* { dg-require-dot "2.40" } */
 /* { dg-additional-options "-fdump-analyzer-callgraph 
-fdump-analyzer-exploded-graph -fdump-analyzer-state-purge 
-fdump-analyzer-supergraph" } */
 
 #include 
diff --git a/gcc/testsuite/lib/target-supports-dg.exp 
b/gcc/testsuite/lib/target-supports-dg.exp
index 2a21424b890..8bee84975cb 100644
--- a/gcc/testsuite/lib/target-supports-dg.exp
+++ b/gcc/testsuite/lib/target-supports-dg.exp
@@ -180,11 +180,12 @@ proc dg-require-iconv { args } {
 }
 }
 
-# If this host does not have "dot", skip this test.
+# If this host does not have "dot", with a minimum version
+# of at least REQ_MAJOR.REQ_MINOR, skip this test.
 
 proc dg-require-dot { args } {
 verbose "dg-require-dot" 2
-if { ![ check_dot_available ] } {
+if { ![ check_dot_available $args ] } {
upvar dg-do-what dg-do-what
 set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
 }
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 79166986c77..b527d30e8a7 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -514,17 +514,78 @@ proc check_gc_sections_available { } {
 }]
 }
 
-# Returns 1 if "dot" is supported on the host.
+# Attempt to parse STR as a major.minor pair.
+# Return in list form as a major.minor pair, or throw an exception
+
+proc parse_version_string { str } {
+if { [regexp {([0-9]*)\.([0-9]*)} $str match major minor] } {
+   verbose "major: $major" 3
+   verbose "minor: $minor" 3
+   lappend result $major $minor
+   return $result
+} else {
+   error "unable to parse version $str"
+}
+}
 
-proc check_dot_available { } {
+# Returns 1 if "dot" is supported on the host, with a minimum version
+# of at least "REQ_MAJOR.REQ_MINOR"
+
+proc check_dot_available { args } {
 verbose "check_dot_available" 2
+verbose "  args: $args" 3
+set req_version_str [lindex [lindex $args 0] 1]
+verbose "  req_version_str: $req_version_str" 3
+if { [catch { set req_version [parse_version_string $req_version_str] } ] 
} {
+   verbose "unable to determine required dot version" 2
+   return 0
+} else {
+   set req_major [lindex $req_version 0]
+   set req_minor [lindex $req_version 1]
+}
+verbose "  req_version: $req_version" 3
+verbose "  req_major: $req_major" 3
+verbose "  req_minor: $req_minor" 3
 
 set status [remote_exec host "dot" "-V"]
 verbose "  status: $status" 2
 if { [lindex $status 0] != 0 } {
return 0
 }
-return 1
+set dot_output [lindex $status 1]
+verbose "  dot_output: $dot_output" 3
+
+# Attempt to parse the dot version into major and minor components.

[PATCH] analyzer: fix pattern-test-2.c (PR 93291)

[David Malcolm]

Amongst the inputs to the analyzer state machines that can lead to state
transitions are conditions on CFG edges, such as a test for a pointer
being non-NULL.

These conditionals can be non-trivial to determine in the face of
optimization.  For example, at -O2:

  if (p == NULL || q == NULL)

is optimized on some targets (e.g. x86_64) to a bitwise-or:

  _1 = p_5(D) == 0B;
  _2 = q_6(D) == 0B;
  _3 = _1 | _2;
  if (_3 != 0)
goto ; [51.12%]
  else
goto ; [48.88%]

but on other targets (e.g. powerpc64le) as control flow:

  if (p_2(D) == 0B)
goto ; [18.09%]
  else
goto ; [81.91%]

   [local count: 879501929]:
  if (q_3(D) == 0B)
goto ; [30.95%]
  else
goto ; [69.05%]

region_model::add_any_constraints_from_ssa_def_stmt attempts to walk
SSA def chains to reconstruct the conditions that hold, so that
e.g. in the above case of bitwise-or, the state machine for
"p" can transition to the "known-null" state along the edge leading
to bb 3.

In gcc.dg/analyzer/pattern-test-2.c I attempted to write test coverage
for this, but the test fails on those targets for which the || is
expressed via control flow.

Is there a way to force the use of this optimization at -O2, or is it
always going to be target dependent?

This patch rewrites the test to make explicit use of bitwise-or, and
adds coverage for bitwise-and for good measure.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for master?

gcc/testsuite/ChangeLog:
PR analyzer/93291
* gcc.dg/analyzer/pattern-test-2.c: Remove include of stdlib.h.
(test_2): Rewrite to explicitly perform a bitwise-or of two
boolean conditions.
(test_3): New function, to test bitwise-and.
---
 .../gcc.dg/analyzer/pattern-test-2.c  | 30 +--
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c 
b/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c
index ffc06a2f87a..f5424f526f7 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c
@@ -1,8 +1,6 @@
 /* { dg-additional-options "-fanalyzer-checker=pattern-test -O2" } */
 // TODO: run this at every optimization level
 
-#include 
-
 extern void foo(void *);
 extern void bar(void *);
 
@@ -18,12 +16,38 @@ void test1(void *ptr)
 
 void test_2 (void *p, void *q)
 {
-  if (p == NULL || q == NULL) /* { dg-line cond_2 }  */
+  _Bool tmp1 = p == 0;
+  _Bool tmp2 = q == 0;
+  _Bool tmp = tmp1 | tmp2;
+
+  /* Verify that we can detect the implied conditions on p and q here.  */
+  if (tmp) /* { dg-line cond_2 }  */
 return;
   foo(p);
 
+  /* { dg-warning "pattern match on 'tmp1 == 0'" "tmp1 == 0" { target *-*-* } 
cond_2 } */
+  /* { dg-warning "pattern match on 'tmp2 == 0'" "tmp2 == 0" { target *-*-* } 
cond_2 } */
   /* { dg-warning "pattern match on ' == 0'" " == 0" { 
target *-*-* } cond_2 } */
   /* { dg-warning "pattern match on ' != 0'" " != 0" { 
target *-*-* } cond_2 } */
   /* { dg-warning "pattern match on 'p != 0'" "p != 0" { target *-*-* } cond_2 
} */
   /* { dg-warning "pattern match on 'q != 0'" "q != 0" { target *-*-* } cond_2 
} */
 }
+
+void test_3 (void *p, void *q)
+{
+  _Bool tmp1 = p == 0;
+  _Bool tmp2 = q == 0;
+  _Bool tmp = tmp1 & tmp2;
+
+  /* Verify that we can detect the implied conditions on p and q here.  */
+  if (tmp) /* { dg-line cond_3 }  */
+return;
+  foo(p);
+
+  /* { dg-warning "pattern match on 'tmp1 != 0'" "tmp1 != 0" { target *-*-* } 
cond_3 } */
+  /* { dg-warning "pattern match on 'tmp2 != 0'" "tmp2 != 0" { target *-*-* } 
cond_3 } */
+  /* { dg-warning "pattern match on ' == 0'" " == 0" { 
target *-*-* } cond_3 } */
+  /* { dg-warning "pattern match on ' != 0'" " != 0" { 
target *-*-* } cond_3 } */
+  /* { dg-warning "pattern match on 'p == 0'" "p == 0" { target *-*-* } cond_3 
} */
+  /* { dg-warning "pattern match on 'q == 0'" "q == 0" { target *-*-* } cond_3 
} */
+}
-- 
2.21.0

[PATCH] analyzer: introduce namespace to avoid ODR clashes (PR 93307)

[David Malcolm]

PR analyzer/93307 reports that in an LTO bootstrap, there are ODR
violations between:
- the "region" type:
gcc/analyzer/region-model.h:792
  vs:
gcc/sched-int.h:1443
- the "constraint" type:
gcc/analyzer/constraint-manager.h:121
  vs:
gcc/tree-ssa-structalias.c:533

This patches solves this clash by putting all of the analyzer names
within a namespace.  I chose "ana" as it is short (to save typing).
The analyzer selftests are moved from namespace "selftest" to
"ana::selftest".

There are various places where the namespace has to be closed
and reopened, to allow e.g. for specializations of templates
in the global namespace.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for master?

gcc/analyzer/ChangeLog:
PR analyzer/93307
* analysis-plan.h: Wrap everything namespace "ana".
* analyzer-logging.cc: Likewise.
* analyzer-logging.h: Likewise.
* analyzer-pass.cc (pass_analyzer::execute): Update for "ana"
namespace.
* analyzer-selftests.cc: Wrap everything namespace "ana".
* analyzer-selftests.h: Likewise.
* analyzer.h: Likewise for forward decls of types.
* call-string.h: Likewise.
* checker-path.cc: Likewise.
* checker-path.h: Likewise.
* constraint-manager.cc: Likewise.
* constraint-manager.h: Likewise.
* diagnostic-manager.cc: Likewise.
* diagnostic-manager.h: Likewise.
* engine.cc: Likewise.
* engine.h: Likewise.
* exploded-graph.h: Likewise.
* function-set.cc: Likewise.
* function-set.h: Likewise.
* pending-diagnostic.cc: Likewise.
* pending-diagnostic.h: Likewise.
* program-point.cc: Likewise.
* program-point.h: Likewise.
* program-state.cc: Likewise.
* program-state.h: Likewise.
* region-model.cc: Likewise.
* region-model.h: Likewise.
* sm-file.cc: Likewise.
* sm-malloc.cc: Likewise.
* sm-pattern-test.cc: Likewise.
* sm-sensitive.cc: Likewise.
* sm-signal.cc: Likewise.
* sm-taint.cc: Likewise.
* sm.cc: Likewise.
* sm.h: Likewise.
* state-purge.h: Likewise.
* supergraph.cc: Likewise.
* supergraph.h: Likewise.

gcc/ChangeLog:
PR analyzer/93307
* gdbinit.in (break-on-saved-diagnostic): Update for move of
diagnostic_manager into "ana" namespace.
* selftest-run-tests.c (selftest::run_tests): Update for move of
selftest::run_analyzer_selftests to
ana::selftest::run_analyzer_selftests.
---
 gcc/analyzer/analysis-plan.h   |  4 ++
 gcc/analyzer/analyzer-logging.cc   |  4 ++
 gcc/analyzer/analyzer-logging.h|  4 ++
 gcc/analyzer/analyzer-pass.cc  |  2 +-
 gcc/analyzer/analyzer-selftests.cc |  4 ++
 gcc/analyzer/analyzer-selftests.h  |  6 ++-
 gcc/analyzer/analyzer.h|  5 ++
 gcc/analyzer/call-string.h |  4 ++
 gcc/analyzer/checker-path.cc   |  4 ++
 gcc/analyzer/checker-path.h|  4 ++
 gcc/analyzer/constraint-manager.cc |  4 ++
 gcc/analyzer/constraint-manager.h  |  4 ++
 gcc/analyzer/diagnostic-manager.cc |  4 ++
 gcc/analyzer/diagnostic-manager.h  |  4 ++
 gcc/analyzer/engine.cc | 12 +
 gcc/analyzer/engine.h  |  4 ++
 gcc/analyzer/exploded-graph.h  |  4 ++
 gcc/analyzer/function-set.cc   |  4 ++
 gcc/analyzer/function-set.h|  4 ++
 gcc/analyzer/pending-diagnostic.cc |  4 ++
 gcc/analyzer/pending-diagnostic.h  |  4 ++
 gcc/analyzer/program-point.cc  |  4 ++
 gcc/analyzer/program-point.h   |  4 ++
 gcc/analyzer/program-state.cc  |  4 ++
 gcc/analyzer/program-state.h   |  8 +++
 gcc/analyzer/region-model.cc   |  8 +++
 gcc/analyzer/region-model.h| 80 ++
 gcc/analyzer/sm-file.cc|  4 ++
 gcc/analyzer/sm-malloc.cc  |  4 ++
 gcc/analyzer/sm-pattern-test.cc|  4 ++
 gcc/analyzer/sm-sensitive.cc   |  4 ++
 gcc/analyzer/sm-signal.cc  |  4 ++
 gcc/analyzer/sm-taint.cc   |  4 ++
 gcc/analyzer/sm.cc |  4 ++
 gcc/analyzer/sm.h  |  4 ++
 gcc/analyzer/state-purge.h |  4 ++
 gcc/analyzer/supergraph.cc |  4 ++
 gcc/analyzer/supergraph.h  | 26 ++
 gcc/gdbinit.in |  4 +-
 gcc/selftest-run-tests.c   |  2 +-
 40 files changed, 268 insertions(+), 5 deletions(-)

diff --git a/gcc/analyzer/analysis-plan.h b/gcc/analyzer/analysis-plan.h
index a44c79561be..79030bae382 100644
--- a/gcc/analyzer/analysis-plan.h
+++ b/gcc/analyzer/analysis-plan.h
@@ -21,6 +21,8 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_ANALYZER_ANALYSIS_PLAN_H
 #define GCC_ANALYZER_ANALYSIS_PLAN_H
 
+namespace ana {
+
 /* A class to encapsulate decisions about how the analysis should happen.
Examples:
- the order in which functions should be analyzed, so that function
@@ 

[committed] analyzer: prevent ICE on isnan (PR 93290)

[David Malcolm]

PR analyzer/93290 reports an ICE on calls to isnan().
The root cause is that an UNORDERED_EXPR is passed
to region_model::eval_condition_without_cm, and there's
a stray gcc_unreachable () in the case where we're comparing
an svalue against itself.

I attempted a more involved patch that properly handled NaN in general
but it seems I've baked the assumption of reflexivity too deeply into
the constraint_manager code.

For now, this patch avoids the ICE and documents the limitation.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Pushed to master as 07c86323a199ca15177d99ad6c488b8f5fb5c729.

gcc/analyzer/ChangeLog:
PR analyzer/93290
* region-model.cc (region_model::eval_condition_without_cm): Avoid
gcc_unreachable for unexpected operations for the case where
we're comparing an svalue against itself.

gcc/ChangeLog
* doc/analyzer.texi (Limitations): Add note about NaN.

gcc/testsuite/ChangeLog:
PR analyzer/93290
* gcc.dg/analyzer/pr93290.c: New test.
---
 gcc/analyzer/region-model.cc| 10 ++
 gcc/doc/analyzer.texi   |  3 +++
 gcc/testsuite/gcc.dg/analyzer/pr93290.c |  9 +
 3 files changed, 18 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr93290.c

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index f67572e2d45..1e0be312e03 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -5189,13 +5189,11 @@ region_model::eval_condition_without_cm (svalue_id 
lhs_sid,
 {
   if (lhs == rhs)
{
- /* If we have the same svalue, then we have equality.
+ /* If we have the same svalue, then we have equality
+(apart from NaN-handling).
 TODO: should this definitely be the case for poisoned values?  */
  switch (op)
{
-   default:
- gcc_unreachable ();
-
case EQ_EXPR:
case GE_EXPR:
case LE_EXPR:
@@ -5205,6 +5203,10 @@ region_model::eval_condition_without_cm (svalue_id 
lhs_sid,
case GT_EXPR:
case LT_EXPR:
  return tristate::TS_FALSE;
+
+   default:
+ /* For other ops, use the logic below.  */
+ break;
}
}
 
diff --git a/gcc/doc/analyzer.texi b/gcc/doc/analyzer.texi
index b4e9b01da2e..81acdd8998b 100644
--- a/gcc/doc/analyzer.texi
+++ b/gcc/doc/analyzer.texi
@@ -388,6 +388,9 @@ The implementation of call summaries is currently very 
simplistic.
 @item
 Lack of function pointer analysis
 @item
+The constraint-handling code assumes reflexivity in some places
+(that values are equal to themselves), which is not the case for NaN.
+@item
 The region model code creates lots of little mutable objects at each
 @code{region_model} (and thus per @code{exploded_node}) rather than
 sharing immutable objects and having the mutable state in the
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr93290.c 
b/gcc/testsuite/gcc.dg/analyzer/pr93290.c
new file mode 100644
index 000..fa35629d955
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr93290.c
@@ -0,0 +1,9 @@
+#include 
+
+int test_1 (void)
+{
+  float foo = 42.;
+  if (isnan (foo))
+return 1;
+  return 0;
+}
-- 
2.21.0

[wwwdocs] Fix up formatting of one sentence in the main Fortran page.

[Gerald Pfeifer]

Pushed.

Gerald
---
 htdocs/fortran/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/fortran/index.html b/htdocs/fortran/index.html
index 42012ddc..7b6aa805 100644
--- a/htdocs/fortran/index.html
+++ b/htdocs/fortran/index.html
@@ -30,7 +30,7 @@ this to attract a diverse team of developers and to ensure 
that GFortran
 works on multiple architectures and diverse environments.  We always need
 more help.  If you are interested in participating, please contact us at
 mailto:fort...@gcc.gnu.org;>fort...@gcc.gnu.org.
-(Also check out our mailing lists page)
+(Also check out our mailing lists page.)
 
 The Wiki and Getting the Compiler
 
-- 
2.24.1

[PATCH] analyzer: ensure that all DejaGnu tests have unique names

[David Malcolm]

DejaGnu test directives such as dg-warning support an optional
"comment" argument for disambiguating multiple tests on the same line.

Jeff noticed various name collisions of test names in the analyzer
testsuite, due to me using empty comment strings when using line
offsets in test directives.

This patch adds non-empty comment strings to such DejaGnu directives
throughout the analyzer testsuite.

I verified that test names are unique in the gcc.sum file after this
patch via a script.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for master?

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c: Ensure that all
test names are unique.
* gcc.dg/analyzer/attribute-nonnull.c: Likewise.
* gcc.dg/analyzer/conditionals-notrans.c: Likewise.
* gcc.dg/analyzer/data-model-1.c: Likewise.
* gcc.dg/analyzer/data-model-18.c: Likewise.
* gcc.dg/analyzer/data-model-8.c: Likewise.
* gcc.dg/analyzer/data-model-9.c: Likewise.
* gcc.dg/analyzer/file-1.c: Likewise.
* gcc.dg/analyzer/file-paths-1.c: Likewise.
* gcc.dg/analyzer/loop-2.c: Likewise.
* gcc.dg/analyzer/loop-2a.c: Likewise.
* gcc.dg/analyzer/loop-4.c: Likewise.
* gcc.dg/analyzer/loop.c: Likewise.
* gcc.dg/analyzer/malloc-1.c: Likewise.
* gcc.dg/analyzer/malloc-2.c: Likewise.
* gcc.dg/analyzer/malloc-ipa-10.c: Likewise.
* gcc.dg/analyzer/malloc-ipa-2.c: Likewise.
* gcc.dg/analyzer/malloc-macro-separate-events.c: Likewise.
* gcc.dg/analyzer/malloc-paths-1.c: Likewise.
* gcc.dg/analyzer/malloc-paths-2.c: Likewise.
* gcc.dg/analyzer/malloc-paths-3.c: Likewise.
* gcc.dg/analyzer/malloc-paths-4.c: Likewise.
* gcc.dg/analyzer/malloc-paths-5.c: Likewise.
* gcc.dg/analyzer/malloc-paths-7.c: Likewise.
* gcc.dg/analyzer/malloc-paths-9.c: Likewise.
* gcc.dg/analyzer/operations.c: Likewise.
* gcc.dg/analyzer/params.c: Likewise.
* gcc.dg/analyzer/pattern-test-1.c: Likewise.
* gcc.dg/analyzer/pattern-test-2.c: Likewise.
* gcc.dg/analyzer/sensitive-1.c: Likewise.
* gcc.dg/analyzer/switch.c: Likewise.
* gcc.dg/analyzer/taint-1.c: Likewise.
* gcc.dg/analyzer/unknown-fns.c: Likewise.
---
 .../analyzer/CVE-2005-1689-dedupe-issue.c |   4 +-
 .../gcc.dg/analyzer/attribute-nonnull.c   |  16 +--
 .../gcc.dg/analyzer/conditionals-notrans.c|  60 +-
 gcc/testsuite/gcc.dg/analyzer/data-model-1.c  | 104 +-
 gcc/testsuite/gcc.dg/analyzer/data-model-18.c |   4 +-
 gcc/testsuite/gcc.dg/analyzer/data-model-8.c  |   4 +-
 gcc/testsuite/gcc.dg/analyzer/data-model-9.c  |   8 +-
 gcc/testsuite/gcc.dg/analyzer/file-1.c|  12 +-
 gcc/testsuite/gcc.dg/analyzer/file-paths-1.c  |   8 +-
 gcc/testsuite/gcc.dg/analyzer/loop-2.c|   4 +-
 gcc/testsuite/gcc.dg/analyzer/loop-2a.c   |  14 +--
 gcc/testsuite/gcc.dg/analyzer/loop-4.c|  12 +-
 gcc/testsuite/gcc.dg/analyzer/loop.c  |  16 +--
 gcc/testsuite/gcc.dg/analyzer/malloc-1.c  |   4 +-
 gcc/testsuite/gcc.dg/analyzer/malloc-2.c  |   8 +-
 gcc/testsuite/gcc.dg/analyzer/malloc-ipa-10.c |  14 +--
 gcc/testsuite/gcc.dg/analyzer/malloc-ipa-2.c  |  14 +--
 .../analyzer/malloc-macro-separate-events.c   |   6 +-
 .../gcc.dg/analyzer/malloc-paths-1.c  |   8 +-
 .../gcc.dg/analyzer/malloc-paths-2.c  |   6 +-
 .../gcc.dg/analyzer/malloc-paths-3.c  |   6 +-
 .../gcc.dg/analyzer/malloc-paths-4.c  |  12 +-
 .../gcc.dg/analyzer/malloc-paths-5.c  |  18 +--
 .../gcc.dg/analyzer/malloc-paths-7.c  |   4 +-
 .../gcc.dg/analyzer/malloc-paths-9.c  |   4 +-
 gcc/testsuite/gcc.dg/analyzer/operations.c|  20 ++--
 gcc/testsuite/gcc.dg/analyzer/params.c|   8 +-
 .../gcc.dg/analyzer/pattern-test-1.c  |  12 +-
 .../gcc.dg/analyzer/pattern-test-2.c  |  12 +-
 gcc/testsuite/gcc.dg/analyzer/sensitive-1.c   |  14 +--
 gcc/testsuite/gcc.dg/analyzer/switch.c|   4 +-
 gcc/testsuite/gcc.dg/analyzer/taint-1.c   |  20 ++--
 gcc/testsuite/gcc.dg/analyzer/unknown-fns.c   |   4 +-
 33 files changed, 232 insertions(+), 232 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c 
b/gcc/testsuite/gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c
index 941d3b834a1..53c046ed12f 100644
--- a/gcc/testsuite/gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c
+++ b/gcc/testsuite/gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c
@@ -11,8 +11,8 @@ void
 recvauth_common(krb5_data inbuf)
 {
   free(inbuf.data);
-  free(inbuf.data); /* { dg-warning "double-'free'" } */
-  /* { dg-message "2 duplicates" "" { target *-*-* } .-1 } */
+  free(inbuf.data); /* { dg-warning "double-'free'" "warning" } */
+  /* { dg-message "2 duplicates" "duplicates notification" { target *-*-* } 
.-1 } */
 }
 
 void krb5_recvauth(krb5_data inbuf)

[wwwdocs] Simplify and adjust to the switch from SVN to Git.

[Gerald Pfeifer]

Remove a section that only applies to SVN and some specifics on
encoding patches in mails that are rarely relevant.

Shorten the initial statement, the note on copyright disclaimers,
and trim some further overly picky/explicit statements.

Use active voice and improve markup in one case each.


I still feel this is too long/verbose, and if one of you wants to
have a go at further steps, that would be cool.

Pushed.

Gerald

---
 htdocs/contribute.html | 35 +++
 1 file changed, 11 insertions(+), 24 deletions(-)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index ae19cb88..042ff069 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -1,5 +1,6 @@
 
 
+
 
 
 
@@ -12,12 +13,11 @@
 
 Contributing to GCC
 
-We strongly encourage individuals as well as organizations to
-contribute to the development of GCC in the form of new features, new
+We strongly encourage contributions in the form of features, new
 or improved optimizations, bug fixes, documentation updates, web page
 improvements, etc
 
-There are certain legal requirements and style issues which all
+There are certain legal requirements and style issues which
 contributions must meet:
 
 
@@ -52,11 +52,10 @@ your request.
 
 If a contributor is reluctant to sign a copyright assignment for a
 change, a copyright disclaimer to put the change in the public domain is
-acceptable as well.  The copyright disclaimer form is different than an
-employer disclaimer form.  A copyright assignment is more convenient if a
+acceptable as well.  A copyright assignment is more convenient if a
 contributor plans to make several separate contributions.
 
-Small changes can be accepted without a copyright disclaimer or a
+We can accept small changes without a copyright disclaimer or a
 copyright assignment on file.
 
 
@@ -85,9 +84,7 @@ addition to using real hardware, you can
 Much of GCC's code is used only by some targets, or used in quite
 different ways by different targets.  When choosing targets to test a
 patch with, make sure that your selections exercise all aspects of the
-code you are changing.  For instance, a change to conditional branch
-handling should be tested both with targets that use cc0,
-and targets that don't.
+code you are changing.
 
 You will of course have tested that your change does what you
 expected it to do: fix a bug, improve an optimization, add a new
@@ -127,9 +124,8 @@ must perform a complete bootstrap; however, running other 
language
 testsuites is not necessary.
 
 In all cases you must test exactly the change that you intend to
-submit; it's not good enough to test an earlier variant.  The tree
-where you perform this test should not have any other changes applied
-to it.  Include all your new testcases in your testsuite run.
+submit.  The tree where you perform this test should not have any
+other changes applied.
 
 
 Documentation Changes
@@ -207,14 +203,8 @@ of your testing.
 
 The patch itself
 
-If you are accessing the SVN repository at
-gcc.gnu.org, please configure your svn to use GNU diff
-and generate patches using the -up or 
--cp options.
-See https://gcc.gnu.org/wiki/SvnSetup;>SVN setup instructions
-for more details.
 Do not include generated files as part of the patch, just mention
-them in the ChangeLog (e.g., "* configure: Regenerate."). 
+them in the ChangeLog (e.g., "* configure: Regenerate."). 
 
 
 
@@ -234,14 +224,11 @@ the changes that actually make use of the new code and 
change GCC's
 behavior.)
 
 We prefer patches posted as plain text or as MIME parts of type
-text/x-patch or text/plain, disposition
-inline, encoded as 7bit or
-8bit.
+text/x-patch or text/plain.
 It is strongly discouraged to post patches as MIME parts of type
 application/whatever, disposition
 attachment or encoded as base64 or
-quoted-printable.  Avoid MIME large-message splitting
-(message/partial) at all costs.
+quoted-printable.
 
  If the patch is too big or too mechanical, posting it gzipped or
 bzip2ed and uuencoded or encoded as a base64 MIME part is
-- 
2.24.1

[PATCH 3/3] OpenACC dynamic data lifetimes ending within structured blocks

[Julian Brown]

This patch adds a new function to logically decrement the "dynamic
reference counter" for a mapped OpenACC variable, and handles some cases
in which that counter drops to zero inside a structured data
block. Previously, it's likely that at least in some cases, ending a
dynamic data lifetime in this way could behave unpredictably.

Several new test cases are included.

This patch is strongly related to the previous two, but is somewhat of
a separate change, and those two patches can stand alone if this one
gets deferred.

Tested alongside the previous patches in the series with offloading to NVPTX.

OK?

Thanks,

Julian

ChangeLog

libgomp/
* oacc-mem.c (decr_dynamic_refcount): New function.
(goacc_exit_datum): Call above function.
(goacc_exit_data_internal): Call above function.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c: New
test.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c:
Likewise.
---
 libgomp/oacc-mem.c| 128 ++
 .../static-dynamic-lifetimes-1-lib.c  |   3 +
 .../static-dynamic-lifetimes-1.c  | 160 ++
 .../static-dynamic-lifetimes-6-lib.c  |   5 +
 .../static-dynamic-lifetimes-6.c  |  46 +
 .../static-dynamic-lifetimes-7-lib.c  |   5 +
 .../static-dynamic-lifetimes-7.c  |  45 +
 .../static-dynamic-lifetimes-8-lib.c  |   5 +
 .../static-dynamic-lifetimes-8.c  |  50 ++
 9 files changed, 412 insertions(+), 35 deletions(-)
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c

diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index 783e7f363fb..f34ffa67079 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -725,6 +725,92 @@ acc_pcopyin (void *h, size_t s)
 #endif
 
 
+/* Perform actions necessary to decrement the dynamic reference counter for
+   splay tree key N.  Returns TRUE on success, or FALSE on failure (e.g. if we
+   hit a case we can't presently handle inside a data region).  */
+
+static bool
+decr_dynamic_refcount (splay_tree_key n, bool finalize)
+{
+  if (finalize)
+{
+  if (n->refcount != REFCOUNT_INFINITY)
+   n->refcount -= n->virtual_refcount;
+  n->virtual_refcount = 0;
+}
+
+  if (n->virtual_refcount > 0)
+{
+  if (n->refcount != REFCOUNT_INFINITY)
+   n->refcount--;
+  n->virtual_refcount--;
+}
+  /* An initial "enter data" mapping might create a target_mem_desc (in
+ gomp_map_vars_async via goacc_enter_datum or
+ goacc_enter_data_internal).  In that case we have a structural
+ reference count but a zero virtual reference count: we nevertheless
+ want to do the "exit data" operation here.  Detect the special case
+ using a sentinel value stored in the "prev" field, which is otherwise
+ unused for dynamic data mappings.  */
+  else if (n->refcount > 0
+  && n->refcount != REFCOUNT_INFINITY
+  && n->tgt->prev == _tgt_sentinel)
+{
+  n->refcount--;
+  /* We know n->virtual_refcount is zero here, so if we still have a
+non-zero n->refcount we are ending a dynamically-scoped variable
+lifetime in the middle of a static lifetime for the same variable.
+If we're not careful this results in a dangling reference.  Attempt
+to handle this here, if only in simple cases.  E.g.:
+
+  #pragma acc enter data copyin(var)
+  #pragma acc data copy(var{, ...})
+  {
+#pragma acc exit data copyout(var)
+  }
+
+Here (the "exit data"), we reattach the relevant fields of the
+previously 

[PATCH 0/3] Mixed static/dynamic data lifetimes with OpenACC (PR92843)

[Julian Brown]

This patch series provides fixes for some cases of mixing static and
dynamic data lifetimes in OpenACC, hopefully addressing some of Thomas's
concerns in PR92843 -- in particular that an "exit data"-type operation on
a given variable inside a structured block (also mapping that variable)
should be a no-op.

On further investigation of related patterns, other cases of mixing static
and dynamic lifetimes also turn out to problematic at present. Some of
these cases are handled by this patch series, and others are diagnosed
as errors (rather than allowing silent and hard-to-diagnose failures
later during runtime).

The first two patches are sufficient to fix the test case introduced
for PR92843, and the third patch provides further support/diagnostics
for dynamic unmapping operations taking place within structured blocks.

Further commentary provided alongside individual patches. Tested with
offloading to NVPTX, also with a version of my refcount-verification patch
(not currently on trunk).

I believe this (at least the first two parts) fixes a regression (for
the pr92843-1.c test case), so OK for stage 4?

Thanks,

Julian

Julian Brown (3):
  Introduce dynamic data mapping sentinel for OpenACC
  Don't copy back vars mapped with acc_map_data
  OpenACC dynamic data lifetimes ending within structured blocks

 libgomp/libgomp.h |   3 +-
 libgomp/oacc-int.h|   2 +
 libgomp/oacc-mem.c| 158 ---
 libgomp/target.c  |  56 +-
 .../libgomp.oacc-c-c++-common/pr92843-1.c |   4 +-
 .../static-dynamic-lifetimes-1-lib.c  |   3 +
 .../static-dynamic-lifetimes-1.c  | 160 +++
 .../static-dynamic-lifetimes-2-lib.c  |   3 +
 .../static-dynamic-lifetimes-2.c  | 166 
 .../static-dynamic-lifetimes-3-lib.c  |   3 +
 .../static-dynamic-lifetimes-3.c  | 183 ++
 .../static-dynamic-lifetimes-4-lib.c  |   6 +
 .../static-dynamic-lifetimes-4.c  |  71 +++
 .../static-dynamic-lifetimes-5-lib.c  |   6 +
 .../static-dynamic-lifetimes-5.c  |  63 ++
 .../static-dynamic-lifetimes-6-lib.c  |   5 +
 .../static-dynamic-lifetimes-6.c  |  46 +
 .../static-dynamic-lifetimes-7-lib.c  |   5 +
 .../static-dynamic-lifetimes-7.c  |  45 +
 .../static-dynamic-lifetimes-8-lib.c  |   5 +
 .../static-dynamic-lifetimes-8.c  |  50 +
 21 files changed, 1000 insertions(+), 43 deletions(-)
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c

-- 
2.23.0

[PATCH 2/3] Don't copy back vars mapped with acc_map_data

[Julian Brown]

This patch prevents "exit data" directives from copying back data that
was mapped with an acc_map_data API call. This matches the behaviour
expected by the pr92843-1.c test, and together with the previous patch
in this series, allows that test to pass (with no other regressions).

Tested alongside other patches in this series with offloading to NVPTX
(with and without the third & final patch).

OK?

Thanks,

Julian

ChangeLog

PR libgomp/92843

libgomp/
* oacc-mem.c (goacc_exit_data_internal): Don't copy-back data mapped
with acc_map_data on an "exit data" directive.
* testsuite/libgomp.oacc-c-c++-common/pr92843-1.c: Remove XFAIL.  Add
explanatory comment.
---
 libgomp/oacc-mem.c  | 1 +
 libgomp/testsuite/libgomp.oacc-c-c++-common/pr92843-1.c | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index 45ab2b169d7..783e7f363fb 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -1235,6 +1235,7 @@ goacc_exit_data_internal (struct gomp_device_descr 
*acc_dev, size_t mapnum,
  n->refcount--;
 
if (copyfrom
+   && n->refcount != REFCOUNT_INFINITY
&& (kind != GOMP_MAP_FROM || n->refcount == 0))
  gomp_copy_dev2host (acc_dev, aq, (void *) cur_node.host_start,
  (void *) (n->tgt->tgt_start + n->tgt_offset
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92843-1.c 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92843-1.c
index f16c46a37bf..786a12a8504 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92843-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92843-1.c
@@ -1,7 +1,6 @@
 /* Verify that 'acc_copyout' etc. is a no-op if there's still a structured
reference count.  */
 
-/* { dg-xfail-run-if "TODO PR92843" { *-*-* } } */
 /* { dg-skip-if "" { *-*-* } { "*" } { "-DACC_MEM_SHARED=0" } } */
 
 #include 
@@ -96,6 +95,9 @@ test_acc_map_data ()
   verify_array (h, N, c1);
 
   assign_array (h, N, c1);
+  /* Note that we're not expecting this (nor the copyouts below) to perform
+ an actual "finalize" or copyout since the data was mapped with
+ acc_map_data.  */
 #pragma acc exit data copyout (h[0:N]) finalize
   assert (acc_is_present (h, N));
   verify_array (h, N, c1);
-- 
2.23.0

[PATCH 1/3] Introduce dynamic data mapping sentinel for OpenACC

[Julian Brown]

This patch provides a way to distinguish target_mem_descs that arise from
"enter data" operations from those that arise from structured OpenACC
data blocks. In that way, we can implement the equivalent of the "no-op"
behaviour of decrementing a dynamic reference count that is already zero
for some given variable, as described in the OpenACC 2.6 spec.

We do this by re-using the "prev" field of the target_mem_desc (currently
unused for dynamic data mappings) to store a special sentinel value.

Several new tests are added, both for cases that now work, and for
diagnostics for cases that do not. Tested alongside other patches in
this series with offloading to NVPTX.

OK?

Thanks,

Julian

ChangeLog

PR libgomp/92843

libgomp/
* libgomp.h (target_mem_desc): Update comment for prev field.
* oacc-int.h (goacc_mark_dynamic): Add prototype.
* oacc-mem.c (dyn_tgt_sentinel): New static global.
(goacc_mark_dynamic): New function.
(goacc_enter_datum, goacc_enter_data_internal): Call goacc_mark_dynamic
on non-NULL target_mem_desc return from gomp_map_vars_async.
(goacc_exit_datum, goacc_exit_data_internal): Check target_mem_desc for
sentinel value on structural refcount decrement.
* target.c (gomp_unmap_vars_internal): Re-use target_mem_desc for
"structural" data mapping for extending dynamic mapping beyond the end
of a structured block when possible.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c: New
test.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c:
Likewise.
---
 libgomp/libgomp.h |   3 +-
 libgomp/oacc-int.h|   2 +
 libgomp/oacc-mem.c|  53 -
 libgomp/target.c  |  56 +-
 .../static-dynamic-lifetimes-2-lib.c  |   3 +
 .../static-dynamic-lifetimes-2.c  | 166 
 .../static-dynamic-lifetimes-3-lib.c  |   3 +
 .../static-dynamic-lifetimes-3.c  | 183 ++
 .../static-dynamic-lifetimes-4-lib.c  |   6 +
 .../static-dynamic-lifetimes-4.c  |  71 +++
 .../static-dynamic-lifetimes-5-lib.c  |   6 +
 .../static-dynamic-lifetimes-5.c  |  63 ++
 12 files changed, 596 insertions(+), 19 deletions(-)
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c
 create mode 100644 
libgomp/testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c

diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index 15a1394c16d..bbab4f9f34f 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -975,7 +975,8 @@ struct target_mem_desc {
   uintptr_t tgt_end;
   /* Handle to free.  */
   void *to_free;
-  /* Previous target_mem_desc.  */
+  /* Previous target_mem_desc.  Also used in OpenACC to indicate that this
+ target_mem_desc is used only for an "enter data" mapping.  */
   struct target_mem_desc *prev;
   /* Number of items in following list.  */
   size_t list_count;
diff --git a/libgomp/oacc-int.h b/libgomp/oacc-int.h
index 3c2c9b84b2f..bb67188c3e9 100644
--- a/libgomp/oacc-int.h
+++ b/libgomp/oacc-int.h
@@ -165,6 +165,8 @@ bool _goacc_profiling_setup_p (struct goacc_thread *,
 void goacc_profiling_dispatch (acc_prof_info *, acc_event_info *,
   acc_api_info *);
 
+extern void goacc_mark_dynamic (struct target_mem_desc *);
+
 #ifdef HAVE_ATTRIBUTE_VISIBILITY
 # pragma GCC visibility pop
 #endif
diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index bd1a99d9277..45ab2b169d7 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -550,6 +550,24 @@ acc_unmap_data (void *h)
 }
 }
 
+/* Indicate (via storing its 

[C++ PATCH] PR c++/93299 - ICE in tsubst_copy with parenthesized expression.

[Marek Polacek]

Since e4511ca2e9ecdb51d41b64452398f8e2df575668 force_paren_expr can create
a VIEW_CONVERT_EXPR so that we have something to set REF_PARENTHESIZED_P
on, while not making the expression dependent.  But tsubst_copy can't cope
with such a VIEW_CONVERT_EXPR, because it's not location_wrapper_p, or
a TEMPLATE_PARM_INDEX wrapped in a VIEW_CONVERT_EXPR.

I think we need to teach tsubst_copy how to handle it.  Setting
EXPR_LOCATION_WRAPPER_P in force_paren_expr would make the ICE go away
too, but tsubst_copy would lose the REF_PARENTHESIZED_P flag.

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

* pt.c (tsubst_copy): Handle a REF_PARENTHESIZED_P VIEW_CONVERT_EXPR.

* g++.dg/cpp1y/paren5.C: New test.
---
 gcc/cp/pt.c |  8 
 gcc/testsuite/g++.dg/cpp1y/paren5.C | 12 
 2 files changed, 20 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/paren5.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1b3d07b1a52..5d3d127e528 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -16423,6 +16423,14 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
  return op;
}
}
+ /* force_paren_expr can also create a VIEW_CONVERT_EXPR.  */
+ else if (code == VIEW_CONVERT_EXPR && REF_PARENTHESIZED_P (t))
+   {
+ op = tsubst_copy (op, args, complain, in_decl);
+ op = build1 (code, TREE_TYPE (op), op);
+ REF_PARENTHESIZED_P (op) = true;
+ return op;
+   }
  /* We shouldn't see any other uses of these in templates.  */
  gcc_unreachable ();
}
diff --git a/gcc/testsuite/g++.dg/cpp1y/paren5.C 
b/gcc/testsuite/g++.dg/cpp1y/paren5.C
new file mode 100644
index 000..86a51356465
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/paren5.C
@@ -0,0 +1,12 @@
+// PR c++/93299 - ICE in tsubst_copy with parenthesized expression.
+// { dg-do compile { target c++14 } }
+
+template  struct A {
+  enum { b = 8 };
+};
+
+template  struct __attribute__((aligned((A::b D { };
+struct S : D<0> { };
+
+template  struct __attribute__((aligned((A::b) + N))) D2 { };
+struct S2 : D2<0> { };

base-commit: 6687d13a87c42dddc7d1c7adade38d31ba0d1401
-- 
2.24.1

[wwwdocs] Remove the last reference to svnwrite.html and retire it.

[Gerald Pfeifer]

One step^Wfile at a time; next in line: svn.html.

Pushed.

Gerald

---
 htdocs/contribute.html |   4 +-
 htdocs/svnwrite.html   | 432 -
 2 files changed, 2 insertions(+), 434 deletions(-)
 delete mode 100644 htdocs/svnwrite.html

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index e7ff3990..ae19cb88 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -74,7 +74,7 @@ preparation of patches you can use the script https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup;>
 contrib/check_GNU_style.sh.
 
-
+
 Testing Patches
 
 All patches must be thoroughly tested.  We encourage you to test
@@ -257,7 +257,7 @@ href="gitwrite.html">Read-write Git access pages.
 
 (Everything listed here still applies if you can check in the patch
 without further approval under the GCC write access policies, except
+href="gitwrite.html#policies">GCC write access policies, except
 that ChangeLog entries may be included as part of the patch and diffs
 representing new files may be omitted, especially if large, since they
 can be accessed directly from the repository.) 
diff --git a/htdocs/svnwrite.html b/htdocs/svnwrite.html
deleted file mode 100644
index a1346be1..
--- a/htdocs/svnwrite.html
+++ /dev/null
@@ -1,432 +0,0 @@
-
-
-
-
-Read-write SVN access
-https://gcc.gnu.org/gcc.css; />
-
-
-
-
-Read-write SVN access
-
-We have read/write access to the SVN repository available for
-maintainers and significant developers.
-
-Our web pages are managed via git.
-
-
-Contents
-
-  Authenticated access
-  Setting up your local SVN tree
-  Write access policies
-  Testing changes
-  Checking in a change
-  Example check-in session
-  Creating and using branches
-  TipsTricks around your account
-
-
-
-Authenticated access
-
-We provide authenticated access via the SSH protocol.  This needs to
-be sponsored by an existing maintainer (someone with "write after approval"
-is not sufficient).
-
-If you already have an account on sourceware.org / gcc.gnu.org, ask
-overse...@gcc.gnu.org to add access to the GCC repository.
-Include the name of your sponsor and CC: her.
-If you do not have an account yet, use https://sourceware.org/cgi-bin/pdw/ps_form.cgi;>this form,
-again specifying your sponsor.
-
-We will then provision you on  
-gcc.gnu.org and inform you by mail. At this point,
-check out a tree using the instructions below and add yourself
-to the MAINTAINERS file.  Note: Your first and last names must
-be exactly the same between your account on gcc.gnu.org and the
-MAINTAINERS file.   Place your name in the correct section following
-the conventions specified in the file (e.g. "Write After Approval"
-is "last name alphabetical order").
-
-Then produce a diff to that file and circulate it to the
-gcc-patches list, whilst also checking in your change to
-test write access (approval from the mailing list is not needed in this
-one case).  For all other changes, please be sure to follow the write
-access policies below.
-
-
-Setting up your local SVN tree
-
-Once your account has been set up, check out the GCC sources by 
-issuing the command:
-
-
-svn co svn+ssh://username@gcc.gnu.org/svn/gcc/trunk gcc
-
-
-where username is your user name at gcc.gnu.org.
-
-It is also possible to convert an existing SVN tree to use SSH by
-using svn switch --relocate:
-
-
-svn switch --relocate svn://gcc.gnu.org/svn/gcc 
svn+ssh://username@gcc.gnu.org/svn/gcc
-
-
-To avoid the nuisance of having to supply your passphrase for each
-operation, you may want to use ssh-agent(1) and
-ssh-add(1).
-
-To avoid messages about (lack of) X11 forwarding, put in your
-$HOME/.ssh/config an entry like:
-
-
-Host gcc.gnu.org
-ForwardX11 no
-
-
-
-Write access policies
-
-The GCC project grants developers various levels of write access to
-and review authority over the GCC master sources.  We have not put any
-technical enforcement in place, rather we rely on everyone to follow
-the appropriate policies.
-
-
-  Global reviewers.
-  A limited number of developers have global review permission
-  and can approve other people's changes to any part of the compiler.
-  
-
-  Localized write permission.
-  This is for people who have primary responsibility for ports,
-  front ends, or other specific aspects of the compiler.  These folks
-  are allowed to make changes to areas they maintain and related
-  documentation, web pages, and test cases (and target conditionals)
-  without approval from anyone else, and approve other people's changes
-  in those areas.
-  They must get approval for changes elsewhere in the compiler.
-
-  Maintainers of a port maintain the relevant files in
-  gcc/config, documentation, web pages, and test cases
-  and aspects of these relevant to that port.  Port maintainers do
-  not have approval rights beyond this.
-
-  Localized review permission.
-  This is similar to localized write permission, except
-  that reviewers required approval for their 

Re: Make profile estimation more precise

[Jan Hubicka]

> Hi Honza,
> 
> This change seems to have cost a 0.2% regression in SPEC2017 vs a codesize 
> reduction of 0.02%.
> 
> Only leela seems to have made any noticable difference at 2.64% codesize 
> reduction.
> 
> Is there anyway to keep the performance at -O3 where the codesize doesn't 
> matter much?

The patch mostly eliminated roundoff errors.  We used to calculate
everythig with 1 based fixpoint probabilities.  Then the code was
updated to use higher precision but the propagation recalculated to
1 base rounding to nearest value.  This led to some basic blocks to
have sum of outgoing probabilities greater than 1 which in turn led to
never ending loops.

So it would be good to understand why performance chnaged.  If you have
testcases to look into, it would be useful.  We may want to reduce big
speedup threshold or so which may be better tunned for the broken
behaviour.  Perhaps incresing --param max-predicted-loop-iterations
could help, too.  Large values however lead to troubles for functions
which combine loop nests with known and loop nests with unknown number
of iterations.

We preict loops with unkonwn iterations to predict somewhere between 3
and 10 iterations.  Loops with known number of iterations are predicted
precisely up to --param max-predicted-loop-iterations.

I remember debugging spec2k benchmark which had multiple nested loops to
perform initialization followed with actual calculation with unkown
bounds.  The logic above made us to predict initialization code to be
hot and actual calculation to be cold.

Honza
> 
> Thanks,
> Tamar
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org 
> > On Behalf Of Jan Hubicka
> > Sent: Thursday, January 16, 2020 23:00
> > To: gcc-patches@gcc.gnu.org
> > Subject: Make profile estimation more precise
> > 
> > Hi,
> > while analyzing code size regression in SPEC2k GCC binary I noticed that we
> > perform some inline decisions because we think that number of executions
> > are very high.
> > In particular there was inline decision inlining gen_rtx_fmt_ee to
> > find_reloads believing that it is called 4 billion times.  This turned out 
> > to be
> > cummulation of roundoff errors in propagate_freq which was bit
> > mechanically updated from original sreals to C++ sreals and later to new
> > probabilities.
> > 
> > This led us to estimate that a loopback edge is reached with probability 2.3
> > which was capped to 1-1/1 and since this happened in nested loop it
> > quickly escalated to large values.
> > 
> > Originally capping to REG_BR_PROB_BASE avoided such problems but now
> > we have much higher range.
> > 
> > This patch avoids going from probabilites to REG_BR_PROB_BASE so
> > precision is kept.  In addition it makes the propagation to not estimate 
> > more
> > than param-max-predicted-loop-iterations.  The first change makes the cap
> > to not be triggered on the gcc build, but it is still better to be safe 
> > than sorry.
> > 
> > 2020-01-16  Jan Hubicka  
> > 
> > * ipa-fnsummary.c (estimate_calls_size_and_time): Fix formating of
> > dump.
> > * params.opt: (max-predicted-iterations): Set bounds.
> > * predict.c (real_almost_one, real_br_prob_base,
> > real_inv_br_prob_base, real_one_half, real_bb_freq_max): Remove.
> > (propagate_freq): Add max_cyclic_prob parameter; cap cyclic
> > probabilities; do not truncate to reg_br_prob_bases.
> > (estimate_loops_at_level): Pass max_cyclic_prob.
> > (estimate_loops): Compute max_cyclic_prob.
> > (estimate_bb_frequencies): Do not initialize real_*; update
> > calculation
> > of back edge prob.
> > * profile-count.c (profile_probability::to_sreal): New.
> > * profile-count.h (class sreal): Move up in file.
> > (profile_probability::to_sreal): Declare.
> > 
> > diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c index
> > 4e1c587b101..dbd53f12a40 100644
> > --- a/gcc/ipa-fnsummary.c
> > +++ b/gcc/ipa-fnsummary.c
> > @@ -3258,7 +3258,7 @@ estimate_calls_size_and_time (struct cgraph_node
> > *node, int *size,
> >   gcc_assert (*size == old_size);
> >   if (time && (*time - old_time > 1 || *time - old_time < -1)
> >   && dump_file)
> > -   fprintf (dump_file, "Time mismatch in call summary %f!=%f",
> > +   fprintf (dump_file, "Time mismatch in call summary %f!=%f\n",
> >  old_time.to_double (),
> >  time->to_double ());
> > }
> > diff --git a/gcc/params.opt b/gcc/params.opt index
> > 31cc20031b1..f02c769d0e3 100644
> > --- a/gcc/params.opt
> > +++ b/gcc/params.opt
> > @@ -555,7 +555,7 @@ Common Joined UInteger
> > Var(param_max_pow_sqrt_depth) Init(5) IntegerRange(1, 32)  Maximum
> > depth of sqrt chains to use when synthesizing exponentiation by a real
> > constant.
> > 
> >  -param=max-predicted-iterations=
> > -Common Joined UInteger Var(param_max_predicted_iterations) Init(100)
> > Param Optimization
> > +Common Joined UInteger 

[PATCH] arm: fix rtl checking bootstrap (PR target/93312)

[Jakub Jelinek]

Hi!

As reported in PR93312, the:
> > > > > >     * config/arm/arm.c (clear_operation_p): New function.
change broke RTL checking bootstrap.

On the testcase from the PR (which is distilled from libgcc2.c, so I think
we don't need to add it into testsuite) we ICE because SET_DEST (elt) is
not a REG, but SUBREG.  The code uses REGNO on it, which is invalid, but
only stores it into a variable, then performs REG_P (reg) check,
determines it is not a REG and bails early.

The following patch just moves the regno variable initialization after that
check, it isn't used in between.  And, as a small optimization, because
reg doesn't change, doesn't use REGNO (reg) a second time to set last_regno.

Ok for trunk if it passes bootstrap/regtest?

2020-01-17  Jakub Jelinek  

PR target/93312
* config/arm/arm.c (clear_operation_p): Don't use REGNO until
after checking the argument is a REG.  Don't use REGNO (reg)
again to set last_regno, reuse regno variable instead.

--- gcc/config/arm/arm.c.jj 2020-01-17 09:31:28.594195284 +0100
+++ gcc/config/arm/arm.c2020-01-17 19:30:47.747756756 +0100
@@ -13779,7 +13779,6 @@ clear_operation_p (rtx op, bool vfp)
return false;
 
   reg = SET_DEST (elt);
-  regno = REGNO (reg);
   zero = SET_SRC (elt);
 
   if (!REG_P (reg)
@@ -13787,6 +13786,8 @@ clear_operation_p (rtx op, bool vfp)
  || zero != CONST0_RTX (SImode))
return false;
 
+  regno = REGNO (reg);
+
   if (vfp)
{
  if (i != 1 && regno != last_regno + 1)
@@ -13800,7 +13801,7 @@ clear_operation_p (rtx op, bool vfp)
return false;
}
 
-  last_regno = REGNO (reg);
+  last_regno = regno;
 }
 
   return true;


Jakub

Re: [PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions

[Jakub Jelinek]

On Fri, Jan 17, 2020 at 11:12:08AM +, Mihail Ionescu wrote:
> On 01/17/2020 08:37 AM, Jakub Jelinek wrote:
> > On Wed, Dec 18, 2019 at 05:00:01PM +, Mihail Ionescu wrote:
> > > 2019-12-18  Mihail Ionescu  
> > > 2019-12-18  Andre Vieira  
> > > 
> > >   * config/arm/arm-cpus.in (mve, mve_float): New features.
> > >   (dsp, mve, mve.fp): New options.
> > 
> > Note, the above is not the right ChangeLog formatting when you have more
> > than one author.  The date should be there only for the first line, for the
> > other authors there should be just tab and 4 spaces, otherwise various tools
> > that parse ChangeLog entries will be quite confused.  So like:
> > 2019-12-18  Mihail Ionescu  
> > Andre Vieira  
> > 
> > I've fixed your commits in 2b3534a3122236d6317256f16daa332278391907
> > but please remember this next time.
> 
> Thank you, I did not realise that I wasn't using the correct formatting
> style. I'll keep that in mind for next time.

Two more things.

One is I wonder if it has been bootstrapped, because at least in a cross
from x86_64-linux to armv7hl-linux-gnueabi I'm seeing:
../../gcc/config/arm/arm.c: In function ‘void 
cmse_nonsecure_call_inline_register_clear()’:
../../gcc/config/arm/arm.c:18469:18: warning: unused variable ‘next’ 
[-Wunused-variable]
rtx_insn *next, *last, *pop_insn, *after = insn;
  ^~~~
warning, which I believe in bootstrap would result in
-Werror=unused-variable error.
The variable is really unused, so I've checked in as obvious following
patch.

The other thing is that https://gcc.gnu.org/codingconventions.html and
https://www.gnu.org/prep/standards/standards.html#Formatting say that 
rtx tmp =
  copy_to_suggested_reg (XEXP (operands[0], 0),
 gen_rtx_REG (SImode, R4_REGNUM),
 SImode);
etc. I've seen in your patch is not correctly formatted, the =
should not be at the end of line (similarly to |, &, ||, &&, +, -,
etc.), but should be at the start of the next line.
That would be then
rtx tmp
  = copy_to_suggested_reg (XEXP (operands[0], 0),
   gen_rtx_REG (SImode, R4_REGNUM),
   SImode);
but the line is really short, so I don't see a point to break line there at
all, you can just use:
rtx tmp = copy_to_suggested_reg (XEXP (operands[0], 0),
 gen_rtx_REG (SImode, R4_REGNUM),
 SImode);

2020-01-17  Jakub Jelinek  

* config/arm/arm.c (cmse_nonsecure_call_inline_register_clear): Remove
unused variable.

--- gcc/config/arm/arm.c.jj 2020-01-17 09:31:28.594195284 +0100
+++ gcc/config/arm/arm.c2020-01-17 19:30:47.747756756 +0100
@@ -18466,7 +18466,7 @@ cmse_nonsecure_call_inline_register_clea
 
  if (TARGET_HAVE_FPCXT_CMSE)
{
- rtx_insn *next, *last, *pop_insn, *after = insn;
+ rtx_insn *last, *pop_insn, *after = insn;
 
  start_sequence ();
 


Jakub

[committed, amdgcn/openacc] Rename acc_device_gcn to acc_device_radeon

[Andrew Stubbs]

I've committed this patch, pre-approved by Thomas. It's basically just a 
search and replace.


I had originally invented acc_device_gcn for the device number, but as 
Thomas pointed out the OpenACC documentation already uses 
acc_device_radeon for AMD devices. Presumably this is what any existing 
code will use, if anything, so we ought to be compatible.


There's no official release using the "wrong" name, so I don't believe 
we need to retain that name for any reason.


I've tested that there are no regressions.

Andrew
Rename acc_device_gcn to acc_device_radeon

2020-01-17  Andrew Stubbs  

	libgomp/
	* config/accel/openacc.f90 (openacc_kinds): Rename acc_device_gcn to
	acc_device_radeon.
	(openacc): Likewise.
	* openacc.f90 (openacc_kinds): Likewise.
	(openacc): Likewise.
	* openacc.h (acc_device_t): Likewise.
	* openacc_lib.h: Likewise.
	* testsuite/lib/libgomp.exp
	(check_effective_target_openacc_amdgcn_accel_present): Likewise.
	* testsuite/libgomp.oacc-c-c++-common/acc_prof-init-1.c
	(cb_compute_construct_end): Likewise.
	* testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
	(cb_enqueue_launch_start): Likewise.
	* testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c
	(cb_enter_data_end): Likewise.
	(cb_exit_data_start): Likewise.
	(cb_exit_data_end): Likewise.
	(cb_compute_construct_end): Likewise.
	(cb_enqueue_launch_start): Likewise.
	(cb_enqueue_launch_end): Likewise.
	* testsuite/libgomp.oacc-c-c++-common/asyncwait-nop-1.c
	(main): Likewise.

diff --git a/libgomp/config/accel/openacc.f90 b/libgomp/config/accel/openacc.f90
index b4d40362c5d..a8e5144349e 100644
--- a/libgomp/config/accel/openacc.f90
+++ b/libgomp/config/accel/openacc.f90
@@ -50,7 +50,7 @@ module openacc_kinds
   ! integer (acc_device_kind), parameter :: acc_device_host_nonshm = 3 removed.
   integer (acc_device_kind), parameter :: acc_device_not_host = 4
   integer (acc_device_kind), parameter :: acc_device_nvidia = 5
-  integer (acc_device_kind), parameter :: acc_device_gcn = 8
+  integer (acc_device_kind), parameter :: acc_device_radeon = 8
 
 end module openacc_kinds
 
@@ -86,7 +86,7 @@ module openacc
   ! From openacc_kinds
   public :: acc_device_kind
   public :: acc_device_none, acc_device_default, acc_device_host
-  public :: acc_device_not_host, acc_device_nvidia, acc_device_gcn
+  public :: acc_device_not_host, acc_device_nvidia, acc_device_radeon
 
   public :: acc_on_device
 
diff --git a/libgomp/openacc.f90 b/libgomp/openacc.f90
index 6c92c7c12c9..e2639bf622e 100644
--- a/libgomp/openacc.f90
+++ b/libgomp/openacc.f90
@@ -49,7 +49,7 @@ module openacc_kinds
   ! integer (acc_device_kind), parameter :: acc_device_host_nonshm = 3 removed.
   integer (acc_device_kind), parameter :: acc_device_not_host = 4
   integer (acc_device_kind), parameter :: acc_device_nvidia = 5
-  integer (acc_device_kind), parameter :: acc_device_gcn = 8
+  integer (acc_device_kind), parameter :: acc_device_radeon = 8
 
   integer, parameter :: acc_device_property = c_size_t
 
@@ -767,7 +767,7 @@ module openacc
   ! From openacc_kinds
   public :: acc_device_kind
   public :: acc_device_none, acc_device_default, acc_device_host
-  public :: acc_device_not_host, acc_device_nvidia, acc_device_gcn
+  public :: acc_device_not_host, acc_device_nvidia, acc_device_radeon
 
   public :: acc_device_property
   public :: acc_property_memory, acc_property_free_memory
diff --git a/libgomp/openacc.h b/libgomp/openacc.h
index 62b2b0ea559..61736463474 100644
--- a/libgomp/openacc.h
+++ b/libgomp/openacc.h
@@ -56,7 +56,7 @@ typedef enum acc_device_t {
   /* acc_device_host_nonshm = 3 removed.  */
   acc_device_not_host = 4,
   acc_device_nvidia = 5,
-  acc_device_gcn = 8,
+  acc_device_radeon = 8,
   _ACC_device_hwm,
   /* Ensure enumeration is layout compatible with int.  */
   _ACC_highest = __INT_MAX__,
diff --git a/libgomp/openacc_lib.h b/libgomp/openacc_lib.h
index b327ba76403..717f9b4ef08 100644
--- a/libgomp/openacc_lib.h
+++ b/libgomp/openacc_lib.h
@@ -44,7 +44,7 @@
 ! removed.
   integer (acc_device_kind), parameter :: acc_device_not_host = 4
   integer (acc_device_kind), parameter :: acc_device_nvidia = 5
-  integer (acc_device_kind), parameter :: acc_device_gcn = 8
+  integer (acc_device_kind), parameter :: acc_device_radeon = 8
 
   integer, parameter :: acc_handle_kind = 4
 
diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index f52ed7184e4..7e94527c7ca 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -489,7 +489,7 @@ proc check_effective_target_openacc_amdgcn_accel_present { } {
 return [check_runtime openacc_amdgcn_accel_present {
 	#include 
 	int main () {
-	return !(acc_get_num_devices (acc_device_gcn) > 0);
+	return !(acc_get_num_devices (acc_device_radeon) > 0);
 	}
 } "" ]
 }
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_prof-init-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_prof-init-1.c
index 

[wwwdocs] Reduce references to FTP for downloads.

[Gerald Pfeifer]

This is not directly related to our move to Git, though I noticed
it in the context of working to update the web pages.

Most of our downloads are now happening via http, and Chrome will
soon even remove support for the ftp protocol.

Pushed.

Gerald
---
 htdocs/gcc-2.95/branch.html | 2 +-
 htdocs/mirrors.html | 2 +-
 htdocs/snapshots.html   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/gcc-2.95/branch.html b/htdocs/gcc-2.95/branch.html
index 7ba3250f..03746846 100644
--- a/htdocs/gcc-2.95/branch.html
+++ b/htdocs/gcc-2.95/branch.html
@@ -29,7 +29,7 @@ situation you have three choices for handling your CVS 
tree.
 Considering that the primary focus of the developers is on the GCC 2.95
 release, option #2 or #3 is recommended.
 
-FTP snapshots will track the GCC 2.95 release only.  After GCC 2.95 is
+Snapshots will track the GCC 2.95 release only.  After GCC 2.95 is
 released, snapshots will return to tracking the mainline sources.
 
 
diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html
index d8979b76..1917d04a 100644
--- a/htdocs/mirrors.html
+++ b/htdocs/mirrors.html
@@ -13,7 +13,7 @@
 
 Our releases are available on the
 http://www.gnu.org/prep/ftp.html;>GNU FTP server and its
-mirrors.  The following sites mirror the gcc.gnu.org FTP site
+mirrors.  The following sites mirror the gcc.gnu.org download site
 (Phoenix, Arizona, USA) directly:
 
 
diff --git a/htdocs/snapshots.html b/htdocs/snapshots.html
index 7b15b0f5..3c491b00 100644
--- a/htdocs/snapshots.html
+++ b/htdocs/snapshots.html
@@ -14,7 +14,7 @@
 We recommend that you use SVN to access our
 current development sources.
 
-We also make regular snapshots available for FTP download from our
+We also make regular snapshots available for download from our
 mirror sites about once
 a week. These snapshots are intended to give everyone access to work in
 progress.  Any given snapshot may generate incorrect code or even fail to
-- 
2.24.1

Re: Deque rotate on current node

[François Dumont]

On 1/17/20 11:01 AM, Jonathan Wakely wrote:

On 20/05/19 07:39 +0200, François Dumont wrote:

Hi

  std::deque is supposed to be like a double-queue that you can 
attack from front and back. But currrently its implementation makes 
it behave differently when starting from a fresh deque. If push_back 
then all goes well, it is copy/move to the current internal 'node'. 
If push_front then a new 'node' is created and on next pop_back the 
initial node will be deallocated without having ever be used.


  This patch changes this behavior. As long as deque is empty we can 
play with its state to make it push_back- or push_front-ready. It 
will also benefit to the usage of deque in the std::stack.


  More generally it could really improve scenario in which deque is 
used as queue of elements exchanged between different threads. As you 
need to make sure that consumers are faster than producers then your 
deque should remain empty most of the time and so this proposed patch 
should avoid nodes to be allocated/deallocated all the time.


This benefits the case where you always push at the same end. But with
your patch if I do push_front then push_back,
we still allocate a second node even though the first one is nearly
empty.

Would it be better to point into the middle of the node, not right at
the end or right at the beginning?


That's purely empirical but I tend to think that when you need push_back 
only you go with std::vector or std::deque, when you need push_front 
only you go with std::deque and when you need both you go with 
std::list. At least std::stack and std::queue are following this axiom 
per default.


The tradeoff you are describing is not worst than current situation 
where you will eventually deallocate a node that you haven't used at all.


Are you proposing to just init in the middle or also to always reset 
when empty in the middle ? If we also reset in the middle those doing 
always push_back or push_front will live with half a node unreachable.


We could just init in the middle however. It would be a different patch 
as this one is focus on just recycling the last empty node.


I consider adding a flag keeping the info that the deque is 
push_back|push_front|both-oriented updated based on its usage but I 
doubt it would worth it. Moreover it would introduce an abi breakage.





    * include/bits/deque.tcc (deque<>::_M_push_back_aux):
    Rotate on current node if deque is empty.
    (deue<>::_M_push_front_aux): Likewise.

Tested under Linux x86_64, ok to commit ?

François



diff --git a/libstdc++-v3/include/bits/deque.tcc 
b/libstdc++-v3/include/bits/deque.tcc

index 2053afe1d69..245e3e712d8 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -507,6 +507,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  _M_push_back_aux(const value_type& __t)
#endif
  {
+    if (empty())
+  {
+    // Move iterators to point to the current node begin.
+    this->_M_impl._M_start._M_cur = 
this->_M_impl._M_start._M_first;
+    this->_M_impl._M_finish._M_cur = 
this->_M_impl._M_finish._M_first;

+#if __cplusplus >= 201103L
+    emplace_back(std::forward<_Args>(__args)...);
+#else
+    push_back(__t);
+#endif
+    return;
+  }
+
if (size() == max_size())
  __throw_length_error(
  __N("cannot create std::deque larger than max_size()"));
@@ -546,6 +559,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  _M_push_front_aux(const value_type& __t)
#endif
  {
+    if (empty())
+  {
+    // Move iterators to point to the current node end.
+    this->_M_impl._M_finish._M_cur = 
this->_M_impl._M_finish._M_last - 1;
+    this->_M_impl._M_start._M_cur = 
this->_M_impl._M_start._M_last - 1;

+#if __cplusplus >= 201103L
+    emplace_front(std::forward<_Args>(__args)...);
+#else
+    push_front(__t);
+#endif
+    return;
+  }
+
if (size() == max_size())
  __throw_length_error(
  __N("cannot create std::deque larger than max_size()"));

[PATCH] libstdc++: Fix freestanding build PR 92376)

[Jonathan Wakely]

In a freestanding library we don't install the 
header, so don't try to include it unless it exists.

Explicitly declare aligned alloc functions for freestanding, because
 doesn't declare them.

PR libstdc++/92376
* include/bits/c++config: Only do PSTL config when the header is
present, to fix freestanding.
* libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Declare allocation
functions if they were detected by configure.

Tested powerpc64le-linux, committed to trunk.

This needs to be backported too.

commit 0ba6a850b597236832140bf57bf6083b6fab93f9
Author: Jonathan Wakely 
Date:   Fri Jan 17 15:49:02 2020 +

libstdc++: Fix freestanding build PR 92376)

In a freestanding library we don't install the 
header, so don't try to include it unless it exists.

Explicitly declare aligned alloc functions for freestanding, because
 doesn't declare them.

PR libstdc++/92376
* include/bits/c++config: Only do PSTL config when the header is
present, to fix freestanding.
* libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Declare allocation
functions if they were detected by configure.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 875a5e76890..b1fad59d4b3 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -666,6 +666,8 @@ namespace std
 // PSTL configuration
 
 #if __cplusplus >= 201703L
+// This header is not installed for freestanding:
+#if __has_include()
 // Preserved here so we have some idea which version of upstream we've pulled 
in
 // #define PSTL_VERSION 9000
 
@@ -684,6 +686,7 @@ namespace std
 # define _PSTL_ASSERT_MSG(_Condition, _Message) __glibcxx_assert(_Condition)
 
 #include 
+#endif // __has_include
+#endif // C++17
 
-#endif
 // End of prewritten config; the settings discovered at configure time follow.
diff --git a/libstdc++-v3/libsupc++/new_opa.cc 
b/libstdc++-v3/libsupc++/new_opa.cc
index 4e36fbf589d..8fac193cc7e 100644
--- a/libstdc++-v3/libsupc++/new_opa.cc
+++ b/libstdc++-v3/libsupc++/new_opa.cc
@@ -43,6 +43,21 @@ extern "C" void *memalign(std::size_t boundary, std::size_t 
size);
 using std::new_handler;
 using std::bad_alloc;
 
+#if ! _GLIBCXX_HOSTED
+extern "C"
+{
+# if _GLIBCXX_HAVE_ALIGNED_ALLOC
+  void *aligned_alloc(size_t alignment, size_t size);
+# elif _GLIBCXX_HAVE__ALIGNED_MALLOC
+  void *_aligned_malloc(size_t size, size_t alignment);
+# elif _GLIBCXX_HAVE_POSIX_MEMALIGN
+  void *posix_memalign(void **, size_t alignment, size_t size);
+# elif _GLIBCXX_HAVE_MEMALIGN
+  void *memalign(size_t alignment, size_t size);
+# endif
+}
+#endif
+
 namespace __gnu_cxx {
 #if _GLIBCXX_HAVE_ALIGNED_ALLOC
 using ::aligned_alloc;

Re: [PATCH][AARCH64] Set jump-align=4 for neoversen1

[Wilco Dijkstra]

Hi Kyrill & Richard,

> I was leaving this to others in case it was obvious to them.  On the
> basis that silence suggests it wasn't, :-) could you go into more details?
> Is it expected on first principles that jump alignment doesn't matter
> for Neoverse N1, or is this purely based on experimentation?  If it's

Jump alignment is set to 4 on almost all cores because higher values have
a major codesize cost and yet give no performance gains.

I suspect any core that set it higher has done so by accident rather than
having benchmarked the cost/benefit.

> expected, are we sure that the other "32:16" entries are still worthwhile?
> When you say it doesn't make a difference in performance, does that mean
> that no individual test's performance changed significantly, or just that
> the aggregate score didn't?  Did you experiment with anything inbetween
> the current 32:16 and 4, such as 32:8 or even 32:4?

I mean there is no difference above the noise floor for any test you throw at 
it.
I tried other alignments including 32:16, 32:12, 32:8 but all have a significant
cost and zero benefit.

Cheers,
Wilco

[PATCH][Arm] ACLE intrinsics: AdvSIMD BFloat16 convert instructions

[Dennis Zhang]

Hi all,

This patch is part of a series adding support for Armv8.6-A features.
It depends on Arm BFMode patch 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html

This patch implements intrinsics to convert between bfloat16 and float32 
formats.
ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Regression tested.

Is it OK for trunk please?

Thanks,
Dennis

gcc/ChangeLog:

2020-01-17  Dennis Zhang  

* config/arm/arm_bf16.h (vcvtah_f32_bf16, vcvth_bf16_f32): New.
* config/arm/arm_neon.h (vcvt_f32_bf16, vcvtq_low_f32_bf16): New.
(vcvtq_high_f32_bf16, vcvt_bf16_f32): New.
(vcvtq_low_bf16_f32, vcvtq_high_bf16_f32): New.
* config/arm/arm_neon_builtins.def (vbfcvt, vbfcvt_high): New entries.
(vbfcvtv4sf, vbfcvtv4sf_high): Likewise.
* config/arm/iterators.md (VBFCVT, VBFCVTM): New mode iterators.
(V_bf_low, V_bf_cvt_m): New mode attributes.
* config/arm/neon.md (neon_vbfcvtv4sf): New.
(neon_vbfcvtv4sf_highv8bf, neon_vbfcvtsf): New.
(neon_vbfcvt, neon_vbfcvt_highv8bf): New.
(neon_vbfcvtbf_cvtmode, neon_vbfcvtbf): New
* config/arm/unspecs.md (UNSPEC_BFCVT, UNSPEC_BFCVT_HIG): New.

gcc/testsuite/ChangeLog:

2020-01-17  Dennis Zhang  

* gcc.target/arm/simd/bf16_cvt_1.c: New test.


diff --git a/gcc/config/arm/arm_bf16.h b/gcc/config/arm/arm_bf16.h
index decf23f38346c033f9d7502ce82e11ce81b9bc3a..1aa593192c091850e3ffbe4433d18c0ff543173a 100644
--- a/gcc/config/arm/arm_bf16.h
+++ b/gcc/config/arm/arm_bf16.h
@@ -34,6 +34,20 @@ extern "C" {
 typedef __bf16 bfloat16_t;
 typedef float float32_t;
 
+__extension__ extern __inline float32_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvtah_f32_bf16 (bfloat16_t __a)
+{
+  return __builtin_neon_vbfcvtbf (__a);
+}
+
+__extension__ extern __inline bfloat16_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvth_bf16_f32 (float32_t __a)
+{
+  return __builtin_neon_vbfcvtsf (__a);
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 3c78f435009ab027f92693d00ab5b40960d5419d..60ac68702c4f1ef0408c2d0663ebd89bfc6610a2 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -18745,6 +18745,55 @@ vcmlaq_rot270_laneq_f32 (float32x4_t __r, float32x4_t __a, float32x4_t __b,
 #pragma GCC pop_options
 #endif
 
+#pragma GCC push_options
+#pragma GCC target ("arch=armv8.2-a+bf16")
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvt_f32_bf16 (bfloat16x4_t __a)
+{
+  return __builtin_neon_vbfcvtv4bf (__a);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvtq_low_f32_bf16 (bfloat16x8_t __a)
+{
+  return __builtin_neon_vbfcvtv8bf (__a);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvtq_high_f32_bf16 (bfloat16x8_t __a)
+{
+  return __builtin_neon_vbfcvt_highv8bf (__a);
+}
+
+__extension__ extern __inline bfloat16x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvt_bf16_f32 (float32x4_t __a)
+{
+  return __builtin_neon_vbfcvtv4sfv4bf (__a);
+}
+
+__extension__ extern __inline bfloat16x8_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvtq_low_bf16_f32 (float32x4_t __a)
+{
+  return __builtin_neon_vbfcvtv4sfv8bf (__a);
+}
+
+/* The 'inactive' operand is not converted but it provides the
+   low 64 bits to assemble the final 128-bit result.  */
+__extension__ extern __inline bfloat16x8_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvtq_high_bf16_f32 (bfloat16x8_t inactive, float32x4_t __a)
+{
+  return __builtin_neon_vbfcvtv4sf_highv8bf (inactive, __a);
+}
+
+#pragma GCC pop_options
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/gcc/config/arm/arm_neon_builtins.def b/gcc/config/arm/arm_neon_builtins.def
index e9ff4e501cbb5d16b9211f5bc96db376ddf21afc..bc750895f994bff6799232ef2e63e27c9349e27d 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -373,3 +373,9 @@ VAR2 (MAC_LANE_PAIR, vcmlaq_lane0, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane90, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane180, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane270, v4sf, v8hf)
+
+VAR2 (UNOP, vbfcvt, sf, bf)
+VAR2 (UNOP, vbfcvt, v4bf, v8bf)
+VAR1 (UNOP, vbfcvt_high, v8bf)
+VAR2 (UNOP, vbfcvtv4sf, v4bf, v8bf)
+VAR1 (BINOP, vbfcvtv4sf_high, v8bf)
\ No newline at end of file
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index 33e29509f00a89fa23d0546687c0e4643f0b32d2..003de33bcddcec1c0d9682f775acdedf69c09ea8 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -229,6 +229,10 @@
 ;; Modes for polynomial or float values.
 

Re: [PR47785] COLLECT_AS_OPTIONS

[H.J. Lu]

On Tue, Jan 14, 2020 at 11:29 PM Prathamesh Kulkarni
 wrote:
>
> On Wed, 8 Jan 2020 at 15:50, Prathamesh Kulkarni
>  wrote:
> >
> > On Tue, 5 Nov 2019 at 17:38, Richard Biener  
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > >  wrote:
> > > >
> > > > Hi,
> > > > Thanks for the review.
> > > >
> > > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu  wrote:
> > > > >
> > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan Vivekanandarajah
> > > > >  wrote:
> > > > > >
> > > > > > Thanks for the reviews.
> > > > > >
> > > > > >
> > > > > > On Sat, 2 Nov 2019 at 02:49, H.J. Lu  wrote:
> > > > > > >
> > > > > > > On Thu, Oct 31, 2019 at 6:33 PM Kugan Vivekanandarajah
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Wed, 30 Oct 2019 at 03:11, H.J. Lu  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Richard,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Wed, 23 Oct 2019 at 23:07, Richard Biener 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Oct 21, 2019 at 10:04 AM Kugan Vivekanandarajah
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the pointers.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 11 Oct 2019 at 22:33, Richard Biener 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Oct 11, 2019 at 6:15 AM Kugan Vivekanandarajah
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 2 Oct 2019 at 20:41, Richard Biener 
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 10:39 AM Kugan 
> > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As mentioned in the PR, attached patch adds 
> > > > > > > > > > > > > > > > COLLECT_AS_OPTIONS for
> > > > > > > > > > > > > > > > passing assembler options specified with -Wa, 
> > > > > > > > > > > > > > > > to the link-time driver.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The proposed solution only works for uniform 
> > > > > > > > > > > > > > > > -Wa options across all
> > > > > > > > > > > > > > > > TUs. As mentioned by Richard Biener, supporting 
> > > > > > > > > > > > > > > > non-uniform -Wa flags
> > > > > > > > > > > > > > > > would require either adjusting partitioning 
> > > > > > > > > > > > > > > > according to flags or
> > > > > > > > > > > > > > > > emitting multiple object files  from a single 
> > > > > > > > > > > > > > > > LTRANS CU. We could
> > > > > > > > > > > > > > > > consider this as a follow up.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Bootstrapped and regression tests on  
> > > > > > > > > > > > > > > > arm-linux-gcc. Is this OK for trunk?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > While it works for your simple cases it is 
> > > > > > > > > > > > > > > unlikely to work in practice since
> > > > > > > > > > > > > > > your implementation needs the assembler options 
> > > > > > > > > > > > > > > be present at the link
> > > > > > > > > > > > > > > command line.  I agree that this might be the way 
> > > > > > > > > > > > > > > for people to go when
> > > > > > > > > > > > > > > they face the issue but then it needs to be 
> > > > > > > > > > > > > > > documented somewhere
> > > > > > > > > > > > > > > in the manual.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > That is, with COLLECT_AS_OPTION (why singular?  
> > > > > > > > > > > > > > > I'd expected
> > > > > > > > > > > > > > > COLLECT_AS_OPTIONS) available to cc1 we could 
> > > > > > > > > > > > > > > stream this string
> > > > > > > > > > > > > > > to lto_options and re-materialize it at link time 
> > > > > > > > > > > > > > > (and diagnose mismatches
> > > > > > > > > > > > > > > even if we like).
> > > > > > > > > > > > > > OK. I will try to implement this. So the idea is if 
> > > > > > > > > > > > > > we provide
> > > > > > > > > > > > > > -Wa,options as part of the lto compile, this should 
> > > > > > > > > > > > > > be available
> > > > > > > > > > > > > > during link time. Like in:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > arm-linux-gnueabihf-gcc -march=armv7-a -mthumb -O2 
> > > > > > > > > > > > > > -flto
> > > > > > > > > > > > > > -Wa,-mimplicit-it=always,-mthumb -c test.c
> > > > > > > > > > > > > > arm-linux-gnueabihf-gcc  -flto  test.o
> > > > > > > > > > > > 

RE: Make profile estimation more precise

[Tamar Christina]

Hi Honza,

This change seems to have cost a 0.2% regression in SPEC2017 vs a codesize 
reduction of 0.02%.

Only leela seems to have made any noticable difference at 2.64% codesize 
reduction.

Is there anyway to keep the performance at -O3 where the codesize doesn't 
matter much?

Thanks,
Tamar

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> On Behalf Of Jan Hubicka
> Sent: Thursday, January 16, 2020 23:00
> To: gcc-patches@gcc.gnu.org
> Subject: Make profile estimation more precise
> 
> Hi,
> while analyzing code size regression in SPEC2k GCC binary I noticed that we
> perform some inline decisions because we think that number of executions
> are very high.
> In particular there was inline decision inlining gen_rtx_fmt_ee to
> find_reloads believing that it is called 4 billion times.  This turned out to 
> be
> cummulation of roundoff errors in propagate_freq which was bit
> mechanically updated from original sreals to C++ sreals and later to new
> probabilities.
> 
> This led us to estimate that a loopback edge is reached with probability 2.3
> which was capped to 1-1/1 and since this happened in nested loop it
> quickly escalated to large values.
> 
> Originally capping to REG_BR_PROB_BASE avoided such problems but now
> we have much higher range.
> 
> This patch avoids going from probabilites to REG_BR_PROB_BASE so
> precision is kept.  In addition it makes the propagation to not estimate more
> than param-max-predicted-loop-iterations.  The first change makes the cap
> to not be triggered on the gcc build, but it is still better to be safe than 
> sorry.
> 
> 2020-01-16  Jan Hubicka  
> 
>   * ipa-fnsummary.c (estimate_calls_size_and_time): Fix formating of
>   dump.
>   * params.opt: (max-predicted-iterations): Set bounds.
>   * predict.c (real_almost_one, real_br_prob_base,
>   real_inv_br_prob_base, real_one_half, real_bb_freq_max): Remove.
>   (propagate_freq): Add max_cyclic_prob parameter; cap cyclic
>   probabilities; do not truncate to reg_br_prob_bases.
>   (estimate_loops_at_level): Pass max_cyclic_prob.
>   (estimate_loops): Compute max_cyclic_prob.
>   (estimate_bb_frequencies): Do not initialize real_*; update
> calculation
>   of back edge prob.
>   * profile-count.c (profile_probability::to_sreal): New.
>   * profile-count.h (class sreal): Move up in file.
>   (profile_probability::to_sreal): Declare.
> 
> diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c index
> 4e1c587b101..dbd53f12a40 100644
> --- a/gcc/ipa-fnsummary.c
> +++ b/gcc/ipa-fnsummary.c
> @@ -3258,7 +3258,7 @@ estimate_calls_size_and_time (struct cgraph_node
> *node, int *size,
> gcc_assert (*size == old_size);
> if (time && (*time - old_time > 1 || *time - old_time < -1)
> && dump_file)
> - fprintf (dump_file, "Time mismatch in call summary %f!=%f",
> + fprintf (dump_file, "Time mismatch in call summary %f!=%f\n",
>old_time.to_double (),
>time->to_double ());
>   }
> diff --git a/gcc/params.opt b/gcc/params.opt index
> 31cc20031b1..f02c769d0e3 100644
> --- a/gcc/params.opt
> +++ b/gcc/params.opt
> @@ -555,7 +555,7 @@ Common Joined UInteger
> Var(param_max_pow_sqrt_depth) Init(5) IntegerRange(1, 32)  Maximum
> depth of sqrt chains to use when synthesizing exponentiation by a real
> constant.
> 
>  -param=max-predicted-iterations=
> -Common Joined UInteger Var(param_max_predicted_iterations) Init(100)
> Param Optimization
> +Common Joined UInteger Var(param_max_predicted_iterations) Init(100)
> +IntegerRange(1, 65536) Param Optimization
>  The maximum number of loop iterations we predict statically.
> 
>  -param=max-reload-search-insns=
> diff --git a/gcc/predict.c b/gcc/predict.c index 02c5fe0667d..c3aed9ed854
> 100644
> --- a/gcc/predict.c
> +++ b/gcc/predict.c
> @@ -76,10 +76,6 @@ enum predictor_reason  static const char
> *reason_messages[] = {"", " (ignored)",
>  " (single edge duplicate)", " (edge pair duplicate)"};
> 
> -/* real constants: 0, 1, 1-1/REG_BR_PROB_BASE, REG_BR_PROB_BASE,
> -1/REG_BR_PROB_BASE, 0.5, BB_FREQ_MAX.  */
> -static sreal real_almost_one, real_br_prob_base,
> -  real_inv_br_prob_base, real_one_half, real_bb_freq_max;
> 
>  static void combine_predictions_for_insn (rtx_insn *, basic_block);  static
> void dump_prediction (FILE *, enum br_predictor, int, basic_block, @@ -
> 3266,7 +3262,8 @@ public:
> TOVISIT, starting in HEAD.  */
> 
>  static void
> -propagate_freq (basic_block head, bitmap tovisit)
> +propagate_freq (basic_block head, bitmap tovisit,
> + sreal max_cyclic_prob)
>  {
>basic_block bb;
>basic_block last;
> @@ -3322,22 +3319,14 @@ propagate_freq (basic_block head, bitmap tovisit)
> 
> FOR_EACH_EDGE (e, ei, bb->preds)
>   if (EDGE_INFO (e)->back_edge)
> -   {
> - cyclic_probability += EDGE_INFO (e)->back_edge_prob;
> - 

Re: limit on emails for merge commits.

[Jason Merrill]

On 1/17/20 9:22 AM, Joseph Myers wrote:

On Fri, 17 Jan 2020, Joel Brobecker wrote:


The main goal of the limit is really to avoid accidents where someone
pushes something he shouldn't or something he didn't realize would
push so many commits. If the GCC repository is such that merges of
100 commits or more is going to be, if not routine, at least to be
expected, then perhaps increasing the limit would make sense.


Such merges are routine.


What I would do is wait a bit and see. This may become moot soon,
depending on the direction that we want to take for vendor/user branches
with respect to emails. I'm still trying to think this over...


Even disregarding user/vendor branches (and thus disregarding the question
of "new" commits resulting from rebasing, discussed in Iain's last comment
on ), there is the matter
of shared refs/heads/devel/ branches (of which devel/c++-coroutines, the
one in the present discussion, is one).

Those branches are expected to have merges; the hooks prevent
non-fast-forward pushes to them.  They are expected to live for a long
time, since it's large and complicated projects that tend to use such
branches.  Merges may or may not be of more than 100 commits, depending on
how frequent they are.  It's expected that several such branches will be
active at once.  As shared projects, it's clear that commit mails for them
should go to gcc-cvs, even if we end up sending commit mails for user and
vendor branches to another list.  And if there are say ten such branches
active at once, we don't want that to result in every commit to master
being mailed to gcc-cvs eleven times, once when originally committed and
once when merged to each such branch.


Indeed.  Merge commits (where they are allowed) should produce a single 
email about the merge itself, perhaps containing a list of commits.


Jason

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

[Steve Kargl]

On Fri, Jan 17, 2020 at 09:29:33AM +0100, Tobias Burnus wrote:
> On 1/17/20 4:49 AM, Steve Kargl wrote:
> > On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> >> +type(t) :: foo
> >> +print *, foo(1)%a ! { dg-error "Function call can not contain a 
> >> reference" }
> > I do not understand this error message, and find it to be confusing.
> > foo(1)%a looks like an invalid array reference.  That is, foo is scalar
> > and foo(1) is an array element.
> 
> Well, we simply do not know whether "external" or "dimension" has been 
> forgotten. As "external" can also be determined by the use, we end up 
> regarding it as function reference…
> 
> Another example:
> 
> character(len=4):: str
> print *, str(1)(1:4)
> end
> 
> Maybe a more helpful error message is: "Unexpected junk after function 
> reference or missing dimension declaration for %s", sym->name)
> 
> (Or instead of "junk" the fancier variant of my previous email.)
> 

Gfortran probably should not try to guess what the user
thought s/he wanted.  The generic "Syntax error" would
seem to apply here.  To me, foo(1)%a looks much more like
an array reference rather than a function reference.

-- 
Steve

Re: [PATCH][AARCH64] Enable compare branch fusion

[Wilco Dijkstra]

Hi Richard,

> If you're able to say for the record which cores you tested, then that'd
> be good.

I've mostly checked it on Cortex-A57 - if there is any affect, it would be on
older cores.

> OK, thanks.  I agree there doesn't seem to be an obvious reason why this
> would pessimise any cores significantly.  And it looked from a quick
> check like all AArch64 cores give these compares the lowest in-use
> latency (as expected).

Indeed.

> We can revisit this if anyone finds any counterexamples.

Yes - it's unlikely there are any though!

Cheers,
Wilco





>

> --

> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c

> index 
> a3b18b381e1748f8fe5e522bdec4f7c850821fe8..1c32a3543bec4031cc9b641973101829c77296b5
>  100644

> --- a/gcc/config/aarch64/aarch64.c

> +++ b/gcc/config/aarch64/aarch64.c

> @@ -726,7 +726,7 @@ static const struct tune_params generic_tunings =

>    SVE_NOT_IMPLEMENTED, /* sve_width  */

>    4, /* memmov_cost  */

>    2, /* issue_rate  */

> -  (AARCH64_FUSE_AES_AESMC), /* fusible_ops  */

> +  (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops  */

>    "16:12",/* function_align.  */

>    "4",/* jump_align.  */

>    "8",/* loop_align.  */

> @@ -1130,7 +1130,7 @@ static const struct tune_params neoversen1_tunings =

>    SVE_NOT_IMPLEMENTED, /* sve_width  */

>    4, /* memmov_cost  */

>    3, /* issue_rate  */

> -  AARCH64_FUSE_AES_AESMC, /* fusible_ops  */

> +  (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops  */

>    "32:16",/* function_align.  */

>    "32:16",/* jump_align.  */

>    "32:16",/* loop_align.  */

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

[Martin Liška]

Ok, after personal discussion with Honza that I had,
we should be more conservative and prune only
a run-time TOP N counters before we merge them.
The patch does that. Can you please Honza test me the patch of Firefox?

Thanks,
Martin
>From 7fe1e6a59139ae00cefd1f5edf082d428952203e Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 15 Jan 2020 15:39:55 +0100
Subject: [PATCH] Smart relaxation of TOP N counter.

---
 gcc/profile.c |  9 +-
 libgcc/libgcov-driver.c   | 58 ++-
 libgcc/libgcov-profiler.c | 27 --
 3 files changed, 77 insertions(+), 17 deletions(-)

diff --git a/gcc/profile.c b/gcc/profile.c
index 6a2de21c3bd..1a6caf75a61 100644
--- a/gcc/profile.c
+++ b/gcc/profile.c
@@ -863,7 +863,14 @@ compute_value_histograms (histogram_values values, unsigned cfg_checksum,
 
   if (hist->type == HIST_TYPE_TOPN_VALUES
 	  || hist->type == HIST_TYPE_INDIR_CALL)
-	sort_hist_values (hist);
+	{
+	  /* Each count value is multiplied by GCOV_TOPN_VALUES.  */
+	  if (hist->hvalue.counters[2] != -1)
+	for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+	  hist->hvalue.counters[2 * i + 2] /= GCOV_TOPN_VALUES;
+
+	  sort_hist_values (hist);
+	}
 
   /* Time profiler counter is not related to any statement,
  so that we have to read the counter and set the value to
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index 1c07761b7f1..b71b0e3edac 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -213,6 +213,60 @@ static struct gcov_fn_buffer *fn_buffer;
 /* Including system dependent components. */
 #include "libgcov-driver-system.c"
 
+/* Prune TOP N value COUNTERS.  */
+
+static void
+prune_topn_counter (gcov_type *counters, gcov_type all)
+{
+  if (counters[1] == -1)
+return;
+
+  // TODO
+#if 0
+  fprintf (stderr, "prune_topn_counter for all=%d\n", all);
+  for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+fprintf (stderr, "%d:%d:%d\n", i, counters[2 * i], counters[2 * i + 1]);
+#endif
+
+  for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+{
+  if (counters[2 * i + 1] < all)
+	{
+	  counters[2 * i] = 0;
+	  counters[2 * i + 1] = 0;
+	}
+}
+}
+
+/* Prune counters so that they are ready to store or merge.  */
+
+static void
+prune_counters (struct gcov_info *gi)
+{
+  for (unsigned i = 0; i < gi->n_functions; i++)
+{
+  const struct gcov_fn_info *gfi = gi->functions[i];
+  const struct gcov_ctr_info *ci = gfi->ctrs;
+  for (unsigned j = 0; j < GCOV_COUNTERS; j++)
+	{
+	  if (gi->merge[j] == NULL)
+	continue;
+
+	  if (gi->merge[j] == __gcov_merge_topn)
+	{
+	  gcc_assert (!(ci->num % GCOV_TOPN_VALUES_COUNTERS));
+	  for (unsigned k = 0; k < (ci->num / GCOV_TOPN_VALUES_COUNTERS); k++)
+		{
+		  gcov_type *counters
+		= ci->values + (k * GCOV_TOPN_VALUES_COUNTERS);
+		  prune_topn_counter (counters + 1, *counters);
+		}
+	}
+	  ci++;
+	}
+}
+}
+
 /* This function merges counters in GI_PTR to an existing gcda file.
Return 0 on success.
Return -1 on error. In this case, caller will goto read_fatal.  */
@@ -429,9 +483,11 @@ dump_one_gcov (struct gcov_info *gi_ptr, struct gcov_filename *gf,
   struct gcov_summary summary = {};
   int error;
   gcov_unsigned_t tag;
-
   fn_buffer = 0;
 
+  /* Prune current counters before we merge them.  */
+  prune_counters (gi_ptr);
+
   error = gcov_exit_open_gcda_file (gi_ptr, gf);
   if (error == -1)
 return;
diff --git a/libgcc/libgcov-profiler.c b/libgcc/libgcov-profiler.c
index 9417904d462..39e3c523250 100644
--- a/libgcc/libgcov-profiler.c
+++ b/libgcc/libgcov-profiler.c
@@ -119,37 +119,34 @@ __gcov_topn_values_profiler_body (gcov_type *counters, gcov_type value,
 
   ++counters;
 
-  /* We have GCOV_TOPN_VALUES as we can keep multiple values
- next to each other.  */
-  unsigned sindex = 0;
-
   for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
 {
   if (value == counters[2 * i])
 	{
 	  if (use_atomic)
-	__atomic_fetch_add ([2 * i + 1], 1, __ATOMIC_RELAXED);
+	__atomic_fetch_add ([2 * i + 1], GCOV_TOPN_VALUES, __ATOMIC_RELAXED);
 	  else
-	counters[2 * i + 1]++;
+	counters[2 * i + 1] += GCOV_TOPN_VALUES;
 	  return;
 	}
   else if (counters[2 * i + 1] == 0)
 	{
 	  /* We found an empty slot.  */
 	  counters[2 * i] = value;
-	  counters[2 * i + 1] = 1;
+	  counters[2 * i + 1] = GCOV_TOPN_VALUES;
 	  return;
 	}
-
-  if (counters[2 * i + 1] < counters[2 * sindex + 1])
-	sindex = i;
 }
 
-  /* We haven't found an empty slot, then decrement the smallest.  */
-  if (use_atomic)
-__atomic_fetch_sub ([2 * sindex + 1], 1, __ATOMIC_RELAXED);
-  else
-counters[2 * sindex + 1]--;
+  /* We haven't found an empty slot, then decrement all
+ counter values by one.  */
+  for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+{
+  if (use_atomic)
+	__atomic_fetch_sub ([2 * i + 1], 1, __ATOMIC_RELAXED);
+  else
+	counters[2 * i + 1]--;
+}
 }
 

Re: limit on emails for merge commits.

[Joseph Myers]

On Fri, 17 Jan 2020, Richard Biener wrote:

> We also make sure (?) to not make them show up in bugzilla, right?

That's already done; the email-to-bugzilla-filtered script only passes 
commits to master and release branches (i.e., pushes that update those 
refs) to Bugzilla.

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

Re: limit on emails for merge commits.

[Richard Biener]

On January 17, 2020 3:22:11 PM GMT+01:00, Joseph Myers 
 wrote:
>On Fri, 17 Jan 2020, Joel Brobecker wrote:
>
>> The main goal of the limit is really to avoid accidents where someone
>> pushes something he shouldn't or something he didn't realize would
>> push so many commits. If the GCC repository is such that merges of
>> 100 commits or more is going to be, if not routine, at least to be
>> expected, then perhaps increasing the limit would make sense.
>
>Such merges are routine.
>
>> What I would do is wait a bit and see. This may become moot soon,
>> depending on the direction that we want to take for vendor/user
>branches
>> with respect to emails. I'm still trying to think this over...
>
>Even disregarding user/vendor branches (and thus disregarding the
>question 
>of "new" commits resulting from rebasing, discussed in Iain's last
>comment 
>on ), there is the
>matter 
>of shared refs/heads/devel/ branches (of which devel/c++-coroutines,
>the 
>one in the present discussion, is one).
>
>Those branches are expected to have merges; the hooks prevent 
>non-fast-forward pushes to them.  They are expected to live for a long 
>time, since it's large and complicated projects that tend to use such 
>branches.  Merges may or may not be of more than 100 commits, depending
>on 
>how frequent they are.  It's expected that several such branches will
>be 
>active at once.  As shared projects, it's clear that commit mails for
>them 
>should go to gcc-cvs, even if we end up sending commit mails for user
>and 
>vendor branches to another list.  And if there are say ten such
>branches 
>active at once, we don't want that to result in every commit to master 
>being mailed to gcc-cvs eleven times, once when originally committed
>and 
>once when merged to each such branch.

We also make sure (?) to not make them show up in bugzilla, right?

Richard. 

[C++ PATCH] PR c++/92531 - ICE with noexcept(lambda).

[Jason Merrill]

This was failing because uses_template_parms didn't recognize LAMBDA_EXPR as
a kind of expression.  Instead of trying to enumerate all the different
varieties of expression and then aborting if what's left isn't
error_mark_node, let's handle error_mark_node and then assume anything else
is an expression.

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

* pt.c (uses_template_parms): Don't try to enumerate all the
expression cases.
---
 gcc/cp/pt.c | 17 +++--
 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda25.C |  7 +++
 2 files changed, 10 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda25.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 872f8ff8f52..1b3d07b1a52 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10537,22 +10537,11 @@ uses_template_parms (tree t)
   || uses_template_parms (TREE_CHAIN (t)));
   else if (TREE_CODE (t) == TYPE_DECL)
 dependent_p = dependent_type_p (TREE_TYPE (t));
-  else if (DECL_P (t)
-  || EXPR_P (t)
-  || TREE_CODE (t) == TEMPLATE_PARM_INDEX
-  || TREE_CODE (t) == OVERLOAD
-  || BASELINK_P (t)
-  || identifier_p (t)
-  || TREE_CODE (t) == TRAIT_EXPR
-  || TREE_CODE (t) == CONSTRUCTOR
-  || CONSTANT_CLASS_P (t))
+  else if (t == error_mark_node)
+dependent_p = false;
+  else
 dependent_p = (type_dependent_expression_p (t)
   || value_dependent_expression_p (t));
-  else
-{
-  gcc_assert (t == error_mark_node);
-  dependent_p = false;
-}
 
   processing_template_decl = saved_processing_template_decl;
 
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda25.C 
b/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda25.C
new file mode 100644
index 000..74db03ff569
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda25.C
@@ -0,0 +1,7 @@
+// PR c++/92531
+// { dg-do compile { target c++17 } }
+
+template 
+void ky () noexcept ([]{}); // IFNDR
+// Optional error: void(*)() to bool conv in converted constant expression
+// { dg-prune-output "converted constant expression" }

base-commit: bf09d886a4be1031f7003073115af6cbc5575353
-- 
2.18.1

Re: limit on emails for merge commits.

[Joseph Myers]

On Fri, 17 Jan 2020, Joel Brobecker wrote:

> The main goal of the limit is really to avoid accidents where someone
> pushes something he shouldn't or something he didn't realize would
> push so many commits. If the GCC repository is such that merges of
> 100 commits or more is going to be, if not routine, at least to be
> expected, then perhaps increasing the limit would make sense.

Such merges are routine.

> What I would do is wait a bit and see. This may become moot soon,
> depending on the direction that we want to take for vendor/user branches
> with respect to emails. I'm still trying to think this over...

Even disregarding user/vendor branches (and thus disregarding the question 
of "new" commits resulting from rebasing, discussed in Iain's last comment 
on ), there is the matter 
of shared refs/heads/devel/ branches (of which devel/c++-coroutines, the 
one in the present discussion, is one).

Those branches are expected to have merges; the hooks prevent 
non-fast-forward pushes to them.  They are expected to live for a long 
time, since it's large and complicated projects that tend to use such 
branches.  Merges may or may not be of more than 100 commits, depending on 
how frequent they are.  It's expected that several such branches will be 
active at once.  As shared projects, it's clear that commit mails for them 
should go to gcc-cvs, even if we end up sending commit mails for user and 
vendor branches to another list.  And if there are say ten such branches 
active at once, we don't want that to result in every commit to master 
being mailed to gcc-cvs eleven times, once when originally committed and 
once when merged to each such branch.

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

Re: [C++ PATCH] Fix deprecated attribute handling on templates (PR c++/93228)

[Jason Merrill]

On 1/10/20 3:28 PM, Jakub Jelinek wrote:

Hi!

As the following testcase shows, when deprecated attribute is on a template,
we'd never print the message if any, because the attribute is not
present on the TEMPLATE_DECL with which warn_deprecated_use is called,
but on its DECL_TEMPLATE_RESULT or its type.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2020-01-10  Jakub Jelinek  

PR c++/93228
* parser.c (cp_parser_template_name): Look up deprecated attribute
in DECL_TEMPLATE_RESULT or its type's attributes.


OK.

Jason

Re: [PATCH] Fix ICE caused by swallowing a token in c_parser_consume_token

[Jakub Jelinek]

On Fri, Jan 17, 2020 at 09:07:01AM -0500, Jason Merrill wrote:
> On 12/30/19 3:51 PM, Kerem Kat wrote:
> > +/* { dg-message "expected" "expected" { target *-*-* } .3 } */
> 
> Dejagnu doesn't like this:
> 
> ERROR: c-c++-common/pr92833-4.c  -std=c++98: expected integer but got ".3"
> for " dg-message 4 "expected" "expected" { target *-*-* } .3 "

Yeah, it can handle .-3 if you want 3 lines before the one with dg-message,
or .+3 if you want 3 lines after it, or . for current line (then you can
leave that and target out), or exact line number, or some symbolic name if
earlier marked.

Jakub

Re: [PATCH] Fix ICE caused by swallowing a token in c_parser_consume_token

[Jason Merrill]

On 12/30/19 3:51 PM, Kerem Kat wrote:

+/* { dg-message "expected" "expected" { target *-*-* } .3 } */


Dejagnu doesn't like this:

ERROR: c-c++-common/pr92833-4.c  -std=c++98: expected integer but got 
".3" for " dg-message 4 "expected" "expected" { target *-*-* } .3 "


Jason

[PR 93306] short circuit has_include

[Nathan Sidwell]

As Jonathan discovered,
#if FALSE_THING && has_include 
still goes look for foo.

This patch makes the has_include evaluator check skip_eval before 
looking for foo -- but after parsing the has_include to diagnose 
ill-formedness.


Sadly, no testcase, because it's pretty much only observable via strace, 
which I did manually.


nathan
--
Nathan Sidwell
2020-01-17  Nathan Sidwell  

	PR preprocessor/93306
	* expr.c (parse_has_include): Refactor.  Check skip_eval before
	looking.

diff --git c/libcpp/expr.c w/libcpp/expr.c
index 1078c0722f6..317faf50208 100644
--- c/libcpp/expr.c
+++ w/libcpp/expr.c
@@ -2195,11 +2195,6 @@ static cpp_num
 parse_has_include (cpp_reader *pfile, enum include_type type)
 {
   cpp_num result;
-  bool paren = false;
-  cpp_hashnode *node = 0;
-  const cpp_token *token;
-  bool bracket = false;
-  char *fname = 0;
 
   result.unsignedp = false;
   result.high = 0;
@@ -2208,39 +2203,34 @@ parse_has_include (cpp_reader *pfile, enum include_type type)
 
   pfile->state.in__has_include__++;
 
-  token = cpp_get_token (pfile);
-  if (token->type == CPP_OPEN_PAREN)
-{
-  paren = true;
-  token = cpp_get_token (pfile);
-}
+  const cpp_token *token = cpp_get_token (pfile);
+  bool paren = token->type == CPP_OPEN_PAREN;
+  if (paren)
+token = cpp_get_token (pfile);
 
+  bool bracket = token->type != CPP_STRING;
+  cpp_hashnode *node = NULL;
+  char *fname = NULL;
   if (token->type == CPP_STRING || token->type == CPP_HEADER_NAME)
 {
-  if (token->type == CPP_HEADER_NAME)
-	bracket = true;
   fname = XNEWVEC (char, token->val.str.len - 1);
   memcpy (fname, token->val.str.text + 1, token->val.str.len - 2);
   fname[token->val.str.len - 2] = '\0';
   node = token->val.node.node;
 }
   else if (token->type == CPP_LESS)
-{
-  bracket = true;
-  fname = _cpp_bracket_include (pfile);
-}
+fname = _cpp_bracket_include (pfile);
   else
 cpp_error (pfile, CPP_DL_ERROR,
 	   "operator \"__has_include__\" requires a header string");
 
   if (fname)
 {
-  int angle_brackets = (bracket ? 1 : 0);
-
-  if (_cpp_has_header (pfile, fname, angle_brackets, type))
+  /* Do not do the lookup if we're skipping, that's unnecessary
+	 IO.  */
+  if (!pfile->state.skip_eval
+	  && _cpp_has_header (pfile, fname, bracket, type))
 	result.low = 1;
-  else
-	result.low = 0;
 
   XDELETEVEC (fname);
 }

Patch ping (was Re: [C++ PATCH] Fix deprecated attribute handling on templates (PR c++/93228))

[Jakub Jelinek]

Hi!

I'd like to ping following patch.  Thanks.

On Fri, Jan 10, 2020 at 09:28:20PM +0100, Jakub Jelinek wrote:
> 2020-01-10  Jakub Jelinek  
> 
>   PR c++/93228
>   * parser.c (cp_parser_template_name): Look up deprecated attribute
>   in DECL_TEMPLATE_RESULT or its type's attributes.
> 
>   * g++.dg/cpp1y/attr-deprecated-3.C: New test.
> 
> --- gcc/cp/parser.c.jj2020-01-10 17:52:48.084062620 +0100
> +++ gcc/cp/parser.c   2020-01-10 19:15:29.019861630 +0100
> @@ -16882,7 +16882,17 @@ cp_parser_template_name (cp_parser* pars
>  {
>if (TREE_DEPRECATED (decl)
> && deprecated_state != DEPRECATED_SUPPRESS)
> - warn_deprecated_use (decl, NULL_TREE);
> + {
> +   tree d = DECL_TEMPLATE_RESULT (decl);
> +   tree attr;
> +   if (TREE_CODE (d) == TYPE_DECL)
> + attr = lookup_attribute ("deprecated",
> +  TYPE_ATTRIBUTES (TREE_TYPE (d)));
> +   else
> + attr = lookup_attribute ("deprecated",
> +  DECL_ATTRIBUTES (d));
> +   warn_deprecated_use (decl, attr);
> + }
>  }
>else
>  {
> --- gcc/testsuite/g++.dg/cpp1y/attr-deprecated-3.C.jj 2020-01-10 
> 19:20:44.165196267 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/attr-deprecated-3.C2020-01-10 
> 19:20:48.699129148 +0100
> @@ -0,0 +1,13 @@
> +// PR c++/93228
> +// { dg-do compile { target c++14 } }
> +
> +template 
> +struct [[deprecated("foo")]] bar {}; // { dg-message "declared here" }
> +struct [[deprecated("baz")]] qux {}; // { dg-message "declared here" 
> }
> +
> +void
> +quux ()
> +{
> +  bar b;// { dg-warning "is deprecated: foo" }
> +  qux c; // { dg-warning "is deprecated: baz" }
> +}
> 

Jakub

[committed] aarch64: Don't raise FE_INVALID for -__builtin_isgreater [PR93133]

[Richard Sandiford]

AIUI, the main purpose of REVERSE_CONDITION is to take advantage of
any integer vs. FP information encoded in the CC mode, particularly
when handling LT, LE, GE and GT.  For integer comparisons we can
safely map LT->GE, LE->GT, GE->LT and GT->LE, but for float comparisons
this would usually be invalid without -ffinite-math-only.

The aarch64 definition of REVERSE_CONDITION used
reverse_condition_maybe_unordered for FP comparisons, which had the
effect of converting an unordered-signalling LT, LE, GE or GT into a
quiet UNGE, UNGT, UNLT or UNLE.  And it would do the same in reverse:
convert a quiet UN* into an unordered-signalling comparison.

This would be safe in practice (although a little misleading) if we
always used a compare:CCFP or compare:CCFPE to do the comparison and
then used (gt (reg:CCFP/CCFPE CC_REGNUM) (const_int 0)) etc. to test
the result.  In that case any signal is raised by the compare and the
choice of quiet vs. signalling relations doesn't matter when testing
the result.  The problem is that we also want to use GT directly on
float registers, where any signal is raised by the comparison operation
itself and so must follow the normal rtl rules (GT signalling,
UNLE quiet).

I think the safest fix is to make REVERSIBLE_CC_MODE return false
for FP comparisons.  We can then use the default REVERSE_CONDITION
for integer comparisons and the usual conservatively-correct
reversed_comparison_code_parts behaviour for FP comparisons.
Unfortunately reversed_comparison_code_parts doesn't yet handle
-ffinite-math-only, but that's probably GCC 11 material.

A downside is that:

int f (float x, float y) { return !(x < y); }

now generates:

fcmpe   s0, s1
csetw0, mi
eor w0, w0, 1
ret

without -ffinite-math-only.  Maybe for GCC 11 we should define rtx
codes for all IEEE comparisons, so that we don't have this kind of
representational gap.

Changing REVERSE_CONDITION itself is pretty easy.  However, the macro
was also used in the ccmp handling, which relied on being able to
reverse all comparisons.  The patch adds new reversed patterns for
cases in which the original condition needs to be kept.

The test is based on gcc.dg/torture/pr91323.c.  It might well fail
on other targets that have similar bugs; please XFAIL as appropriate
if you don't want to fix the target for GCC 10.

Tested on aarch64-linux-gnu, applied.

Richard


2020-01-17  Richard Sandiford  

gcc/
* config/aarch64/aarch64.h (REVERSIBLE_CC_MODE): Return false
for FP modes.
(REVERSE_CONDITION): Delete.
* config/aarch64/iterators.md (CC_ONLY): New mode iterator.
(CCFP_CCFPE): Likewise.
(e): New mode attribute.
* config/aarch64/aarch64.md (ccmp): Rename to...
(@ccmp): ...this, using CC_ONLY instead of CC.
(fccmp, fccmpe): Merge into...
(@ccmp): ...this combined pattern.
(@ccmp_rev): New pattern.
(@ccmp_rev): Likewise.
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Update
name of generator from gen_ccmpdi to gen_ccmpccdi.
(aarch64_gen_ccmp_next): Use code_for_ccmp.  If we want to reverse
the previous comparison but aren't able to, use the new ccmp_rev
patterns instead.
---
 gcc/config/aarch64/aarch64.c   | 30 
 gcc/config/aarch64/aarch64.h   | 10 ++--
 gcc/config/aarch64/aarch64.md  | 64 ++
 gcc/config/aarch64/iterators.md|  6 +++
 gcc/testsuite/gcc.dg/torture/pr93133.c | 41 +
 5 files changed, 116 insertions(+), 35 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr93133.c

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 600a238c1f4..3660ce7bde0 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2345,9 +2345,9 @@ aarch64_gen_compare_reg (RTX_CODE code, rtx x, rtx y)
 
   rtx x_hi = operand_subword (x, 1, 0, TImode);
   rtx y_hi = operand_subword (y, 1, 0, TImode);
-  emit_insn (gen_ccmpdi (cc_reg, cc_reg, x_hi, y_hi,
-gen_rtx_EQ (cc_mode, cc_reg, const0_rtx),
-GEN_INT (AARCH64_EQ)));
+  emit_insn (gen_ccmpccdi (cc_reg, cc_reg, x_hi, y_hi,
+  gen_rtx_EQ (cc_mode, cc_reg, const0_rtx),
+  GEN_INT (AARCH64_EQ)));
 }
   else
 {
@@ -20270,24 +20270,20 @@ aarch64_gen_ccmp_next (rtx_insn **prep_seq, rtx_insn 
**gen_seq, rtx prev,
 case E_HImode:
 case E_SImode:
   cmp_mode = SImode;
-  icode = CODE_FOR_ccmpsi;
   break;
 
 case E_DImode:
   cmp_mode = DImode;
-  icode = CODE_FOR_ccmpdi;
   break;
 
 case E_SFmode:
   cmp_mode = SFmode;
   cc_mode = aarch64_select_cc_mode ((rtx_code) cmp_code, op0, op1);
-  icode = cc_mode == CCFPEmode ? CODE_FOR_fccmpesf : CODE_FOR_fccmpsf;
   break;
 
 case E_DFmode:
   cmp_mode = 

[PATCH] Fix gcc.dg/torture/pr91323.c for aarch64 targets

[Richard Sandiford]

PR91323 was fixed for x86 and sparc in target code, but aarch64
instead relies on the target-independent comparison splitters.
Since LTGT is an unordered-signalling operation, we should split
it into unordered-signalling operations for any input that could
be NaN, not just inputs that could be signalling NaNs.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2020-01-17  Richard Sandiford  

gcc/
* dojump.c (split_comparison): Use HONOR_NANS rather than
HONOR_SNANS when splitting LTGT.
---
 gcc/dojump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/dojump.c b/gcc/dojump.c
index 7bf578a7178..28b47b7ab6d 100644
--- a/gcc/dojump.c
+++ b/gcc/dojump.c
@@ -897,7 +897,7 @@ split_comparison (enum rtx_code code, machine_mode mode,
   return false;
 case LTGT:
   /* Do not turn a trapping comparison into a non-trapping one.  */
-  if (HONOR_SNANS (mode))
+  if (HONOR_NANS (mode))
{
   *code1 = LT;
   *code2 = GT;

Re: [patch] contrib: Don't add push rules for personal and vendor spaces.

[Richard Earnshaw (lists)]

On 16/01/2020 15:00, Jakub Jelinek wrote:

On Wed, Jan 15, 2020 at 10:48:23PM +, Joseph Myers wrote:

A reasonable replacement for those push rules might be command aliases
(e.g. "git upush " to push the user branch ).


Would we have then separate aliases for pushing to one vendor branch and
another vendor branch?
Couldn't one alias determine from the branch remote and merge and
perhaps the fetch rules figure out the right git push arguments
given the setup (e.g. treat $(git config --get gcc-config.userpfx)
and $(git config --get gcc-config.user) as push to user branch,
devel/*, master, releases/* as normal git push and the rest as vendors
(or let git-fetch-vendor.sh record list of all used vendors in some gcc-config
setting)?

Jakub



I think the new proposed remotes structure should eliminate most of the 
concerns about unsafe push rules; at worst you will only push everything 
related to the 'remote' that your current branch is on.


So I think having more aliases is now unnecessary.

R.

Re: contrib: Check and if needed set user.name and user.email in gcc-git-customization.sh

[Richard Earnshaw (lists)]

On 16/01/2020 14:49, Andreas Schwab wrote:

On Jan 16 2020, Richard Earnshaw (lists) wrote:


diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index dae2c35bb57..1cde6fd8224 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -11,9 +11,9 @@ ask () {
  read answer
  if [ "x$answer" = "x" ]
  then
-   eval $var=$default
+   eval $var=\"$default\"
  else
-   eval $var=$answer
+   eval $var=\"$answer\"


This still isn't the safe way to do indirect assignment.  The expansion
of the rhs needs to be delayed, so that the result isn't subject to
further expansions.

Andreas.

Subject: [PATCH] gcc-git-customization.sh: avoid double expansion

---
  contrib/gcc-git-customization.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index b7e4ce308062..26f4389bcc8a 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -11,9 +11,9 @@ ask () {
  read answer
  if [ "x$answer" = "x" ]
  then
-   eval $var=\"$default\"
+   eval $var=\$default
  else
-   eval $var=\"$answer\"
+   eval $var=\$answer
  fi
  }
  



OK.

[v2] contrib: New remotes structure for vendor and personal refs

[Richard Earnshaw (lists)]

The initial structure for vendor and personal branches makes use of the 
default remote (normally origin) for the upstream repository). 
Unfortunately, this causes some confusion, especially for personal 
branches because a push will not push to the correct upstream location. 
This can be 'fixed' by adding a push refspec for the remote, but that 
has the unfortunate consequence of breaking the push.default behaviour 
for git push, and it becomes too easy to accidentally commit something 
unintended to the main parts of the repository.


To work around this, this patch changes the configuration to use 
separate 'remotes' for these additional refs, with one remote for the 
personal space and another remote for each vendor's space.  The personal 
space is called after the user's preferred branch-space prefix (default 
'me'), the vendor spaces are called vendors/.


As far as possible, I've made the script automatically restructure any 
existing fetch or push lines that earlier versions of the scripts may 
have created - the gcc-git-customization.sh script will convert all 
vendor refs that it can find, so it is not necessary to re-add any 
vendors you've already added.


You might, however, want to run
  git remote prune 
after running to clean up any stale upstream-refs that might still be in 
your local repo, and then

  git fetch vendors/
or
  git fetch 
to re-populate the remotes/ structures.

Also, for any branch you already have that tracks a personal or vendor 
branch upstream, you might need to run

  git config branch..remote 

so that merges and pushes go to the right place (I haven't attempted to 
automate this last part).


For vendors, the new structure means that

  git checkout -b / remotes/vendors//

will correctly set up a remote tracking branch.

Please be aware that if you have multiple personal branches set up, then

  git push 

will still consider all of them for pushing.  If you only want to push 
one branch, then either write

  git push  HEAD
or
  git push  /branch
as appropriate.

And don't forget '-n' (--dry-run) to see what would be done if this were 
not a dry run.


Finally, now that the vendors spaces are isolated from each other and 
from the other spaces, I've added an option "--enable-push" to 
git-fetch-vendor.sh.  If passed, then a "push" spec will be added for 
that vendor to enable pushing to the upstream.  If you re-run the script 
for the same vendor without the option, the push spec will be removed.


* gcc-git-customization.sh: New personal and vendor layout.
Convert any existing fetch/push rules to new layout.
* git-fetch-vendor.sh: New vendor layout.  Add --enable-push
option.
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 26f4389bcc8..c16db747503 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -81,6 +81,13 @@ then
 upstream="origin"
 fi
 ask "Local name for upstream repository" "origin" upstream
+
+v=$(git config --get-all "remote.${upstream}.fetch")
+if [ "x$v" = "x" ]
+then
+echo "Remote $upstream does not seem to exist as a remote"
+exit 1
+fi
 git config "gcc-config.upstream" "$upstream"
 
 remote_id=$(git config --get "gcc-config.user")
@@ -100,6 +107,7 @@ then
 	fi
 fi
 fi
+
 ask "Account name on gcc.gnu.org (for your personal branches area)" $remote_id remote_id
 git config "gcc-config.user" "$remote_id"
 
@@ -108,27 +116,44 @@ if [ "x$old_pfx" = "x" ]
 then
 old_pfx="me"
 fi
+echo
 echo "Local branch prefix for personal branches you want to share"
 echo "(local branches starting / can be pushed directly to your"
 ask "personal area on the gcc server)" $old_pfx new_pfx
 git config "gcc-config.userpfx" "$new_pfx"
 
-echo "Setting up tracking for personal namespace $remote_id in remotes/$upstream/${new_pfx}"
-git config --replace-all "remote.${upstream}.fetch" "+refs/users/${remote_id}/heads/*:refs/remotes/${upstream}/${new_pfx}/*" ":refs/remotes/${upstream}/${old_pfx}/"
-git config --replace-all "remote.${upstream}.fetch" "+refs/users/${remote_id}/tags/*:refs/tags/${new_pfx}/*" ":refs/tags/${old_pfx}/"
+# Scan the existing settings to see if there are any we need to rewrite.
+vendors=$(git config --get-all "remote.${upstream}.fetch" "refs/vendors/" | sed -r "s:.*refs/vendors/([^/]+)/.*:\1:" | sort | uniq)
+url=$(git config --get "remote.${upstream}.url")
+pushurl=$(git config --get "remote.${upstream}.pushurl")
+for v in $vendors
+do
+echo "Migrating vendor $v to new remote vendors/$v"
+git config --unset-all "remote.${upstream}.fetch" "refs/vendors/$v/"
+git config --unset-all "remote.${upstream}.push" "refs/vendors/$v/"
+git config "remote.vendors/${v}.url" "${url}"
+if [ "x$pushurl" != "x" ]
+then
+	git config "remote.vendors/${v}.pushurl" "${pushurl}"
+fi
+git config --add "remote.vendors/${v}.fetch" "+refs/vendors/$v/heads/*:refs/remotes/vendors/${v}/*"
+git config --add 

Re: [PATCH] [ARC] Use hardware support for double-precision compare instructions.

[Claudiu Zissulescu Ianculescu]

It is already ported :)
https://github.com/gcc-mirror/gcc/commit/555e4a053951a0ae24835a266e71819336d7f637#diff-5b8bd26eec6c2b9f560870c205416edc

Cheers,
Claudiu

On Wed, Jan 15, 2020 at 1:49 AM Vineet Gupta  wrote:
>
> On 12/9/19 1:52 AM, Claudiu Zissulescu wrote:
> > Although the FDCMP (the double precision floating point compare 
> > instruction) is added to the compiler, it is not properly used via cstoredi 
> > pattern. Fix it.
> >
> > OK to apply?
> > Claudidu
> >
> > -xx-xx  Claudiu Zissulescu  
> >
> >   * config/arc/arc.md (iterator SDF): Check TARGET_FP_DP_BASE.
> >   (cstoredi4): Use TARGET_HARD_FLOAT.
> > ---
> >  gcc/config/arc/arc.md | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
> > index b592f25afce..bd44030b409 100644
> > --- a/gcc/config/arc/arc.md
> > +++ b/gcc/config/arc/arc.md
> > @@ -3749,7 +3749,7 @@ archs4x, archs4xd"
> >  })
> >
> >  (define_mode_iterator SDF [(SF "TARGET_FP_SP_BASE || TARGET_OPTFPE")
> > -(DF "TARGET_OPTFPE")])
> > +(DF "TARGET_FP_DP_BASE || TARGET_OPTFPE")])
> >
> >  (define_expand "cstore4"
> >[(set (reg:CC CC_REG)
> > @@ -3759,7 +3759,7 @@ archs4x, archs4xd"
> >   (match_operator:SI 1 "comparison_operator" [(reg CC_REG)
> >   (const_int 0)]))]
> >
> > -  "TARGET_FP_SP_BASE || TARGET_OPTFPE"
> > +  "TARGET_HARD_FLOAT || TARGET_OPTFPE"
> >  {
> >gcc_assert (XEXP (operands[1], 0) == operands[2]);
> >gcc_assert (XEXP (operands[1], 1) == operands[3]);
>
> Can this be backported to gcc-9 please ?
> glibc testing uses gcc-9
>
> Thx,
> -Vineet

Re: [PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions

[Mihail Ionescu]

Hi Jakub,

On 01/17/2020 08:37 AM, Jakub Jelinek wrote:

On Wed, Dec 18, 2019 at 05:00:01PM +, Mihail Ionescu wrote:

2019-12-18  Mihail Ionescu  
2019-12-18  Andre Vieira  

* config/arm/arm-cpus.in (mve, mve_float): New features.
(dsp, mve, mve.fp): New options.


Note, the above is not the right ChangeLog formatting when you have more
than one author.  The date should be there only for the first line, for the
other authors there should be just tab and 4 spaces, otherwise various tools
that parse ChangeLog entries will be quite confused.  So like:
2019-12-18  Mihail Ionescu  
Andre Vieira  

I've fixed your commits in 2b3534a3122236d6317256f16daa332278391907
but please remember this next time.

Thanks.

Jakub



Thank you, I did not realise that I wasn't using the correct formatting 
style. I'll keep that in mind for next time.



Regards,
Mihail

Re: [PATCH, GCC/ARM, 1/2] Add support for ASRL(reg) and LSLL(reg) instructions for Armv8.1-M Mainline

[Kyrill Tkachov]

On 12/18/19 1:23 PM, Mihail Ionescu wrote:



Hi Kyrill,

On 12/11/2019 05:50 PM, Kyrill Tkachov wrote:
> Hi Mihail,
>
> On 11/14/19 1:54 PM, Mihail Ionescu wrote:
>> Hi,
>>
>> This patch adds the new scalar shift instructions for Armv8.1-M
>> Mainline to the arm backend.
>> This patch is adding the following instructions:
>>
>> ASRL (reg)
>> LSLL (reg)
>>
>
> Sorry for the delay, very busy time for GCC development :(
>
>
>>
>> ChangeLog entry are as follow:
>>
>> *** gcc/ChangeLog ***
>>
>>
>> 2019-11-14  Mihail-Calin Ionescu 
>> 2019-11-14  Sudakshina Das 
>>
>>     * config/arm/arm.h (TARGET_MVE): New macro for MVE support.
>
>
> I don't see this hunk in the patch... There's a lot of v8.1-M-related
> patches in flight. Is it defined elsewhere?

Thanks for having a look at this.
Yes, I forgot to remove that bit from the ChangeLog and mention that the
patch depends on the Armv8.1-M MVE CLI --
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00641.htm which introduces
the required TARGET_* macros needed. I've updated the ChangeLog to
reflect that:

*** gcc/ChangeLog ***


2019-12-18  Mihail-Calin Ionescu 
2019-12-18  Sudakshina Das  

    * config/arm/arm.md (ashldi3): Generate thumb2_lsll for 
TARGET_HAVE_MVE.

    (ashrdi3): Generate thumb2_asrl for TARGET_HAVE_MVE.
    * config/arm/arm.c (arm_hard_regno_mode_ok): Allocate even odd
    register pairs for doubleword quantities for ARMv8.1M-Mainline.
    * config/arm/thumb2.md (thumb2_asrl): New.
    (thumb2_lsll): Likewise.

>
>
>>     * config/arm/arm.md (ashldi3): Generate thumb2_lsll for
>> TARGET_MVE.
>>     (ashrdi3): Generate thumb2_asrl for TARGET_MVE.
>>     * config/arm/arm.c (arm_hard_regno_mode_ok): Allocate even odd
>>     register pairs for doubleword quantities for ARMv8.1M-Mainline.
>>     * config/arm/thumb2.md (thumb2_asrl): New.
>>     (thumb2_lsll): Likewise.
>>
>> *** gcc/testsuite/ChangeLog ***
>>
>> 2019-11-14  Mihail-Calin Ionescu 
>> 2019-11-14  Sudakshina Das 
>>
>>     * gcc.target/arm/armv8_1m-shift-reg_1.c: New test.
>>
>> Testsuite shows no regression when run for arm-none-eabi targets.
>>
>> Is this ok for trunk?
>>
>> Thanks
>> Mihail
>>
>>
>> ### Attachment also inlined for ease of reply
>> ###
>>
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index
>> 
be51df7d14738bc1addeab8ac5a3806778106bce..bf788087a30343269b30cf7054ec29212ad9c572 


>> 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -24454,14 +24454,15 @@ arm_hard_regno_mode_ok (unsigned int regno,
>> machine_mode mode)
>>
>>    /* We allow almost any value to be stored in the general registers.
>>   Restrict doubleword quantities to even register pairs in ARM 
state

>> - so that we can use ldrd.  Do not allow very large Neon structure
>> - opaque modes in general registers; they would use too many.  */
>> + so that we can use ldrd and Armv8.1-M Mainline instructions.
>> + Do not allow very large Neon structure opaque modes in general
>> + registers; they would use too many.  */
>
>
> This comment now reads:
>
> "Restrict doubleword quantities to even register pairs in ARM state
>   so that we can use ldrd and Armv8.1-M Mainline instructions."
>
> Armv8.1-M Mainline is not ARM mode though, so please clarify this
> comment further.
>
> Looks ok to me otherwise (I may even have merged this with the second
> patch, but I'm not complaining about keeping it simple :) )
>
> Thanks,
>
> Kyrill
>

I've now updated the comment to read:
"Restrict doubleword quantities to even register pairs in ARM state
so that we can use ldrd. The same restriction applies for MVE."



Ok.

Thanks,

Kyril




Regards,
Mihail

>
>>    if (regno <= LAST_ARM_REGNUM)
>>  {
>>    if (ARM_NUM_REGS (mode) > 4)
>>  return false;
>>
>> -  if (TARGET_THUMB2)
>> +  if (TARGET_THUMB2 && !TARGET_HAVE_MVE)
>>  return true;
>>
>>    return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno & 1)
>> != 0);
>> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
>> index
>> 
a91a4b941c3f9d2c3d443f9f4639069ae953fb3b..b735f858a6a5c94d02a6765c1b349cdcb5e77ee3 


>> 100644
>> --- a/gcc/config/arm/arm.md
>> +++ b/gcc/config/arm/arm.md
>> @@ -3503,6 +3503,22 @@
>>     (match_operand:SI 2 "reg_or_int_operand")))]
>>    "TARGET_32BIT"
>>    "
>> +  if (TARGET_HAVE_MVE)
>> +    {
>> +  if (!reg_or_int_operand (operands[2], SImode))
>> +    operands[2] = force_reg (SImode, operands[2]);
>> +
>> +  /* Armv8.1-M Mainline double shifts are not expanded.  */
>> +  if (REG_P (operands[2]))
>> +   {
>> + if (!reg_overlap_mentioned_p(operands[0], operands[1]))
>> +   emit_insn (gen_movdi (operands[0], operands[1]));
>> +
>> + emit_insn (gen_thumb2_lsll (operands[0], operands[2]));
>> + DONE;
>> +   }
>> +    }
>> +
>>    arm_emit_coreregs_64bit_shift (ASHIFT, 

Re: Deque rotate on current node

[Jonathan Wakely]

On 20/05/19 07:39 +0200, François Dumont wrote:

Hi

  std::deque is supposed to be like a double-queue that you can attack 
from front and back. But currrently its implementation makes it behave 
differently when starting from a fresh deque. If push_back then all 
goes well, it is copy/move to the current internal 'node'. If 
push_front then a new 'node' is created and on next pop_back the 
initial node will be deallocated without having ever be used.


  This patch changes this behavior. As long as deque is empty we can 
play with its state to make it push_back- or push_front-ready. It will 
also benefit to the usage of deque in the std::stack.


  More generally it could really improve scenario in which deque is 
used as queue of elements exchanged between different threads. As you 
need to make sure that consumers are faster than producers then your 
deque should remain empty most of the time and so this proposed patch 
should avoid nodes to be allocated/deallocated all the time.


This benefits the case where you always push at the same end. But with
your patch if I do push_front then push_back,
we still allocate a second node even though the first one is nearly
empty.

Would it be better to point into the middle of the node, not right at
the end or right at the beginning?


    * include/bits/deque.tcc (deque<>::_M_push_back_aux):
    Rotate on current node if deque is empty.
    (deue<>::_M_push_front_aux): Likewise.

Tested under Linux x86_64, ok to commit ?

François




diff --git a/libstdc++-v3/include/bits/deque.tcc 
b/libstdc++-v3/include/bits/deque.tcc
index 2053afe1d69..245e3e712d8 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -507,6 +507,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  _M_push_back_aux(const value_type& __t)
#endif
  {
+   if (empty())
+ {
+   // Move iterators to point to the current node begin.
+   this->_M_impl._M_start._M_cur = this->_M_impl._M_start._M_first;
+   this->_M_impl._M_finish._M_cur = this->_M_impl._M_finish._M_first;
+#if __cplusplus >= 201103L
+   emplace_back(std::forward<_Args>(__args)...);
+#else
+   push_back(__t);
+#endif
+   return;
+ }
+
if (size() == max_size())
  __throw_length_error(
  __N("cannot create std::deque larger than max_size()"));
@@ -546,6 +559,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  _M_push_front_aux(const value_type& __t)
#endif
  {
+   if (empty())
+ {
+   // Move iterators to point to the current node end.
+   this->_M_impl._M_finish._M_cur = this->_M_impl._M_finish._M_last - 
1;
+   this->_M_impl._M_start._M_cur = this->_M_impl._M_start._M_last - 1;
+#if __cplusplus >= 201103L
+   emplace_front(std::forward<_Args>(__args)...);
+#else
+   push_front(__t);
+#endif
+   return;
+ }
+
if (size() == max_size())
  __throw_length_error(
  __N("cannot create std::deque larger than max_size()"));

Re: [PATCH][AARCH64] Set jump-align=4 for neoversen1

[Kyrill Tkachov]

Hi Richard, Wilco,

On 1/17/20 8:43 AM, Richard Sandiford wrote:

Wilco Dijkstra  writes:
> Testing shows the setting of 32:16 for jump alignment has a 
significant codesize
> cost, however it doesn't make a difference in performance. So set 
jump-align

> to 4 to get 1.6% codesize improvement.

I was leaving this to others in case it was obvious to them.  On the
basis that silence suggests it wasn't, :-) could you go into more details?
Is it expected on first principles that jump alignment doesn't matter
for Neoverse N1, or is this purely based on experimentation?  If it's
expected, are we sure that the other "32:16" entries are still worthwhile?
When you say it doesn't make a difference in performance, does that mean
that no individual test's performance changed significantly, or just that
the aggregate score didn't?  Did you experiment with anything inbetween
the current 32:16 and 4, such as 32:8 or even 32:4?



Sorry for dragging my feet on this one, as I put in those numbers last 
year and I've been trying to recall my experiments from then.


The Neoverse N1 Software Optimization guide recommends aligning branch 
targets to 32 bytes withing the bounds of code density requirements.


From my benchmarking last year I do seem to remember function and loop 
alignment to matter.


I probably added the jump alignment for completeness as it's a good idea 
from first principles. But if the code size hit is too large we could 
look to decrease it.


I'd also be interested in seeing the impact of 32:8 and 32:4.

Thanks,

Kyrill




The problem with applying the patch only with the explanation above is
that if someone in future has evidence that jump alignment can make a
difference for their testcase, it would be very hard for them to
reproduce the reasoning that led to this change.

Thanks,
Richard

> OK for commit?
>
> ChangeLog
> 2019-12-24  Wilco Dijkstra  
>
> * config/aarch64/aarch64.c (neoversen1_tunings): Set jump_align to 4.
>
> --
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
1646ed1d9a3de8ee2f0abff385a1ea145e234475..209ed8ebbe81104d9d8cff0df31946ab7704fb33 
100644

> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1132,7 +1132,7 @@ static const struct tune_params 
neoversen1_tunings =

>    3, /* issue_rate  */
>    (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* 
fusible_ops  */

>    "32:16",/* function_align.  */
> -  "32:16",/* jump_align.  */
> +  "4",/* jump_align.  */
>    "32:16",/* loop_align.  */
>    2,/* int_reassoc_width.  */
>    4,/* fp_reassoc_width.  */

[PATCH] Make target_clones resolver fn static.

[Martin Liška]

Hi.

The patch removes need to have a gnu_indirect_function global
symbol. That aligns the code with what ppc64 target does.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-01-17  Martin Liska  

PR target/93274
* config/i386/i386-features.c (make_resolver_func):
Align the code with ppc64 target implementaion.
We do not need to have gnu_indirect_function
as a global function.

gcc/testsuite/ChangeLog:

2020-01-17  Martin Liska  

PR target/93274
* gcc.target/i386/pr81213.c: Adjust to not expect
a global unique name.
---
 gcc/config/i386/i386-features.c | 20 +---
 gcc/testsuite/gcc.target/i386/pr81213.c |  4 ++--
 2 files changed, 7 insertions(+), 17 deletions(-)


diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index e580b26b995..2517123b581 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -2738,26 +2738,17 @@ make_resolver_func (const tree default_decl,
 		const tree ifunc_alias_decl,
 		basic_block *empty_bb)
 {
-  char *resolver_name;
-  tree decl, type, decl_name, t;
+  tree decl, type, t;
 
-  /* IFUNC's have to be globally visible.  So, if the default_decl is
- not, then the name of the IFUNC should be made unique.  */
-  if (TREE_PUBLIC (default_decl) == 0)
-{
-  char *ifunc_name = make_unique_name (default_decl, "ifunc", true);
-  symtab->change_decl_assembler_name (ifunc_alias_decl,
-	  get_identifier (ifunc_name));
-  XDELETEVEC (ifunc_name);
-}
-
-  resolver_name = make_unique_name (default_decl, "resolver", false);
+  /* Make the resolver function static.  The resolver function returns
+ void *.  */
+  tree decl_name = clone_function_name (default_decl, "resolver");
+  const char *resolver_name = IDENTIFIER_POINTER (decl_name);
 
   /* The resolver function should return a (void *). */
   type = build_function_type_list (ptr_type_node, NULL_TREE);
 
   decl = build_fn_decl (resolver_name, type);
-  decl_name = get_identifier (resolver_name);
   SET_DECL_ASSEMBLER_NAME (decl, decl_name);
 
   DECL_NAME (decl) = decl_name;
@@ -2809,7 +2800,6 @@ make_resolver_func (const tree default_decl,
 
   /* Create the alias for dispatch to resolver here.  */
   cgraph_node::create_same_body_alias (ifunc_alias_decl, decl);
-  XDELETEVEC (resolver_name);
   return decl;
 }
 
diff --git a/gcc/testsuite/gcc.target/i386/pr81213.c b/gcc/testsuite/gcc.target/i386/pr81213.c
index 13e15d5fef0..89c47529861 100644
--- a/gcc/testsuite/gcc.target/i386/pr81213.c
+++ b/gcc/testsuite/gcc.target/i386/pr81213.c
@@ -14,6 +14,6 @@ int main()
   return foo();
 }
 
-/* { dg-final { scan-assembler "\t.globl\tfoo\\..*\\.ifunc" } } */
+/* { dg-final { scan-assembler "\t.globl\tfoo" } } */
 /* { dg-final { scan-assembler "foo.resolver:" } } */
-/* { dg-final { scan-assembler "foo\\..*\\.ifunc, @gnu_indirect_function" } } */
+/* { dg-final { scan-assembler "foo\\, @gnu_indirect_function" } } */

Re: [PATCH][AARCH64] Enable compare branch fusion

[Richard Sandiford]

Wilco Dijkstra  writes:
> Enable the most basic form of compare-branch fusion since various CPUs
> support it. This has no measurable effect on cores which don't support
> branch fusion, but increases fusion opportunities on cores which do.

If you're able to say for the record which cores you tested, then that'd
be good.

> Bootstrapped on AArch64, OK for commit?
>
> ChangeLog:
> 2019-12-24  Wilco Dijkstra  
>
> * config/aarch64/aarch64.c (generic_tunings): Add branch fusion.
> (neoversen1_tunings): Likewise.

OK, thanks.  I agree there doesn't seem to be an obvious reason why this
would pessimise any cores significantly.  And it looked from a quick
check like all AArch64 cores give these compares the lowest in-use
latency (as expected).

We can revisit this if anyone finds any counterexamples.

Richard


>
> --
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
> a3b18b381e1748f8fe5e522bdec4f7c850821fe8..1c32a3543bec4031cc9b641973101829c77296b5
>  100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -726,7 +726,7 @@ static const struct tune_params generic_tunings =
>SVE_NOT_IMPLEMENTED, /* sve_width  */
>4, /* memmov_cost  */
>2, /* issue_rate  */
> -  (AARCH64_FUSE_AES_AESMC), /* fusible_ops  */
> +  (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops  */
>"16:12",/* function_align.  */
>"4",/* jump_align.  */
>"8",/* loop_align.  */
> @@ -1130,7 +1130,7 @@ static const struct tune_params neoversen1_tunings =
>SVE_NOT_IMPLEMENTED, /* sve_width  */
>4, /* memmov_cost  */
>3, /* issue_rate  */
> -  AARCH64_FUSE_AES_AESMC, /* fusible_ops  */
> +  (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops  */
>"32:16",/* function_align.  */
>"32:16",/* jump_align.  */
>"32:16",/* loop_align.  */

Re: [PATCH] Fix ICE caused by swallowing a token in c_parser_consume_token

[Kerem Kat]

Thank you for reviewing and committing it.

Kerem

On Fri, Jan 17, 2020 at 1:04 AM Jeff Law  wrote:

> On Thu, 2020-01-16 at 23:43 +, Joseph Myers wrote:
> > Thanks, patch committed.
> Beat me to it :-)  I spun it yesterday, but didn't get around to
> committing it.
> jeff
>
>

Re: [PATCH][AARCH64] Set jump-align=4 for neoversen1

[Richard Sandiford]

Wilco Dijkstra  writes:
> Testing shows the setting of 32:16 for jump alignment has a significant 
> codesize
> cost, however it doesn't make a difference in performance. So set jump-align
> to 4 to get 1.6% codesize improvement.

I was leaving this to others in case it was obvious to them.  On the
basis that silence suggests it wasn't, :-) could you go into more details?
Is it expected on first principles that jump alignment doesn't matter
for Neoverse N1, or is this purely based on experimentation?  If it's
expected, are we sure that the other "32:16" entries are still worthwhile?
When you say it doesn't make a difference in performance, does that mean
that no individual test's performance changed significantly, or just that
the aggregate score didn't?  Did you experiment with anything inbetween
the current 32:16 and 4, such as 32:8 or even 32:4?

The problem with applying the patch only with the explanation above is
that if someone in future has evidence that jump alignment can make a
difference for their testcase, it would be very hard for them to
reproduce the reasoning that led to this change.

Thanks,
Richard

> OK for commit?
>
> ChangeLog
> 2019-12-24  Wilco Dijkstra  
>
> * config/aarch64/aarch64.c (neoversen1_tunings): Set jump_align to 4.
>
> --
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
> 1646ed1d9a3de8ee2f0abff385a1ea145e234475..209ed8ebbe81104d9d8cff0df31946ab7704fb33
>  100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1132,7 +1132,7 @@ static const struct tune_params neoversen1_tunings =
>3, /* issue_rate  */
>(AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops  */
>"32:16",/* function_align.  */
> -  "32:16",/* jump_align.  */
> +  "4",/* jump_align.  */
>"32:16",/* loop_align.  */
>2,/* int_reassoc_width.  */
>4,/* fp_reassoc_width.  */

Re: [PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions

[Jakub Jelinek]

On Wed, Dec 18, 2019 at 05:00:01PM +, Mihail Ionescu wrote:
> 2019-12-18  Mihail Ionescu  
> 2019-12-18  Andre Vieira  
> 
>   * config/arm/arm-cpus.in (mve, mve_float): New features.
>   (dsp, mve, mve.fp): New options.

Note, the above is not the right ChangeLog formatting when you have more
than one author.  The date should be there only for the first line, for the
other authors there should be just tab and 4 spaces, otherwise various tools
that parse ChangeLog entries will be quite confused.  So like:
2019-12-18  Mihail Ionescu  
Andre Vieira  

I've fixed your commits in 2b3534a3122236d6317256f16daa332278391907
but please remember this next time.

Thanks.

Jakub

Re: limit on emails for merge commits.

[Joel Brobecker]

Hi Ian,

> As I noted, 100 commits to master is a small number, so I expect this problem
> to fire almost every time someone does a merge of master to a devel or user
> branch (unless they have the habit of doing that almost daily, which I doubt
> for
> most).

The main goal of the limit is really to avoid accidents where someone
pushes something he shouldn't or something he didn't realize would
push so many commits. If the GCC repository is such that merges of
100 commits or more is going to be, if not routine, at least to be
expected, then perhaps increasing the limit would make sense.

What I would do is wait a bit and see. This may become moot soon,
depending on the direction that we want to take for vendor/user branches
with respect to emails. I'm still trying to think this over...

-- 
Joel

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

[Tobias Burnus]

On 1/17/20 4:49 AM, Steve Kargl wrote:

On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:

+type(t) :: foo
+print *, foo(1)%a ! { dg-error "Function call can not contain a reference" }

I do not understand this error message, and find it to be confusing.
foo(1)%a looks like an invalid array reference.  That is, foo is scalar
and foo(1) is an array element.


Well, we simply do not know whether "external" or "dimension" has been 
forgotten. As "external" can also be determined by the use, we end up 
regarding it as function reference…


Another example:

character(len=4):: str
print *, str(1)(1:4)
end

Maybe a more helpful error message is: "Unexpected junk after function 
reference or missing dimension declaration for %s", sym->name)


(Or instead of "junk" the fancier variant of my previous email.)

Cheers,

Tobias

Re: [PATCH] gimplifier: handle POLY_INT_CST-sized TARGET_EXPRs

[Richard Biener]

On Thu, Jan 16, 2020 at 1:10 PM Richard Sandiford
 wrote:
>
> If a TARGET_EXPR has poly-int size, the gimplifier would treat it
> like a VLA and use gimplify_vla_decl.  gimplify_vla_decl in turn
> would use an alloca and expect all references to be gimplified
> via the DECL_VALUE_EXPR.  This caused confusion later in
> gimplify_var_or_parm_decl_1 when we (correctly) had direct rather
> than indirect references.
>
> For completeness, the patch also fixes similar tests in the RETURN_EXPR
> handling and OpenMP depend clauses.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  I guess this isn't
> really a regression, but instead a bug in a new feature.  It should
> be very low risk for non-SVE targets though, so OK anyway?

OK.

Richard.

> Richard
>
>
> 2020-01-16  Richard Sandiford  
>
> gcc/
> * gimplify.c (gimplify_return_expr): Use poly_int_tree_p rather
> than testing directly for INTEGER_CST.
> (gimplify_target_expr, gimplify_omp_depend): Likewise.
>
> gcc/testsuite/
> * g++.target/aarch64/sve/acle/general-c++/gimplify_1.C: New test.
> ---
>  gcc/gimplify.c  | 6 +++---
>  .../g++.target/aarch64/sve/acle/general-c++/gimplify_1.C| 4 
>  2 files changed, 7 insertions(+), 3 deletions(-)
>  create mode 100644 
> gcc/testsuite/g++.target/aarch64/sve/acle/general-c++/gimplify_1.C
>
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index 05d7922116b..e50be5706c7 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -1632,7 +1632,7 @@ gimplify_return_expr (tree stmt, gimple_seq *pre_p)
>  result = NULL_TREE;
>else if (aggregate_value_p (result_decl, TREE_TYPE 
> (current_function_decl)))
>  {
> -  if (TREE_CODE (DECL_SIZE (result_decl)) != INTEGER_CST)
> +  if (!poly_int_tree_p (DECL_SIZE (result_decl)))
> {
>   if (!TYPE_SIZES_GIMPLIFIED (TREE_TYPE (result_decl)))
> gimplify_type_sizes (TREE_TYPE (result_decl), pre_p);
> @@ -6714,7 +6714,7 @@ gimplify_target_expr (tree *expr_p, gimple_seq *pre_p, 
> gimple_seq *post_p)
>
>/* TARGET_EXPR temps aren't part of the enclosing block, so add it
>  to the temps list.  Handle also variable length TARGET_EXPRs.  */
> -  if (TREE_CODE (DECL_SIZE (temp)) != INTEGER_CST)
> +  if (!poly_int_tree_p (DECL_SIZE (temp)))
> {
>   if (!TYPE_SIZES_GIMPLIFIED (TREE_TYPE (temp)))
> gimplify_type_sizes (TREE_TYPE (temp), pre_p);
> @@ -7921,7 +7921,7 @@ gimplify_omp_depend (tree *list_p, gimple_seq *pre_p)
>tree type = build_array_type (ptr_type_node, build_index_type (totalpx));
>tree array = create_tmp_var_raw (type);
>TREE_ADDRESSABLE (array) = 1;
> -  if (TREE_CODE (totalpx) != INTEGER_CST)
> +  if (!poly_int_tree_p (totalpx))
>  {
>if (!TYPE_SIZES_GIMPLIFIED (TREE_TYPE (array)))
> gimplify_type_sizes (TREE_TYPE (array), pre_p);
> diff --git 
> a/gcc/testsuite/g++.target/aarch64/sve/acle/general-c++/gimplify_1.C 
> b/gcc/testsuite/g++.target/aarch64/sve/acle/general-c++/gimplify_1.C
> new file mode 100644
> index 000..06ee7eae029
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/sve/acle/general-c++/gimplify_1.C
> @@ -0,0 +1,4 @@
> +/* { dg-additional-options "-flax-vector-conversions" } */
> +
> +inline void foo (const __SVInt32_t ) {}
> +void bar (__SVUint32_t x) { foo(x); }

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

[Tobias Burnus]

Hello Thomas, hi all,

On 1/16/20 11:34 PM, Thomas Koenig wrote:

Anyway, the fix is rather straightforward. We cannot have a reference
on a function. If this slipped through on parsing, let's issue the
error during resolution.

Regression-tested. OK for trunk?

I think I am fine with the check itself – but …

+  if (expr->ref)
+{
+  gfc_error ("Function call can not contain a reference at %L",


I have issues with the wording of the error message.

First, when reading the error message without context, I thought it is 
about something regarding the arguments ("contain") or maybe the 
reference of a function iself.


It is clear that we do not want to have anything after the 
function-reference (→R1521). And we do lack a good wording for that what 
one can (but shan't) put after the function-reference as it can be quite 
a lot (cf. →R901): a following '%' to attempt to create a 
structure-component or complex-part-component access or "(" to get a 
substring or array-element/section access or '[' to get something coindexed.


Not that I like the wording in particular, but we use quite often 
"Unexpected junk" in the parser. Hence: "Unexpected junk after function 
reference at %L" would work.


Or maybe clearer:
char ref_char = '%'; // REF_INQUIRY or REF_COMPONENT
if (expr->ref->type == REF_ARRAY || expr->ref->type == REF_SUBSTRING)
  ref_char = ((expr->ref->type == REF_ARRAY && !expr->ref->u.ar.dimen)
  '[' : '(';
 … ("Unexpected %qc after function reference at %L", ref_char, …);

Although, I am not sure the '[' (coindex) can occur.

Cheers,

Tobias

Re: limit on emails for merge commits.

[Iain Sandoe]

Hi Folks,

Joel Brobecker  wrote:



You should include Joel on such questions as the expert on the hooks.

I don't know whether there's something to put in the commit message to say
"allow this merge of more than 100 commits".  I don't think a squashed
merge is the right workaround, supposing you do want the git ancestry
information to reflect what got merged.  The simple workaround is to do
three successive merges, each of under 100 commits and each pushed
separately.  Alternatively, you could check out refs/meta/config, push a
change that either increases hooks.max-commit-emails or sets
hooks.no-emails to prevent mails for this branch, then push the merge,
then push a reversion of the change to refs/meta/config.


Joseph pretty much nailed it in terms of options.


Yeah - I agree.

I didn’t do the squash merge because I don’t want to lose the ancestor  
history

on the branch.

For the sake of separating the process of merging coroutines from our general
git policies, I am going to use several smaller merges - this is a simple and
transparent workaround.

I think editing the hooks would be less transparent and doesn’t solve the
‘spamming the commits ML’ any better.

---

As I noted, 100 commits to master is a small number, so I expect this problem
to fire almost every time someone does a merge of master to a devel or user
branch (unless they have the habit of doing that almost daily, which I  
doubt for

most).

thanks
Iain