> On 9 Jan 2020, at 21:01, Jonathan Wakely wrote:
>
>>
>> 2020-01-09 Olivier Hainque
>>
>> libstdc++-v3/
>> * doc/xml/manual/appendix_contributing.xml: Document _C2
>> as a reserved identifier, by VxWorks.
>> * include/bits/stl_map.h: Rename _C2 template typenames as _
Committed.
Richard.
2010-01-10 Richard Biener
PR testsuite/93216
* gcc.dg/optimize-bswaphi-1.c: Split previously added
case into a LE and BE variant.
Index: gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
===
Ping.
On Sun, 5 Jan 2020, Alexander Monakov wrote:
> Hi,
>
> I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well
> as
> any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 :
> 4.
> It's also evident that rtx_cost does redundant work for a SET rtx
The following patch addresses the quadraticness when sinking
clobbers across a long chain of "empty" EH landing pads one
pad at a time, walking the chain of clobbers that becomes longer
and longer repeatedly. The idea is simply to record sunk clobbers
off-IL to avoid the need to re-analyze them.
On Fri, Jan 10, 2020 at 10:47:32AM +0100, Richard Biener wrote:
>
> The following patch addresses the quadraticness when sinking
> clobbers across a long chain of "empty" EH landing pads one
> pad at a time, walking the chain of clobbers that becomes longer
> and longer repeatedly. The idea is si
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01081.html.
Thank you,
Jérémy
On Sun, Dec 15, 2019 at 07:20:26PM +0100, Jérémy Lefaure wrote:
> Hi!
>
> Since in ARM state the value of PC is the address of the current
> instruction plus 8 bytes, the code inspecting the value of PC
The following manages to avoid high EH indegree of landing pads
during the sequence of cleaning up empty EH with a chain of those.
By walking the landing pads in reverse order we mimic walking of
the EH tree depth-first (which I am too lazy to write...). It
looks like EH build assures that this
On Fri, Jan 10, 2020 at 11:23:34AM +0100, Richard Biener wrote:
>
> The following manages to avoid high EH indegree of landing pads
> during the sequence of cleaning up empty EH with a chain of those.
> By walking the landing pads in reverse order we mimic walking of
> the EH tree depth-first (whi
On 09/01/2020 16:50, Richard Earnshaw (lists) wrote:
Given the proposed intention to use non-standard refspecs for private
and vendor branches I've written some notes on how to use these.
It would be helpful if someone could do some experiments to ensure that
what I've written works properly f
> > I think you are also not removing the common_target and
> > common_target_probability from cgraph_edge.
> > There is now code in ipa-utils merging the histograms. You will need to
> > update that to your representation. It should not be hard - it either
> > copies all the values from target fun
On 1/9/20 10:51 AM, Jan Hubicka wrote:
On 1/8/20 3:05 PM, Jan Hubicka wrote:
I would still preffer invalidation before streaming (which is fully
deterministic) and possibly have option
Do you mean __gcov_merge_topn?
I suggest we do the following:
- have non-deterministic and determini
> > > > counter less than total_count/N (they are not useful anyway).
> >
> > However it seems that I missed a problem here. With step 2 and 4 the
> > merge is not distributive.
> >
> > I added 2 and 4 trying to work around the fact that we have no
> > convenient place to do pruning if mergi
Hi all,
This patch adds initial entries for notable features that went in to GCC
10 on the arm and aarch64 front.
The list is by no means complete so if you'd like your contribution
called please shout or post a follow-up patch.
It is, nevertheless, a decent start at the relevant sections in c
Hi,
On Thu, 9 Jan 2020 at 22:21, Jonathan Wakely wrote:
>
> On 09/01/20 19:57 +, Jonathan Wakely wrote:
> >I'll commit the attached patch after more testing.
>
> And this follow-up to fix some fallout.
>
I have noticed:
FAIL: g++:g++.dg/cpp0x/std-layout1.C -std=c++2a (test for excess errors
Hi.
This restores parenthesis to before r280040.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
And fixes the issue for ppc64le-linux-gnu.
Thanks,
Martin
gcc/ChangeLog:
2020-01-10 Martin Liska
PR ipa/93217
* ipa-inline-analysis.c (offline_size): Mak
Added the following change to the v10 changes site.
Johann
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index d6108269..7d96bc66 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -334,7 +334,54 @@ a work-in-progress.
arm-uclinuxfdpiceabi, and
This caches alias info avoiding repeated (expensive)
get_ref_base_and_extent. It doesn't address the unlimited quadraticness
in this function the PR93199 testcase runs into.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-01-10 Richard Biener
* gimple
update_epilogue_loop_vinfo applies SSA renmaing to the DR_REF of a
gather or scatter, so that vect_check_gather_scatter continues to work.
However, we sometimes also rely on vect_check_gather_scatter when
using gathers and scatters to implement strided accesses.
This showed up on existing tests wh
The related_vector_mode series missed this case in
vect_create_epilog_for_reduction, where we want to create the
unsigned integer equivalent of another vector. Without it we
could mix SVE and Advanced SIMD vectors in the same operation.
This showed up on existing tests when testing with fixed-len
One of the SVE run tests was specific to 256-bit SVE but tried to
run for all SVE lengths.
Tested on aarch64-linux-gnu and applied as r280104.
Richard
2020-01-10 Richard Sandiford
gcc/testsuite/
* gcc.target/aarch64/sve/index_1_run.c: Require aarch64_sve256_hw
rather than aa
Hi,
On Thu, Jan 09 2020, Christophe Lyon wrote:
> On Tue, 7 Jan 2020 at 14:18, 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 in
This patch is intended to help with folks setting up a git work
environment for use with GCC following the transition to git. It
currently does a couple of things.
1) Add an alias 'svn-rev' to git so that you can look up a legacy commit
by its svn revision number. This enables you to type
g
On Fri, Jan 10, 2020 at 2:23 PM Richard Earnshaw (lists)
wrote:
>
> This patch is intended to help with folks setting up a git work
> environment for use with GCC following the transition to git. It
> currently does a couple of things.
>
> 1) Add an alias 'svn-rev' to git so that you can look up
On Fri, Jan 10, 2020 at 1:39 PM Richard Sandiford
wrote:
>
> update_epilogue_loop_vinfo applies SSA renmaing to the DR_REF of a
> gather or scatter, so that vect_check_gather_scatter continues to work.
> However, we sometimes also rely on vect_check_gather_scatter when
> using gathers and scatters
On Fri, Jan 10, 2020 at 1:45 PM Richard Sandiford
wrote:
>
> The related_vector_mode series missed this case in
> vect_create_epilog_for_reduction, where we want to create the
> unsigned integer equivalent of another vector. Without it we
> could mix SVE and Advanced SIMD vectors in the same oper
Hi Ian,
> This libgo patch compiles examples in _test packages. Previously if
> the only names defined by _test packages were examples, the gotest
> script would emit an incorrect _testmain.go file. I worked around
> that by marking the example_test.go files +build ignored. This CL
> changes th
Hi,
This patch addresses the problem reported in PR92429. When creating an
epilogue for vectorization we have to replace the SSA_NAMEs in the
PATTERN_DEF_SEQs and RELATED_STMTs of the epilogue's loop_vec_infos.
When doing this we were using simplify_replace_tree which always folds
the replac
On 10/01/20 13:25 +0100, Christophe Lyon wrote:
Hi,
On Thu, 9 Jan 2020 at 22:21, Jonathan Wakely wrote:
On 09/01/20 19:57 +, Jonathan Wakely wrote:
>I'll commit the attached patch after more testing.
And this follow-up to fix some fallout.
I have noticed:
FAIL: g++:g++.dg/cpp0x/std-la
[for some reason something dropped the emails on their first reposting,
it took me a while to realize I'd missed something]
On 1/10/20 7:29 AM, Iain Sandoe wrote:
I was able to address all the comments that you made without finding any
show-stoppers. In addition to your comments, I’ve had one
On 10/01/2020 13:29, Richard Biener wrote:
On Fri, Jan 10, 2020 at 2:23 PM Richard Earnshaw (lists)
wrote:
This patch is intended to help with folks setting up a git work
environment for use with GCC following the transition to git. It
currently does a couple of things.
1) Add an alias 'svn-
Hi!
The C++ testcase shows we aren't able to determine constant when loading
from
const union U { struct V { int a, b; } c; long long d; } u = { { 1, 2 } };
u.d, but since your patch in the summer can handle
const union V { int a[2]; long long d; } v = { { 1, 2 } };
v.d.
I have noticed dwarf2out.
On 10/01/2020 14:01, Richard Earnshaw (lists) wrote:
On 10/01/2020 13:29, Richard Biener wrote:
On Fri, Jan 10, 2020 at 2:23 PM Richard Earnshaw (lists)
wrote:
This patch is intended to help with folks setting up a git work
environment for use with GCC following the transition to git. It
cur
The multi-byte store enhancement to the strlen optimization checked
sometime last summer didn't take care to prevent the nul-over-nul
store elimination of multi-byte assignments. This made it possible
for subsequent multi-byte stores of fewer nuls to cause prior larger
stores to be eliminated. T
The patch for sub-word atomics support added an include of stdint.h for the
definition of uintptr_h, but this can result in GCC compilation failing if the
stdint.h header has not been installed (from newlib in the case of AMD GCN).
I have fixed this by removing the stdint.h include and replacin
On 10/01/2020 13:23, Richard Earnshaw (lists) wrote:
This patch is intended to help with folks setting up a git work
environment for use with GCC following the transition to git. It
currently does a couple of things.
1) Add an alias 'svn-rev' to git so that you can look up a legacy commit
by
This patch to the Go frontend permits duplicate methods from embedded
interfaces. This is a language change for Go 1.14. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
Hi,
When gcc for Arm is configured with --with-multilib-list=aprofile a
misplaced endif directive in the makefile was causing the arm->thumb
mapping for multilibs to be omitted from the reuse rules. This
resulted in the default multilib being picked rather than the thumb2
opimized version.
gcc/Ch
Hi,
When only the rmprofile multilibs are built, compiling for armv7-a
should select the generic v7 multilibs. This used to work before +sec
and +mp were added to the architecture options but it was broken by
that update. This patch fixes those variants and adds some tests to
ensure that they rem
On 10/01/2020 14:21, Kwok Cheung Yeung wrote:
The patch for sub-word atomics support added an include of stdint.h for
the definition of uintptr_h, but this can result in GCC compilation
failing if the stdint.h header has not been installed (from newlib in
the case of AMD GCN).
I have fixed th
Having the "same" vector types with different modes means that we can
end up vectorising a constructor with a different mode from the lhs.
This patch adds a VIEW_CONVERT_EXPR in that case.
This showed up on existing tests when testing with fixed-length
-msve-vector-bits=128.
Tested on aarch64-lin
This simple script is intended to setup a new git configuration to pull
the branches and tags for a specific vendor. This should simplify some
of the steps needed for working with a vendor's branches.
* git-fetch-vendor.sh: New file.
R.
diff --git a/contrib/git-fetch-vendor.sh b/contrib/git-f
aarch64_builtin_vectorized_function checked vectors based on the
number of elements and the element mode. This doesn't interact
well with fixed-length 128-bit SVE, where SVE modes can have those
same properties. (And we can't just use the built-ins for SVE because
the types use a different ABI.
On 10/12/19 15:19 +, Jonathan Wakely wrote:
On 09/12/19 10:32 +0100, François Dumont wrote:
After completing this work and running more tests I realized that
the declaration of algos was still not ideal.
So here is another version where algos are not re-declare in
stl_deque.h, I rather in
Since LWG 445 was implemented for GCC 4.7, the std::iterator base class
of std::istreambuf_iterator changes type depending on the -std mode
used. This creates an ABI incompatibility between different -std modes.
This change ensures the base class always has the same type. This makes
layout for C++
On Fri, Jan 10, 2020 at 5:40 AM Rainer Orth
wrote:
>
> > This libgo patch compiles examples in _test packages. Previously if
> > the only names defined by _test packages were examples, the gotest
> > script would emit an incorrect _testmain.go file. I worked around
> > that by marking the examp
On Wed, 2020-01-08 at 23:35 -0500, David Malcolm wrote:
> On Wed, 2020-01-08 at 21:17 -0700, Jeff Law wrote:
> > On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > > I may be able to self-approve this. It's used by the
> > > diagnostic_path
> > > patch, and by the analyzer test suite. Pe
On Wed, 2020-01-08 at 17:07 -0500, David Malcolm wrote:
> (replying to my own "[PATCH 05/41] Add -fdiagnostics-nn-line-numbers"
> with a followup that does it at the DejaGnu level rather than as a
> test-only option)
>
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > I may be able to
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> I believe I can self-approve this with my "diagnostic messages"
> maintainer hat on. It has dependencies on the auto_delete_vec
> and the -fdiagnostics-nn-line-numbers patches.
>
> Changed in v5:
> - updated copyright years to include 2020
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> This takes the place of the auto_client_timevar code from v1 of the kit:
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01519.html
>
> gcc/ChangeLog:
> * timevar.def (TV_ANALYZER): New timevar.
> (TV_ANALYZ
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> New in v5. Creating this file means all the ChangeLog entries in
> gcc/analyzer are now for this file, rather than for gcc/ChangeLog.
>
> gcc/analyzer/ChangeLog:
> * ChangeLog: New file.
Not sure if we have a policy here, but given t
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Unchanged since v4; needs review.
>
> This patch adds a configuration option to disable building the analyzer.
> It is built by default (but off by default at compile-time).
>
> gcc/ChangeLog:
> * configure.ac (--disable-analyzer, EN
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00497.html
> I believe the subsequent changes are obvious enough to be self-approvable.
>
> Changed in v5:
> - update ChangeLog path
> - upda
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Unchanged since v4; needs review
>
> gcc/ChangeLog:
> * Makefile.in (lang_opt_files): Add analyzer.opt.
> (ANALYZER_OBJS): New.
> (OBJS): Add digraph.o, graphviz.o, tristate.o and ANALYZER_OBJS.
OK
jeff
>
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> Changed in v5:
> - update ChangeLog path
> - updated copyright years to include 2020
>
> Changed in v4:
> - wrap with #if ENABLE_ANALYZER
> - add DISABLE_COPY_AND_ASSIGN
>
> This patch adds a logging framework to the ana
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review
>
> Changed in v5:
> - updated copyright years to include 2020
>
> Changed in v3:
> - https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02461.html
> - moved from gcc/analyzer to gcc
>
> This patch adds a simple wrapper class to m
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> Changed in v5:
> - update ChangeLog path
> - updated copyright years to include 2020
>
> Changed in v4:
> - Remove include of gcc-plugin.h, reworking includes accordingly.
> - Use TV_ANALYZER rather than TV_NONE for the p
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff semi-approved an earlier version of this here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00502.html
>
> Changed in v5:
> - updated copyright years to include 2020
>
> Changed in v4:
> - Moved from gcc/analyzer to gcc, renami
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff reviewed an earlier version of this here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00503.html
> My response:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00809.html
> I have followup patches that implement the function_set
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff semi-approved an earlier version of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00504.html
>
> msebor had some observations here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00644.html
> TODO: investigate
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> There was some discussion of the v1 version of this here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00536.html
> in terms of whether this could be moved up to the "gcc" subdir
> (not without a lot of extra work).
>
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff reviewed the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00507.html
> > I note this seems somewhat incomplete -- which is fine given my
> > recommendation was to focus on the double-free analyzer. T
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00508.html
> and the subsequent changes are obvious in my view.
>
> Changed in v5:
> - update ChangeLog path
> - updated copyright years to i
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff reviewed the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00509.html
> > Given it's not ready for production, fine. Presumably one of the areas
> > for improvement is a better answer to the "what con
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> Although the comments say "experimental", there are followups (using
> function_set) which make this much more production-ready than the
> other sm-*.cc (other than malloc).
>
> Changed in v5:
> - update ChangeLog path
>
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 n
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Initial comments by Jeff here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00510.html
> This checker isn't ready for production yet, so the discussion in the
> cover letter applies here.
>
> Changed in v5:
> - update ChangeLog path
>
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved the v1 version of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00806.html
> and the followups count as obvious in my opinion.
>
> Changed in v5:
> - update ChangeLog path
> - updated copyright years to inc
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved ("No concerns here") the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00511.html
> and the subsequent changes fall under the "obvious" rule in my
> opinion.
>
> Changed in v5:
> - update Cha
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved the v1 version of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00811.html
> (modulo hash_map issues), and the followups count as obvious in my
> opinion.
>
> Changed in v5:
> - update ChangeLog path
> - up
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff's initial review of v1 of this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00813.html
> I've addressed most of the issues he raised there.
> TODO: should some structs be classes?
>
> Changed in v5:
> - update ChangeLog pat
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 t
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved the v1 version of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00815.html
> (with one item that I've addressed in v5), and the followups count as
> obvious in my opinion.
>
> Changed in v5:
> - update Chan
On Wed, 2020-01-08 at 04:03 -0500, David Malcolm wrote:
> Needs review (or potentially falls under the "obvious" rule, at a
> stretch).
>
> This patch adds a "break-on-saved-diagnostic" command to gdbinit.in,
> useful for debugging when a diagnostic is queued by the analyzer.
>
> gcc/ChangeLog:
>
On Wed, 2020-01-08 at 04:03 -0500, David Malcolm wrote:
> Needs review.
>
> Changed in v5:
> - updated for removal of analyzer-specific builtins:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01310.html
>
> Changed in v4:
> - more tests, including a test for .dot output and an LTO test
> - up
On 1/8/20 11:26 AM, Matthew Malcomson wrote:
Hi everyone,
I'm writing this email to summarise & publicise the state of this patch
series, especially the difficulties around approval for GCC 10 mentioned
on IRC.
The main obstacle seems to be that no maintainer feels they have enough
knowledge
On 1/9/20 4:13 PM, Stam Markianos-Wright wrote:
>
>
> On 1/9/20 4:07 PM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> diff --git a/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
>>> b/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
>>> new file mode 100644
>>
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review. This is used in many places in the analyzer.
> msebor made some comments about the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00231.html
>
> Changed in v5:
> - updated copyright years to
Stam Markianos-Wright writes:
> On 1/9/20 4:13 PM, Stam Markianos-Wright wrote:
>> On 1/9/20 4:07 PM, Richard Sandiford wrote:
>>> Stam Markianos-Wright writes:
diff --git a/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
b/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.
On Fri, 2020-01-10 at 09:22 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Needs review. This is used in many places in the analyzer.
> > msebor made some comments about the v1 version of this patch here:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg002
aarch64_evpc_sel (new in GCC 10) got the true and false vectors
the wrong way round, leading to execution failures with fixed-length
128-bit SVE.
Now that the ACLE types are in trunk, it's much easier to match
the exact asm sequence for a permute.
Tested on aarch64-linux-gnu and applied as r28012
I believe except for bugs and known omissions (e.g. PR93225+93226), the
GCC 10 trunk implementation is complete – and the version number can be
bumped from 2.0 (alias 201306) to OpenACC 2.6 (alias 201711).
That's what this patch does (i.e. applying the previously mentioned OG9
patch).
It als
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review. msebor expressed some concerns in an earlier version
> of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00233.html
> re overlap with existing functions, and very long names.
> For the former, they all have
On Fri, 2020-01-10 at 09:01 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Needs review.
> >
> > Although the comments say "experimental", there are followups
> > (using
> > function_set) which make this much more production-ready than the
> > other sm-*.cc (o
On Fri, 2020-01-10 at 08:35 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 17:07 -0500, David Malcolm wrote:
> > (replying to my own "[PATCH 05/41] Add -fdiagnostics-nn-line-
> > numbers"
> > with a followup that does it at the DejaGnu level rather than as a
> > test-only option)
> >
> > On Wed, 2
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> The v1 version of this patch was reviewed by Jeff here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00805.html
> TODO: looks like I still need to act on some of his comments there
>
> Changed in v5:
> - update ChangeLog path
> - updat
On 10/01/2020 14:30, Przemyslaw Wirkus wrote:
Hi,
When gcc for Arm is configured with --with-multilib-list=aprofile a
misplaced endif directive in the makefile was causing the arm->thumb
mapping for multilibs to be omitted from the reuse rules. This
resulted in the default multilib being picked
On 10/01/2020 14:31, Przemyslaw Wirkus wrote:
Hi,
When only the rmprofile multilibs are built, compiling for armv7-a
should select the generic v7 multilibs. This used to work before +sec
and +mp were added to the architecture options but it was broken by
that update. This patch fixes those vari
On Fri, 2020-01-10 at 11:30 -0500, David Malcolm wrote:
> On Fri, 2020-01-10 at 09:22 -0700, Jeff Law wrote:
> > On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > > Needs review. This is used in many places in the analyzer.
> > > msebor made some comments about the v1 version of this pat
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> Re the v1 version of this patch Jeff asked in:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00506.html
> > This goes well beyond what we were originally targeting -- which begs
> > the question, what's the state of th
On Wed, 2020-01-08 at 04:03 -0500, David Malcolm wrote:
> Needs review. Jeff reviewed the v1 version of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00818.html
> requesting a function to be split up, which I did in v4.
> See the URLs below for notes on the other changes.
Just
On Fri, 2020-01-10 at 08:53 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Jeff reviewed an earlier version of this here:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00503.html
> > My response:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00809.h
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Jeff approved the v1 version of the patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00820.html
> There are some non-trivial changes in the followups (see the URLs
> below).
>
> Changed in v5:
> - update ChangeLog path
> - upda
The attached patch corrects a logic error in the validation
of the new attribute access where the code incorrectly expects
the human readable representation of the attribute to match
the terse internal representation of the positional argument.
Committed in ra280124 after bootstrapping it and run
On Fri, 2020-01-10 at 09:10 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Jeff's initial review of v1 of this patch:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00813.html
> > I've addressed most of the issues he raised there.
> > TODO: should some str
On Fri, 2020-01-10 at 12:18 -0500, David Malcolm wrote:
> On Fri, 2020-01-10 at 09:10 -0700, Jeff Law wrote:
> > On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > > Jeff's initial review of v1 of this patch:
> > > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00813.html
> > > I've addre
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> Changed in v5:
> - update ChangeLog path
> - updated copyright years to include 2020
>
> Changed in v4:
> - Rework includes to avoid gcc-plugin.h
> - Wrap everything with #if ENABLE_ANALYZER
> - Replace auto_client_timeva
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review.
>
> Changed in v5:
> - update ChangeLog path
> - updated copyright years to include 2020
>
> Changed in v4:
> - Remove include of gcc-plugin.h, reworking includes accordingly.
> - Wrap everything in #if ENABLE_ANALYZER
> - Re
On Fri, 2020-01-10 at 10:24 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Needs review.
> >
> > Changed in v5:
> > - update ChangeLog path
> > - updated copyright years to include 2020
> >
> > Changed in v4:
> > - Rework includes to avoid gcc-plugin.h
> > -
On Fri, 2020-01-10 at 12:40 -0500, David Malcolm wrote:
> >
> On Fri, 2020-01-10 at 10:24 -0700, Jeff Law wrote:
> > I don't see any EH handling mechansisms. I realize we haven't
> > focused
> > on C++ and thus EH hasn't been the top of our minds, but are we going
> > to have to handle that at s
On Fri, 2020-01-10 at 11:44 -0500, David Malcolm wrote:
> On Fri, 2020-01-10 at 08:35 -0700, Jeff Law wrote:
> > On Wed, 2020-01-08 at 17:07 -0500, David Malcolm wrote:
> > > (replying to my own "[PATCH 05/41] Add -fdiagnostics-nn-line-
> > > numbers"
> > > with a followup that does it at the DejaG
1 - 100 of 136 matches
Mail list logo
