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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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 {
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 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):
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 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 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
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 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
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
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
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
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
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
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
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
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
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.
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
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
101 - 136 of 136 matches
Mail list logo
