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
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 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 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 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 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
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, 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
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)
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 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.
>
(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, 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
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:
> 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, 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
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
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
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
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
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
[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
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
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, 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
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 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.
+
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 flagged by -Wstringop-overflow
thanks to its also recently enha
On 08/01/20 16:44 +, Jonathan Wakely wrote:
When recursing into a directory, any errors that occur while removing a
directory entry are ignored, because the subsequent increment of the
directory iterator clears the error_code object.
This fixes that bug by checking the result of each recursi
> 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_
When recursing into a directory, any errors that occur while removing a
directory entry are ignored, because the subsequent increment of the
directory iterator clears the error_code object.
This fixes that bug by checking the result of each recursive operation
before incrementing. This is a change
> 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.
> >> >
> >> > @Mar
> 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_
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
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_ma
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_sr
> 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_
Hello,
This patch adds missing { dg-require-effective-target fpic }
directives to aarch64 tests using -fpic or -fPIC explicitly.
This prevents spurious test failures on configurations not
supporting the options, such as VxWorks for at least kernel
mode on any target.
Committing to trunk after re
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
> 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_max_agg_items
> param_ipa_cp_unit_growth
> pa
> 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_
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_ma
When looking at libgomp.texi the other day, I saw that the acc_*_async
variants and the acc_*_finalize functions of OpenACC 2.5 were not
documented.
Hence, this patch adds them. Those are part of OpenACC 2.5, hence, I
updated the @ref (but referenced to OpenACC 2.6 instead).
Possible variant
> On 7 Jan 2020, at 18:21, Richard Sandiford wrote:
>> * gcc.target/aarch64/stack-check-alloca.h: Remove
>> #include alloca.h. #define alloca __builtin_alloca
>> instead.
> OK, thanks.
Great, thanks Richard!
On Wed, Jan 8, 2020 at 8:58 AM Jakub Jelinek wrote:
>
> Hi!
>
> On the following testcase, the peephole2s merge @stack_protect_set_1_
> with not the expected *mov{si,di}_internal, but *lea instead -
> which looks like a mov, but uses address_no_seg_operand predicate/Ts
> constraint. The peephole2
On Wed, Jan 8, 2020 at 8:48 AM Jakub Jelinek wrote:
>
> Hi!
>
> Joseph reported ia32 glibc build ICEs, because the
> *adddi3_doubleword_cc_overflow_1 pattern allows a memory output and matching
> input, but addcarry* to which it splits doesn't, for some strange
> reason it only allows register out
On 12/10/19 5:03 PM, Kyrill Tkachov wrote:
> Hi Stam,
>
> On 11/15/19 5:26 PM, Stam Markianos-Wright wrote:
>> Pinging with more correct maintainers this time :)
>>
>> Also would need to backport to gcc7,8,9, but need to get this approved
>> first!
>>
>
> Sorry for the delay.
Same here now! So
> Hi.
>
> The patch consistent usage of cgraph_node::dump_{asm_,}name where possible.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK, thanks!
Not all dump_name/dump_asm_name choices are fully logical, but I see it
is comming form name/as
Committed as obvious.
Tobias
Index: libgomp/ChangeLog
===
--- libgomp/ChangeLog (revision 280006)
+++ libgomp/ChangeLog (revision 280008)
@@ -0,0 +1,4 @@
+2020-01-08 Tobias Burnus
+
+ * libgomp.texi: Fix typos, use https.
+
Index
Hi.
The patch consistent usage of cgraph_node::dump_{asm_,}name where possible.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-01-08 Martin Liska
* cgraph.c (cgraph_node::dump): Use ::dump_name or
This makes $subject reliably catch secondary opportunities (which
cause quadraticness in PR93199). It also makes virtual operand
updating in this process a bit cheaper.
This is a first step with the second addressing the quadraticness
(either by some algorithmic changes or by capping the number
Committed.
Richard.
2020-01-08 Richard Biener
PR testsuite/92997
* gcc.dg/torture/ftrapv-1.c (iaddv): Use noipa attribute.
Index: gcc/testsuite/gcc.dg/torture/ftrapv-1.c
===
--- gcc/testsuite/gcc.dg/torture/ftr
>
> >
> > 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 deterministic version of TOPN counter
and a flag chosing between determi
Hello Thomas,
sorry for the belated review. I am not completely happy about the
introduction of yet another two global variables, but I also do not see
an easy way out. Hence: OK.
I was playing around with the following test case – you might consider
to add them as well. (I would exclude the
On 08/01/20 06:43 +0100, François Dumont wrote:
@@ -404,15 +413,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_begin() const
{ return static_cast<__node_type*>(_M_before_begin._M_nxt); }
- // Assign *this using another _Hashtable instance. Either elements
- // are copy or move d
On 1/8/20 1:24 PM, Jan Hubicka wrote:
On 1/8/20 11:35 AM, Jan Hubicka wrote:
Hi,
Just to explain better what I am worried about. The overall sum of
counters in TOPN does not have very good meaning if you have more than N
target.
Lets for simplicity assume that we have TOPN for N=1 (i.e. old co
PING
Hi Jakub,
I have attached a version of the patch that has been rebased on the current
trunk.
Frederik
On 03.12.19 12:16, Harwath, Frederik wrote:
> On 08.11.19 07:41, Harwath, Frederik wrote:
>> On 06.11.19 14:00, Jakub Jelinek wrote:
>> [...]
>>> I'm not sure it is a good idea to use a TR
> On 1/8/20 11:35 AM, Jan Hubicka wrote:
> > Hi,
> > Just to explain better what I am worried about. The overall sum of
> > counters in TOPN does not have very good meaning if you have more than N
> > target.
> >
> > Lets for simplicity assume that we have TOPN for N=1 (i.e. old code). It
> > gua
On 1/8/20 11:08 AM, Jan Hubicka wrote:
On 1/7/20 11:27 AM, Martin Liška wrote:
Which is fine. Apparently there are just few usages of manual printing
of a symtab node and order like:
fprintf (f,
"%*s%s/%i %s\n%*s freq:%4.2f",
indent, "", callee->name (), calle
On unrelated note, looking what we print with --verbose -v
The following options are specific to just the language LTO:
-flinker-output=Set linker output type (used internally during
LTO optimization).
-fltransRun the link-time optimizer in local
transformatio
On Wed, Jan 8, 2020 at 11:22 AM Jan Hubicka wrote:
>
> > > > Given all warning options can be enabled/disabled via #pragma GCC
> > > > diagnostic
> > > > all Warning annotated options should be implicitely 'Optimization' for
> > > > the purpose
> > > > of LTO streaming then?
> > >
> > > Well, per
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/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
> +void test_strcpy_warn (
On Wed, Jan 8, 2020 at 12:30 PM Bin.Cheng wrote:
>
> On Wed, Jan 8, 2020 at 6:31 PM Richard Biener
> wrote:
> >
> > On Wed, Jan 8, 2020 at 6:01 AM bin.cheng
> > wrote:
> > >
> > > Sorry, here is the patch.
> > > --
> > > Sender:bin
On 1/8/20 11:35 AM, Jan Hubicka wrote:
Hi,
Just to explain better what I am worried about. The overall sum of
counters in TOPN does not have very good meaning if you have more than N
target.
Lets for simplicity assume that we have TOPN for N=1 (i.e. old code). It
guarantees if target X is taken
The following adjusts gsi_remove to do what is documented - not touch
operand caches or force updating by marking it modified when the
remove is not permanent. This avoids redundant operand scans for
stmt move (gsi_move_* does a gsi_remove / gsi_insert combo as well).
For the original testcase
On 08/01/2020 11:07, Kwok Cheung Yeung wrote:
+#define __sync_subword_compare_and_swap(type, size) \
Macro parameters are conventionally upper case.
+ \
+type \
+__sync_val_compare_and_swap_##size (ty
On 1/8/20 12:08 PM, Jan Hubicka wrote:
Hmm, indeed. Well, I belive we use the 'Optimization' flag for other purposes
than only triggering LTO streaming and option save/restore, so we need another
flag that only triggers save/restore then (and also allow us to avoid
dropping the
flag at lto-optio
On Wed, Jan 8, 2020 at 6:31 PM Richard Biener
wrote:
>
> On Wed, Jan 8, 2020 at 6:01 AM bin.cheng wrote:
> >
> > Sorry, here is the patch.
> > --
> > Sender:bin.cheng
> > Sent At:2020 Jan. 8 (Wed.) 12:58
> > Recipient:GCC Patches
>
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 about hwasan and justification that it's wort
On Tue, Jan 7, 2020 at 6:48 PM Kewen.Lin wrote:
>
> on 2020/1/7 下午5:14, Richard Biener wrote:
> > On Mon, 6 Jan 2020, Kewen.Lin wrote:
> >
> >> We are thinking whether it can be handled in IVOPTs instead of one RTL
> >> pass.
> >>
> >> During IVOPTs selecting IV cands, it doesn't know the loop wi
> Hmm, indeed. Well, I belive we use the 'Optimization' flag for other purposes
> than only triggering LTO streaming and option save/restore, so we need another
> flag that only triggers save/restore then (and also allow us to avoid
> dropping the
> flag at lto-option streaming time where we curre
Hello
This patch adds support for 8- and 16-bit sync_compare_and_swap
operations on AMD GCN. GCN does not natively support atomic compare and
swap for quantities smaller than 32-bit words, so the subword compare
and swap is implemented in terms of 32-bit compare and swap.
The algorithm is si
Hi,
Just to explain better what I am worried about. The overall sum of
counters in TOPN does not have very good meaning if you have more than N
target.
Lets for simplicity assume that we have TOPN for N=1 (i.e. old code). It
guarantees if target X is taken by more than 50% of times, it will win,
On Wed, Jan 8, 2020 at 6:01 AM bin.cheng wrote:
>
> Sorry, here is the patch.
> --
> Sender:bin.cheng
> Sent At:2020 Jan. 8 (Wed.) 12:58
> Recipient:GCC Patches
> Subject:[PATCH GCC11]Improve uninitialized warning with value range i
> > > Given all warning options can be enabled/disabled via #pragma GCC
> > > diagnostic
> > > all Warning annotated options should be implicitely 'Optimization' for
> > > the purpose
> > > of LTO streaming then?
> >
> > Well, perhaps they can be marked but for late optimizations this does
> > not
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:
> > >
On Tue, Jan 7, 2020 at 4:46 PM Jan Hubicka wrote:
>
> > On Tue, Jan 7, 2020 at 3:26 PM Jan Hubicka wrote:
> > >
> > > > Err - Optimization also lists it in some -help section? It's a Warning
> > > > option and certainly we don't handle per-function Warnings in general
> > > > (with LTO) even tho
> On 1/7/20 11:27 AM, Martin Liška wrote:
> > Which is fine. Apparently there are just few usages of manual printing
> > of a symtab node and order like:
> >
> > fprintf (f,
> > "%*s%s/%i %s\n%*s freq:%4.2f",
> > indent, "", callee->name (), callee->order,
> >
> >
>
> Thanks. So caller could be {hot, cold} + {large, small}, same for callee.
> It may
> produce up to 4 * 4 = 16 combinations. Agree that hard to define useful,
> and useful really doesn't reflect performance improvements certainly. :)
>
> My case is A1(1) calls A2(2), A2(2) calls A3(3). A1
On 1/7/20 11:27 AM, Martin Liška wrote:
Which is fine. Apparently there are just few usages of manual printing
of a symtab node and order like:
fprintf (f,
"%*s%s/%i %s\n%*s freq:%4.2f",
indent, "", callee->name (), callee->order,
I can replace these with symtab_
On 1/8/20 9:22 AM, Jakub Jelinek wrote:
With mixed REF_COMPONENT and REF_ARRAY, one can have var(:), or var2%comp(:)
or var3(:)%comp, or var3%comp(:)%comp2 etc.
Technically, one can also have var3(4)%comp(:)%comp2(1) – with one
nonelement/AR_FULL reference and two element references. (At least a
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 remain
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
- updated copyright years to include 2020
Changed in v4:
- Remove include of
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
- updated copyright years to include 2020
Changed in v4:
- Remove include o
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 a "-Wanalyzer-" prefix to
distinguish them, and for the latter, I
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.
Changed in v5:
- update ChangeLog path
- updated copyright years to
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 path
- updated copyright years to include 2020
Changed in v4:
- Remove /
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 ChangeLog path
- updated copyright years to include 2020
- kill the debugg
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 constitutes exposure"
> question ;-)
I have followup work using fun
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
- updated copyright years to include 2020
Changed in v4:
- Remove include of
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 include 2020
Changed in v4:
- Remove include of gcc-plugin.h, reworkin
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
- Remove /// comment lines
- Rework logging to avoid exploded_graph multiple-inh
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
- Remove /// comment lines
- Add support for global state:
- https://gcc.gnu.o
Here's an updated version of the analyzer patch kit.
The main change in this version of the kit is that I've added notes to
the top of each patch describing its review status
(e.g. "needs review" vs "approved" etc), to try to clarify what's left
to do here.
This is v5, and is relative to r279963
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 the other checkers in here?
Jeff: I thought I had responded to that by
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
- updated copyright years to include 2020
Changed in v4:
- Remove include o
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:
* gdbinit.in (break-on-saved-diagnostic): New command.
---
gcc
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, renaming selftests accordingly
- Remove comments
- Replace auto_clien
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 ChangeLog path
- updated copyright years to include 2020
Changed in v4:
1 - 100 of 128 matches
Mail list logo
