On Tue, 7 Jan 2020, Wilco Dijkstra wrote:
> Thanks for the suggestions, I've reworded it as:
> + GCC now defaults to -fno-common. As a result, global
> + variable accesses are more efficient on various targets. In C, global
> + variables with multiple tentative definitions now result
On Thu, 12 Dec 2019, Matthew Malcomson wrote:
> gcc/ChangeLog:
>
> 2019-12-12 Matthew Malcomson
>
> * doc/install.texi: Document bootstrap-asan configuration option.
I see this introduces a new table.
> +Some examples of build configurations designed for developers of GCC are:
@samp{b
This is a pretty rare situation since the C++11 change to make all
destructors default to noexcept, but it is still possible to define throwing
destructors, and if a destructor for a local variable throws during the
return, we've already constructed the return value, so now we need to
destroy it.
The library has already worked around this issue, but I was curious about
why it wasn't working. The answer: because we were passing &var to fold,
which doesn't know about the constexpr values hash table. Fixed by passing
&"str" instead.
Tested x86_64-pc-linux-gnu. Does this seem useful even th
On Wed, 2019-12-11 at 17:00 +0100, Jakub Jelinek wrote:
> On Wed, Dec 11, 2019 at 10:44:58AM -0500, David Malcolm wrote:
> > Is it OK for a hash_map key to have a "empty" value that isn't
> > all-zeroes (and thus the same for a hash_table entry)?
> >
> > Is the following patch OK for trunk?
>
> I
Here's a patch to replace the unsafe, unbounded operator>> with the
new one that only allows reading into a fixed-size array.
I think I'll sit on this until stage1 though.
The other options are to bump the libstdc++.so version and add it now,
or not bump the version and also add the new symbol o
This implements the new requirements for C++20 that std::atomic should
initialize the atomic variable in its default constructor.
This patch does not add the deprecated attribute to atomic_init, but
that should be done at some point as it's deprecated in C++20.
The paper also deprecates the ATOMI
From: Andrew Pinski
This adds octeontx2 naming. It currently uses the cortexa57
cost model and schedule model until I submit this. This is
more a place holder to get the naming of the cores in GCC 10.
I will submit the cost model in the next couple of days.
OK? Bootstrapped and tested on aarc
Hi!
On 2019-12-21T23:02:38+0100, I wrote:
> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
> wrote:
>>> > --- a/include/gomp-constants.h
>>> > +++ b/include/gomp-constants.h
>>> > +#define GOMP_DEVICE_CURRENT -3
>>> Should this actually get value '-1' instead of '-3'? Or, is th
Hi!
On 2020-01-09T22:00:09+0100, I wrote:
> On 2019-12-24T15:23:56+0100, Tobias Burnus wrote:
>> PS: History: [...]
>> A minor fix was committed to OG8?/OG9 as Rev.
>> 995f9680a46c3a7246fe465faa847f8009e47ed8.
>
> That patch by Julian is on og9 only, and -- as far as I can tell -- has
> never be
On Fri, 2020-01-10 at 09:46 -0700, Jeff Law wrote:
> 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 th
On 10/01/20 22:01 +, Jonathan Wakely wrote:
On 10/01/20 18:54 +0100, François Dumont wrote:
Hi
Here is my attempt to improve == operator.
There is a small optimization for the std::unordered_mutiXXX
containers but the main enhancement rely on some partial template
specialization
This fixes a typo and also explains why test_container is not a range
when used with output_iterator_wrapper or input_iterator_wrapper.
* testsuite/util/testsuite_iterators.h: Improve comment.
Committed to trunk.
commit 6fe8c46fff330747f1a5995f99af898c0e582c01
Author: Jonathan Wakely
Da
On 10/01/20 18:54 +0100, François Dumont wrote:
Hi
Here is my attempt to improve == operator.
There is a small optimization for the std::unordered_mutiXXX
containers but the main enhancement rely on some partial template
specialization of the _Equality type. I limit it to usage of uno
On Fri, 2020-01-10 at 08:38 -0700, Jeff Law wrote:
> 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.
> >
On Thu, Jan 09, 2020 at 02:26:10PM +0100, Richard Biener wrote:
> > >> + tree lhs = gimple_assign_lhs (stmt);
> > >> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), val);
> > >
> > > since we're using the optab entry shouldn't you check for == 2 here?
> >
> > Yes, that looks
On Thu, Jan 09, 2020 at 02:26:10PM +0100, Richard Biener wrote:
> > 2019-12-11 Wilco Dijkstra
> >
> > PR tree-optimization/90838
> > * tree-ssa-forwprop.c (check_ctz_array): Add new function.
> > (check_ctz_string): Likewise.
> > (optimize_count_trailing_zeroes):
Sorry, I found that the test will not work on x86 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
So I committed additionally the following patch
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=280135
Also I did a typo in PR # in ChangeLogs and the test name so I fixed
this too.
On January 10, 2020 3:04:07 PM GMT+01:00, Jakub Jelinek
wrote:
>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 {
Hi!
Older glibcs used to declare fwrite with -D_FORTIFY_SOURCE{,=2} as
warn_unused_result.
The following is just an workaround against that, not really using it in the
end, but just letting the compiler think we are.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2020
Hi!
As the following testcase shows, when deprecated attribute is on a template,
we'd never print the message if any, because the attribute is not
present on the TEMPLATE_DECL with which warn_deprecated_use is called,
but on its DECL_TEMPLATE_RESULT or its type.
Fixed thusly, bootstrapped/regtest
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
The patch was successfully tested bootstrapped on x86-64.
Committed as r280133
Index: ChangeLog
===
--- ChangeLog (revision 280132)
+++ ChangeLog (workin
On 1/10/20 4:29 PM, Richard Sandiford wrote:
> 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/g
On 1/9/20 3:42 PM, Richard Sandiford wrote:
> Thanks for the update, looks great.
>
> Stam Markianos-Wright writes:
>> diff --git a/gcc/config/aarch64/arm_bf16.h b/gcc/config/aarch64/arm_bf16.h
>> new file mode 100644
>> index
>> ..884b6f3bc7a28c516e54c2
On 12/18/19 1:25 PM, Stam Markianos-Wright wrote:
>
>
> On 12/13/19 10:22 AM, Stam Markianos-Wright wrote:
>> Hi all,
>>
>> This patch adds the ARMv8.6 Extension ACLE intrinsics for dot product
>> operations (vector/by element) to the ARM back-end.
>>
>> These are:
>> usdot (vector), dot (by el
Hi all,
This patch is part 2 of Bfloat16_t enablement in the ARM back-end.
This new type is constrained using target hooks TARGET_INVALID_CONVERSION,
TARGET_INVALID_UNARY_OP, TARGET_INVALID_BINARY_OP so that it may only be used
through ACLE intrinsics (will be provided in later patches).
Regress
Hi all,
This is a respin of patch:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html
which has now been split into two (similar to the Aarch64 version).
This is patch 1 of 2 and adds Bfloat type support to the ARM back-end.
It also adds a new machine_mode (BFmode) for this type and accom
We don't unshare CONSTRUCTORs as often during constexpr evaluation, so we
need to unshare them here.
Many thanks to bin cheng for the analysis and initial patch.
Tested x86_64-pc-linux-gnu, applying to trunk.
* constexpr.c (cxx_eval_outermost_constant_expr): Don't assume
CONSTRUC
related_vector_mode and compatible_vector_types_p make it possible
to generate 128-bit SVE code while still maintaining the distinction
between SVE vectors and Advanced SIMD vectors. We can therefore generate
VL-specific code for -msve-vector-bits=128 on little-endian targets.
In theory we could d
My patch for 93033 wasn't sufficient to handle all the possible sharing
introduced by split_nonconstant_init, and it occurred to me that it would
make sense to use the same unsharing technique as unshare_body, namely
copy_if_shared.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93
On Fri, 10 Jan 2020, Joseph Myers wrote:
> In gitwrite.html: the various custom setup of checkouts for which scripts
> have been posted, including usage of branches not fetched by default; an
> actual example commit session should be included like the one in
> svnwrite.html; more examples shoul
Back in 2009 Manuel sent a patch to avoid useless -Wconversion warnings
on compound assignment of types that get promoted to int:
https://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html
Joseph argued that those warnings are sometimes useful, and that they
should be controlled by a separate fl
I've applied this patch to add very preliminary documentation based on the
corresponding SVN documentation. It is deliberately not linked to from
anywhere, and does not yet include the list of branches from svn.html
(which is very out of date regarding what branches are actually active).
I adv
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
Hi
Here is my attempt to improve == operator.
There is a small optimization for the std::unordered_mutiXXX
containers but the main enhancement rely on some partial template
specialization of the _Equality type. I limit it to usage of unordered
containers with std::equal_to to be sure
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 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
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 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 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 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 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 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
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 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
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: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 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 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 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 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 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 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 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
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
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
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
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 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
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 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 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 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: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 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'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 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 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/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:
> 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
>
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:
> 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
>
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:
> 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/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:
> 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 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:
> 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 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:
> 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:
> 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:
> - 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:
> 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:
> 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.
>
> 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:
> 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:
> 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 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 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 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
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 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
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.
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
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
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
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
1 - 100 of 136 matches
Mail list logo
