Re: [PATCH GCC11]Improve uninitialized warning with value range info

[Richard Biener]

On Mon, Jan 13, 2020 at 3:15 AM bin.cheng  wrote:
>
> --
> Sender:Richard Biener 
> Sent At:2020 Jan. 9 (Thu.) 20:01
> Recipient:Bin.Cheng 
> Cc:bin.cheng ; GCC Patches 
> 
> Subject:Re: [PATCH GCC11]Improve uninitialized warning with value range info
>
>
> On Thu, Jan 9, 2020 at 11:17 AM Bin.Cheng  wrote:
> > > I am not quite follow here. Do you mean we collect three cases "i <
> > > j", "i < min(j)", "max(i) < j" then
> > > call prune_uninit_phi_opnds for all three conditions?
> >
> > No, I've meant to somehow arrange that the 'preds' passed to
> > use_pred_not_overlap_with_undef_path_pred contain all three predicates
> > rather than just i < j, thus "expand" fully symbolic predicates.
>
> Seems this would require non-trivial refactoring of the original code.
>
> > > This is another question? because now we simply break out of for loop
> > > for finding such condition:
> > >
> > > -  if ((gimple_code (flag_def) == GIMPLE_PHI)
> > > - && (gimple_bb (flag_def) == gimple_bb (phi))
> > > - && find_matching_predicate_in_rest_chains (the_pred, preds,
> > > -num_preds))
> > > -   break;
> > >
> > > It's always possible that this flag_def can't prune use predicates
> > > against undefined path predicates, while a later one can prune but is
> > > skipped?
> >
> > I don't follow but I also don't want to understand the code too much ;)
> >
> > I'm fine with the idea and if the patch cannot introudce extra bogus 
> > warnings
> > let's go with it.  Can you amed the comment before the two 
> > find_var_cmp_const
> > calls?  I wonder whether eliding the second sweep when the first didn't find
> > any predicate it skipped is worth the trouble.
>
> Thanks for the comments, I updated the patch as attached.

OK.

Thanks,
Richard.

> Thanks,
> bin
>
> 2020-01-08  Bin Cheng  
>
> * tree-ssa-uninit.c (find_var_cmp_const): New function.
> (use_pred_not_overlap_with_undef_path_pred): Call above.
> (find_matching_predicate_in_rest_chains): Remove param.

[PATCH 1/2] PR middle-end/93246 - missing alias subsets

[Richard Biener]

Starting with the introduction of TYPE_TYPELESS_STORAGE the situation
of having a alias-set zero aggregate field became more common which
prevents recording alias-sets of fields of said aggregate as subset
of the outer aggregate.  component_uses_parent_alias_set_from in the
past fended off some of the issues with that but the alias oracles
use of the alias set of the base of an access path never appropriately
handled it.

The following makes it so that alias-sets of fields of alias-set zero
aggregate fields are still recorded as subset of the container.

Bootstrapped and tested on x86_64-unknown-linux-gnu, will apply
momentarily.

Richard.

2020-01-14  Richard Biener  

PR middle-end/93246
* alias.c (record_component_aliases): Take superset to record
into, recurse for alias-set zero fields.
(record_component_aliases): New oveerload wrapping around the above.

* g++.dg/torture/pr93246.C: New testcase.
---
 gcc/alias.c| 34 ++
 gcc/testsuite/g++.dg/torture/pr93246.C | 31 +++
 2 files changed, 61 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr93246.C

diff --git a/gcc/alias.c b/gcc/alias.c
index 336af4e52a7..9629b5a9f48 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1191,15 +1191,14 @@ record_alias_subset (alias_set_type superset, 
alias_set_type subset)
 }
 }
 
-/* Record that component types of TYPE, if any, are part of that type for
+/* Record that component types of TYPE, if any, are part of SUPERSET for
aliasing purposes.  For record types, we only record component types
for fields that are not marked non-addressable.  For array types, we
only record the component type if it is not marked non-aliased.  */
 
 void
-record_component_aliases (tree type)
+record_component_aliases (tree type, alias_set_type superset)
 {
-  alias_set_type superset = get_alias_set (type);
   tree field;
 
   if (superset == 0)
@@ -1253,7 +1252,21 @@ record_component_aliases (tree type)
 == get_alias_set (TREE_TYPE (field)));
}
 
- record_alias_subset (superset, get_alias_set (t));
+ alias_set_type set = get_alias_set (t);
+ record_alias_subset (superset, set);
+ /* If the field has alias-set zero make sure to still record
+any componets of it.  This makes sure that for
+  struct A {
+struct B {
+  int i;
+  char c[4];
+} b;
+  };
+in C++ even though 'B' has alias-set zero because
+TYPE_TYPELESS_STORAGE is set, 'A' has the alias-set of
+'int' as subset.  */
+ if (set == 0)
+   record_component_aliases (t, superset);
}
   }
   break;
@@ -1270,6 +1283,19 @@ record_component_aliases (tree type)
 }
 }
 
+/* Record that component types of TYPE, if any, are part of that type for
+   aliasing purposes.  For record types, we only record component types
+   for fields that are not marked non-addressable.  For array types, we
+   only record the component type if it is not marked non-aliased.  */
+
+void
+record_component_aliases (tree type)
+{
+  alias_set_type superset = get_alias_set (type);
+  record_component_aliases (type, superset);
+}
+
+
 /* Allocate an alias set for use in storing and reading from the varargs
spill area.  */
 
diff --git a/gcc/testsuite/g++.dg/torture/pr93246.C 
b/gcc/testsuite/g++.dg/torture/pr93246.C
new file mode 100644
index 000..4c523443175
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr93246.C
@@ -0,0 +1,31 @@
+// { dg-do run }
+// { dg-additional-options "-fstrict-aliasing" }
+
+template  struct Optional {
+  auto is_present() const { const bool &p = inner.present; return p; }
+  auto set_present() { if (not is_present()) inner.present = true; }
+  struct InnerType {
+bool present = false;
+char padding[1] = {0};
+  };
+  using inner_t = InnerType;
+  inner_t inner = {};
+};
+
+template  struct Wrapper {
+  auto operator-> () { return value; }
+  WrappedType *value;
+};
+
+void __attribute__((noipa)) foo(Optional<>& x) {}
+
+int main()
+{
+  Optional<> buf{};
+  foo(buf);
+  Wrapper> wo = {&buf};
+  wo->set_present();
+  auto x = wo->is_present();
+  if (!x)
+__builtin_abort ();
+}
-- 
2.16.4

[PATCH 2/2] Optimize alias subset recording

[Richard Biener]

When an alias-set is an already existing subset there is no need
to re-record its children as childs of the parent.

I noticed this when doing 1/2 as trivial opportunity to squeeze
back some performance for the non-caching recursion I added.  The
whole thing is still quadratic in the depth of the structure, of course.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Since I'm curious I'll test a variant which checks the children
are actually recorded before pushing this ... (OK, maybe I shouldn't
do this...)

Richard.

2020-01-14  Richard Biener  

* alias.c (record_alias_subset): Avoid redundant work when
subset is already recorded.
---
 gcc/alias.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/alias.c b/gcc/alias.c
index 9629b5a9f48..3794f9b6a9e 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1164,10 +1164,16 @@ record_alias_subset (alias_set_type superset, 
alias_set_type subset)
 superset_entry->has_zero_child = 1;
   else
 {
-  subset_entry = get_alias_set_entry (subset);
   if (!superset_entry->children)
superset_entry->children
  = hash_map::create_ggc (64);
+
+  /* Enter the SUBSET itself as a child of the SUPERSET.  If it was
+already there we're done.  */
+  if (superset_entry->children->put (subset, 0))
+   return;
+
+  subset_entry = get_alias_set_entry (subset);
   /* If there is an entry for the subset, enter all of its children
 (if they are not already present) as children of the SUPERSET.  */
   if (subset_entry)
@@ -1185,9 +1191,6 @@ record_alias_subset (alias_set_type superset, 
alias_set_type subset)
superset_entry->children->put ((*iter).first, (*iter).second);
}
}
-
-  /* Enter the SUBSET itself as a child of the SUPERSET.  */
-  superset_entry->children->put (subset, 0);
 }
 }
 
-- 
2.16.4

Re: [PATCH] Fix typo and avoid possible memory leak

[Kewen.Lin]

on 2020/1/13 下午6:46, Richard Sandiford wrote:
> "Kewen.Lin"  writes:
>> Hi,
>>
>> Function average_num_loop_insns forgets to free loop body in early return.  
>> Besides, overflow comparison checks 100 (e6) but the return value is
>> 10 (e5), I guess it's unexpected, a typo?
>>
>> Bootstrapped and regress tested on powerpc64le-linux-gnu.  
>> I guess this should go to GCC11? Is it ok?
> 
> OK for GCC 10, thanks.  This is a regression from GCC 7.
> 
Hi Richard,

Thanks for correcting me it's a regression!  Committed in b38e86ddb7a9.

BR,
Kewen

Re: [PATCH] contrib: git descr/undescr aliases

[Roman Zhuykov]

13.01.2020 14:37, Jakub Jelinek wrote:

The following patch adds the descr/undescr aliases (for converting to
monotonically increasing revision numbers and back) there next to svn-rev.
Both have been changed to use basepoints/gcc-* tags instead of
branchpoints/gcc-*, the first one now supports --full option, where
$ git descr origin/master
r10-5835
$ git descr --full origin/master
r10-5835-g1fc15853e301337b46d7f1234966a6244ef0cdab
where the second form is what is used in gcc-cvs mail bodies and bugzilla
comments from commits, the former what is used in the subjects.
The second alias has been tweaked to use git config --get gcc-config.upstream
with fallback to origin to be able to deal with non-default upstream
configurations.

It was a bit confusing to see "git descr" here in posted patch and "git 
gcc-descr" actually committed.

Moreover "git gcc-descr" doesn't work for me with old git:

~$ git --version
git version 2.7.4
~$ git clone git://gcc.gnu.org/git/gcc test
<...>
~$ cd test/
~/test$
~/test$ ./contrib/gcc-git-customization.sh
<...>
~/test$ git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' 
origin/master
basepoints/gcc-10-5938-gedabbec31e3bfc9a9757f80c8610706ed00e5a1a
~/test$ git gcc-descr origin/master
~/test$

So, locally I have to fix alias removing "tags/" part in commands like "sed -n 
's,^tags/basepoints/gcc-,r,p'".

With new git v2.24.0 alias works fine.  Investigation shows it was changed 
inside git by commit 
https://github.com/git/git/commit/1bba00130a1a0332ec0ad2f878a09ca9b2b18ee2 two 
years ago.  So, only git v2.16.2, v2.17.0 or newer versions correctly run 
current alias.  Not sure we want to bother about supporting older versions.

--
Roman


PS. We at ISPRAS see that for ~28 hours (11 Jan 2020, 18:00 UTC - 12 Jan 2020, 22:00 UTC) 
our servers haven't received any gcc mailing list letters, but they are available at 
https://gcc.gnu.org/ml/ archives (totally 6 mails on gcc@ and 16 on gcc-patches@ were 
lost).  Looking also at obviously 
corruptedhttps://gcc.gnu.org/ml/gcc-patches/2020-01/msg00674.html  it is reasonable to 
assume that it was some worldwide issue because of high "git clone" server 
load, and I wonder not to see any discussion here.

Re: [PATCH] contrib: git descr/undescr aliases

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 12:04:04PM +0300, Roman Zhuykov wrote:
> It was a bit confusing to see "git descr" here in posted patch and "git
> gcc-descr" actually committed.

That was an IRC request from Richard Earnshaw.

> Moreover "git gcc-descr" doesn't work for me with old git:
> 
> ~$ git --version
> git version 2.7.4
> ~$ git clone git://gcc.gnu.org/git/gcc test
> <...>
> ~$ cd test/
> ~/test$
> ~/test$ ./contrib/gcc-git-customization.sh
> <...>
> ~/test$ git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' 
> origin/master
> basepoints/gcc-10-5938-gedabbec31e3bfc9a9757f80c8610706ed00e5a1a
> ~/test$ git gcc-descr origin/master
> ~/test$
> 
> So, locally I have to fix alias removing "tags/" part in commands like "sed 
> -n 's,^tags/basepoints/gcc-,r,p'".
> 
> With new git v2.24.0 alias works fine.  Investigation shows it was changed 
> inside git by commit 
> https://github.com/git/git/commit/1bba00130a1a0332ec0ad2f878a09ca9b2b18ee2 
> two years ago.  So, only git v2.16.2, v2.17.0 or newer versions correctly run 
> current alias.  Not sure we want to bother about supporting older versions.

Note, for the scripts running on sourceware I also had to remove those tags/
part, but thought it is because of running against the bare repo.
We could change those into ^\\(tags/\\)\\?basepoints/gcc- etc. (and adjust
the \\1.
I'll post a patch.

> PS. We at ISPRAS see that for ~28 hours (11 Jan 2020, 18:00 UTC - 12 Jan 
> 2020, 22:00 UTC) our servers haven't received any gcc mailing list letters, 
> but they are available at https://gcc.gnu.org/ml/ archives (totally 6 mails 
> on gcc@ and 16 on gcc-patches@ were lost).  Looking also at obviously 
> corruptedhttps://gcc.gnu.org/ml/gcc-patches/2020-01/msg00674.html  it is 
> reasonable to assume that it was some worldwide issue because of high "git 
> clone" server load, and I wonder not to see any discussion here.

Strange, I certainly am receiving gcc mailing list mails.

Jakub

Re: [PATCH 1/2] hash-table.h: support non-zero empty values in empty_slow (v2)

[Jakub Jelinek]

On Mon, Jan 13, 2020 at 11:51:53PM -0500, David Malcolm wrote:
> > * cfg.s correctly has a call to memset (even with no optimization)
> > for
> > hash_table::empty_slow

I have intestigated unpatched cc1plus and in the (usually inlined)
alloc_entries I see in all the places the xcalloc or ggc_internal_cleared_alloc
followed by either a loop storing some zeros or a memset, which is something
I'd hope the patch also improves.

As for graphite.c, sure, empty_zero_p = false is a fallback value, the
question was not directly related to this patch, but rather wondering how it
can work at all.

> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu (in
> conjuction with the analyzer patch kit, which it fixes)
> 
> OK for master?

Yes to both patches, thanks.

> gcc/cp/ChangeLog:  Jakub Jelinek  
>   * cp-gimplify.c (source_location_table_entry_hash::empty_zero_p):
>   New static constant.
>   * cp-tree.h (named_decl_hash::empty_zero_p): Likewise.
>   (struct named_label_hash::empty_zero_p): Likewise.
>   * decl2.c (mangled_decl_hash::empty_zero_p): Likewise.
> 
> gcc/ChangeLog:  Jakub Jelinek  ,
>   David Malcolm  
>   * attribs.c (excl_hash_traits::empty_zero_p): New static constant.
>   * gcov.c (function_start_pair_hash::empty_zero_p): Likewise.
>   * graphite.c (struct sese_scev_hash::empty_zero_p): Likewise.
>   * hash-map-tests.c (selftest::test_nonzero_empty_key): New selftest.
>   (selftest::hash_map_tests_c_tests): Call it.
>   * hash-map-traits.h (simple_hashmap_traits::empty_zero_p):
>   New static constant, using the value of = H::empty_zero_p.
>   (unbounded_hashmap_traits::empty_zero_p): Likewise, using the value
>   from default_hash_traits .
>   * hash-map.h (hash_map::empty_zero_p): Likewise, using the value
>   from Traits.
>   * hash-set-tests.c (value_hash_traits::empty_zero_p): Likewise.
>   * hash-table.h (hash_table::alloc_entries): Guard the loop of
>   calls to mark_empty with !Descriptor::empty_zero_p.
>   (hash_table::empty_slow): Conditionalize the memset call with a
>   check that Descriptor::empty_zero_p; otherwise, loop through the
>   entries calling mark_empty on them.
>   * hash-traits.h (int_hash::empty_zero_p): New static constant.
>   (pointer_hash::empty_zero_p): Likewise.
>   (pair_hash::empty_zero_p): Likewise.
>   * ipa-devirt.c (default_hash_traits ::empty_zero_p):
>   Likewise.
>   * ipa-prop.c (ipa_bit_ggc_hash_traits::empty_zero_p): Likewise.
>   (ipa_vr_ggc_hash_traits::empty_zero_p): Likewise.
>   * profile.c (location_triplet_hash::empty_zero_p): Likewise.
>   * sanopt.c (sanopt_tree_triplet_hash::empty_zero_p): Likewise.
>   (sanopt_tree_couple_hash::empty_zero_p): Likewise.
>   * tree-hasher.h (int_tree_hasher::empty_zero_p): Likewise.
>   * tree-ssa-sccvn.c (vn_ssa_aux_hasher::empty_zero_p): Likewise.
>   * tree-vect-slp.c (bst_traits::empty_zero_p): Likewise.
>   * tree-vectorizer.h
>   (default_hash_traits::empty_zero_p):
>   Likewise.

Jakub

[patch,avr,applied]: Simplify asm macro skip.

[Georg-Johann Lay]

Applied the following trivial and obvious patch to the avr back.

Johann

libgcc/
* config/avr/lib1funcs.S (skip): Simplify.


diff --git a/libgcc/config/avr/lib1funcs.S b/libgcc/config/avr/lib1funcs.S
index 8ebdc01c88c..2ffa2090b25 100644
--- a/libgcc/config/avr/lib1funcs.S
+++ b/libgcc/config/avr/lib1funcs.S
@@ -169,11 +169,7 @@ see the files COPYING3 and COPYING.RUNTIME 
respectively.  If not, see

 .endm

 ;; Skip next instruction, typically a jump target
-#if defined(__AVR_TINY__)
-#define skip cpse 0,0
-#else
 #define skip cpse 16,16
-#endif

 ;; Negate a 2-byte value held in consecutive registers
 .macro NEG2  reg

Re: [PATCH] Do not set -fomit-frame-pointer if TARGET_OMIT_LEAF_FRAME_POINTER_P.

[Martin Liška]

PING^1

On 1/3/20 12:23 PM, Martin Liška wrote:

Hi.

I'm not fully sure about the change, but -momit-leaf-frame-pointer
probably should not globally omit frame pointers?

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-01-03  Martin Liska  

 PR tree-optimization/92860
 * config/i386/i386-options.c (ix86_option_override_internal):
 Do not enable -fomit-frame-pointer with -momit-leaf-frame-pointer
 as it will globally omit pointers (like in ira.c).
---
  gcc/config/i386/i386-options.c | 2 --
  1 file changed, 2 deletions(-)

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Gerald Pfeifer]

On Mon, 13 Jan 2020, Jonathan Wakely wrote:
> Here's what I've committed to releases/gcc-9, I'll do something
> similar for gcc-8.

Cool, thank you.  

That was a good catch, even without the conversion to GIT; I'll
see that I'll contribute to the conversion on the wwwdocs side
over the coming evenings.

Gerald

[wwwdocs] Reduce references (textual and links) to SVN in older news.

[Gerald Pfeifer]

Pushed.

Gerald

- Log -
commit 7d8a79bc2a6409c7adb30c70b884dd6f5934d999
Author: Gerald Pfeifer 
Date:   Tue Jan 14 12:01:19 2020 +0100

Reduce references (textual and links) to SVN in older news.

diff --git a/htdocs/news.html b/htdocs/news.html
index 9da7300d..dd4e1c09 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -701,7 +701,7 @@ annual report for 2008
 
 January 8, 2007
 Andrew Haley and Tom Tromey of Red Hat merged the
-gcj-eclipse branch to svn trunk.  GCC now uses the
+gcj-eclipse branch to GCC trunk.  GCC now uses the
 Eclipse compiler as a front end, enabling all 1.5 language
 features.  This merge also brings in a new, generics-enabled
 version of Classpath, including October 26, 2005
 
-GCC has moved from CVS to SVN
-for revision control.
+GCC has moved from CVS to SVN for revision control.
 
 
 September 28, 2005

---

Summary of changes:
 htdocs/news.html | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
gcc-wwwdocs

Re: [PATCH] Do not set -fomit-frame-pointer if TARGET_OMIT_LEAF_FRAME_POINTER_P.

[Jan Hubicka]

> PING^1
> 
> On 1/3/20 12:23 PM, Martin Liška wrote:
> > Hi.
> > 
> > I'm not fully sure about the change, but -momit-leaf-frame-pointer
> > probably should not globally omit frame pointers?
> > 
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > 
> > Ready to be installed?
> > Thanks,
> > Martin
> > 
> > gcc/ChangeLog:
> > 
> > 2020-01-03  Martin Liska  
> > 
> >  PR tree-optimization/92860
> >  * config/i386/i386-options.c (ix86_option_override_internal):
> >  Do not enable -fomit-frame-pointer with -momit-leaf-frame-pointer
> >  as it will globally omit pointers (like in ira.c).

Does gcc omit frame pointer of leaf functions after your change?
My recollection how this code works is that flag_omit_frame_pointer is
needed for regalloc to consider omitting at first plce and then it
queries frame_pointer_required hook wihch if only
-momit-leaf-frame-pointer is used will return true for all non-leaf
functions so effectivly only leaf ones are omitted.

If you stop setting the flag I think IRA will not consider omitting at
all and whole flag will become noop.

Honza

Re: [PATCH 2/2] Optimize alias subset recording

[Richard Biener]

On Tue, 14 Jan 2020, Richard Biener wrote:

> When an alias-set is an already existing subset there is no need
> to re-record its children as childs of the parent.
> 
> I noticed this when doing 1/2 as trivial opportunity to squeeze
> back some performance for the non-caching recursion I added.  The
> whole thing is still quadratic in the depth of the structure, of course.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> Since I'm curious I'll test a variant which checks the children
> are actually recorded before pushing this ... (OK, maybe I shouldn't
> do this...)

So I did it.  It works but for

FAIL: gnat.dg/interface2.adb 3 blank line(s) in output
FAIL: gnat.dg/interface2.adb (test for excess errors)
UNRESOLVED: gnat.dg/interface2.adb compilation failed to produce 
executable
FAIL: gnat.dg/predicate2_main.adb 3 blank line(s) in output
FAIL: gnat.dg/predicate2_main.adb (test for excess errors)

which ICE with the adjusted patch below.  Ada calls
record_component_aliases itself and eventually too early when
some types are not yet complete?  Which would also mean that
subsets could be failed to recorded properly.

So I'm still inclined to go with the original non-checking patch
unless Eric tells me I'm completely wrong and there isn't a
latent issue in the Ada frontend.

Thanks,
Richard.


diff --git a/gcc/alias.c b/gcc/alias.c
index 336af4e52a7..0eae5386444 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1164,10 +1164,15 @@ record_alias_subset (alias_set_type superset, 
alias_set_type subset)
 superset_entry->has_zero_child = 1;
   else
 {
-  subset_entry = get_alias_set_entry (subset);
   if (!superset_entry->children)
superset_entry->children
  = hash_map::create_ggc (64);
+
+  /* Enter the SUBSET itself as a child of the SUPERSET.  If it was
+already there we're done.  */
+  bool present = superset_entry->children->put (subset, 0);
+
+  subset_entry = get_alias_set_entry (subset);
   /* If there is an entry for the subset, enter all of its children
 (if they are not already present) as children of the SUPERSET.  */
   if (subset_entry)
@@ -1182,12 +1187,12 @@ record_alias_subset (alias_set_type superset, 
alias_set_type subset)
  hash_map::iterator iter
= subset_entry->children->begin ();
  for (; iter != subset_entry->children->end (); ++iter)
-   superset_entry->children->put ((*iter).first, (*iter).second);
+   {
+ bool cpresent = superset_entry->children->put ((*iter).first, 
(*iter).second);
+ gcc_assert (!present || cpresent);
+   }
}
}
-
-  /* Enter the SUBSET itself as a child of the SUPERSET.  */
-  superset_entry->children->put (subset, 0);
 }
 }
 

Re: [PATCH] Do not set -fomit-frame-pointer if TARGET_OMIT_LEAF_FRAME_POINTER_P.

[Martin Liška]

On 1/14/20 12:18 PM, Jan Hubicka wrote:

PING^1

On 1/3/20 12:23 PM, Martin Liška wrote:

Hi.

I'm not fully sure about the change, but -momit-leaf-frame-pointer
probably should not globally omit frame pointers?

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-01-03  Martin Liska  

  PR tree-optimization/92860
  * config/i386/i386-options.c (ix86_option_override_internal):
  Do not enable -fomit-frame-pointer with -momit-leaf-frame-pointer
  as it will globally omit pointers (like in ira.c).


Does gcc omit frame pointer of leaf functions after your change?
My recollection how this code works is that flag_omit_frame_pointer is
needed for regalloc to consider omitting at first plce and then it
queries frame_pointer_required hook wihch if only
-momit-leaf-frame-pointer is used will return true for all non-leaf
functions so effectivly only leaf ones are omitted.


I've got it.



If you stop setting the flag I think IRA will not consider omitting at
all and whole flag will become noop.


Yes, then patch is then incorrect. We would needs something like:

diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 2acc9fb0cfe..ec538724581 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -1671,6 +1671,9 @@ ix86_recompute_optlev_based_flags (struct gcc_options 
*opts,
opts->x_flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN;
}
 }
+
+  if (TARGET_OMIT_LEAF_FRAME_POINTER_P (opts->x_target_flags))
+opts->x_flag_omit_frame_pointer = 1;
 }
 
 /* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook.  */

@@ -2437,8 +2440,6 @@ ix86_option_override_internal (bool main_args_p,
   /* Keep nonleaf frame pointers.  */
   if (opts->x_flag_omit_frame_pointer)
 opts->x_target_flags &= ~MASK_OMIT_LEAF_FRAME_POINTER;
-  else if (TARGET_OMIT_LEAF_FRAME_POINTER_P (opts->x_target_flags))
-opts->x_flag_omit_frame_pointer = 1;
 
   /* If we're doing fast math, we don't care about comparison order

  wrt NaNs.  This lets us use a shorter comparison sequence.  */

But it does not work as opts->x_target_flags is changed for some reason
for a per-function opts.

Martin



Honza

Re: [PATCH 3/4] Also propagate SRA accesses from LHS to RHS (PR 92706)

[Richard Biener]

On Mon, 13 Jan 2020, Martin Jambor wrote:

> Hi,
> 
> sorry for taking so long to reply...
> 
> On Wed, Dec 18 2019, Richard Biener wrote:
> > On December 17, 2019 1:43:15 PM GMT+01:00, Martin Jambor  
> > wrote:
> >>Hi,
> >>
> >>the previous patch unfortunately does not fix the first testcase in PR
> >>92706 and since I am afraid it might be the important one, I also
> >>focused on that.  The issue here is again total scalarization accesses
> >>clashing with those representing accesses in the IL - on another
> >>aggregate but here the sides are switched.  Whereas in the previous
> >>case the total scalarization accesses prevented propagation along
> >>assignments, here we have the user accesses on the LHS, so even though
> >>we do not create anything there, we totally scalarize the RHS and
> >>again end up with assignments with different scalarizations leading to
> >>bad code.
> >>
> >>So we clearly need to propagate information about accesses from RHSs
> >>to LHSs too, which the patch below does.  Because the intent is only
> >>preventing bad total scalarization - which the last patch now performs
> >>late enough - and do not care about grp_write flag and so forth, the
> >>propagation is a bit simpler and so I did not try to unify all of the
> >>code for both directions.
> >
> >  But can we really propagate the directions independently? Lacc to racc 
> > propagation would induce accesses to different racc to Lacc branches of the 
> > access tree of the parent, no? So in full generality the access links Form 
> > an undirected graph where you perform propagation in both directions of 
> > edges (and you'd have to consider cycles). 'linked parts' of the graph then 
> > need to have the same (or at least a compatible) scalarization, and three 
> > would be the possibility to compute the optimal 'conflict border' where to 
> > fix the conflict we'd keep one node in the graph unscalarized. 
> >
> > The way you did it might be sufficient in practice of course and we should 
> > probably go with that for now?
> 
> I think it should be - at least I think I would not be able to come up
> with an implementation quickly enough for GCC 10 - I assumed that was
> the target.  And also because there is that one important difference
> between the propagation, the RHS->LHS also propagates
> "actually-contains-data" whereas the other direction is just to prevent
> total scalarization to create conflicts - and it is sufficient to do
> that and I suppose in any search for optimal scalarization we'd give
> total scalarization the smallest priority anyway.

OK, sounds reasonable.

The patch is OK then, but I'll wait for your updated series.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> >
> > Richard. 
> >
> >>I still think that even with this patch the total scalarization has to
> >>follow the declared type of the aggregate and cannot be done using
> >>integers of the biggest suitable power, at least in early SRA, because
> >>these propagations of course do not work interprocedurally but
> >>inlining can and does eventually bring accesses from two functions
> >>together which could (and IMHO would) lead to same problems.
> >>
> >>Bootstrapped and LTO-bootstrapped and tested on an x86_64-linux and
> >>bootstrapped and tested it on aarch64 and i686 (except that on i686
> >>the testcase will need to be skipped because __int128_t is not
> >>available there).  I expect that review will lead to requests to
> >>change things but as far as I am concerned, this is ready for trunk
> >>too.
> >>
> >>Thanks,
> >>
> >>Martin
> >>
> >>2019-12-11  Martin Jambor  
> >>
> >>PR tree-optimization/92706
> >>* tree-sra.c (struct access): Fields first_link, last_link,
> >>next_queued and grp_queued renamed to first_rhs_link, last_rhs_link,
> >>next_rhs_queued and grp_rhs_queued respectively, new fields
> >>first_lhs_link, last_lhs_link, next_lhs_queued and grp_lhs_queued.
> >>(struct assign_link): Field next renamed to next_rhs, new field
> >>next_lhs.  Updated comment.
> >>(work_queue_head): Renamed to rhs_work_queue_head.
> >>(lhs_work_queue_head): New variable.
> >>(add_link_to_lhs): New function.
> >>(relink_to_new_repr): Also relink LHS lists.
> >>(add_access_to_work_queue): Renamed to add_access_to_rhs_work_queue.
> >>(add_access_to_lhs_work_queue): New function.
> >>(pop_access_from_work_queue): Renamed to
> >>pop_access_from_rhs_work_queue.
> >>(pop_access_from_lhs_work_queue): New function.
> >>(build_accesses_from_assign): Also add links to LHS lists and to LHS
> >>work_queue.
> >>(child_would_conflict_in_lacc): Renamed to
> >>child_would_conflict_in_acc.  Adjusted parameter names.
> >>(create_artificial_child_access): New parameter set_grp_read, use it.
> >>(subtree_mark_written_and_enqueue): Renamed to
> >>subtree_mark_written_and_rhs_enqueue.
> >>(propagate_subaccesses_across_link): Renamed to
> >>propagate_subaccesses_from_rhs.
> >>   

Re: [PATCH 2/2] Optimize alias subset recording

[Richard Biener]

On Tue, 14 Jan 2020, Richard Biener wrote:

> On Tue, 14 Jan 2020, Richard Biener wrote:
> 
> > When an alias-set is an already existing subset there is no need
> > to re-record its children as childs of the parent.
> > 
> > I noticed this when doing 1/2 as trivial opportunity to squeeze
> > back some performance for the non-caching recursion I added.  The
> > whole thing is still quadratic in the depth of the structure, of course.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > 
> > Since I'm curious I'll test a variant which checks the children
> > are actually recorded before pushing this ... (OK, maybe I shouldn't
> > do this...)
> 
> So I did it.  It works but for
> 
> FAIL: gnat.dg/interface2.adb 3 blank line(s) in output
> FAIL: gnat.dg/interface2.adb (test for excess errors)
> UNRESOLVED: gnat.dg/interface2.adb compilation failed to produce 
> executable
> FAIL: gnat.dg/predicate2_main.adb 3 blank line(s) in output
> FAIL: gnat.dg/predicate2_main.adb (test for excess errors)
> 
> which ICE with the adjusted patch below.  Ada calls
> record_component_aliases itself and eventually too early when
> some types are not yet complete?  Which would also mean that
> subsets could be failed to recorded properly.
> 
> So I'm still inclined to go with the original non-checking patch
> unless Eric tells me I'm completely wrong and there isn't a
> latent issue in the Ada frontend.

Btw, all the dance the Ada FE performs in relate_alias_sets isn't
going to work with LTO unless it is no longer necessary anyways.

Oh, and we miss libbacktrace support for GNAT bug boxes, for the
above I'd like to know whether its from record_component_aliases
calls or calls of record_alias_subset.

Richard.

> diff --git a/gcc/alias.c b/gcc/alias.c
> index 336af4e52a7..0eae5386444 100644
> --- a/gcc/alias.c
> +++ b/gcc/alias.c
> @@ -1164,10 +1164,15 @@ record_alias_subset (alias_set_type superset, 
> alias_set_type subset)
>  superset_entry->has_zero_child = 1;
>else
>  {
> -  subset_entry = get_alias_set_entry (subset);
>if (!superset_entry->children)
>   superset_entry->children
> = hash_map::create_ggc (64);
> +
> +  /* Enter the SUBSET itself as a child of the SUPERSET.  If it was
> +  already there we're done.  */
> +  bool present = superset_entry->children->put (subset, 0);
> +
> +  subset_entry = get_alias_set_entry (subset);
>/* If there is an entry for the subset, enter all of its children
>(if they are not already present) as children of the SUPERSET.  */
>if (subset_entry)
> @@ -1182,12 +1187,12 @@ record_alias_subset (alias_set_type superset, 
> alias_set_type subset)
> hash_map::iterator iter
>   = subset_entry->children->begin ();
> for (; iter != subset_entry->children->end (); ++iter)
> - superset_entry->children->put ((*iter).first, (*iter).second);
> + {
> +   bool cpresent = superset_entry->children->put ((*iter).first, 
> (*iter).second);
> +   gcc_assert (!present || cpresent);
> + }
>   }
>   }
> -
> -  /* Enter the SUBSET itself as a child of the SUPERSET.  */
> -  superset_entry->children->put (subset, 0);
>  }
>  }
>  
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH v7] Missed function specialization + partial devirtualization

[Martin Liška]

On 1/13/20 4:23 AM, luoxhu wrote:

Thanks a lot!  Rebased & updated, will commit below patch shortly when git push 
is ready.


Hello.

I'm pretty sure the patch contains failure of the following tests:

FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c scan-pgo-wpa-ipa-dump 
profile_estimate "2 \\(200.00%\\) speculations produced."
FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-2.c scan-pgo-wpa-ipa-dump 
profile_estimate "2 \\(200.00%\\) speculations produced."
FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c execution,-fprofile-use 
-D_PROFILE_USE

Can you please take a look?
Thanks,
Martin

[wwwdocs] Fix indentation of .ssh/config snippet

[Jonathan Wakely]

OK for wwwdocs?


commit a449e14116456cf66ea15d4aca203a50b55f6e20
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:16:12 2020 +

Fix indentation of .ssh/config snippet

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 12606201..85a0da2d 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -90,7 +90,7 @@ operation, you may want to use ssh-agent(1) and
 
 
 Host gcc.gnu.org
-ForwardX11 no
+  ForwardX11 no
 
 
 Git needs to know your name and email address.  If you have not

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Chung-Lin Tang]

On 2020/1/6 11:25 PM, Maciej W. Rozycki wrote:

  Overall if libgomp-test-support.exp is considered appropriate for
standalone testing, then I think two solutions are possible here:

1. An option is added to libgomp's $CC such that the compiler is able to
make builds involving the offload compiler where requested, and this
then propagates to GCC_UNDER_TEST as it stands.

2. The definition of GCC_UNDER_TEST in libgomp-test-support.exp is only
made if inexistent, and then you can predefine the variable in site.exp
however you find appropriate.


Hi Maciej,
I understand your situation with --with-build-sysroot/--without-sysroot, but the
way you set GCC_UNDER_TEST in libgomp-test-support.exp appears to override too
much of the machinery in libgomp/testsuite/lib/libgomp.exp that sets 
GCC_UNDER_TEST
using DejaGNU find_gcc, etc.

Can you test if the attached patch works for you? The patch exports the build 
sysroot
setting from the toplevel to target library subdirs, and adds the --sysroot= 
option
when doing build-tree testing (I assume that blddir != "" test is sufficient 
from the
surrounding comments)

I can only verify that it no longer "interferes" with our installed-mode 
testing.
Also, if this does work, then other library testsuites (e.g. libatomic.exp) 
might
also need considering updating, I think.

Thanks,
Chung-Lin

2020-01-14  Chung-Lin Tang  

* Makefile.tpl  (NORMAL_TARGET_EXPORTS): Add export of
SYSROOT_CFLAGS_FOR_TARGET variable.
* Makefile.in:  Regenerate.

libgomp/
* testsuite/lib/libgomp.exp (ALWAYS_CFLAGS): Add
--sysroot=$SYSROOT_CFLAGS_FOR_TARGET option when doing build-tree 
testing.
Fix comment typo.
* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Delete 
definition.
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp   (revision 279954)
+++ libgomp/testsuite/lib/libgomp.exp   (working copy)
@@ -171,9 +171,16 @@ proc libgomp_init { args } {
 lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
 lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
 
-# For build-tree testing, also consider the library paths used for builing.
+# For build-tree testing, also consider the library paths used for 
building.
 # For installed testing, we assume all that to be provided in the sysroot.
 if { $blddir != "" } {
+
+   # If --with-build-sysroot= was specified, we assume it will be needed
+   # for build-tree testing.
+   if [info exists SYSROOT_CFLAGS_FOR_TARGET] {
+   lappend ALWAYS_CFLAGS 
"additional_flags=--sysroot=$SYSROOT_CFLAGS_FOR_TARGET"
+   }
+   
# The `-fopenacc' and `-fopenmp' options imply `-pthread', and
# that implies `-latomic' on some hosts, so wire in libatomic
# build directories.
Index: libgomp/testsuite/libgomp-test-support.exp.in
===
--- libgomp/testsuite/libgomp-test-support.exp.in   (revision 279954)
+++ libgomp/testsuite/libgomp-test-support.exp.in   (working copy)
@@ -1,5 +1,3 @@
-set GCC_UNDER_TEST {@CC@}
-
 set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
 set cuda_driver_lib "@CUDA_DRIVER_LIB@"
 set hsa_runtime_lib "@HSA_RUNTIME_LIB@"
Index: Makefile.in
===
--- Makefile.in (revision 279954)
+++ Makefile.in (working copy)
@@ -319,6 +319,7 @@ RAW_CXX_TARGET_EXPORTS = \
 
 NORMAL_TARGET_EXPORTS = \
$(BASE_TARGET_EXPORTS) \
+   SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export 
SYSROOT_CFLAGS_FOR_TARGET; \
CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
 
 # Where to find GMP
Index: Makefile.tpl
===
--- Makefile.tpl(revision 279954)
+++ Makefile.tpl(working copy)
@@ -322,6 +322,7 @@ RAW_CXX_TARGET_EXPORTS = \
 
 NORMAL_TARGET_EXPORTS = \
$(BASE_TARGET_EXPORTS) \
+   SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export 
SYSROOT_CFLAGS_FOR_TARGET; \
CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
 
 # Where to find GMP

[wwwdocs] Recommend reviewing local changes before pushing them

[Jonathan Wakely]

I really think people should be reviewing what they're about to push
before doing it.

OK for wwwdocs?

commit 2c54cb9e98fe67096b62718d8dbd3b2ca485ff89
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:34:02 2020 +

Recommend reviewing local changes before pushing them

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 85a0da2d..98ac7201 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -274,7 +274,13 @@ made after you called git add for 
them.
 After exiting the editor, Git will check in your
 changes locally.  When your prompt returns
 the local checkin is finished, but you still need to
-push the changes to the shared repository; do git push.
+push the changes to the shared repository. Before pushing it to gcc.gnu.org,
+review your local changes to make sure your local branch only contains
+the changes you expect, e.g. git log @{u}.. or
+git diff @{u} (where @{u} refers to the upstream
+branch, most likely something like origin/master or
+origin/releases/gcc-9).
+Once you're ready to publish the changes, do git push.
 A message will be sent to the gcc-cvs mailing list indicating that a
 change was made.  If git push gives an error because
 someone else has pushed their own changes to the same branch,

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Richard Earnshaw]

On 14/01/2020 13:37, Jonathan Wakely wrote:
> I really think people should be reviewing what they're about to push
> before doing it.
> 
> OK for wwwdocs?
> 

I'd recommend

git push origin HEAD:

rather than just 'git push'

Otherwise, OK.

R.

Re: [wwwdocs] Fix indentation of .ssh/config snippet

[Richard Earnshaw]

On 14/01/2020 13:18, Jonathan Wakely wrote:
> OK for wwwdocs?
> 
> 
OK.

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

[Christophe Lyon]

On Mon, 13 Jan 2020 at 14:49, Kyrill Tkachov
 wrote:
>
> Hi Christophe,
>
> On 12/17/19 3:31 PM, Kyrill Tkachov wrote:
> >
> > On 12/17/19 2:33 PM, Christophe Lyon wrote:
> >> On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
> >>  wrote:
> >>> Hi Christophe,
> >>>
> >>> On 11/18/19 9:00 AM, Christophe Lyon wrote:
>  On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
>   wrote:
> > On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> >  wrote:
> >> On 18/10/2019 14:18, Christophe Lyon wrote:
> >>> +  bool not_supported = arm_arch_notm || flag_pic ||
>  TARGET_NEON;
> >> This is a poor name in the context of the function as a whole.
> >> What's
> >> not supported.  Please think of a better name so that I have some
> >> idea
> >> what the intention is.
> > That's to keep most of the code common when checking if -mpure-code
> > and -mslow-flash-data are supported.
> > These 3 cases are common to the two compilation flags, and
> > -mslow-flash-data still needs to check TARGET_HAVE_MOVT in addition.
> >
> > Would "common_unsupported_modes" work better for you?
> > Or I can duplicate the "arm_arch_notm || flag_pic || TARGET_NEON" in
> > the two tests.
> >
>  Hi,
> 
>  Here is an updated version, using "common_unsupported_modes" instead
>  of "not_supported", and fixing the typo reported by Kyrill.
>  The ChangeLog is still the same.
> 
>  OK?
> >>>
> >>> The name looks ok to me. Richard had a concern about Armv8-M Baseline,
> >>> but I do see it being supported as you pointed out.
> >>>
> >>> So I believe all the concerns are addressed.
> >> OK, thanks!
> >>
> >>> Thus the code is ok. However, please also updated the documentation for
> >>> -mpure-code in invoke.texi (it currently states that a MOVT instruction
> >>> is needed).
> >>>
> >> I didn't think about this :(
> >> It currently says: "This option is only available when generating
> >> non-pic code for M-profile targets with the MOVT instruction."
> >>
> >> I suggest to remove the "with the MOVT instruction" part. Is that OK
> >> if I commit my patch and this doc change?
> >
> > Yes, I think that is simplest correct change to make.
> >
>
> Can you also send a patch to the changes.html page for GCC 10 making
> users aware that this restriction is now lifted?
>

Sure. I should have thought of it when I submitted the GCC patch...

How about the attached? I'm not sure about the right upper/lower case
and  markers

Thanks,

Christophe

> Thanks,
>
> Kyrill
>
>
> > Thanks,
> >
> > Kyrill
> >
> >
> >> Christophe
> >>
> >>> Thanks,
> >>>
> >>> Kyrill
> >>>
> >>>
> >>>
>  Thanks,
> 
>  Christophe
> 
> > Thanks,
> >
> > Christophe
> >
> >> R.
commit ba2a354c9ed6c75ec00bf21dd6938b89a113a96e
Author: Christophe Lyon 
Date:   Tue Jan 14 13:48:19 2020 +

[arm] Document -mpure-code support for v6m in gcc-10

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index caa9df7..26cdf66 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -417,7 +417,11 @@ a work-in-progress.
   data-processing intrinsics to include 32-bit SIMD, saturating arithmetic,
   16-bit multiplication and other related intrinsics aimed at DSP algorithm
   optimization.
-   
+  
+  Support for -mpure-code in Thumb-1 (v6m) has been
+  added: this M-profile feature is no longer restricted to targets
+  with MOTV. For instance, Cortex-M0 is now
+  supported
 
 
 AVR

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

[Kyrill Tkachov]

On 1/14/20 1:50 PM, Christophe Lyon wrote:

On Mon, 13 Jan 2020 at 14:49, Kyrill Tkachov
 wrote:

Hi Christophe,

On 12/17/19 3:31 PM, Kyrill Tkachov wrote:

On 12/17/19 2:33 PM, Christophe Lyon wrote:

On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
 wrote:

Hi Christophe,

On 11/18/19 9:00 AM, Christophe Lyon wrote:

On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
 wrote:

On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
 wrote:

On 18/10/2019 14:18, Christophe Lyon wrote:

+  bool not_supported = arm_arch_notm || flag_pic ||

TARGET_NEON;

This is a poor name in the context of the function as a whole.
What's
not supported.  Please think of a better name so that I have some
idea
what the intention is.

That's to keep most of the code common when checking if -mpure-code
and -mslow-flash-data are supported.
These 3 cases are common to the two compilation flags, and
-mslow-flash-data still needs to check TARGET_HAVE_MOVT in addition.

Would "common_unsupported_modes" work better for you?
Or I can duplicate the "arm_arch_notm || flag_pic || TARGET_NEON" in
the two tests.


Hi,

Here is an updated version, using "common_unsupported_modes" instead
of "not_supported", and fixing the typo reported by Kyrill.
The ChangeLog is still the same.

OK?

The name looks ok to me. Richard had a concern about Armv8-M Baseline,
but I do see it being supported as you pointed out.

So I believe all the concerns are addressed.

OK, thanks!


Thus the code is ok. However, please also updated the documentation for
-mpure-code in invoke.texi (it currently states that a MOVT instruction
is needed).


I didn't think about this :(
It currently says: "This option is only available when generating
non-pic code for M-profile targets with the MOVT instruction."

I suggest to remove the "with the MOVT instruction" part. Is that OK
if I commit my patch and this doc change?

Yes, I think that is simplest correct change to make.


Can you also send a patch to the changes.html page for GCC 10 making
users aware that this restriction is now lifted?


Sure. I should have thought of it when I submitted the GCC patch...

How about the attached? I'm not sure about the right upper/lower case
and  markers

Thanks,

Christophe


commit ba2a354c9ed6c75ec00bf21dd6938b89a113a96e
Author: Christophe Lyon
Date:   Tue Jan 14 13:48:19 2020 +

[arm] Document -mpure-code support for v6m in gcc-10

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index caa9df7..26cdf66 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -417,7 +417,11 @@ a work-in-progress.
   data-processing intrinsics to include 32-bit SIMD, saturating arithmetic,
   16-bit multiplication and other related intrinsics aimed at DSP algorithm
   optimization.
-   
+  
+  Support for -mpure-code in Thumb-1 (v6m) has been
+  added: this M-profile feature is no longer restricted to targets
+  with MOTV. For instance, Cortex-M0 is now
+  supported

Typo in MOVT.
Let's make the last sentence. "For example, -mcpu=cortex-m0 now 
supports this option."

Ok with those changes.
Thanks,
Kyrill

 
 
 AVR

[PATCH] Document how to track whether you have a good build.

[Eric S. Raymond]

Document what I was told on #gcc
---
 gcc/doc/install.texi | 8 
 1 file changed, 8 insertions(+)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 643f3bb311f..12a6db1666a 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3039,6 +3039,14 @@ current time the testing harness does not allow fine 
grained control
 over whether or not a test is expected to fail.  This problem should
 be fixed in future releases.
 
+At present (Jan 2020) you can expect routine failures in quality tests
+related to the optimizer even on first-tier platforms such as x86_64.
+Until the test suite behavior is improved, an effective way to proceed
+is to run contrib/test_summary immediately after first build on a
+clean tree, save the output, and treat that as a correctness baseline.
+
+After making your changes, run contrib/test_summary again and look for
+regressions - that is, FAIL results where it was previously PASS.
 
 @section Submitting test results
 
-- 
2.20.1

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Richard Biener]

On Tue, Jan 14, 2020 at 2:37 PM Jonathan Wakely  wrote:
>
> I really think people should be reviewing what they're about to push
> before doing it.
>
> OK for wwwdocs?

So I figure that first doing the git push with -n -v and then reviewing
the pushed changes (cut&paste the revision range) with git show
is a workflow easy to remember and less "implicit" than your wording
(I dont' understand what I actually should _do_ with to review the
changes for your description)

Richard.

>

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

[Christophe Lyon]

On Tue, 14 Jan 2020 at 14:54, Kyrill Tkachov
 wrote:
>
>
> On 1/14/20 1:50 PM, Christophe Lyon wrote:
> > On Mon, 13 Jan 2020 at 14:49, Kyrill Tkachov
> >  wrote:
> >> Hi Christophe,
> >>
> >> On 12/17/19 3:31 PM, Kyrill Tkachov wrote:
> >>> On 12/17/19 2:33 PM, Christophe Lyon wrote:
>  On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
>   wrote:
> > Hi Christophe,
> >
> > On 11/18/19 9:00 AM, Christophe Lyon wrote:
> >> On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
> >>  wrote:
> >>> On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> >>>  wrote:
>  On 18/10/2019 14:18, Christophe Lyon wrote:
> > +  bool not_supported = arm_arch_notm || flag_pic ||
> >> TARGET_NEON;
>  This is a poor name in the context of the function as a whole.
>  What's
>  not supported.  Please think of a better name so that I have some
>  idea
>  what the intention is.
> >>> That's to keep most of the code common when checking if -mpure-code
> >>> and -mslow-flash-data are supported.
> >>> These 3 cases are common to the two compilation flags, and
> >>> -mslow-flash-data still needs to check TARGET_HAVE_MOVT in addition.
> >>>
> >>> Would "common_unsupported_modes" work better for you?
> >>> Or I can duplicate the "arm_arch_notm || flag_pic || TARGET_NEON" in
> >>> the two tests.
> >>>
> >> Hi,
> >>
> >> Here is an updated version, using "common_unsupported_modes" instead
> >> of "not_supported", and fixing the typo reported by Kyrill.
> >> The ChangeLog is still the same.
> >>
> >> OK?
> > The name looks ok to me. Richard had a concern about Armv8-M Baseline,
> > but I do see it being supported as you pointed out.
> >
> > So I believe all the concerns are addressed.
>  OK, thanks!
> 
> > Thus the code is ok. However, please also updated the documentation for
> > -mpure-code in invoke.texi (it currently states that a MOVT instruction
> > is needed).
> >
>  I didn't think about this :(
>  It currently says: "This option is only available when generating
>  non-pic code for M-profile targets with the MOVT instruction."
> 
>  I suggest to remove the "with the MOVT instruction" part. Is that OK
>  if I commit my patch and this doc change?
> >>> Yes, I think that is simplest correct change to make.
> >>>
> >> Can you also send a patch to the changes.html page for GCC 10 making
> >> users aware that this restriction is now lifted?
> >>
> > Sure. I should have thought of it when I submitted the GCC patch...
> >
> > How about the attached? I'm not sure about the right upper/lower case
> > and  markers
> >
> > Thanks,
> >
> > Christophe
>
> commit ba2a354c9ed6c75ec00bf21dd6938b89a113a96e
> Author: Christophe Lyon
> Date:   Tue Jan 14 13:48:19 2020 +
>
>  [arm] Document -mpure-code support for v6m in gcc-10
>
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index caa9df7..26cdf66 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -417,7 +417,11 @@ a work-in-progress.
> data-processing intrinsics to include 32-bit SIMD, saturating 
> arithmetic,
> 16-bit multiplication and other related intrinsics aimed at DSP algorithm
> optimization.
> -   
> +  
> +  Support for -mpure-code in Thumb-1 (v6m) has been
> +  added: this M-profile feature is no longer restricted to targets
> +  with MOTV. For instance, Cortex-M0 is now
> +  supported
>
> Typo in MOVT.

sigh, I did read my text several times :(

> Let's make the last sentence. "For example, -mcpu=cortex-m0 now 
> supports this option."
>
OK, thanks

> Ok with those changes.
> Thanks,
> Kyrill
>
>   
>
>   AVR
>

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Jonathan Wakely]

On 14/01/20 15:08 +0100, Richard Biener wrote:

On Tue, Jan 14, 2020 at 2:37 PM Jonathan Wakely  wrote:


I really think people should be reviewing what they're about to push
before doing it.

OK for wwwdocs?


So I figure that first doing the git push with -n -v and then reviewing
the pushed changes (cut&paste the revision range) with git show
is a workflow easy to remember and less "implicit" than your wording


"cut&paste the revision range" seems awfully tedious to me ;-)

The equivalent is 'git show @{u}..' or if you don't want to remember
the @{u} thing (aka @{upstream}), you can name the branch explicitly:

  git show origin/master..

or even more explicitly (but identical):

  git show origin/master..HEAD


(I dont' understand what I actually should _do_ with to review the
changes for your description)


If you run the commands, isn't it obvious? (Genuine question)

master wwwdocs$ git log @{u}..
commit 0eecf8a69a52cd27faeea64c8269a6df3f8db855 (HEAD -> master)
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:34:02 2020 +

Recommend reviewing local changes before pushing them

commit a449e14116456cf66ea15d4aca203a50b55f6e20
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:16:12 2020 +

Fix indentation of .ssh/config snippet

Here git log shows two local commits. If I push, they'll both be
pushed. Is that what I meant to do, or did I forget that a449e1411 was
also in my local branch?

You should check that only the commits you expect are shown in the
log.

You can also just do "git log" and check which commits are more recent
than the one shown as the upstream:

$ git log
commit 9e502f6deae9f821bd7079aad5f98a4f3bae15cf (HEAD -> master)
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:34:02 2020 +

Recommend reviewing local changes before pushing them

commit 83f833b74f2dada4235f1b68b2e3cab5e5bba757
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:16:12 2020 +

Fix indentation of .ssh/config snippet

commit 10463a79371068a0b32d8babefb9cf2ee409f4d1 (origin/master, origin/HEAD)
Author: Christophe Lyon 
Date:   Tue Jan 14 13:48:19 2020 +

[arm] Document -mpure-code support for v6m in gcc-10

The one marked (origin/master, origin/HEAD) is the commit that is
upstream, the ones before it are local.

Maybe I should just say use 'git status' and/or 'git log' and check
that your local branch doesn't contain anything unexpected.

The other command shows the diff between your local branch and
upstream. Check the diff only contains the differences you expect it
to.

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Jonathan Wakely]

On 14/01/20 13:39 +, Richard Earnshaw wrote:

On 14/01/2020 13:37, Jonathan Wakely wrote:

I really think people should be reviewing what they're about to push
before doing it.

OK for wwwdocs?



I'd recommend

git push origin HEAD:

rather than just 'git push'

Otherwise, OK.


Here's a different proposal, which adds your recommendation (in
addition to the simple 'git push') and also tries to address Richi's
concern by simplifying the instructions for checking what you're about
to push.


commit 067f0438c20e740abe71979ff82d5a5ec5bef484
Author: Jonathan Wakely 
Date:   Tue Jan 14 14:35:46 2020 +

Recommend reviewing local changes before pushing them

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 85a0da2d..3b8b18dd 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -274,7 +274,14 @@ made after you called git add for them.
 After exiting the editor, Git will check in your
 changes locally.  When your prompt returns
 the local checkin is finished, but you still need to
-push the changes to the shared repository; do git push.
+push the changes to the shared repository.  Before pushing it to gcc.gnu.org,
+make sure your local branch only contains the changes you expect,
+e.g. by reviewing the git status or git log output.
+Once you're ready to publish the changes, do git push,
+or to be more explicit,
+git push origin HEAD:,
+where  is the branch on the remote,
+such as master or releases/gcc-9.
 A message will be sent to the gcc-cvs mailing list indicating that a
 change was made.  If git push gives an error because
 someone else has pushed their own changes to the same branch,

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Richard Biener]

On Tue, Jan 14, 2020 at 3:28 PM Jonathan Wakely  wrote:
>
> On 14/01/20 15:08 +0100, Richard Biener wrote:
> >On Tue, Jan 14, 2020 at 2:37 PM Jonathan Wakely  wrote:
> >>
> >> I really think people should be reviewing what they're about to push
> >> before doing it.
> >>
> >> OK for wwwdocs?
> >
> >So I figure that first doing the git push with -n -v and then reviewing
> >the pushed changes (cut&paste the revision range) with git show
> >is a workflow easy to remember and less "implicit" than your wording
>
> "cut&paste the revision range" seems awfully tedious to me ;-)
>
> The equivalent is 'git show @{u}..' or if you don't want to remember
> the @{u} thing (aka @{upstream}), you can name the branch explicitly:
>
>git show origin/master..
>
> or even more explicitly (but identical):
>
>git show origin/master..HEAD
>
> >(I dont' understand what I actually should _do_ with to review the
> >changes for your description)
>
> If you run the commands, isn't it obvious? (Genuine question)
>
> master wwwdocs$ git log @{u}..
> commit 0eecf8a69a52cd27faeea64c8269a6df3f8db855 (HEAD -> master)
> Author: Jonathan Wakely 
> Date:   Tue Jan 14 13:34:02 2020 +
>
>  Recommend reviewing local changes before pushing them
>
> commit a449e14116456cf66ea15d4aca203a50b55f6e20
> Author: Jonathan Wakely 
> Date:   Tue Jan 14 13:16:12 2020 +
>
>  Fix indentation of .ssh/config snippet
>
> Here git log shows two local commits. If I push, they'll both be
> pushed. Is that what I meant to do, or did I forget that a449e1411 was
> also in my local branch?
>
> You should check that only the commits you expect are shown in the
> log.
>
> You can also just do "git log" and check which commits are more recent
> than the one shown as the upstream:
>
> $ git log
> commit 9e502f6deae9f821bd7079aad5f98a4f3bae15cf (HEAD -> master)
> Author: Jonathan Wakely 
> Date:   Tue Jan 14 13:34:02 2020 +
>
>  Recommend reviewing local changes before pushing them
>
> commit 83f833b74f2dada4235f1b68b2e3cab5e5bba757
> Author: Jonathan Wakely 
> Date:   Tue Jan 14 13:16:12 2020 +
>
>  Fix indentation of .ssh/config snippet
>
> commit 10463a79371068a0b32d8babefb9cf2ee409f4d1 (origin/master, origin/HEAD)
> Author: Christophe Lyon 
> Date:   Tue Jan 14 13:48:19 2020 +
>
>  [arm] Document -mpure-code support for v6m in gcc-10
>
> The one marked (origin/master, origin/HEAD) is the commit that is
> upstream, the ones before it are local.
>
> Maybe I should just say use 'git status' and/or 'git log' and check
> that your local branch doesn't contain anything unexpected.
>
> The other command shows the diff between your local branch and
> upstream. Check the diff only contains the differences you expect it
> to.

Guess the -n -v approach is more obvious that it shows what a
random git push command will do rather your description which
is vague as to what kind of push it applies to?

Richard.

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

[Richard Earnshaw (lists)]

Originally, it seemed like a good idea to add automatic 'push' rules
to the git configuration, so that personal- and vendor-space commits
would automatically push to the right place.  Unfortunately, this
changes git's behaviour and with these settings "git push" will try to
push all branches in a local tree up to the corresponding location on
the server (ignoring the push.default setting).  The only known
mitigation for this is to ALWAYS use "git push  ".

So instead, we no-longer add those rules by default and will document
the options on the wiki.  We don't automatically remove the push
entries but do print out the command that will do so, if the user so
wishes.

OK?

* gcc-git-customization.sh: Explain why we want the user's
upstream account name.  Don't add push rules.  Check if push rules
have been added and suggest that they should be removed.
* git-fetch-vendor.sh: Don't add push rules.
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 3b9d79d3d38..dae2c35bb57 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -55,7 +55,7 @@ then
 	fi
 fi
 fi
-ask "Account name on gcc.gnu.org" $remote_id remote_id
+ask "Account name on gcc.gnu.org (for your personal branches area)" $remote_id remote_id
 git config "gcc-config.user" "$remote_id"
 
 old_pfx=`git config --get "gcc-config.userpfx"`
@@ -71,4 +71,19 @@ 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}/"
-git config --replace-all "remote.${upstream}.push" "refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" "^\+?refs/heads/${old_pfx}/"
+
+push_rule=`git config --get "remote.${upstream}.push"`
+if [ "x$push_rule" != "x" ]
+then
+echo "***"
+echo "  Warning"
+echo "***"
+echo
+echo "Old versions of this script used to add custom push"
+echo "rules to simplify pushing to personal branches."
+echo "Your configuration contains such rules, but we no-longer"
+echo "recommend doing this."
+echo
+echo "To delete these rules run:"
+echo "  git config --unset-all \"remote.${upstream}.push\""
+fi
diff --git a/contrib/git-fetch-vendor.sh b/contrib/git-fetch-vendor.sh
index 5e1b1f0a854..d2d3ed56ad7 100755
--- a/contrib/git-fetch-vendor.sh
+++ b/contrib/git-fetch-vendor.sh
@@ -15,8 +15,6 @@ then
 fi
 
 echo "setting up git to fetch vendor ${vendor} to remotes/${upstream}/${vendor}"
-
 git config --replace-all "remote.${upstream}.fetch" "+refs/vendors/${vendor}/heads/*:refs/remotes/${upstream}/${vendor}/*" ":refs/remotes/${upstream}/${vendor}/"
 git config --replace-all "remote.${upstream}.fetch" "+refs/vendors/${vendor}/tags/*:refs/tags/${vendor}/*" ":refs/tags/${vendor}/"
-git config --replace-all "remote.${upstream}.push" "+refs/heads/${vendor}/*:refs/vendors/${vendor}/heads/*" "^\+refs/heads/${vendor}/"
 git fetch

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Andreas Schwab]

On Jan 14 2020, Jonathan Wakely wrote:

> You can also just do "git log" and check which commits are more recent
> than the one shown as the upstream:
>
> $ git log
> commit 9e502f6deae9f821bd7079aad5f98a4f3bae15cf (HEAD -> master)
> Author: Jonathan Wakely 
> Date:   Tue Jan 14 13:34:02 2020 +
>
> Recommend reviewing local changes before pushing them
>
> commit 83f833b74f2dada4235f1b68b2e3cab5e5bba757
> Author: Jonathan Wakely 
> Date:   Tue Jan 14 13:16:12 2020 +
>
> Fix indentation of .ssh/config snippet
>
> commit 10463a79371068a0b32d8babefb9cf2ee409f4d1 (origin/master, origin/HEAD)
> Author: Christophe Lyon 
> Date:   Tue Jan 14 13:48:19 2020 +
>
> [arm] Document -mpure-code support for v6m in gcc-10
>
> The one marked (origin/master, origin/HEAD) is the commit that is
> upstream, the ones before it are local.

Note that you need have log.decorate enabled in your config, or use git
log --decorate to enable the markers.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [wwwdocs] Recommend reviewing local changes before pushing them

[Jonathan Wakely]

On 14/01/20 16:00 +0100, Andreas Schwab wrote:

On Jan 14 2020, Jonathan Wakely wrote:


You can also just do "git log" and check which commits are more recent
than the one shown as the upstream:

$ git log
commit 9e502f6deae9f821bd7079aad5f98a4f3bae15cf (HEAD -> master)
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:34:02 2020 +

Recommend reviewing local changes before pushing them

commit 83f833b74f2dada4235f1b68b2e3cab5e5bba757
Author: Jonathan Wakely 
Date:   Tue Jan 14 13:16:12 2020 +

Fix indentation of .ssh/config snippet

commit 10463a79371068a0b32d8babefb9cf2ee409f4d1 (origin/master, origin/HEAD)
Author: Christophe Lyon 
Date:   Tue Jan 14 13:48:19 2020 +

[arm] Document -mpure-code support for v6m in gcc-10

The one marked (origin/master, origin/HEAD) is the commit that is
upstream, the ones before it are local.


Note that you need have log.decorate enabled in your config, or use git
log --decorate to enable the markers.


Thanks. Looks like log.decorate=auto is the default (so they're shown
when the log goes to a terminal, not otherwise).

[PATCH] Fix dejagnu pruning of constexpr context messages.

[Jason Merrill]

I wonder why nobody fixed this until now; it's been two years since the
diagnostic context output was changed.

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

* lib/prune.exp (prune_gcc_output): Adjust constexpr pattern.
---
 gcc/testsuite/lib/prune.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp
index 60402208c37..eea4bf383a7 100644
--- a/gcc/testsuite/lib/prune.exp
+++ b/gcc/testsuite/lib/prune.exp
@@ -35,7 +35,7 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*(: )?At (top level|global scope):\[^\n\]*" 
$text "" text
 regsub -all "(^|\n)\[^\n\]*:   (recursively )?required \[^\n\]*" $text "" 
text
 regsub -all "(^|\n)\[^\n\]*:   . skipping \[0-9\]* instantiation contexts 
\[^\n\]*" $text "" text
-regsub -all "(^|\n)\[^\n\]*:   in constexpr expansion \[^\n\]*" $text "" 
text
+regsub -all "(^|\n)\[^\n\]*:   in .constexpr. expansion \[^\n\]*" $text "" 
text
 regsub -all "(^|\n)\[^\n\]*:   in requirements \[^\n\]*" $text "" text
 regsub -all "(^|\n)inlined from \[^\n\]*" $text "" text
 regsub -all "(^|\n)collect2: error: ld returned \[^\n\]*" $text "" text

base-commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1
-- 
2.18.1

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Kamil Rytarowski]

On 10.01.2020 17:11, Jonathan Wakely wrote:
> On 07/01/20 12:44 -0800, Jason Thorpe wrote:
>>
>>> On Jan 7, 2020, at 7:43 AM, Jonathan Wakely  wrote:
>>>
>>> For Jason and Krister's benefit, that last comment was referring to
>>> an earlier suggestion to not try to support old NetBSD releases, see
>>> https://gcc.gnu.org/ml/libstdc++/2020-01/msg00026.html
>>>
 I think we need the netbsd target maintainers (CC'd) to decide whether
 GCC should still support older releases or drop that support for GCC
 10. Usually I'd say we need a period of deprecation, but if GCC
 doesn't currently build on NetBSD then maybe that's unnecessary.
>>
>> The affected NetBSD versions are NetBSD 6 and earlier, which are EOL
>> from the NetBSD perspective, so I think this is OK.
> 
> So is this patch OK then?
> 

Looks good to me.

> Could somebody please test it on NetBSD? (Ideally on the oldest
> supported release, but anything is better than nothing).
> 

Works for me on:

$ uname -a
NetBSD chieftec 9.99.37 NetBSD 9.99.37 (GENERIC) #5: Mon Jan 13 15:39:58
CET 2020
root@chieftec:/public/netbsd-root/sys/arch/amd64/compile/GENERIC amd64

I see no reason why would it break on older releases, but I don't have
them handy for tests.

> This differs from the patches posted by using _CTYPE_BL for the
> isblank class, which seems better than using _CTYPE_S.
> 
> 

_CTYPE_BL is the right bit for isblank().



signature.asc
Description: OpenPGP digital signature

[C++ PATCH] PR c++/92009 - ICE with punning of typeid.

[Jason Merrill]

There were two issues in this PR:

1) We were crashing in is_really_empty_class because we say that the
internal RTTI types are classes, but never gave them TYPE_BINFO.

2) We were allowing the cast to a different pointer type because STRIP_NOPS
in cxx_fold_indirect_ref ignored REINTERPRET_CAST_P.

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

* rtti.c (get_tinfo_desc): Call xref_basetypes.
* constexpr.c (cxx_fold_indirect_ref): Don't strip
REINTERPRET_CAST_P.
---
 gcc/cp/constexpr.c| 11 +-
 gcc/cp/rtti.c |  1 +
 .../g++.dg/cpp0x/constexpr-reinterpret2.C | 21 +++
 gcc/testsuite/g++.dg/rtti/typeid13.C  | 11 ++
 4 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret2.C
 create mode 100644 gcc/testsuite/g++.dg/rtti/typeid13.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 3a9fb566a52..bb126a9c006 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4023,7 +4023,16 @@ cxx_fold_indirect_ref (location_t loc, tree type, tree 
op0, bool *empty_base)
   tree subtype;
   poly_uint64 const_op01;
 
-  STRIP_NOPS (sub);
+  /* STRIP_NOPS, but stop if REINTERPRET_CAST_P.  */
+  while (CONVERT_EXPR_P (sub) || TREE_CODE (sub) == NON_LVALUE_EXPR
+|| TREE_CODE (sub) == VIEW_CONVERT_EXPR)
+{
+  if (TREE_CODE (sub) == NOP_EXPR
+ && REINTERPRET_CAST_P (sub))
+   return NULL_TREE;
+  sub = TREE_OPERAND (sub, 0);
+}
+
   subtype = TREE_TYPE (sub);
   if (!INDIRECT_TYPE_P (subtype))
 return NULL_TREE;
diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c
index 2fc52f07980..36c1b4ed7bc 100644
--- a/gcc/cp/rtti.c
+++ b/gcc/cp/rtti.c
@@ -1472,6 +1472,7 @@ get_tinfo_desc (unsigned ix)
   /* Pass the fields chained in reverse.  */
   finish_builtin_struct (pseudo_type, pseudo_name, fields, NULL_TREE);
   CLASSTYPE_AS_BASE (pseudo_type) = pseudo_type;
+  xref_basetypes (pseudo_type, /*bases=*/NULL_TREE);
 
   res->type = cp_build_qualified_type (pseudo_type, TYPE_QUAL_CONST);
   res->name = get_identifier (real_name);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret2.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret2.C
new file mode 100644
index 000..1bc2a8f3012
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret2.C
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+struct S { void *p; };
+struct T { S s; };
+constexpr S s = { nullptr };
+constexpr T t = { { nullptr } };
+
+constexpr void *
+foo ()
+{
+  return ((void **) &t)[0];// { dg-error "reinterpret_cast" }
+}
+
+constexpr void *
+bar ()
+{
+  return ((void **) &s)[0];// { dg-error "reinterpret_cast" }
+}
+
+constexpr auto x = foo ();
+constexpr auto y = bar ();
diff --git a/gcc/testsuite/g++.dg/rtti/typeid13.C 
b/gcc/testsuite/g++.dg/rtti/typeid13.C
new file mode 100644
index 000..d42005ed0d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/rtti/typeid13.C
@@ -0,0 +1,11 @@
+// PR c++/92009
+
+namespace std {
+  class type_info {};
+}
+
+bool
+a2 ()
+{
+  return ((void **) &typeid (int))[0];
+}

base-commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1
-- 
2.18.1

[avr,applied]: Remove a no more existing file from contrib/gcc_update::files_and_dependencies.

[Georg-Johann Lay]

Hi,

gcc/config/avr/t-multilib does no more exist, hence removed from the 
files to touch.  Applied addendum to PR92055 (which removed that file) 
as obvious.


Johann


The mentioned auto-generated file is no more part of the
GCC sources, it's auto-generated in $(builddir) during build.

PR target/92055
* contrib/gcc_update (files_and_dependencies): Remove
entry for gcc/config/avr/t-multilib.


diff --git a/contrib/gcc_update b/contrib/gcc_update
index c04b5dfb0a3..5df3297f7f8 100755
--- a/contrib/gcc_update
+++ b/contrib/gcc_update
@@ -82,7 +82,6 @@ gcc/fixinc/fixincl.x: gcc/fixinc/fixincl.tpl 
gcc/fixinc/inclhack.def
 gcc/config/aarch64/aarch64-tune.md: 
gcc/config/aarch64/aarch64-cores.def gcc/config/aarch64/gentune.sh
 gcc/config/arm/arm-tune.md: gcc/config/arm/arm-cpus.in 
gcc/config/arm/parsecpu.awk
 gcc/config/arm/arm-tables.opt: gcc/config/arm/arm-cpus.in 
gcc/config/arm/parsecpu.awk
-gcc/config/avr/t-multilib: gcc/config/avr/avr-mcus.def 
gcc/config/avr/genmultilib.awk
 gcc/config/c6x/c6x-tables.opt: gcc/config/c6x/c6x-isas.def 
gcc/config/c6x/genopt.sh
 gcc/config/c6x/c6x-sched.md: gcc/config/c6x/c6x-sched.md.in 
gcc/config/c6x/gensched.sh
 gcc/config/c6x/c6x-mult.md: gcc/config/c6x/c6x-mult.md.in 
gcc/config/c6x/genmult.sh

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Jason Thorpe]

> On Jan 14, 2020, at 8:49 AM, Kamil Rytarowski  wrote:
> 
> On 10.01.2020 17:11, Jonathan Wakely wrote:
>> On 07/01/20 12:44 -0800, Jason Thorpe wrote:
>>> 
 On Jan 7, 2020, at 7:43 AM, Jonathan Wakely  wrote:
 
 For Jason and Krister's benefit, that last comment was referring to
 an earlier suggestion to not try to support old NetBSD releases, see
 https://gcc.gnu.org/ml/libstdc++/2020-01/msg00026.html
 
> I think we need the netbsd target maintainers (CC'd) to decide whether
> GCC should still support older releases or drop that support for GCC
> 10. Usually I'd say we need a period of deprecation, but if GCC
> doesn't currently build on NetBSD then maybe that's unnecessary.
>>> 
>>> The affected NetBSD versions are NetBSD 6 and earlier, which are EOL
>>> from the NetBSD perspective, so I think this is OK.
>> 
>> So is this patch OK then?
>> 
> 
> Looks good to me.

Now that we have Kamil's confirmation that it's working for him, it also gets a 
thumbs-up from me.

Thanks!

> 
>> Could somebody please test it on NetBSD? (Ideally on the oldest
>> supported release, but anything is better than nothing).
>> 
> 
> Works for me on:
> 
> $ uname -a
> NetBSD chieftec 9.99.37 NetBSD 9.99.37 (GENERIC) #5: Mon Jan 13 15:39:58
> CET 2020
> root@chieftec:/public/netbsd-root/sys/arch/amd64/compile/GENERIC amd64
> 
> I see no reason why would it break on older releases, but I don't have
> them handy for tests.
> 
>> This differs from the patches posted by using _CTYPE_BL for the
>> isblank class, which seems better than using _CTYPE_S.
>> 
>> 
> 
> _CTYPE_BL is the right bit for isblank().
> 

-- thorpej

[C++ PATCH] PR c++/92594 - ICE with inherited trivial default ctor.

[Jason Merrill]

Here we were getting confused about whether or not pod_tuple has a trivial
default constructor.  bar inherits the trivial e default constructor; the
effect of calling that inherited constructor is equivalent to calling a
defaulted default constructor in bar, so let's treat it as such.

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

* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.
---
 gcc/cp/method.c |  7 ++-
 gcc/testsuite/g++.dg/cpp0x/inh-ctor34.C | 13 +
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/inh-ctor34.C

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index fef19e18196..e20a88febdc 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -458,7 +458,12 @@ trivial_fn_p (tree fn)
   /* If fn is a clone, get the primary variant.  */
   if (tree prim = DECL_CLONED_FUNCTION (fn))
 fn = prim;
-  return type_has_trivial_fn (DECL_CONTEXT (fn), special_function_p (fn));
+  special_function_kind sfk = special_function_p (fn);
+  /* An inherited default constructor is equivalent to a non-inherited default
+ constructor, so let it be trivial.  */
+  if (sfk == sfk_inheriting_constructor && default_ctor_p (fn))
+sfk = sfk_constructor;
+  return type_has_trivial_fn (DECL_CONTEXT (fn), sfk);
 }
 
 /* PARM is a PARM_DECL for a function which we want to forward to another
diff --git a/gcc/testsuite/g++.dg/cpp0x/inh-ctor34.C 
b/gcc/testsuite/g++.dg/cpp0x/inh-ctor34.C
new file mode 100644
index 000..9afc0e9e536
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/inh-ctor34.C
@@ -0,0 +1,13 @@
+// PR c++/92594
+// { dg-do compile { target c++11 } }
+
+template  struct tuple {
+  tuple() : _M_head_impl() {}
+  _Head _M_head_impl;
+};
+template  struct pod_tuple { type0 _head; };
+struct e {};
+struct bar : e {
+  using e::e;
+};
+int main() { tuple> a; }

base-commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1
-- 
2.18.1

Re: [PATCH 1/2] hash-table.h: support non-zero empty values in empty_slow (v2)

[David Malcolm]

On Tue, 2020-01-14 at 11:02 +0100, Jakub Jelinek wrote:
> On Mon, Jan 13, 2020 at 11:51:53PM -0500, David Malcolm wrote:
> > > * cfg.s correctly has a call to memset (even with no
> > > optimization)
> > > for
> > > hash_table::empty_slow
> 
> I have intestigated unpatched cc1plus and in the (usually inlined)
> alloc_entries I see in all the places the xcalloc or
> ggc_internal_cleared_alloc
> followed by either a loop storing some zeros or a memset, which is
> something
> I'd hope the patch also improves.

It does: I looked at tree-ssa.s, at the alloc_entries code generated
for:
   static hash_map > *edge_var_maps;

In an unoptimized build:
  Before the patch I see the loop in the .s calling mark_empty after
the calls to data_alloc and ggc_cleared_vec_alloc; 
  After the patch there's no longer that loop in the generated .s

With -O2 it's harder to follow as the ctor gets inlined into
redirect_edge_var_map_add, but:
  Before the patch there's a loop that's zeroing the keys after the
call to ggc_internal_cleared_alloc
  After the patch that loop isn't present.

> As for graphite.c, sure, empty_zero_p = false is a fallback value,
> the
> question was not directly related to this patch, but rather wondering
> how it
> can work at all.
> 
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu (in
> > conjuction with the analyzer patch kit, which it fixes)
> > 
> > OK for master?
> 
> Yes to both patches, thanks.

Thanks.  I rebased and did another bootstrap®ression test with just
patch 1 to be sure.  I've pushed it to master as
7ca50de02cf12c759f4f8daf60913704782b7d45.


I've rebased and squashed the analyzer patch kit and squashed patch 2
into it, and am re-testing it now.

Dave

Re: [PATCH v7] Missed function specialization + partial devirtualization

[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.

gcc/ChangeLog:
* 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 fc231c916b7..699419ead19 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -1069,3 +1069,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

[PATCH, i386]: Fix PR93254, -msse generates sse2 instructions

[Uros Bizjak]

2020-01-14  Uroš Bizjak  

PR target/93254
* config/i386/i386.md (*movsf_internal): Require SSE2 ISA for
alternatives 9 and 10.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline, will be backported to gcc-9 branch.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 03441109f48..f08410a471e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3696,7 +3696,7 @@
 }
 }
   [(set (attr "isa")
- (cond [(eq_attr "alternative" "14,15")
+ (cond [(eq_attr "alternative" "9,10,14,15")
  (const_string "sse2")
   ]
   (const_string "*")))

[PR90916] ICE in retrieve specialization

[Nathan Sidwell]

This fixes an ICE caused by a cleanup of get_class_binding.  Previously 
its type_or_fn parm defaulted to -1, which had some funky behaviour I 
convinced myself was irrelevant to C++ source.  Here we're peeking 
behind the curtain of a class under construction, and previously the -1 
behaviour caused us never to see a type here -- we could only get back 
function decls, because we only looked in the method_vector (and that's 
only created during construction if there are functions).


so, look at DECL_TEMPLATE_INFO or CLASSTYPE_TEMPLATE_INFO depending on 
what we got back.  Incidentally, this means we will now optimize member 
class instantiations in this case, whereas before we didn't.


Committing to trunk.

nathan
--
Nathan Sidwell
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 004ce0fdcdf..3cc7c48b490 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2020-01-14  Nathan Sidwell  
+
+	PR c++/90916
+	* pt.c (retrieve_specialization): Get the TI from the decl or the
+	classtype as appropriate.
+
 2020-01-14  David Malcolm  
 
 	* cp-gimplify.c (source_location_table_entry_hash::empty_zero_p):
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index fa82ecad233..4fdc74f9ca8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1252,11 +1252,16 @@ retrieve_specialization (tree tmpl, tree args, hashval_t hash)
   for (ovl_iterator iter (fns); iter; ++iter)
 	{
 	  tree fn = *iter;
-	  if (DECL_TEMPLATE_INFO (fn) && DECL_TI_TEMPLATE (fn) == tmpl
-	  /* using-declarations can add base methods to the method vec,
-		 and we don't want those here.  */
-	  && DECL_CONTEXT (fn) == class_specialization)
-	return fn;
+	  if (tree ti = (TREE_CODE (fn) == TYPE_DECL && !TYPE_DECL_ALIAS_P (fn)
+			 ? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
+			 : DECL_TEMPLATE_INFO (fn)))
+	if (TI_TEMPLATE (ti) == tmpl
+		/* using-declarations can bring in a different
+		   instantiation of tmpl as a member of a different
+		   instantiation of tmpl's class.  We don't want those
+		   here.  */
+		&& DECL_CONTEXT (fn) == class_specialization)
+	  return fn;
 	}
   return NULL_TREE;
 }
diff --git a/gcc/testsuite/g++.dg/template/pr90916.C b/gcc/testsuite/g++.dg/template/pr90916.C
new file mode 100644
index 000..bdb7e7b58ef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr90916.C
@@ -0,0 +1,8 @@
+// PR c++/90916 ICE in retrieve_specialization
+
+template  struct S
+{
+  struct A;
+  struct f A ();
+};
+template class S ;

Re: [PR90916] ICE in retrieve specialization

[Jason Merrill]

On 1/14/20 2:14 PM, Nathan Sidwell wrote:

+ if (tree ti = (TREE_CODE (fn) == TYPE_DECL && !TYPE_DECL_ALIAS_P (fn)
+? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
+: DECL_TEMPLATE_INFO (fn)))


Is there a reason not to use get_template_info?

Jason

[C++ PATCH] PR c++/92590 - wrong handling of inherited default ctor.

[Jason Merrill]

I thought my earlier fix for 91930 was an obvious bug fix, but apparently an
inherited constructor does not count as user-declared.  So this patch
reverts that change and the other follow-on patches, and fixes 91930
differently, by not letting the inherited default constructor hide the
implicitly-declared default constructor.

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

* class.c (add_method): A constrained inherited ctor doesn't hide an
implicit derived ctor.

Revert:
PR c++/91930 - ICE with constrained inherited default ctor.
* name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR
for inherited constructor.
PR c++/92552 - ICE with inherited constrained default ctor.
* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
PR c++/92594 - ICE with inherited trivial default ctor.
* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.
---
 gcc/cp/class.c |  5 +++--
 gcc/cp/method.c|  7 +--
 gcc/cp/name-lookup.c   |  1 -
 gcc/cp/pt.c|  1 -
 gcc/testsuite/g++.dg/concepts/inherit-ctor3.C  |  4 ++--
 gcc/testsuite/g++.dg/cpp0x/inh-ctor35.C| 14 ++
 gcc/testsuite/g++.dg/cpp0x/inh-ctor5.C |  4 ++--
 gcc/testsuite/g++.dg/cpp1z/inh-ctor22.C|  4 ++--
 .../g++.dg/cpp2a/concepts-inherit-ctor2.C  |  4 ++--
 gcc/testsuite/g++.dg/template/crash7.C |  4 +++-
 gcc/testsuite/g++.old-deja/g++.pt/error2.C |  2 +-
 11 files changed, 30 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/inh-ctor35.C

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 07abe5298d1..719c3ece6e1 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1079,9 +1079,10 @@ add_method (tree type, tree method, bool via_using)
{
  special_function_kind sfk = special_memfn_p (method);
 
- if (sfk == sfk_none)
+ if (sfk == sfk_none || DECL_INHERITED_CTOR (fn))
/* Non-special member functions coexist if they are not
-  equivalently constrained.  */
+  equivalently constrained.  A member function is not hidden
+  by an inherited constructor.  */
continue;
 
  /* P0848: For special member functions, deleted, unsatisfied, or
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index e20a88febdc..fef19e18196 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -458,12 +458,7 @@ trivial_fn_p (tree fn)
   /* If fn is a clone, get the primary variant.  */
   if (tree prim = DECL_CLONED_FUNCTION (fn))
 fn = prim;
-  special_function_kind sfk = special_function_p (fn);
-  /* An inherited default constructor is equivalent to a non-inherited default
- constructor, so let it be trivial.  */
-  if (sfk == sfk_inheriting_constructor && default_ctor_p (fn))
-sfk = sfk_constructor;
-  return type_has_trivial_fn (DECL_CONTEXT (fn), sfk);
+  return type_has_trivial_fn (DECL_CONTEXT (fn), special_function_p (fn));
 }
 
 /* PARM is a PARM_DECL for a function which we want to forward to another
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 3c2c50d13a4..cd7a5816e46 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -4634,7 +4634,6 @@ lookup_using_decl (tree scope, name_lookup &lookup)
  maybe_warn_cpp0x (CPP0X_INHERITING_CTORS);
  lookup.name = ctor_identifier;
  CLASSTYPE_NON_AGGREGATE (current) = true;
- TYPE_HAS_USER_CONSTRUCTOR (current) = true;
}
 
   /* Cannot introduce a constructor name.  */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index fa82ecad233..3793b33ce4d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11573,7 +11573,6 @@ instantiate_class_template_1 (tree type)
   SET_TYPE_ALIGN (type, TYPE_ALIGN (pattern));
   TYPE_USER_ALIGN (type) = TYPE_USER_ALIGN (pattern);
   CLASSTYPE_NON_AGGREGATE (type) = CLASSTYPE_NON_AGGREGATE (pattern);
-  TYPE_HAS_USER_CONSTRUCTOR (type) = TYPE_HAS_USER_CONSTRUCTOR (pattern);
   if (ANON_AGGR_TYPE_P (pattern))
 SET_ANON_AGGR_TYPE_P (type);
   if (CLASSTYPE_VISIBILITY_SPECIFIED (pattern))
diff --git a/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C 
b/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
index dda202f4c24..abfe96e8240 100644
--- a/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
+++ b/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
@@ -11,7 +11,7 @@ template
   };
 
 template
-  struct S2 : S1 {
+  struct S2 : S1 { // { dg-error "no matching function" }
 using S1::S1; // { dg-error "no matching function" }
   };
 
@@ -19,5 +19,5 @@ struct X { } x;
 
 int main() {
   S2 s1(0); // { dg-error "use of deleted function" }
-  S2 s2; // { dg-error "no matching function" }
+  S2 s2; // { dg-error "use of dele

Re: [PR90916] ICE in retrieve specialization

[Nathan Sidwell]

On 1/14/20 3:13 PM, Jason Merrill wrote:

On 1/14/20 2:14 PM, Nathan Sidwell wrote:
+  if (tree ti = (TREE_CODE (fn) == TYPE_DECL && 
!TYPE_DECL_ALIAS_P (fn)

+ ? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
+ : DECL_TEMPLATE_INFO (fn)))


Is there a reason not to use get_template_info?


thanks for the pointer, I'll go do that.

nathan

--
Nathan Sidwell

Re: [PATCH] Fix a bug that propagation in recursive function uses wrong aggregate lattice (PR ipa/93084)

[Jeff Law]

On Tue, 2020-01-07 at 14:18 +0100, Martin Jambor wrote:
> Hi,
> 
> On Fri, Jan 03 2020, Feng Xue OS wrote:
> > When checking a self-recursively generated value for aggregate jump
> > function, wrong aggregate lattice was used, which will cause infinite
> > constant propagation. This patch is composed to fix this issue. 
> > 
> > 2020-01-03  Feng Xue  
> > 
> > PR ipa/93084
> > * ipa-cp.c (self_recursively_generated_p): Find matched aggregate
> > lattice for a value to check.
> > (propagate_vals_across_arith_jfunc): Add an assertion to ensure
> > finite propagation in self-recursive scc.
> 
> as far as I am concerned, the patch looks good.
In that case, OK for the trunk :-)

jeff
> 

Re: [PATCH] gdbinit.in: make shorthands accept an explicit argument

[Jeff Law]

On Sat, 2020-01-04 at 16:35 +0300, Alexander Monakov wrote:
> Hi,
> 
> I'm posting an updated patch for GCC gdbinit originally proposed by 
> Konstantin.
> The patch amends debugging shorthands such as 'pr' to accept an explicit
> argument, in addition to taking an implicit argument from $ as today. In other
> words,
> 
>   pr x
> 
> will be accepted to call 'debug_rtx (x)' just like
> 
>   p x
>   pr
> 
> does today.
> 
> I've noticed Konstantin's patch left documentation bits inconsistent with the
> new implementation, so I amended them manually and introduced a new
> 'help-gcc-hooks' command with the index and some general info. I also fixed a
> leftover '$' remaining in 'prc' command.
> 
> Okay to apply?
> 
> Alexander
> 
>   * gdbinit.in (help-gcc-hooks): New command.
>   (pp, pr, prl, pt, pct, pgg, pgq, pgs, pge, pmz, ptc, pdn, ptn, pdd, prc,
>   pi, pbm, pel, trt): Take $arg0 instead of $ if supplied. Update
>   documentation.
OK
jeff
> 

Re: [PATCH] Remove redundant builtins for avx512f scalar instructions.

[Jeff Law]

On Tue, 2019-12-24 at 13:31 +0800, Hongyu Wang wrote:
> Hi:
>   For avx512f scalar instructions, current builtin function like
> __builtin_ia32_*{sd,ss}_round can be replaced by
> __builtin_ia32_*{sd,ss}_mask_round with mask parameter set to -1. This
> patch did the replacement and remove the corresponding redundant
> builtins.
> 
>   Bootstrap is ok, make-check ok for i386 target.
>   Ok for trunk?
> 
> Changelog
> 
> gcc/
> * config/i386/avx512fintrin.h
> (_mm_add_round_sd, _mm_add_round_ss): Use
>  __builtin_ia32_adds?_mask_round builtins instead of
> __builtin_ia32_adds?_round.
> (_mm_sub_round_sd, _mm_sub_round_ss,
> _mm_mul_round_sd, _mm_mul_round_ss,
> _mm_div_round_sd, _mm_div_round_ss,
> _mm_getexp_sd, _mm_getexp_ss,
> _mm_getexp_round_sd, _mm_getexp_round_ss,
> _mm_getmant_sd, _mm_getmant_ss,
> _mm_getmant_round_sd, _mm_getmant_round_ss,
> _mm_max_round_sd, _mm_max_round_ss,
> _mm_min_round_sd, _mm_min_round_ss,
> _mm_fmadd_round_sd, _mm_fmadd_round_ss,
> _mm_fmsub_round_sd, _mm_fmsub_round_ss,
> _mm_fnmadd_round_sd, _mm_fnmadd_round_ss,
> _mm_fnmsub_round_sd, _mm_fnmsub_round_ss): Likewise.
> * config/i386/i386-builtin.def
> (__builtin_ia32_addsd_round, __builtin_ia32_addss_round,
> __builtin_ia32_subsd_round, __builtin_ia32_subss_round,
> __builtin_ia32_mulsd_round, __builtin_ia32_mulss_round,
> __builtin_ia32_divsd_round, __builtin_ia32_divss_round,
> __builtin_ia32_getexpsd128_round, __builtin_ia32_getexpss128_round,
> __builtin_ia32_getmantsd_round, __builtin_ia32_getmantss_round,
> __builtin_ia32_maxsd_round, __builtin_ia32_maxss_round,
> __builtin_ia32_minsd_round, __builtin_ia32_minss_round,
> __builtin_ia32_vfmaddsd3_round,
> __builtin_ia32_vfmaddss3_round): Remove.
> * config/i386/i386-expand.c
> (ix86_expand_round_builtin): Remove corresponding case.
This doesn't really look like a bugfix to me.  Can it wait for gcc-11?

jeff
> 

Analyzer committed to master (was Re: Analyzer status)

[David Malcolm]

On Tue, 2020-01-14 at 08:55 +0100, Richard Biener wrote:
> On Mon, 13 Jan 2020, David Malcolm wrote:
> 
> > I posted the initial version of the analyzer patch kit on 2019-11-
> > 15,
> > shortly before the close of stage 1.
> > 
> > Jeff reviewed (most of) the latest version of the kit on Friday,
> > and
> > said:
> > 
> > > I'm not going to have time to finish #22 or #37 -- hell, I'm not
> > > even
> > > supposed to be working today :-)
> > > 
> > > I'd suggest committing now and we can iterate on any issues.  The
> > > code
> > > is appropriately conditionalized, so it shouldn't affect anyone
> > > that
> > > doesn't ask for it and it was submitted prior to stage1 close.
> > > 
> > > I would also suggest that we have a fairly loose policy for these
> > > bits
> > > right now.  Again, they're conditionally compiled and it's
> > > effectively
> > > "tech preview", so if we muck something up, the after-effects are
> > > relatively small.
> > 
> > Unfortunately, I didn't resolve the hash_table/hash_map issue
> > referred to here:
> >   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00734.html
> > where r279139 on 2019-12-09 introduced the assumption that empty
> > hash_table entries and empty hash_map keys are all zeroes.
> > 
> > The analyzer uses hash_map::empty in a single place with a hash_map
> > where the "empty" key value is all-ones.
> > 
> > Unfortunately, without a fix for this issue, the analyzer can hang,
> > leading to DejaGnu hanging, which I clearly don't want to push to
> > master as-is.
> > 
> > The patch here fixes the issue:
> >   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00776.html
> > but Jakub has expressed concern about the effect on code generated
> > for the compiler.
> > 
> > As noted here:
> >   https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00651.html
> > gcc successfully converts this back to a memset to 0 for hash_table
> > at -O2, but not for hash_map, since it can't "know" that it's OK to
> > clobber the values as well as the keys; it instead generates a loop
> > that zeroes the keys without touching the values.
> > 
> > I've been experimenting with adding template specializations to try
> > to allow for memset to 0 for hash_map, but haven't been successful
> > (e.g. std::is_pod is C++11-only); my closest attempt so far is at:
> >   
> > https://dmalcolm.fedorapeople.org/gcc/2020-01-13/0001-FIXME-experiments-with-fixing-hash_map-empty.patch
> > which at least expresses the memset to 0 without needing
> > optimization for hash_table of *pointer* types, but I wasn't able
> > to
> > do the same for hash_map, today at least.
> > 
> > If the hash_map::empty patch is unacceptable, I've also
> > successfully
> > B&R-ed the following kludge to the analyzer, which avoids using
> > hash_map::empty at the single place where it's problematic.  This
> > kludge is entirely confined to the analyzer.
> > 
> > I'd like to get the analyzer code into gcc 10, but I appreciate
> > it's
> > now stage 4.  Jakub suggested on IRC that with approval before the
> > end of stage 3 (which it was), there may be some flexibility if we
> > get it in soon and I take steps to minimize disruption.
> > 
> > Some options:
> > (a) the patch to fix hash_table::empty, and the analyzer kit
> > (b) the analyzer kit with the following kludge
> > (c) someone with better C++-fu than me figure out a way to get the
> > memset optimization for hash_map with 0-valued empty (or to give me
> > some suggestions)
> > (d) not merge the analyzer for gcc 10
> > 
> > My preferred approach is option (a), but option (b) is confined to
> > the analyzer.
> > 
> > Thoughts?
> 
> (b)
> 
> we can iterate on (a)/(c) if deemed necessary but also this can be
> done
> during next stage1.

Thanks.  Jakub's proposed fix worked, so I've effectively gone with
(c).

I've rebased and squashed the analyzer patch kit and squashed patch 2
of the hash_table fix into it, and re-tested it successfully, so I've
pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7).

I'm going to work through the various followup patches I had on my
branch and re-test and push to master those that seem appropriate.

Dave

Re: [PATCH] Fix wrong-code x86 issue with avx512{f,vl} fma (PR target/93009)

[Jeff Law]

On Sat, 2019-12-21 at 00:34 +0100, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, the following testcase is miscompiled with avx512vl.
> The reason is that the fma *_bcst_1 define_insns have two alternatives:
> "=v,v" "0,v" "v,0" "m,m" and use the same
> vfmadd213* %3, %2, %0
> pattern.  If the first alternative is chosen, everything is ok, but if the
> second alternative is chosen, %2 and %0 are the same register, so instead
> of doing dest=dest*another+membcst we do dest=dest*dest+membcst.
> Now, to fix this, either we'd need separate:
>   "vfmadd213\t{%3, %2, 
> %0|%0, %2, %3}
>vfmadd213\t{%3, %1, 
> %0|%0, %1, %3}"
> where for the second alternative, we'd just use %1 instead of %2, but
> what I think is actually cleaner is just use a single alternative and
> make the two multiplication operands commutative, which they really are.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2019-12-20  Jakub Jelinek  
> 
>   PR target/93009
>   * config/i386/sse.md
>   (*fma_fmadd__bcst_1,
>   *fma_fmsub__bcst_1,
>   *fma_fnmadd__bcst_1,
>   *fma_fnmsub__bcst_1): Use
>   just a single alternative instead of two, make operands 1 and 2
>   commutative.
> 
>   * gcc.target/i386/avx512vl-pr93009.c: New test.
OK
jeff
> 

Re: [PATCH] Fix symver attribute with LTO

[Jeff Law]

On Wed, 2019-12-18 at 10:26 +0100, Jan Hubicka wrote:
> Hi,
> sorry I forgot to include cgraph and varpool changes in the patch.
> 
> Index: varpool.c
> ===
> --- varpool.c (revision 279467)
> +++ varpool.c (working copy)
> @@ -539,8 +539,7 @@ varpool_node::assemble_aliases (void)
>  {
>varpool_node *alias = dyn_cast  (ref->referring);
>if (alias->symver)
> - do_assemble_symver (alias->decl,
> - DECL_ASSEMBLER_NAME (decl));
> + do_assemble_symver (alias->decl, decl);
>else if (!alias->transparent_alias)
>   do_assemble_alias (alias->decl,
>  DECL_ASSEMBLER_NAME (decl));
[ ... ]
Do you plan on committing these bits?

jeff
> 

Re: [PATCH PR92926]Fix wrong code caused by ctor node translation unit wide sharing

[Jeff Law]

On Thu, 2020-01-09 at 14:20 +0800, Bin.Cheng wrote:
> On Fri, Dec 20, 2019 at 3:10 PM Richard Biener
>  wrote:
> > On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng" 
> >  wrote:
> > > On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
> > >  wrote:
> > > > Hi,
> > > > 
> > > > As reported in PR92926, constant ctor is shared translation unit wide
> > > because of constexpr_call_table,
> > > > however, during gimplify, the shared ctor could be modified.  This
> > > patch fixes the issue by unsharing
> > > > it before modification in gimplify.  A test is reduced from cppcoro
> > > library and added.
> > > > Bootstrap and test ongoing.  Not sure if this is the correct fix
> > > though, any comments?
> > > Ping.  Any comment?
> > 
> > Looks reasonable to me.
> Given PR92926 is marked as duplicate of PR93143, I updated test case
> of the patch.
> 
> Thanks,
> bin
> 
> 2019-12-13  Bin Cheng  
> 
> PR tree-optimization/93143
> * gimplify.c (gimplify_init_constructor): Unshare ctor node before
> clearing.
> 
> gcc/testsuite
> 2019-12-13  Bin Cheng  
> 
> PR tree-optimization/93143
> * g++.dg/pr93143.C: New test.
Is this still needed?  I think Jason fixed the outstanding sharing
problems a couple days ago.

jeff

Re: [PR90916] ICE in retrieve specialization

[Nathan Sidwell]

On 1/14/20 3:29 PM, Nathan Sidwell wrote:

On 1/14/20 3:13 PM, Jason Merrill wrote:

On 1/14/20 2:14 PM, Nathan Sidwell wrote:
+  if (tree ti = (TREE_CODE (fn) == TYPE_DECL && 
!TYPE_DECL_ALIAS_P (fn)

+ ? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
+ : DECL_TEMPLATE_INFO (fn)))


Is there a reason not to use get_template_info?


thanks for the pointer, I'll go do that.


Done.

nathan
--
Nathan Sidwell
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index c1375398517..59e0994c397 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,9 @@
 2020-01-14  Nathan Sidwell  
 
+	PT c++/90916
+	* pt.c (retrieve_specialization): Use get_template_info, not open
+	coding access.
+
 	PR c++/90916
 	* pt.c (retrieve_specialization): Get the TI from the decl or the
 	classtype as appropriate.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7e675ce9039..9bb8cc13e5f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1252,9 +1252,7 @@ retrieve_specialization (tree tmpl, tree args, hashval_t hash)
   for (ovl_iterator iter (fns); iter; ++iter)
 	{
 	  tree fn = *iter;
-	  if (tree ti = (TREE_CODE (fn) == TYPE_DECL && !TYPE_DECL_ALIAS_P (fn)
-			 ? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
-			 : DECL_TEMPLATE_INFO (fn)))
+	  if (tree ti = get_template_info (fn))
 	if (TI_TEMPLATE (ti) == tmpl
 		/* using-declarations can bring in a different
 		   instantiation of tmpl as a member of a different

RE: [PATCH] Add Optimization for various IPA parameters.

[Tamar Christina]

Hi Xiong,

> > It seems the parameters no longer do anything. i.e. -flto --param ipa-cp-
> eval-threshold=1 --param ipa-cp-unit-growth=80 doesn't have any effect
> anymore.
> 
> Strange that you don't need -fno-inline to achieve the 30% performance
> boost, I found that some specialized nodes are recursively inlined cause
> register spill and no performance improve.  What's your platform and could
> you please try it with -fno-inline and see any difference please?
> 

You do indeed need to restrict inlining, but that wasn't needed for this 
regression report so I
omitted the extra options. 

Regards,
Tamar

> Thanks
> Xiong Hu
> >
> > Thanks,
> > Tamar
> >
> >> -Original Message-
> >> From: gcc-patches-ow...@gcc.gnu.org 
> >> On Behalf Of Martin Jambor
> >> Sent: Wednesday, January 8, 2020 4:14 PM
> >> To: Martin Liška ; gcc-patches@gcc.gnu.org
> >> Cc: hubi...@ucw.cz; Richard Biener 
> >> Subject: Re: [PATCH] Add Optimization for various IPA parameters.
> >>
> >> Hi,
> >>
> >> On Fri, Jan 03 2020, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> This is similar transformation for IPA passes. This time, one needs
> >>> to use opt_for_fn in order to get the right parameter values.
> >>>
> >>> @Martin, Honza:
> >>> There are last few remaining parameters which should use
> >>> opt_for_fn:
> >>>
> >>> param_ipa_cp_unit_growth
> >>
> >> So as we discussed, picking this one from one particular node is not
> >> what one would expect to happen, but inlining does it too and so anyway:
> >>
> >>
> >> IPA-CP: Always access param_ipcp_unit_growth through opt_for_fn
> >>
> >> 2020-01-07  Martin Jambor  
> >>
> >>* params.opt (param_ipcp_unit_growth): Mark as Optimization.
> >>* ipa-cp.c (max_new_size): Removed.
> >>(orig_overall_size): New variable.
> >>(get_max_overall_size): New function.
> >>(estimate_local_effects): Use it.  Adjust dump.
> >>(decide_about_value): Likewise.
> >>(ipcp_propagate_stage): Do not calculate max_new_size, just store
> >>orig_overall_size.  Adjust dump.
> >>(ipa_cp_c_finalize): Clear orig_overall_size instead of max_new_size.
> >> ---
> >>   gcc/ipa-cp.c   | 39 ++-
> >>   gcc/params.opt |  2 +-
> >>   2 files changed, 27 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c index
> >> 9e20e278eff..c2572e3e0e8
> >> 100644
> >> --- a/gcc/ipa-cp.c
> >> +++ b/gcc/ipa-cp.c
> >> @@ -375,7 +375,7 @@ static profile_count max_count;
> >>
> >>   /* Original overall size of the program.  */
> >>
> >> -static long overall_size, max_new_size;
> >> +static long overall_size, orig_overall_size;
> >>
> >>   /* Node name to unique clone suffix number map.  */  static
> >> hash_map *clone_num_suffixes; @@ -3395,6
> >> +3395,23 @@ perform_estimation_of_a_value (cgraph_node *node,
> >> vec known_csts,
> >> val->local_size_cost = size;
> >>   }
> >>
> >> +/* Get the overall limit oof growth based on parameters extracted
> >> +from
> >> growth.
> >> +   it does not really make sense to mix functions with different
> >> + overall
> >> growth
> >> +   limits but it is possible and if it happens, we do not want to select 
> >> one
> >> +   limit at random.  */
> >> +
> >> +static long
> >> +get_max_overall_size (cgraph_node *node) {
> >> +  long max_new_size = orig_overall_size;
> >> +  long large_unit = opt_for_fn (node->decl, param_large_unit_insns);
> >> +  if (max_new_size < large_unit)
> >> +max_new_size = large_unit;
> >> +  int unit_growth = opt_for_fn (node->decl, param_ipcp_unit_growth);
> >> +  max_new_size += max_new_size * unit_growth / 100 + 1;
> >> +  return max_new_size;
> >> +}
> >> +
> >>   /* Iterate over known values of parameters of NODE and estimate the
> local
> >>  effects in terms of time and size they have.  */
> >>
> >> @@ -3457,7 +3474,7 @@ estimate_local_effects (struct cgraph_node
> *node)
> >>   stats.freq_sum, stats.count_sum,
> >>   size))
> >>{
> >> -if (size + overall_size <= max_new_size)
> >> +if (size + overall_size <= get_max_overall_size (node))
> >>{
> >>  info->do_clone_for_all_contexts = true;
> >>  overall_size += size;
> >> @@ -3467,8 +3484,8 @@ estimate_local_effects (struct cgraph_node
> *node)
> >> "known contexts, growth deemed beneficial.\n");
> >>}
> >>  else if (dump_file && (dump_flags & TDF_DETAILS))
> >> -  fprintf (dump_file, "   Not cloning for all contexts because "
> >> -   "max_new_size would be reached with %li.\n",
> >> +  fprintf (dump_file, "  Not cloning for all contexts because "
> >> +   "maximum unit size would be reached with %li.\n",
> >> size + overall_size);
> >>}
> >> else if (dump_file && (dump_flags & TDF_DETAILS)) @@ -3860,14
> >> +3877,10 @@ ipcp_propagate_stage (class ipa_topo_info *topo)
> >>   max_count = max_count.max (node-

Re: [PR90916] ICE in retrieve specialization

[Marek Polacek]

On Tue, Jan 14, 2020 at 04:10:07PM -0500, Nathan Sidwell wrote:
> On 1/14/20 3:29 PM, Nathan Sidwell wrote:
> > On 1/14/20 3:13 PM, Jason Merrill wrote:
> > > On 1/14/20 2:14 PM, Nathan Sidwell wrote:
> > > > +  if (tree ti = (TREE_CODE (fn) == TYPE_DECL &&
> > > > !TYPE_DECL_ALIAS_P (fn)
> > > > + ? TYPE_TEMPLATE_INFO (TREE_TYPE (fn))
> > > > + : DECL_TEMPLATE_INFO (fn)))
> > > 
> > > Is there a reason not to use get_template_info?
> > 
> > thanks for the pointer, I'll go do that.
> 
> Done.
> 
> nathan
> -- 
> Nathan Sidwell

> diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
> index c1375398517..59e0994c397 100644
> --- a/gcc/cp/ChangeLog
> +++ b/gcc/cp/ChangeLog
> @@ -1,5 +1,9 @@
>  2020-01-14  Nathan Sidwell  
>  
> + PT c++/90916

Note this has PT instead of PR :).

Marek

Re: [PATCH] libstdc++/91223 Improve unordered containers == operator

[François Dumont]

On 1/13/20 10:53 PM, Jonathan Wakely wrote:

On 13/01/20 22:41 +0100, François Dumont wrote:


For the multi-keys we could still avoid redundant comparisons when 
_Equal is just doing == on the key type. On unordered_multiset we 
could just avoids the call to is_permuation and on the 
unordered_multimap we could check the is_permutation only on the 
associated value rather than on the std::pair.



I don't think that's necessary, or helpful.

The idea of https://gcc.gnu.org/ml/libstdc++/2020-01/msg00070.html is
that you shouldn't be using _Equal at all, and therefore it doesn't
matter whether it's std::equal_to or not.



And it was indeed possible.

    PR libstdc++/91223
    * include/bits/hashtable.h (_Hashtable<>): Make _Equality<> friend.
    * include/bits/hashtable_policy.h: Include .
    (_Equality_base): Remove.
    (_Equality<>::_M_equal): Review implementation. Use 
std::is_permutation.

    * testsuite/23_containers/unordered_multiset/operators/1.cc
    (Hash, Equal, test02, test03): New.
    * testsuite/23_containers/unordered_set/operators/1.cc
    (Hash, Equal, test02, test03): New.

Tested under Linux x86_64.

Ok to commit ?

François

diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index 8fac385570b..9e721aad8cc 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -337,6 +337,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	   bool _Constant_iteratorsa>
 	friend struct __detail::_Insert;
 
+  template
+	friend struct __detail::_Equality;
+
 public:
   using size_type = typename __hashtable_base::size_type;
   using difference_type = typename __hashtable_base::difference_type;
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index 7bbfdfd375b..4024e6c37fa 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -34,6 +34,7 @@
 #include 		// for std::tuple, std::forward_as_tuple
 #include 		// for std::numeric_limits
 #include 	// for std::min.
+#include 	// for std::is_permutation.
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -1815,65 +1816,6 @@ namespace __detail
 _M_eq() const { return _EqualEBO::_M_cget(); }
   };
 
-  /**
-   *  struct _Equality_base.
-   *
-   *  Common types and functions for class _Equality.
-   */
-  struct _Equality_base
-  {
-  protected:
-template
-  static bool
-  _S_is_permutation(_Uiterator, _Uiterator, _Uiterator);
-  };
-
-  // See std::is_permutation in N3068.
-  template
-bool
-_Equality_base::
-_S_is_permutation(_Uiterator __first1, _Uiterator __last1,
-		  _Uiterator __first2)
-{
-  for (; __first1 != __last1; ++__first1, ++__first2)
-	if (!(*__first1 == *__first2))
-	  break;
-
-  if (__first1 == __last1)
-	return true;
-
-  _Uiterator __last2 = __first2;
-  std::advance(__last2, std::distance(__first1, __last1));
-
-  for (_Uiterator __it1 = __first1; __it1 != __last1; ++__it1)
-	{
-	  _Uiterator __tmp =  __first1;
-	  while (__tmp != __it1 && !bool(*__tmp == *__it1))
-	++__tmp;
-
-	  // We've seen this one before.
-	  if (__tmp != __it1)
-	continue;
-
-	  std::ptrdiff_t __n2 = 0;
-	  for (__tmp = __first2; __tmp != __last2; ++__tmp)
-	if (*__tmp == *__it1)
-	  ++__n2;
-
-	  if (!__n2)
-	return false;
-
-	  std::ptrdiff_t __n1 = 0;
-	  for (__tmp = __it1; __tmp != __last1; ++__tmp)
-	if (*__tmp == *__it1)
-	  ++__n1;
-
-	  if (__n1 != __n2)
-	return false;
-	}
-  return true;
-}
-
   /**
*  Primary class template  _Equality.
*
@@ -1889,7 +1831,7 @@ namespace __detail
 	   bool _Unique_keys = _Traits::__unique_keys::value>
 struct _Equality;
 
-  /// Specialization.
+  /// unordered_map and unordered_set specializations.
   template::
 _M_equal(const __hashtable& __other) const
 {
+  using __node_base = typename __hashtable::__node_base;
+  using __node_type = typename __hashtable::__node_type;
   const __hashtable* __this = static_cast(this);
-
   if (__this->size() != __other.size())
 	return false;
 
   for (auto __itx = __this->begin(); __itx != __this->end(); ++__itx)
 	{
-	  const auto __ity = __other.find(_ExtractKey()(*__itx));
-	  if (__ity == __other.end() || !bool(*__ity == *__itx))
+	  std::size_t __ybkt = __other._M_bucket_index(__itx._M_cur);
+	  __node_base* __prev_n = __other._M_buckets[__ybkt];
+	  if (!__prev_n)
 	return false;
+
+	  for (__node_type* __n = static_cast<__node_type*>(__prev_n->_M_nxt);;
+	   __n = __n->_M_next())
+	{
+	  if (__n->_M_v() == *__itx)
+		break;
+
+	  if (!__n->_M_nxt
+		  || __other._M_bucket_index(__n->_M_next()) != __ybkt)
+		return false;
+	}
 	}
+
   return true;
 }
 
-  /// Specialization.
+  /// unordered_multiset and unordered_multimap specializations.
   template
 struct _Equality<_Key, _Value, _Alloc, _ExtractKey, 

Re: [PATCH] Fix symver attribute with LTO

[Jan Hubicka]

> On Wed, 2019-12-18 at 10:26 +0100, Jan Hubicka wrote:
> > Hi,
> > sorry I forgot to include cgraph and varpool changes in the patch.
> > 
> > Index: varpool.c
> > ===
> > --- varpool.c   (revision 279467)
> > +++ varpool.c   (working copy)
> > @@ -539,8 +539,7 @@ varpool_node::assemble_aliases (void)
> >  {
> >varpool_node *alias = dyn_cast  (ref->referring);
> >if (alias->symver)
> > -   do_assemble_symver (alias->decl,
> > -   DECL_ASSEMBLER_NAME (decl));
> > +   do_assemble_symver (alias->decl, decl);
> >else if (!alias->transparent_alias)
> > do_assemble_alias (alias->decl,
> >DECL_ASSEMBLER_NAME (decl));
> [ ... ]
> Do you plan on committing these bits?

I think we got into agreement that gas extension is needed, since there
is name@@@nodename that does what we need for name@@nodename
but there is nothing that would do it for name@nodename.  I filled in
GAS PR for that.

Honza
> 
> jeff
> > 
> 

Re: [PATCH 1/3] Refactor copying decl section names

[Jeff Law]

On Tue, 2019-11-12 at 22:28 -0800, Strager Neds wrote:
> Sometimes, we need to copy a section name from one decl or symtab node
> to another. Currently, this is done by getting the source's section
> name and setting the destination's section name. For example:
> 
> set_decl_section_name (dest, DECL_SECTION_NAME (source));
> dest->set_section (source->get_section ());
> 
> This code could be more efficient. Section names are stored in an
> interning hash table, but the current interfaces of
> set_decl_section_name and symtab_node::set_section force unnecessary
> indirections (to get the section name) and hashing (to find the section
> name in the hash table).
> 
> Overload set_decl_section_name and symtab_node::set_section to accept an
> existing symtab_node to copy the section name from:
> 
> set_decl_section_name (dest, source);
> dest->set_section (*source);
> 
> For now, implement these new functions as a simple wrapper around the
> existing functions. In the future, these functions can be implemented
> using just a pointer copy and an increment (for the reference count).
> 
> This patch should not change behavior.
> 
> Testing: Bootstrap on x86_64-linux-gnu with --disable-multilib
> --enable-checking=release --enable-languages=c,c++. Observe no change in
> test results.
> 
> 2019-11-12  Matthew Glazar 
> 
> * gcc/cgraph.h (symtab_node::get_section): Constify.
> (symtab_node::set_section): Declare new overload.
> * gcc/symtab.c (symtab_node::set_section): Define new overload.
> (symtab_node::copy_visibility_from): Use new overload of
> symtab_node::set_section.
> (symtab_node::resolve_alias): Same.
> * gcc/tree.h (set_decl_section_name): Declare new overload.
> * gcc/tree.c (set_decl_section_name): Define new overload.
> * gcc/c/c-decl.c (merge_decls): Use new overload of
> set_decl_section_name.
> * gcc/cp/decl.c (duplicate_decls): Same.
> * gcc/cp/method.c (use_thunk): Same.
> * gcc/cp/optimize.c (maybe_clone_body): Same.
> * gcc/d/decl.cc (finish_thunk): Same.
> * gcc/tree-emutls.c (get_emutls_init_templ_addr): Same.
> * gcc/cgraphclones.c (cgraph_node::create_virtual_clone): Use new
> overload of symtab_node::set_section.
> (cgraph_node::create_version_clone_with_body): Same.
> * gcc/trans-mem.c (ipa_tm_create_version): Same.
[ ... ]
I know these were sent when we were still in stage1, but they fell
through the cracks.  I'm deferring the kit until gcc-11 stage1.

jeff
> 

Re: [PATCH] libiberty, include: add bsearch_r

[Jeff Law]

On Fri, 2020-01-10 at 15:55 +, Nick Alcock wrote:
> libctf wants a bsearch that takes a void * arg pointer to avoid a
> nonportable use of __thread.
> 
> bsearch_r is required, not optional, at this point because as far as I
> can see this obvious-sounding function is not implemented by anyone's
> libc.  We can easily move it to AC_LIBOBJ later if it proves necessary
> to do so.
> 
> include/
>   * libiberty.h (bsearch_r): New.
> libiberty/
>   * bsearch_r.c: New file.
>   * Makefile.in (CFILES): Add bsearch_r.c.
>   (REQUIRED_OFILES): Add bsearch_r.o.
>   * functions.texi: Regenerate.
OK.  Note if the goal is to get this into binutils to support CTF, let
Nick Clifton know he needs to merge the libiberty bits before the next
binutils release.

Jeff

Fix for LTO compromised autoconf test in libiberty

[Jeff Law]

GCC's ability to inline/clone self-recursive calls compromises the
find_stack_direction test in libiberty's configure.

The test essentially takes the address of a local in an outer and inner
context then compares their addresses to determine the direction of
stack growth.

Inlining causes the locals to be allocated in the same context which
totally defeats the purpose of the test.

This patch adds attributes to prevent inlining/cloning and rebuilds the
affected configure file.

Note there are configure files in other directories, but I'm pretty
sure they're using the cached value from libiberty and to fix them
requires an upstream fix to autoconf since those defintions don't come
from libiberty's aclocal.m4.

I'm particularly keen to get this in now as GCC is the master for
libiberty and Nick will be cutting a binutils release soon (and has
agreed to pull in this change already).  Getting the fix into binutils
now means the various copies in Fedora won't have to be patched
individually (mingw-binutils, avr-binutils, cross-binutils, arm-
whatever-binutils, nacl-binutils and possibly others).


You can see the effect by looking at how STACK_DIRECTION is defined in
config.h.  On x86 it should be "-1" and it is for the stage1 build if
you use an old enough compiler ;-)  But for stage2/stage3 it's "1"

Bootstrapped and regression tested on x86_64.  Verified STACK_DIRECTION
is correct via hand inspection.

OK for the trunk?
diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
index bf8a907100f..381ed3b27e3 100644
--- a/libiberty/aclocal.m4
+++ b/libiberty/aclocal.m4
@@ -147,7 +147,7 @@ if test $ac_cv_os_cray = yes; then
 fi
 
 AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction,
-[AC_TRY_RUN([find_stack_direction ()
+[AC_TRY_RUN([__attribute__ ((noclone,noinline)) find_stack_direction ()
 {
   static char *addr = 0;
   auto char dummy;
diff --git a/libiberty/configure b/libiberty/configure
index 7a34dabec32..e8391889cd7 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -6532,7 +6532,7 @@ else
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-find_stack_direction ()
+__attribute__ ((noclone,noinline)) find_stack_direction ()
 {
   static char *addr = 0;
   auto char dummy;

Re: Fix for LTO compromised autoconf test in libiberty

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 03:02:01PM -0700, Jeff Law wrote:
> Bootstrapped and regression tested on x86_64.  Verified STACK_DIRECTION
> is correct via hand inspection.
> 
> OK for the trunk?

Wouldn't that fail due to warnings if compiled e.g. by gcc that doesn't
support noclone attribute?
Can't we e.g. instead do
  int (*volatile fn) ();
  fn = find_stack_direction;
  return fn ();
instead of
  return find_stack_direction ();
when performing the recursive call?
Though, at least current trunk emits tons of warnings on it already, so
maybe it must ignore warnings already.

> diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
> index bf8a907100f..381ed3b27e3 100644
> --- a/libiberty/aclocal.m4
> +++ b/libiberty/aclocal.m4
> @@ -147,7 +147,7 @@ if test $ac_cv_os_cray = yes; then
>  fi
>  
>  AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction,
> -[AC_TRY_RUN([find_stack_direction ()
> +[AC_TRY_RUN([__attribute__ ((noclone,noinline)) find_stack_direction ()
>  {
>static char *addr = 0;
>auto char dummy;
> diff --git a/libiberty/configure b/libiberty/configure
> index 7a34dabec32..e8391889cd7 100755
> --- a/libiberty/configure
> +++ b/libiberty/configure
> @@ -6532,7 +6532,7 @@ else
>  else
>cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> -find_stack_direction ()
> +__attribute__ ((noclone,noinline)) find_stack_direction ()
>  {
>static char *addr = 0;
>auto char dummy;


Jakub

Re: Fix for LTO compromised autoconf test in libiberty

[Andreas Schwab]

On Jan 14 2020, Jeff Law wrote:

> diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
> index bf8a907100f..381ed3b27e3 100644
> --- a/libiberty/aclocal.m4
> +++ b/libiberty/aclocal.m4
> @@ -147,7 +147,7 @@ if test $ac_cv_os_cray = yes; then
>  fi
>  
>  AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction,
> -[AC_TRY_RUN([find_stack_direction ()
> +[AC_TRY_RUN([__attribute__ ((noclone,noinline)) find_stack_direction ()

That makes the test GCC specific, which doesn't actually need the test
in the first place.  That looks pointless.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[wwwdocs] Link to git.html instead of svn.html and use a neutral link text.

[Gerald Pfeifer]

...for all our (past) release pages.

Pushed.

Gerald

- Log -
commit d248ad22e9e02664ac4567a24af7a83c6f12aad7
Author: Gerald Pfeifer 
Date:   Tue Jan 14 23:40:48 2020 +0100

Link to git.html instead of svn.html and use a neutral link text.

diff --git a/htdocs/gcc-3.4/index.html b/htdocs/gcc-3.4/index.html
index 35e78e8b..01f6822f 100644
--- a/htdocs/gcc-3.4/index.html
+++ b/htdocs/gcc-3.4/index.html
@@ -88,7 +88,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites,
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.0/index.html b/htdocs/gcc-4.0/index.html
index c0de4ef8..d5e47283 100644
--- a/htdocs/gcc-4.0/index.html
+++ b/htdocs/gcc-4.0/index.html
@@ -72,7 +72,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites,
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.1/index.html b/htdocs/gcc-4.1/index.html
index 1a8d4a75..5d0b07df 100644
--- a/htdocs/gcc-4.1/index.html
+++ b/htdocs/gcc-4.1/index.html
@@ -62,7 +62,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.2/index.html b/htdocs/gcc-4.2/index.html
index 9a8ea413..7065d3b5 100644
--- a/htdocs/gcc-4.2/index.html
+++ b/htdocs/gcc-4.2/index.html
@@ -74,7 +74,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.3/index.html b/htdocs/gcc-4.3/index.html
index 14fb2b7c..943064ec 100644
--- a/htdocs/gcc-4.3/index.html
+++ b/htdocs/gcc-4.3/index.html
@@ -84,7 +84,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.4/index.html b/htdocs/gcc-4.4/index.html
index 0f9df197..1424a347 100644
--- a/htdocs/gcc-4.4/index.html
+++ b/htdocs/gcc-4.4/index.html
@@ -89,7 +89,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.5/index.html b/htdocs/gcc-4.5/index.html
index e41b552f..76e48248 100644
--- a/htdocs/gcc-4.5/index.html
+++ b/htdocs/gcc-4.5/index.html
@@ -70,7 +70,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.6/index.html b/htdocs/gcc-4.6/index.html
index 0b70fd0f..9c157914 100644
--- a/htdocs/gcc-4.6/index.html
+++ b/htdocs/gcc-4.6/index.html
@@ -79,7 +79,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.7/index.html b/htdocs/gcc-4.7/index.html
index a7468742..312fea7f 100644
--- a/htdocs/gcc-4.7/index.html
+++ b/htdocs/gcc-4.7/index.html
@@ -79,7 +79,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.8/index.html b/htdocs/gcc-4.8/index.html
index fda45402..234dce6e 100644
--- a/htdocs/gcc-4.8/index.html
+++ b/htdocs/gcc-4.8/index.html
@@ -85,7 +85,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-4.9/index.html b/htdocs/gcc-4.9/index.html
index b6a7e14e..8dee3afd 100644
--- a/htdocs/gcc-4.9/index.html
+++ b/htdocs/gcc-4.9/index.html
@@ -79,7 +79,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
diff --git a/htdocs/gcc-5/index.html b/htdocs/gcc-5/index.html
index f2ba9772..153a7be6 100644
--- a/htdocs/gcc-5/index.html
+++ b/htdocs/gcc-5/index.html
@@ -79,7 +79,7 @@ group of volunteers is what makes GCC successful.
 mailto:g...@gcc.gnu.org";>GCC development mailing list.
 
 To obtain GCC please use our mirror sites
-or our SVN server.
+or our version control system.
 
 
 
dif

Re: Fix for LTO compromised autoconf test in libiberty

[Jeff Law]

On Tue, 2020-01-14 at 23:21 +0100, Andreas Schwab wrote:
> On Jan 14 2020, Jeff Law wrote:
> 
> > diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
> > index bf8a907100f..381ed3b27e3 100644
> > --- a/libiberty/aclocal.m4
> > +++ b/libiberty/aclocal.m4
> > @@ -147,7 +147,7 @@ if test $ac_cv_os_cray = yes; then
> >  fi
> >  
> >  AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction,
> > -[AC_TRY_RUN([find_stack_direction ()
> > +[AC_TRY_RUN([__attribute__ ((noclone,noinline)) find_stack_direction ()
> 
> That makes the test GCC specific, which doesn't actually need the test
> in the first place.  That looks pointless.
It's used by alloca.c to implement a C based alloca.  It needs to know
what direction stacks grow so that it knows if it's at a higher point
in the call chain and thus should collect objects allocated at deeper
points in the call chain.

Jakub has a good point though.  THe attributes probably need to be
conditional on GCC and the specific version of GCC being used.

jeff

[wwwdocs] Remove link to the Git mirror entry in our Wiki from navigation bar.

[Gerald Pfeifer]

Pushed.

Gerald

- Log -
commit 3af4155933a9d3b8506b56c16865879b098ab4cf
Author: Gerald Pfeifer 
Date:   Tue Jan 14 23:52:28 2020 +0100

Remove link to the Git mirror entry in our Wiki from navigation bar.

diff --git a/htdocs/style.mhtml b/htdocs/style.mhtml
index c48a3a74..0026d6c4 100644
--- a/htdocs/style.mhtml
+++ b/htdocs/style.mhtml
@@ -111,7 +111,6 @@
   
   SVN read access
   SVN write access
-  https://gcc.gnu.org/wiki/GitMirror";>Git read access
   Rsync
   
   

Re: Fix for LTO compromised autoconf test in libiberty

[Jeff Law]

On Tue, 2020-01-14 at 23:09 +0100, Jakub Jelinek wrote:
> On Tue, Jan 14, 2020 at 03:02:01PM -0700, Jeff Law wrote:
> > Bootstrapped and regression tested on x86_64.  Verified STACK_DIRECTION
> > is correct via hand inspection.
> > 
> > OK for the trunk?
> 
> Wouldn't that fail due to warnings if compiled e.g. by gcc that doesn't
> support noclone attribute?
> Can't we e.g. instead do
>   int (*volatile fn) ();
>   fn = find_stack_direction;
>   return fn ();
> instead of
>   return find_stack_direction ();
> when performing the recursive call?
> Though, at least current trunk emits tons of warnings on it already, so
> maybe it must ignore warnings already.
I think the safe thing to do is make it conditional on GCC and the
versions that support noclone, noinline.

jeff
> 

Re: [PATCH] contrib: git descr/undescr aliases

[Joseph Myers]

On Tue, 14 Jan 2020, Roman Zhuykov wrote:

> PS. We at ISPRAS see that for ~28 hours (11 Jan 2020, 18:00 UTC - 12 Jan 2020,
> 22:00 UTC) our servers haven't received any gcc mailing list letters, but they
> are available at https://gcc.gnu.org/ml/ archives (totally 6 mails on gcc@ and
> 16 on gcc-patches@ were lost).  Looking also at obviously
> corruptedhttps://gcc.gnu.org/ml/gcc-patches/2020-01/msg00674.html  it is
> reasonable to assume that it was some worldwide issue because of high "git
> clone" server load, and I wonder not to see any discussion here.

Sourceware was on the CBL  at that time until I 
noticed (via email delays, since my mail server uses some DNSBLs as a 
basis for greylisting) and removed it.  I don't know why it got listed but 
have no reason to think it related to the high load on the system.  
Probably your mail server uses the CBL, or another DNSBL containing it, as 
a basis for rejecting email.

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

Re: Fix for LTO compromised autoconf test in libiberty

[Joseph Myers]

My preference is still what I said in 
: either 
eliminate C alloca from libiberty, or don't build it with any compiler 
defining __GNUC__.  I'd be surprised if there are host compilers that 
build libiberty, have the relevant optimizations but don't support alloca.

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

Correct git config command syntax

[Joseph Myers]

There is no --set option, git config sets variables without such an
option.

Committed.

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 85a0da2d..f420fe22 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -78,7 +78,7 @@ git clone git+ssh://username@gcc.gnu.org/git/gcc.git 
gcc
 using git config:
 
 
-git config --set remote.origin.url 
git+ssh://username@gcc.gnu.org/git/gcc.git
+git config remote.origin.url git+ssh://username@gcc.gnu.org/git/gcc.git
 
 
 To avoid the nuisance of having to supply your passphrase for each

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

[committed] Remove bogus initial lines from test.

[Jakub Jelinek]

Hi!

I've noticed
FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O0 -flto 
-flto-partition=none -fuse-linker-plugin
FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O2 -flto 
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O0 -flto 
-flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O2 -flto 
-flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O0 -flto -fuse-linker-plugin 
-fno-fat-lto-objects 
FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O2 -flto -fuse-linker-plugin
on both x86_64-linux and i686-linux, dunno how those lines made it into the
test.  Anyway, fixed thusly, tested on x86_64-linux, test passes now,
committed to trunk as obvious.

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index ea37d69fa88..8e99328feb2 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,13 +1,16 @@
 2020-01-15  Jakub Jelinek  
 
+   PR lto/91576
+   * g++.dg/lto/odr-8_1.C: Remove bogus initial lines.
+
PR target/93009
* gcc.target/i386/avx512vl-pr93009.c: New test.
 
 2020-01-14  Jan Hubicka  
 
PR lto/91576
-   * testsuite/g++.dg/lto/odr-8_0.C: New testcase.
-   * testsuite/g++.dg/lto/odr-8_1.C: New testcase.
+   * g++.dg/lto/odr-8_0.C: New testcase.
+   * g++.dg/lto/odr-8_1.C: New testcase.
 
 2020-01-14  David Malcolm  
 
diff --git a/gcc/testsuite/g++.dg/lto/odr-8_1.C 
b/gcc/testsuite/g++.dg/lto/odr-8_1.C
index 742df8cc906..cbcd15d76ad 100644
--- a/gcc/testsuite/g++.dg/lto/odr-8_1.C
+++ b/gcc/testsuite/g++.dg/lto/odr-8_1.C
@@ -1,6 +1,3 @@
 a/gcc/testsuite/g++.dg/lto/odr-8_1.C
-+++ b/gcc/testsuite/g++.dg/lto/odr-8_1.C
-@@ -1,9 +1,9 @@
 struct a {char c; a() {} a(struct a &) {}}; // { dg-lto-message "one type 
needs to be constructed while other not" }
 extern int test (struct a *a);
 int

Jakub

Re: Fix for LTO compromised autoconf test in libiberty

[Jeff Law]

On Tue, 2020-01-14 at 23:33 +, Joseph Myers wrote:
> My preference is still what I said in 
> ;: either 
> eliminate C alloca from libiberty, or don't build it with any compiler 
> defining __GNUC__.  I'd be surprised if there are host compilers that 
> build libiberty, have the relevant optimizations but don't support alloca.
I wasn't even aware that c-alloca came up in that thread!  I'd been
leaving all the sanitizer related stuff to others.

I'd certainly support dropping c-alloca support from libiberty.   I
totally agree that it's only purpose was to support ancient compilers. 
I don't think I've seen c-alloca being used since the late 90s and I
think we started dropping all the alloca (0) that existed solely to
support c-alloca eons ago.

jeff

[PATCH] contrib: git descr/undescr aliases fix for older git

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 10:12:09AM +0100, Jakub Jelinek wrote:
> Note, for the scripts running on sourceware I also had to remove those tags/
> part, but thought it is because of running against the bare repo.
> We could change those into ^\\(tags/\\)\\?basepoints/gcc- etc. (and adjust
> the \\1.
> I'll post a patch.

Here it is, tested on x86_64-linux, ok for trunk?

2020-01-15  Jakub Jelinek  

* gcc-git-customization.sh: Handle output of older git which doesn't
print tags/ prefixes before branchpoint/gcc-.

--- contrib/gcc-git-customization.sh.jj 2020-01-13 15:15:00.472393417 +0100
+++ contrib/gcc-git-customization.sh2020-01-14 15:09:33.364634082 +0100
@@ -22,8 +22,8 @@ git config alias.svn-rev '!f() { rev=$1;
 
 # Add git commands to convert git commit to monotonically increasing revision 
number
 # and vice versa
-git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then r=\$(git 
describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed 
-n 's,^tags/basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$' 
>/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); test -n \$r && echo 
\${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} | 
sed -n 
's,^tags/basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\1-\\2,p;s,^tags/basepoints/gcc-\\([0-9]\\+\\)\$,r\\1-0,p';
 fi; }; f"
-git config alias.gcc-undescr \!"f() { o=\$(git config --get 
gcc-config.upstream); r=\$(echo \$1 | sed -n 
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 
's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && 
exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r); 
test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master); 
p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n 
's,^tags/basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\1,p;s,^tags/basepoints/gcc-[0-9]\\+\$,0,p');
 git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
+git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then r=\$(git 
describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed 
-n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$' 
>/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); test -n \$r && echo 
\${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} | 
sed -n 
's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p';
 fi; }; f"
+git config alias.gcc-undescr \!"f() { o=\$(git config --get 
gcc-config.upstream); r=\$(echo \$1 | sed -n 
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 
's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && 
exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r); 
test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master); 
p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n 
's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p');
 git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
 
 # Make diff on MD files uses "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing


Jakub

Give example of error message when pushing to a branch with other changes

[Joseph Myers]

Giving explicit example of git messages seems helpful for novice users
to understand when they are in a particular situation for which
instructions are given.

Committed.

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index f420fe22..e55cfa92 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -279,7 +279,19 @@ A message will be sent to the gcc-cvs mailing list 
indicating that a
 change was made.  If git push gives an error because
 someone else has pushed their own changes to the same branch,
 do git pull --rebase before trying git push
-again.
+again.  A typical error in this situation looks like:
+
+
+To git+ssh://gcc.gnu.org/git/gcc.git
+ ! [rejected]master -> master (fetch first)
+error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'
+hint: Updates were rejected because the remote contains work that you do
+hint: not have locally. This is usually caused by another repository pushing
+hint: to the same ref. You may want to first integrate the remote changes
+hint: (e.g., 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+
 
 
 

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

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

[Vineet Gupta]

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

Remove warning at top of git web pages

[Joseph Myers]

Although the documentation is still a work in progress, with various
forms of git usage (e.g. contrib/gcc-git-customization.sh) not yet
documented and development branches not yet listed on git.html as they
are on svn.html, the warning about the conversion still being in
progress is no longer accurate, so remove it.

Committed.

diff --git a/htdocs/git.html b/htdocs/git.html
index 0a8294e1..70cc7b73 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -16,10 +16,6 @@
 
 GCC: Anonymous read-only Git access
 
-The conversion from SVN to Git is in progress.  The
-repository described here may not yet be the final version of that
-conversion.
-
 Our Git source repository is available read-only to the public at
 large.  That way you can pick up any version (including releases) of
 GCC that is in our repository.
diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index e55cfa92..3cda6a46 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -10,10 +10,6 @@
 
 Read-write Git access
 
-The conversion from SVN to Git is in progress.  The
-repository described here may not yet be the final version of that
-conversion.
-
 We have read/write access to the Git repository available for
 maintainers and significant developers.
 

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

Re: [PATCH] PR 92846: [ARC] generate signaling FDCMPF for hard float comparisons

[Vineet Gupta]

On 12/9/19 11:02 AM, Vineet Gupta wrote:
> ARC gcc generates FDCMP instructions which raises Invalid operation for
> signaling NaN only. This causes glibc iseqsig() primitives to fail (in
> the current ongoing glibc port to ARC)
>
> So split up the hard float compares into two categories and for unordered
> compares generate the FDCMPF instruction (vs. FDCMP) which raises exception
> for either NaNs.
>
> With this fix testsuite/gcc.dg/torture/pr52451.c passes for ARC.
>
> Also passes 6 additional tests in glibc testsuite (test*iseqsig) and no
> regressions

Can this be backported to gcc-9 please ?
glibc testing uses gcc-9

Thx,
-Vineet

[PATCH] tree-optimization: Fix tree dse of strncpy PR93249

[Jakub Jelinek]

Hi!

As the testcase shows, tail trimming of strncpy in tree-ssa-dse.c is fine,
we just copy or clear fewer bytes in the destination, but unlike
memcpy/memset etc., head trimming is problematic in certain cases.
If we can prove that there are no zero bytes among initial head_trim bytes,
it is ok to trim it, if we can prove there is at least one zero byte among
initial head_trim bytes, we could (not implemented in the patch) turn
the strncpy into memset 0, but otherwise we need to avoid the head trimming,
because the presence or absence of NUL byte there changes the behavior for
subsequent bytes, whether further bytes from src are copied or if further
bytes are cleared.

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

2020-01-15  Jakub Jelinek  

PR tree-optimization/93249
* tree-ssa-dse.c: Include builtins.h and gimple-fold.h.
(maybe_trim_memstar_call): Move head_trim and tail_trim vars to
function body scope, reindent.  For BUILTIN_IN_STRNCPY*, don't
perform head trim unless we can prove there are no '\0' chars
from the source among the first head_trim chars.

* gcc.c-torture/execute/pr93249.c: New test.

--- gcc/tree-ssa-dse.c.jj   2020-01-12 11:54:38.503381877 +0100
+++ gcc/tree-ssa-dse.c  2020-01-14 12:13:39.900589819 +0100
@@ -36,6 +36,8 @@ along with GCC; see the file COPYING3.
 #include "alias.h"
 #include "tree-ssa-loop.h"
 #include "tree-ssa-dse.h"
+#include "builtins.h"
+#include "gimple-fold.h"
 
 /* This file implements dead store elimination.
 
@@ -456,56 +458,83 @@ increment_start_addr (gimple *stmt, tree
 static void
 maybe_trim_memstar_call (ao_ref *ref, sbitmap live, gimple *stmt)
 {
+  int head_trim, tail_trim;
   switch (DECL_FUNCTION_CODE (gimple_call_fndecl (stmt)))
 {
+case BUILT_IN_STRNCPY:
+case BUILT_IN_STRNCPY_CHK:
+  compute_trims (ref, live, &head_trim, &tail_trim, stmt);
+  if (head_trim)
+   {
+ /* Head trimming of strncpy is only possible if we can
+prove all bytes we would trim are non-zero (or we could
+turn the strncpy into memset if there must be zero
+among the head trimmed bytes).  If we don't know anything
+about those bytes, the presence or absence of '\0' bytes
+in there will affect whether it acts for the non-trimmed
+bytes as memset or memcpy/strncpy.  */
+ c_strlen_data lendata = { };
+ int orig_head_trim = head_trim;
+ tree srcstr = gimple_call_arg (stmt, 1);
+ if (!get_range_strlen (srcstr, &lendata, /*eltsize=*/1)
+ || !tree_fits_uhwi_p (lendata.minlen))
+   head_trim = 0;
+ else if (tree_to_uhwi (lendata.minlen) < (unsigned) head_trim)
+   {
+ head_trim = tree_to_uhwi (lendata.minlen);
+ if ((orig_head_trim & (UNITS_PER_WORD - 1)) == 0)
+   head_trim &= ~(UNITS_PER_WORD - 1);
+   }
+ if (orig_head_trim != head_trim
+ && dump_file
+ && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file,
+"  Adjusting strncpy trimming to (head = %d,"
+" tail = %d)\n", head_trim, tail_trim);
+   }
+  goto do_memcpy;
+
 case BUILT_IN_MEMCPY:
 case BUILT_IN_MEMMOVE:
-case BUILT_IN_STRNCPY:
 case BUILT_IN_MEMCPY_CHK:
 case BUILT_IN_MEMMOVE_CHK:
-case BUILT_IN_STRNCPY_CHK:
-  {
-   int head_trim, tail_trim;
-   compute_trims (ref, live, &head_trim, &tail_trim, stmt);
-
-   /* Tail trimming is easy, we can just reduce the count.  */
-if (tail_trim)
- decrement_count (stmt, tail_trim);
-
-   /* Head trimming requires adjusting all the arguments.  */
-if (head_trim)
-  {
-   tree *dst = gimple_call_arg_ptr (stmt, 0);
-   increment_start_addr (stmt, dst, head_trim);
-   tree *src = gimple_call_arg_ptr (stmt, 1);
-   increment_start_addr (stmt, src, head_trim);
-   decrement_count (stmt, head_trim);
- }
-break;
-  }
+  compute_trims (ref, live, &head_trim, &tail_trim, stmt);
+
+do_memcpy:
+  /* Tail trimming is easy, we can just reduce the count.  */
+  if (tail_trim)
+   decrement_count (stmt, tail_trim);
+
+  /* Head trimming requires adjusting all the arguments.  */
+  if (head_trim)
+   {
+ tree *dst = gimple_call_arg_ptr (stmt, 0);
+ increment_start_addr (stmt, dst, head_trim);
+ tree *src = gimple_call_arg_ptr (stmt, 1);
+ increment_start_addr (stmt, src, head_trim);
+ decrement_count (stmt, head_trim);
+   }
+  break;
 
 case BUILT_IN_MEMSET:
 case BUILT_IN_MEMSET_CHK:
-  {
-   int head_trim, tail_trim;
-   compute_trims (ref, live, &head_trim, &tail_trim, stmt);
-
-   /* Tail trimming is easy, we can just reduce the count.  */
-if (tail_trim)
- 

Say more about conflict messages on git pull

[Joseph Myers]

Give an example of the message you get for such a conflict, and
discuss options for keeping local changes when pulling.

Committed.

diff --git a/htdocs/git.html b/htdocs/git.html
index 70cc7b73..725bd81c 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -95,13 +95,30 @@ is: Autoconf, Bison, Xgettext, Automake, and Gperf.
 
 It is not uncommon to get Git conflict messages for some generated files
 when updating your local sources from the Git repository.  Typically such
-conflicts occur with autoconf generated files.
+conflicts occur with autoconf generated files.  Such an error is of
+the form:
+
+
+error: Your local changes to the following files would be overwritten by merge:
+gcc/configure
+Please commit your changes or stash them before you merge.
+Aborting
+
 
 As long as you haven't been making modifications to the generated files
 or the generator files, it is safe to revert the local differences
 using git checkout on the affected files, then run
 git pull again.
 
+If you have changes you want to keep that result in such an error,
+there are a few options.  You can keep those changes on a local branch
+rather than on a branch tracking upstream sources.  If you wish to
+keep those changes uncommitted, do git stash
+before git pull and git stash pop
+after git pull.  If you commit them directly to your
+local upstream-tracking branch, you may prefer to use git pull
+--rebase instead of plain git pull.
+
 
 Branches and Tags
 

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

[PATCH] tree-optimization: Fix tree dse of __*_chk PR93262

[Jakub Jelinek]

Hi!

The following testcase shows that GCC trunk mishandles DSE of __*_chk
calls.  Tail trimming of the calls is fine, we want to just decrease the
third argument and keep the first two and last arguments unmodified.
But for head trimming, we currently increment the two by head_trim and
decrease the third by head_trim, so
  __builtin___memcpy_chk (&a, b_2(D), 48, 32);
  __builtin_memset (&a, 32, 16);
into:
  _5 = b_2(D) + 16;
  __builtin___memcpy_chk (&MEM  [(void *)&a + 16B], _5, 32, 32);
  __builtin_memset (&a, 32, 16);
This is wrong, because the 32 was the determined (maximum) size of the
destination (char a[32]), but &a[16] has maximum size of 16, not 32.
The __builtin___memcpy_chk (&MEM  [(void *)&a + 16B], _5, 32, 32);
call is just folded later into
__builtin_memcpy (&MEM  [(void *)&a + 16B], _5, 32);
because it says that it copies as many bytes into destination as the
destination has.  We need:
  __builtin___memcpy_chk (&MEM  [(void *)&a + 16B], _5, 32, 16);
instead, which will terminate the program instead of letting it silently
overflow the buffer.
The patch just punts if we'd need to decrease the last argument below 0.

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

Fortunately, release branches are unaffected.
P.S. it was quite hard to make the runtime test working, in builtins.exp
neither dg-options nor dg-additional-options work and builtins.exp adds
-fno-tree-dse among several other -fno-* options.  Fortunately optimize
attribute works.

2020-01-15  Jakub Jelinek  

PR tree-optimization/93262
* tree-ssa-dse.c (maybe_trim_memstar_call): For *_chk builtins,
perform head trimming only if the last argument is constant,
either all ones, or larger or equal to head trim, in the latter
case decrease the last argument by head_trim.

* gcc.c-torture/execute/builtins/pr93262-chk.c: New test.
* gcc.c-torture/execute/builtins/pr93262-chk-lib.c: New file.
* gcc.c-torture/execute/builtins/pr93262-chk.x: New file.

--- gcc/tree-ssa-dse.c.jj   2020-01-14 12:13:39.900589819 +0100
+++ gcc/tree-ssa-dse.c  2020-01-14 14:53:09.454382797 +0100
@@ -508,6 +508,22 @@ maybe_trim_memstar_call (ao_ref *ref, sb
   /* Head trimming requires adjusting all the arguments.  */
   if (head_trim)
{
+ /* For __*_chk need to adjust also the last argument.  */
+ if (gimple_call_num_args (stmt) == 4)
+   {
+ tree size = gimple_call_arg (stmt, 3);
+ if (!tree_fits_uhwi_p (size))
+   break;
+ if (!integer_all_onesp (size))
+   {
+ unsigned HOST_WIDE_INT sz = tree_to_uhwi (size);
+ if (sz < (unsigned) head_trim)
+   break;
+ tree arg = wide_int_to_tree (TREE_TYPE (size),
+  sz - head_trim);
+ gimple_call_set_arg (stmt, 3, arg);
+   }
+   }
  tree *dst = gimple_call_arg_ptr (stmt, 0);
  increment_start_addr (stmt, dst, head_trim);
  tree *src = gimple_call_arg_ptr (stmt, 1);
@@ -527,6 +543,22 @@ maybe_trim_memstar_call (ao_ref *ref, sb
   /* Head trimming requires adjusting all the arguments.  */
   if (head_trim)
{
+ /* For __*_chk need to adjust also the last argument.  */
+ if (gimple_call_num_args (stmt) == 4)
+   {
+ tree size = gimple_call_arg (stmt, 3);
+ if (!tree_fits_uhwi_p (size))
+   break;
+ if (!integer_all_onesp (size))
+   {
+ unsigned HOST_WIDE_INT sz = tree_to_uhwi (size);
+ if (sz < (unsigned) head_trim)
+   break;
+ tree arg = wide_int_to_tree (TREE_TYPE (size),
+  sz - head_trim);
+ gimple_call_set_arg (stmt, 3, arg);
+   }
+   }
  tree *dst = gimple_call_arg_ptr (stmt, 0);
  increment_start_addr (stmt, dst, head_trim);
  decrement_count (stmt, head_trim);
--- gcc/testsuite/gcc.c-torture/execute/builtins/pr93262-chk.c.jj   
2020-01-14 14:14:35.976011862 +0100
+++ gcc/testsuite/gcc.c-torture/execute/builtins/pr93262-chk.c  2020-01-14 
14:52:42.636785091 +0100
@@ -0,0 +1,55 @@
+/* PR tree-optimization/93262 */
+
+extern void abort (void);
+typedef __SIZE_TYPE__ size_t;
+extern void *memcpy (void *, const void *, size_t);
+extern void *memset (void *, int, size_t);
+
+#include "chk.h"
+
+char b[32] = "def";
+char a[32] = "abc";
+char c[32] = "ghi";
+int l1;
+
+__attribute__((noipa, noinline, noclone, optimize ("tree-dse"))) void
+foo (char *b)
+{
+  memcpy (a, b, 48);
+  memset (a, ' ', 16);
+}
+
+__attribute__((noipa, noinline, noclone, optimize ("tree-dse"))) void
+bar (void)
+{
+  memset (a, ' ', 48);
+  memset (a, '0', 16);
+}
+
+void
+main_test (void)
+{
+#ifndef __OPTIMIZE__
+  /* Object size c

Ping: [PATCH] Ensure colorization doesn't corrupt multibyte sequences in diagnostics

[Lewis Hyatt]

Hello-

I thought I might ping this short patch please, just in case it may
make sense to include in GCC 10 along with the other UTF-8-related
fixes to diagnostics. Thanks!

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00915.html

-Lewis

On Thu, Dec 12, 2019 at 6:21 PM Lewis Hyatt  wrote:
>
> Hello-
>
> In the original discussion of implementing UTF-8 identifiers
> ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c26 ), I pointed out
> that colorization would corrupt the appearance of certain diagnostics. For
> example, this code, with -std=c99:
>
> --
> int ٩x;
> --
>
> Produces:
>
> t2.cpp:1:5: error: extended character ٩ is not valid at the start of an 
> identifier
> 1 | int ٩x;
>   | ^
>
> The diagnostic location contains only the first byte of the character, so
> when colorization is enabled, the ANSI escapes are inserted in the middle
> of the UTF-8 sequence and produce corrupted output on the terminal.
>
> I feel like there are two separate issues here:
>
> #1. diagnostic_show_locus() should be sure it will not corrupt output in
> this way, regardless of what ranges it is given to work with.
>
> #2. libcpp should probably generate a range that includes the whole UTF-8
> character. Actually in other ways the range seems not ideal, for example
> if an invalid character appears in the middle of the identifier, the
> diagnostic still points to the first byte of the identifier.
>
> The attached patch fixes #1. It's essentially a one-line change, plus a
> new selftest. Would you please have a look at it sometime? bootstrap
> and testsuite were done on linux x86-64.
>
> Other questions that I have:
>
> - I am not quite clear when a selftest is preferred vs a dejagnu test. In
>   this case I stuck with the selftest because color diagnostics don't seem
>   to work well with dg-error etc, and it didn't seem worth creating a new
>   plugin-based test like g++.dg/plugin just for this. (I also considered
>   using the existing g++.dg plugin, but it seems this test should run for
>   gcc as well.)
>
> - I wasn't sure if I should create a PR for an issue such as this, if
>   there is already a patch readily available. And if I did create a PR,
>   not sure if it's preferred to post the patch to gcc-patches, or as an
>   attachment to the PR.
>
> - Does it seem worth me looking into #2? I think the patch to address #1 is
>   appropriate in any case, because it handles generically all potential
>   cases where this may arise, but still perhaps the ranges coming out of
>   libcpp could be improved?
>
> Thanks...
>
> -Lewis

Re: [PATCH] PR 92846: [ARC] generate signaling FDCMPF for hard float comparisons

[Vineet Gupta]

On 1/14/20 3:49 PM, Vineet Gupta wrote:
> On 12/9/19 11:02 AM, Vineet Gupta wrote:
>> ARC gcc generates FDCMP instructions which raises Invalid operation for
>> signaling NaN only. This causes glibc iseqsig() primitives to fail (in
>> the current ongoing glibc port to ARC)
>>
>> So split up the hard float compares into two categories and for unordered
>> compares generate the FDCMPF instruction (vs. FDCMP) which raises exception
>> for either NaNs.
>>
>> With this fix testsuite/gcc.dg/torture/pr52451.c passes for ARC.
>>
>> Also passes 6 additional tests in glibc testsuite (test*iseqsig) and no
>> regressions
> Can this be backported to gcc-9 please ?
> glibc testing uses gcc-9

Never mind, I see that it is present in upstream/releases/gcc-9 !

Thx,
-Vineet

Re: [PATCH] tree-optimization: Fix tree dse of __*_chk PR93262

[Jeff Law]

On Wed, 2020-01-15 at 01:02 +0100, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase shows that GCC trunk mishandles DSE of __*_chk
> calls.  Tail trimming of the calls is fine, we want to just decrease the
> third argument and keep the first two and last arguments unmodified.
> But for head trimming, we currently increment the two by head_trim and
> decrease the third by head_trim, so
>   __builtin___memcpy_chk (&a, b_2(D), 48, 32);
>   __builtin_memset (&a, 32, 16);
> into:
>   _5 = b_2(D) + 16;
>   __builtin___memcpy_chk (&MEM  [(void *)&a + 16B], _5, 32, 32);
>   __builtin_memset (&a, 32, 16);
> This is wrong, because the 32 was the determined (maximum) size of the
> destination (char a[32]), but &a[16] has maximum size of 16, not 32.
> The __builtin___memcpy_chk (&MEM  [(void *)&a + 16B], _5, 32, 32);
> call is just folded later into
> __builtin_memcpy (&MEM  [(void *)&a + 16B], _5, 32);
> because it says that it copies as many bytes into destination as the
> destination has.  We need:
>   __builtin___memcpy_chk (&MEM  [(void *)&a + 16B], _5, 32, 16);
> instead, which will terminate the program instead of letting it silently
> overflow the buffer.
> The patch just punts if we'd need to decrease the last argument below 0.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Fortunately, release branches are unaffected.
> P.S. it was quite hard to make the runtime test working, in builtins.exp
> neither dg-options nor dg-additional-options work and builtins.exp adds
> -fno-tree-dse among several other -fno-* options.  Fortunately optimize
> attribute works.
> 
> 2020-01-15  Jakub Jelinek  
> 
>   PR tree-optimization/93262
>   * tree-ssa-dse.c (maybe_trim_memstar_call): For *_chk builtins,
>   perform head trimming only if the last argument is constant,
>   either all ones, or larger or equal to head trim, in the latter
>   case decrease the last argument by head_trim.
> 
>   * gcc.c-torture/execute/builtins/pr93262-chk.c: New test.
>   * gcc.c-torture/execute/builtins/pr93262-chk-lib.c: New file.
>   * gcc.c-torture/execute/builtins/pr93262-chk.x: New file.
As noted in private IRC.  This is OK.

jeff
> 

Re: [PATCH] tree-optimization: Fix tree dse of strncpy PR93249

[Jeff Law]

On Wed, 2020-01-15 at 00:53 +0100, Jakub Jelinek wrote:
> Hi!
> 
> As the testcase shows, tail trimming of strncpy in tree-ssa-dse.c is fine,
> we just copy or clear fewer bytes in the destination, but unlike
> memcpy/memset etc., head trimming is problematic in certain cases.
> If we can prove that there are no zero bytes among initial head_trim bytes,
> it is ok to trim it, if we can prove there is at least one zero byte among
> initial head_trim bytes, we could (not implemented in the patch) turn
> the strncpy into memset 0, but otherwise we need to avoid the head trimming,
> because the presence or absence of NUL byte there changes the behavior for
> subsequent bytes, whether further bytes from src are copied or if further
> bytes are cleared.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
> 
> 2020-01-15  Jakub Jelinek  
> 
>   PR tree-optimization/93249
>   * tree-ssa-dse.c: Include builtins.h and gimple-fold.h.
>   (maybe_trim_memstar_call): Move head_trim and tail_trim vars to
>   function body scope, reindent.  For BUILTIN_IN_STRNCPY*, don't
>   perform head trim unless we can prove there are no '\0' chars
>   from the source among the first head_trim chars.
> 
>   * gcc.c-torture/execute/pr93249.c: New test.
OK
jeff
> 

Re: [PATCH] Do not set -fomit-frame-pointer if TARGET_OMIT_LEAF_FRAME_POINTER_P.

[Jeff Law]

On Fri, 2020-01-03 at 12:23 +0100, Martin Liška wrote:
> Hi.
> 
> I'm not fully sure about the change, but -momit-leaf-frame-pointer
> probably should not globally omit frame pointers?
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-03  Martin Liska  
> 
>   PR tree-optimization/92860
>   * config/i386/i386-options.c (ix86_option_override_internal):
>   Do not enable -fomit-frame-pointer with -momit-leaf-frame-pointer
>   as it will globally omit pointers (like in ira.c).
But when TARGET_OMIT_LEAF_FRAME_POINTER is on, then for a non-leaf
function ix86_frame_pointer_required returns true. 

So AFAICT we don't globally omit frame-pointers when this option is
turned on.

jeff

Re: [PATCH] Remove redundant builtins for avx512f scalar instructions.

[Hongyu Wang]

For sure.

Jeff Law  于2020年1月15日周三 上午4:48写道：
>
> On Tue, 2019-12-24 at 13:31 +0800, Hongyu Wang wrote:
> > Hi:
> >   For avx512f scalar instructions, current builtin function like
> > __builtin_ia32_*{sd,ss}_round can be replaced by
> > __builtin_ia32_*{sd,ss}_mask_round with mask parameter set to -1. This
> > patch did the replacement and remove the corresponding redundant
> > builtins.
> >
> >   Bootstrap is ok, make-check ok for i386 target.
> >   Ok for trunk?
> >
> > Changelog
> >
> > gcc/
> > * config/i386/avx512fintrin.h
> > (_mm_add_round_sd, _mm_add_round_ss): Use
> >  __builtin_ia32_adds?_mask_round builtins instead of
> > __builtin_ia32_adds?_round.
> > (_mm_sub_round_sd, _mm_sub_round_ss,
> > _mm_mul_round_sd, _mm_mul_round_ss,
> > _mm_div_round_sd, _mm_div_round_ss,
> > _mm_getexp_sd, _mm_getexp_ss,
> > _mm_getexp_round_sd, _mm_getexp_round_ss,
> > _mm_getmant_sd, _mm_getmant_ss,
> > _mm_getmant_round_sd, _mm_getmant_round_ss,
> > _mm_max_round_sd, _mm_max_round_ss,
> > _mm_min_round_sd, _mm_min_round_ss,
> > _mm_fmadd_round_sd, _mm_fmadd_round_ss,
> > _mm_fmsub_round_sd, _mm_fmsub_round_ss,
> > _mm_fnmadd_round_sd, _mm_fnmadd_round_ss,
> > _mm_fnmsub_round_sd, _mm_fnmsub_round_ss): Likewise.
> > * config/i386/i386-builtin.def
> > (__builtin_ia32_addsd_round, __builtin_ia32_addss_round,
> > __builtin_ia32_subsd_round, __builtin_ia32_subss_round,
> > __builtin_ia32_mulsd_round, __builtin_ia32_mulss_round,
> > __builtin_ia32_divsd_round, __builtin_ia32_divss_round,
> > __builtin_ia32_getexpsd128_round, __builtin_ia32_getexpss128_round,
> > __builtin_ia32_getmantsd_round, __builtin_ia32_getmantss_round,
> > __builtin_ia32_maxsd_round, __builtin_ia32_maxss_round,
> > __builtin_ia32_minsd_round, __builtin_ia32_minss_round,
> > __builtin_ia32_vfmaddsd3_round,
> > __builtin_ia32_vfmaddss3_round): Remove.
> > * config/i386/i386-expand.c
> > (ix86_expand_round_builtin): Remove corresponding case.
> This doesn't really look like a bugfix to me.  Can it wait for gcc-11?
>
> jeff
> >
>

[committed] invoke.texi: update -fdiagnostics-show-cwe for analyzer

[David Malcolm]

Committed to master under the "obvious" rule
(ab7c7b46c35ed1be68d4c020a2f20ee96f68b64b)

gcc/ChangeLog:
* doc/invoke.texi (-fdiagnostics-show-cwe): Add note that some of
the analyzer options provide CWE identifiers.
---
 gcc/doc/invoke.texi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 180cde35424..d8b94d837a9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4076,7 +4076,8 @@ the vertical bars and the ``char *'' and ``long int'' 
text).
 @opindex fdiagnostics-show-cwe
 Diagnostic messages can optionally have an associated
 @url{https://cwe.mitre.org/index.html, CWE} identifier.
-GCC itself does not do this for any of its diagnostics, but plugins may do so.
+GCC itself only provides such metadata for some of the @option{-fanalyzer}
+diagnostics.  GCC plugins may also provide diagnostics with such metadata.
 By default, if this information is present, it will be printed with
 the diagnostic.  This option suppresses the printing of this metadata.
 
-- 
2.21.0

Various patches from the analyzer branch pushed to master

[David Malcolm]

These have been in the dmalcolm/analyzer branch for a while.

I've pushed them to master, as the given commits.
(successfully bootstrapped & regrtested on x86_64-pc-linux-gnu)


"analyzer: better logging for dedupe_winners::add"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01235.html
f474fbd5e3cca37ebc886a4950827e93d1c665c8

"analyzer: fix dedupe issue seen with CVE-2005-1689"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01234.html
14f9d7b9a708ebca57257059bda40986bb1e82a7

"analyzer: purge state for unknown function calls"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01237.html
0bd7cd980da625fcd12e6c56f51a166c2

"analyzer: add function-set.cc/h"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01424.html
c37001d7c9974248ffcb65aadba33283c

"analyzer: introduce a set of known async-signal-unsafe functions"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01423.html
4804c5fe965eef2f346de53d9e896ea2cd88f0b9

"analyzer: add known stdio functions to sm-file.cc (PR analyzer/58237)"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01425.html
7a1bb7c14d3805de22248e83a23b90d1a

"tree-diagnostic-path.cc: properly handle ad-hoc wrappers of UNKNOWN_LOCATION"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01471.html
03dc3f26231cbf570028e14706f8ad77fd5a

"analyzer: fix tests for UNKNOWN_LOCATION"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01472.html
8397af8ed0db685312e44117fd52316b57c2c129

"analyzer: ensure .dot output is valid for an empty BB"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01502.html
718930c0c8f8d25d185cb65e38c79a19458b6628

"analyzer: delete checker_event::clone"
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00074.html
94946989e82cfa996873bcf6273242f5606cd7f5

"analyzer: cleanups to checker_path"
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00075.html
e2a538b1c31a13fc3d2f6d8ac3f341437775e984

"analyzer: fix global-sm-state issue affecting sm-signal"
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00080.html
7fb3669edb4aa3c8313ddf8b914b86a1623e0954

analyzer: fix ICE on METHOD_TYPE (PR 93212)"
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00514.html
32077b693df8e3ed0424031a322df23822bf2f7e


Dave

Fix setting of DECL_CONTEXT in pushdecl (PR c/93072)

[Joseph Myers]

Bug 93072 is a case where the C front end (a) wrongly interprets an
inline declaration at block scope as indicating that DECL_CONTEXT
should be set for an inline function and (b) this results in an ICE.
This is a regression resulting from a previous fix of mine for other
bugs involving such declarations being wrongly interpreted elsewhere
as nested function declarations.  The fix is similar to the previous
fix: use TREE_PUBLIC instead of DECL_EXTERNAL in another place as the
relevant test to determine whether to set DECL_CONTEXT.  (When a
variable reaches the code in question in pushdecl, the two are
equivalent.)

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.  Will backport to GCC 9 and 8 branches.

gcc/c:
2020-01-15  Joseph Myers  

PR c/93072
* c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to
determine whether to set DECL_CONTEXT.

gcc/testsuite:
2020-01-15  Joseph Myers  

PR c/93072
* gcc.dg/inline-42.c, gcc.dg/inline-43.c: New tests.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index fa834d91730..8281af7307a 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -3048,7 +3048,7 @@ pushdecl (tree x)
  unless they have initializers (which generate code).  */
   if (current_function_decl
   && (!VAR_OR_FUNCTION_DECL_P (x)
- || DECL_INITIAL (x) || !DECL_EXTERNAL (x)))
+ || DECL_INITIAL (x) || !TREE_PUBLIC (x)))
 DECL_CONTEXT (x) = current_function_decl;
 
   /* Anonymous decls are just inserted in the scope.  */
diff --git a/gcc/testsuite/gcc.dg/inline-42.c b/gcc/testsuite/gcc.dg/inline-42.c
new file mode 100644
index 000..f5ccea8f3cf
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/inline-42.c
@@ -0,0 +1,50 @@
+/* Test inline functions declared in inner scopes.  Bug 93072.  */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+inline_1 (void)
+{
+}
+
+void
+inline_2 (void)
+{
+}
+
+static void
+inline_static_1 (void)
+{
+}
+
+static void
+inline_static_2 (void)
+{
+}
+
+static void
+test (void)
+{
+  inline void inline_1 (void);
+  if (inline_1 == 0) ;
+  extern inline void inline_2 (void);
+  if (inline_2 == 0) ;
+  inline void inline_3 (void);
+  if (inline_3 == 0) ;
+  extern inline void inline_4 (void);
+  if (inline_4 == 0) ;
+  inline void inline_static_1 (void);
+  if (inline_static_1 == 0) ;
+  extern inline void inline_static_2 (void);
+  if (inline_static_2 == 0) ;
+}
+
+void
+inline_3 (void)
+{
+}
+
+void
+inline_4 (void)
+{
+}
diff --git a/gcc/testsuite/gcc.dg/inline-43.c b/gcc/testsuite/gcc.dg/inline-43.c
new file mode 100644
index 000..87b24450384
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/inline-43.c
@@ -0,0 +1,50 @@
+/* Test inline functions declared in inner scopes.  Bug 93072.  */
+/* { dg-do compile } */
+/* { dg-options "-fgnu89-inline" } */
+
+void
+inline_1 (void)
+{
+}
+
+void
+inline_2 (void)
+{
+}
+
+static void
+inline_static_1 (void)
+{
+}
+
+static void
+inline_static_2 (void)
+{
+}
+
+static void
+test (void)
+{
+  inline void inline_1 (void);
+  if (inline_1 == 0) ;
+  extern inline void inline_2 (void);
+  if (inline_2 == 0) ;
+  inline void inline_3 (void);
+  if (inline_3 == 0) ;
+  extern inline void inline_4 (void);
+  if (inline_4 == 0) ;
+  inline void inline_static_1 (void);
+  if (inline_static_1 == 0) ;
+  extern inline void inline_static_2 (void);
+  if (inline_static_2 == 0) ;
+}
+
+void
+inline_3 (void)
+{
+}
+
+void
+inline_4 (void)
+{
+}

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

Re: [PATCH PR92926]Fix wrong code caused by ctor node translation unit wide sharing

[Bin.Cheng]

On Wed, Jan 15, 2020 at 5:04 AM Jeff Law  wrote:
>
> On Thu, 2020-01-09 at 14:20 +0800, Bin.Cheng wrote:
> > On Fri, Dec 20, 2019 at 3:10 PM Richard Biener
> >  wrote:
> > > On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng" 
> > >  wrote:
> > > > On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
> > > >  wrote:
> > > > > Hi,
> > > > >
> > > > > As reported in PR92926, constant ctor is shared translation unit wide
> > > > because of constexpr_call_table,
> > > > > however, during gimplify, the shared ctor could be modified.  This
> > > > patch fixes the issue by unsharing
> > > > > it before modification in gimplify.  A test is reduced from cppcoro
> > > > library and added.
> > > > > Bootstrap and test ongoing.  Not sure if this is the correct fix
> > > > though, any comments?
> > > > Ping.  Any comment?
> > >
> > > Looks reasonable to me.
> > Given PR92926 is marked as duplicate of PR93143, I updated test case
> > of the patch.
> >
> > Thanks,
> > bin
> >
> > 2019-12-13  Bin Cheng  
> >
> > PR tree-optimization/93143
> > * gimplify.c (gimplify_init_constructor): Unshare ctor node before
> > clearing.
> >
> > gcc/testsuite
> > 2019-12-13  Bin Cheng  
> >
> > PR tree-optimization/93143
> > * g++.dg/pr93143.C: New test.
> Is this still needed?  I think Jason fixed the outstanding sharing
> problems a couple days ago.
Yes, the issue is fixed and this can be discarded.

Thanks,
bin
>
> jeff
>

Re: Fix for LTO compromised autoconf test in libiberty

[Jeff Law]

On Tue, 2020-01-14 at 23:33 +, Joseph Myers wrote:
> My preference is still what I said in 
> ;: either 
> eliminate C alloca from libiberty, or don't build it with any compiler 
> defining __GNUC__.  I'd be surprised if there are host compilers that 
> build libiberty, have the relevant optimizations but don't support alloca.
So here's a patch that I think kills the alloca bits.

intl/ was the most interesting in that it has several #if ALLOCA
thingies.  But I reviewed all them and I'm pretty sure we'll do the
right thing (they define HAVE_ALLOCA anytime __GNUC__ is defined).

I've bootstrapped and regression tested without issue, of course.  But
that doesn't really exercise the worrisome cases. I wanted to try and
bootstrap on aix7.2, but the machine is the farm takes several seconds
for every file/directory operation.  Clearly not feasible.  So I then
wanted to try on aix7.1, but it doesn't look like we've got a usable
xlc++.  Then I tried to build on Solaris 11 in the farm.  But no Oracle
C++ compiler seems to be installed on that box.

So I'd really appreciated it if someone could do a bootstrap with
something other than GCC, preferably on AIX, but Solaris would be fine
too.

Anyway, here's the patch which removes all the alloca crud that I think
should disappear.





config/

	* gettext.m4 (AC_FUNC_ALLOCA): No longer required.

intl/
	* config.h.in: Rebuilt.
	* configure: Rebuilt.

libcpp/
	* configure.ac (AC_FUNC_ALLOCA): No longer required.
	* config.h.in: Rebuilt.
	* configure: Rebuilt.

libffi/
	* configure.ac (AC_FUNC_ALLOC): No longer required.
	* Makefile.in: Rebuilt.
	* fficonfig.h.in: Rebuilt.
	* configure: Rebuilt.
	* include/Makefile.in
	* man/Makefile.in
	* testsuite/Makefile.in

libiberty:
	* aclocal.m4 (libiberty_AC_FUNC_C_ALLOCA): Remove
	* configure.in (libiberty_AC_FUNC_C_ALLOC): No longer required
	* Makefile.in: Rebuilt.
	* configure: Rebuilt.
	* alloca.c: Remove.

diff --git a/config/gettext.m4 b/config/gettext.m4
index 45fa6b4ab76..83f4eb98a99 100644
--- a/config/gettext.m4
+++ b/config/gettext.m4
@@ -357,7 +357,6 @@ AC_DEFUN([AM_INTL_SUBDIR],
   AC_REQUIRE([AC_C_INLINE])dnl
   AC_REQUIRE([AC_TYPE_OFF_T])dnl
   AC_REQUIRE([AC_TYPE_SIZE_T])dnl
-  AC_REQUIRE([AC_FUNC_ALLOCA])dnl
   AC_REQUIRE([AC_FUNC_MMAP])dnl
   AC_REQUIRE([jm_GLIBC21])dnl
   AC_REQUIRE([gt_INTDIV0])dnl
diff --git a/intl/config.h.in b/intl/config.h.in
index 9c9b53dc0ea..637977c44b1 100644
--- a/intl/config.h.in
+++ b/intl/config.h.in
@@ -1,13 +1,5 @@
 /* config.h.in.  Generated from configure.ac by autoheader.  */
 
-/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
-   systems. This function is required for `alloca.c' support on those systems.
-   */
-#undef CRAY_STACKSEG_END
-
-/* Define to 1 if using `alloca.c'. */
-#undef C_ALLOCA
-
 /* Define because we depend on libiconv. */
 #undef DEPENDS_ON_LIBICONV
 
@@ -18,13 +10,6 @@
 /* Define to enable relocation. */
 #undef ENABLE_RELOCATABLE
 
-/* Define to 1 if you have `alloca', as a function or macro. */
-#undef HAVE_ALLOCA
-
-/* Define to 1 if you have  and it should be used (not on Ultrix).
-   */
-#undef HAVE_ALLOCA_H
-
 /* Define to 1 if you have the  header file. */
 #undef HAVE_ARGZ_H
 
@@ -211,14 +196,6 @@
 /* Define if  exists and defines unusable PRI* macros. */
 #undef PRI_MACROS_BROKEN
 
-/* If using the C implementation of alloca, define if you know the
-   direction of stack growth for your system; otherwise it will be
-   automatically deduced at runtime.
-	STACK_DIRECTION > 0 => grows toward higher addresses
-	STACK_DIRECTION < 0 => grows toward lower addresses
-	STACK_DIRECTION = 0 => direction of growth unknown */
-#undef STACK_DIRECTION
-
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
diff --git a/intl/configure b/intl/configure
index 2f35993148e..be3f41a6829 100755
--- a/intl/configure
+++ b/intl/configure
@@ -644,7 +644,6 @@ INTLBISON
 LTLIBICONV
 LIBICONV
 GLIBC21
-ALLOCA
 RANLIB
 host_os
 host_vendor
@@ -4282,192 +4281,6 @@ cat >>confdefs.h <<_ACEOF
 #define size_t unsigned int
 _ACEOF
 
-fi
-
-# The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
-# for constant arguments.  Useless!
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" >&5
-$as_echo_n "checking for working alloca.h... " >&6; }
-if ${ac_cv_working_alloca_h+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-#include 
-int
-main ()
-{
-char *p = (char *) alloca (2 * sizeof (int));
-			  if (p) return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_link "$LINENO"; then :
-  ac_cv_working_alloca_h=yes
-else
-  ac_cv_working_alloca_h=no
-fi
-rm -f core conftest.err conftest.$ac_objext \
-conftest$ac_exeext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_working_alloca_h" >&5
-$as_echo "$ac_cv_working_alloca_h" >&6; }
-if 

Re: [PR47785] COLLECT_AS_OPTIONS

[Prathamesh Kulkarni]

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
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am not sure where should we stream this. Currently, 
> > > > > > > > > > > > > cl_optimization
> > > > > > > > > > > > > has all the optimization flag provided for compiler 
> > > > > > > > > > > > > and it is
> > > > > > > > > > > > > autogenerated and all the flags