On 08/01/2020 11:42 am, Andrew Stubbs wrote:
On 08/01/2020 11:07, Kwok Cheung Yeung wrote:
+#define __sync_subword_compare_and_swap(type, size) \
Macro parameters are conventionally upper case.
Fixed. I upper-cased the macro name as well.
+
On Wed, 2020-01-08 at 12:52 +0100, Andreas Schwab wrote:
> On Dez 06 2019, Martin Sebor wrote:
>
> > diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
> > b/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
> > new file mode 100644
> > index 000..249ce2b6ad5
> > --- /dev/null
> > +++ b
On Wed, Jan 08, 2020 at 07:12:29PM +0800, Bin.Cheng wrote:
> I am a bit worried that would make IVOPTs heavy too,
Yeah. And ivopts already *is* heavy, by nature of what it does. Giving
it extra work to do is not a good idea imo.
> it might be
> possible to compute heuristics whether loop should
This commit makes "make selftest-valgrind" clean by fixing this leak:
4 bytes in 1 blocks are definitely lost in loss record 1 of 734
at 0x483AB1A: calloc (vg_replace_malloc.c:762)
by 0x261DBE0: xcalloc (xmalloc.c:162)
by 0x2538C46: selftest::test_map_of_strings_to_int() (hash-map-tests.c
On Wed, 2020-01-08 at 12:52 +0100, Andreas Schwab wrote:
> On Dez 06 2019, Martin Sebor wrote:
>
> > diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
> > b/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
> > new file mode 100644
> > index 000..249ce2b6ad5
> > --- /dev/null
> > +++ b
[asan/hwasan co-author here, with clearly biased opinions]
On Android, HWASAN is already a fully usable testing tool.
We apply it to the kernel, user space system libraries, and select apps.
A phone with HWASAN-ified system is fully usable (I carry one as my
primary device since March 2019).
HWASA
Since we switched to doing constexpr evaluation on pre-GENERIC trees,
we don't have to handle DECL_BY_REFERENCE.
Tested x86_64-pc-linux-gnu, applying to trunk.
* constexpr.c (cxx_eval_call_expression): Remove DECL_BY_REFERENCE
support.
---
gcc/cp/constexpr.c | 17 +++-
Previously it didn't matter whether we looked through a TARGET_EXPR in
constexpr evaluation, but now that we have constexpr destructors it does.
On IRC I mentioned the idea of clearing TARGET_EXPR_CLEANUP in
digest_nsdmi_init, but since this initialization is expressed by an
INIT_EXPR, it's better
The previous patch fixes an instance of directly expanding a TARGET_EXPR that
has TARGET_EXPR_DIRECT_INIT_P set, which should never happen. So let's check
for any other instances.
Tested x86_64-pc-linux-gnu, applying to trunk.
* cp-gimplify.c (cp_gimplify_expr) [TARGET_EXPR]: Check
On Wed, Jan 8, 2020 at 9:09 AM Jakub Jelinek wrote:
>
> Hi!
>
> This is very similar to the previous PR93141 addv4 half and
> improves signed __builtin_sub_overflow on double-words rather than
> __builtin_add_overflow.
>
> I have left out the uaddv4 double-word stuff, because I ran into
> issues w
Hi,
On Wed, Jan 08 2020, Martin Jambor wrote:
> 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 remainin
Hi,
On Wed, Jan 08 2020, Jan Hubicka wrote:
>> 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
On Wed, 2019-12-18 at 10:59 -0500, David Malcolm wrote:
> On Wed, 2019-12-04 at 09:29 -0700, Martin Sebor wrote:
> > On 11/15/19 6:22 PM, David Malcolm wrote:
> > > This patch adds a class auto_delete_vec, a subclass of auto_vec
> > >
> > > that deletes all of its elements on destruction; it's use
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Sandra reviewed the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00549.html
> and noted that the organization could use some work.
>
> TODO: update re Sandra's ideas
>
> Changed in v4:
> - Use -fanalyzer
On Wed, 2020-01-08 at 04:02 -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:
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02026.html
>
> gcc/C
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review. (Used in one place by region-model.cc)
>
> Changed in v5:
> - follow msebor's suggestion of using operator const_sbitmap
> rather than operator const sbitmap&, as per:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00224.htm
(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 self-approve this. It's used by the diagnostic_path
> patch, and by
On Wed, 2019-12-04 at 10:59 -0700, Martin Sebor wrote:
> On 11/15/19 6:23 PM, David Malcolm wrote:
> > This patch adds an ordered_hash_map template, which is similar to
> > hash_map, but preserves insertion order.
> >
> > gcc/ChangeLog:
> > * Makefile.in (OBJS): Add ordered-hash-map-tests.o.
>
Musl and lld don't support TLS copy relocs, and don't want to add support
for this feature which is unique to RISC-V. Only GNU ld and glibc support
them. In the pasbi discussion, people have pointed out various problems
with using them, so we are deprecating them. There doesn't seem to be an
ABI
On 2020/1/8 22:54, Martin Liška wrote:
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index bd44063a1ac..789564ba335 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -1148,8 +1148,7 @@ symbol_table::materialize_all_clones (void)
if (symtab->dump_file)
On Wed, 08 Jan 2020 17:05:21 PST (-0800), Jim Wilson wrote:
Musl and lld don't support TLS copy relocs, and don't want to add support
for this feature which is unique to RISC-V. Only GNU ld and glibc support
them. In the pasbi discussion, people have pointed out various problems
with using them
Hi Bin,
> I am a bit worried that would make IVOPTs heavy too, it might be
> possible to compute heuristics whether loop should be unrolled as a
> post-IVOPTs transformation. Of course the transformation needs to do
> more work than simply unrolling in order to take advantage of
> aforementioned
On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Needs review. Used by diagnostic_path patch and in various places
> in the analyzer.
>
> msebor raised some concerns about the v1 version of this patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00221.html
> which I believe I
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. Perhaps better to make
> undocumeted, or do it via a DejaGnu pruning directive, but I wanted
> to get v5 of the kit posted.
>
>
On Wed, 2020-01-08 at 17:23 +, Martin Sebor wrote:
> A recent improvement to the vectorizer (r278334 if my bisection
> is right) can transform multiple stores to adjacent struct members
> into single vectorized assignments that write over all the members
> in a single MEM_REF. These are then f
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. Perhaps better to make
> > undocumeted, or do it via a DejaGnu pruni
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, 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
101 - 128 of 128 matches
Mail list logo
