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 peephole2s check that operand with several smaller
predicates, as we do not
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 with it - as the pattern uses (set (reg:CC flags) (compare:CC (reg:TI)
Hi Thomas,
I had a quick look at the patch – I thought that it is only a band aid
and should be handled more properly, but after having a closer look, I
believe the latter is more work than I expected and Jakub's patch makes
perfectly sense for Stage 3/4. (Hence, I also did not reply.)
On 1/
On Wed, Jan 08, 2020 at 09:14:10AM +0100, Tobias Burnus wrote:
> Especially in light of the OpenMP 4.5's structure element mapping (for C/C++
> since GCC 7, for Fortran still unsupported), I had preferred some
> consolidation like taking the last reference in that check instead of just
> checking t
Hi Tobias!
On 2019-12-10T18:54:19+0100, Tobias Burnus wrote:
> PS: Besides adding tons of test cases, [r279858] also fixes the transient
> issue
> (which does only occur with -O1 ?!?)
(I saw it with different/differing optimization levels.)
> with the existing
> use_device_addr-{3,4}.f90 tes
Hi Thomas,
On 1/8/20 9:33 AM, Thomas Schwinge wrote:
With 'dg-do run' added, on powerpc64le-unknown-linux-gnu
Have I already expressed that I started to hate that target arch?
I think we really should find out what goes wrong for the small example
of https://gcc.gnu.org/bugzilla/show_bug.cgi
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 addressed in v4:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg013
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 rather than --analyzer
- Add -W[no-]analyzer-unsafe-call-within-signal-
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_ANALYZER_SUPERGRAPH): Likewise.
(TV_ANALYZER_STATE_PURGE): Likewis
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.
This patch implements -fdiagnostics-nn-line-numbers, a new option
wh
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/ChangeLog:
* Makefile.in (TEXI_GCCINT_FILES): Add analyzer.texi.
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.
---
gcc/analyzer/ChangeLog | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 gcc/analyzer
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.
---
gcc/Makefile.in | 32 +++-
1 file changed, 31 insertions
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 analyzer which handles
hierarchical messages (showing the nested structure of the
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 pass
- Add a gate function to the pass
- Move the check for #if ENABLE_ANAL
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.html
gcc/ChangeLog:
* sbitmap.h (auto_sbitmap): Add operator c
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 include 2020
This patch adds an ordered_hash_map template, which is
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 make it easier to
write human-readable .dot files.
gcc/ChangeLog:
*
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 idea.
TODO:
I haven't yet addressed the is_setjmp_call_p/is_lo
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 making operator==/!= be non-members
Changed in v5:
- updated copyri
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, ENABLE_ANALYZER): New option.
(gccdepdir): Also create depdir
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_timevar with TV_ANALYZER_SUPERGRAPH
- Fix .dot output
https://gcc.gnu.org/ml/gcc
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).
Changed in v5:
- update ChangeLog path
- updated copyright years to
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
Changed in v4:
- Add support for paths for signal-handlers:
http
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
- updated copyright years to include 2020
New in v4; part of:
https://g
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
This patch adds classes for tracking the equivalence
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
- updated copyright years to include 2020
Changed in v4:
- Remove inclu
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:
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 include 2020
Changed in v4:
- Remove include of gcc-plugin.h, reworking
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 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.
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
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.
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
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
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'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
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
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
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
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
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
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
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_
>
> 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,
> >
> >
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 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:
> > >
> > > 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 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
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,
> 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
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
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 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
>
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 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
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 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
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 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 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 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 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 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
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 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
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
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
>
> >
> > 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
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
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
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
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?
OK, thanks!
Not all dump_name/dump_asm_name choices are fully logical, but I see it
is comming form name/as
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
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 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 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!
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
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_
> 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_for_fn:
>
> param_ipa_cp
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_
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_for_fn:
>
> param_ipa_ma
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_
> 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
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 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_
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
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
1 - 100 of 128 matches
Mail list logo
