On Wed, 2019-11-27 at 12:23 +0100, Rainer Orth wrote:
> Hi Joseph,
>
> > On Mon, 25 Nov 2019, Rainer Orth wrote:
> >
> > > it seems you missed updating a couple of testcases that are ia32-
> > > only:
> >
> > I think it's unavoidable that such target-specific testcases need
> > updating
> > by
On Wed, 2019-11-27 at 14:08 +0100, Martin Liška wrote:
> Hi.
>
> The patch is about translation of titles in -fdbg-cnt-list table.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-11-27 Marti
On Fri, 2019-12-06 at 14:05 +, Sudakshina Das wrote:
> Hi
>
> While looking at the vectorization for following example, we
> realized
> that even though vectorizable_shift function was distinguishing
> vector
> shifted by vector from vector shifted by scalar, while modeling the
> cost
> it
On Wed, 2019-11-06 at 16:19 +, Jozef Lawrynowicz wrote:
> From 7bc0971d2936ebe71e7b7d3d805cf1bbf9f9f5af Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz
> Date: Mon, 4 Nov 2019 17:38:13 +
> Subject: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
>
> gcc/ChangeLog:
>
> 20
On Wed, 2019-11-06 at 16:17 +, Jozef Lawrynowicz wrote:
> From 967262117f0c838fe8a9226484bf6e014c86f0ba Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz
> Date: Tue, 29 Oct 2019 13:02:08 +
> Subject: [PATCH 2/3] libgcc: Dont define __do_global_dtors_aux if it will be
> empty
>
> libgcc
On Thu, 2019-11-07 at 17:05 +, Dragan Mladjenovic wrote:
> On 01.11.2019. 11:32, Dragan Mladjenovic wrote:
> > On 10.08.2019. 00:15, Joseph Myers wrote:
> > > On Fri, 9 Aug 2019, Jeff Law wrote:
> > >
> > > > > 2019-08-05 Dragan Mladjenovic
> &g
On Fri, 2019-11-29 at 21:00 +, Jozef Lawrynowicz wrote:
> The attached patch consolidates some configuration tweaks I
> previously submitted
> as modifications to the msp430-elf target into a new target called
> "msp430-elfbare" i.e. "bare-metal".
>
> MSP430: Disable TM clone registry by defau
On Sun, 2019-12-08 at 09:43 -0500, David Malcolm wrote:
> On Sat, 2019-12-07 at 08:05 -0700, Jeff Law wrote:
> > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> > > This patch adds classes used by the analyzer for handling its
> > > diagnostics
> > >
On Tue, 2019-12-10 at 21:40 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the newly added asserts.
> Some comments hint that maybe it is fine if CODE_LABEL additions
> don't
> trigger df recomputations, but even if it is not ok,
> regstat_bb_compute_calls_crossed doesn't loo
On Tue, 2019-12-10 at 21:33 +0100, Jakub Jelinek wrote:
> Hi!
>
> The ipa vr hash table apparently intentionally doesn't differentiate
> between
> value ranges with different types, all that matters are the values of
> min and max, so before using it ipa_vr_operation_and_type_effects
> needs to
>
On Tue, 2019-12-10 at 10:27 +0100, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, -fstack-protector-strong in some cases
> instruments
> even functions which except for the stack canary setup and later
> testing of
> that don't touch the stack at all.
>
> This is because for -fstack-prote
On Wed, 2019-12-11 at 00:23 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because gimple_call_alloc_size doesn't
> always
> return a sizetype typed INTEGER_CST, which the callers rely on
> (compare
> those converted to wide_int with other wide_ints with the sizetype
> precisio
On Mon, 2019-12-09 at 13:40 +, Stam Markianos-Wright wrote:
>
> On 12/3/19 10:31 AM, Stam Markianos-Wright wrote:
> >
> > On 12/2/19 9:27 PM, Joseph Myers wrote:
> > > On Mon, 2 Dec 2019, Jeff Law wrote:
> > >
> > > > > 2019-11-13 St
On Wed, 2019-12-11 at 00:03 -0700, Sandra Loosemore wrote:
> On 12/6/19 3:41 PM, Jeff Law wrote:
> > On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote:
> > > I bootstrapped and regression-tested this on x86_64-linux-
> > > gnu. There
> > > are a f
On Wed, 2019-12-11 at 11:49 +, Jozef Lawrynowicz wrote:
> On Mon, 9 Dec 2019 13:05:22 +
> Jozef Lawrynowicz wrote:
>
> > On Sat, 07 Dec 2019 11:27:54 -0700
> > Jeff Law wrote:
> >
> > > On Wed, 2019-11-06 at 16:19 +, Joz
On Wed, 2019-12-11 at 12:21 +, Jozef Lawrynowicz wrote:
> On Wed, 11 Dec 2019 12:19:41 +
> Jozef Lawrynowicz wrote:
>
> > On Mon, 9 Dec 2019 15:28:25 +
> > Jozef Lawrynowicz wrote:
> >
> > > On Sat, 07 Dec 2019 11:40:33 -0700
> > > Jeff
On Wed, 2019-11-27 at 19:53 +, Jozef Lawrynowicz wrote:
> From b74f34e5ae7f649296f7f6bcce35b75c34a2b0fd Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz
> Date: Mon, 25 Nov 2019 12:07:24 +
> Subject: [PATCH] MSP430: Add fno-exceptions multilib
>
> ChangeLog:
>
> 2019-11-27 Jozef Lawry
On Wed, 2019-12-11 at 01:35 +0100, Matthias Klose wrote:
> the toplevel configure.ac repeats common exclusion files for specific
> targets.
> Just factor those out. Maybe not required, but gm2 is adding more
> files to be
> ignored on every target, so make it easy to only have these files
> mentio
On Mon, 2019-12-09 at 11:52 +0200, Claudiu Zissulescu wrote:
> Although the FDCMP (the double precision floating point compare
> instruction) is added to the compiler, it is not properly used via
> cstoredi pattern. Fix it.
>
> OK to apply?
> Claudidu
>
> -xx-xx Claudiu Zissulescu
>
>
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch adds a "state_machine" base class for describing
> API checkers in terms of state machine transitions. Followup
> patches use this to add specific API checkers.
>
> gcc/ChangeLog:
> * analyzer/sm.cc: New file.
> * an
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch adds call_string, a class for representing the
> call stacks at a program_point, so that we can ensure that
> paths through the code are interprocedurally valid.
>
> gcc/ChangeLog:
> * analyzer/call-string.cc: New file.
>
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch introduces function_point and program_point, classes
> for tracking locations within the program (the latter adding
> a call_string for tracking interprocedural location).
>
> gcc/ChangeLog:
> * analyzer/program-point.cc: N
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch adds exploded_graph and related classes, for managing
> exploring paths through the user's code as a directed graph
> of pairs.
>
> gcc/ChangeLog:
> * analyzer/exploded-graph.h: New file.
> ---
> gcc/analyzer/exploded-gra
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch adds classes for tracking what state can be safely purged
> at any given point in the program.
>
> gcc/ChangeLog:
> * analyzer/state-purge.cc: New file.
> * analyzer/state-purge.h: New file.
> ---
> gcc/analyzer/stat
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch adds diagnostic_manager and related support classes for
> saving, deduplicating, and emitting analyzer diagnostics.
>
> gcc/ChangeLog:
> * analyzer/diagnostic-manager.cc: New file.
> * analyzer/diagnostic-manager.h: N
On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> This patch adds a family of classes for representing paths of events
> for analyzer diagnostics.
>
> gcc/ChangeLog:
> * analyzer/checker-path.cc: New file.
> * analyzer/checker-path.h: New file.
>
>
No significant concerns her
On Fri, 2019-12-13 at 05:03 -0600, Segher Boessenkool wrote:
> On Thu, Dec 12, 2019 at 09:32:27AM +, Richard Sandiford wrote:
> > I doubt it will be long before we deprecate
> > all targets that require old reload.)
>
> Do we wait until GCC 12 (to remove old reload completely)? If not, we
> s
On Sat, 2019-12-14 at 15:33 +0100, John Paul Adrian Glaubitz wrote:
> Hi Stefan!
>
> > The problems are in the gcc implementation
> >
> > - the lra implementation is buggy
> > - the compare elimination can't handle parallel's containing a compare
> > - df-core considers parallel's containing a co
On Fri, 2019-12-13 at 17:55 -0700, Martin Sebor wrote:
> After more testing by Jeff's buildbot and correcting the problems
> it exposed I have committed the attached patch in r279392.
And just to close the loop on this. Your last version fixed all the
issues I saw in the tester.
jeff
On Fri, 2019-12-13 at 17:25 +0100, Stefan Franke wrote:
> Hi there,
>
> I suggest this patch to allow architectures do substitute cc0_rtx with a
> generated cc register.
>
> Why? If you are using a cc register plus your architecture as many
> instructions which may clobber that cc register, som
On Sat, 2019-12-14 at 03:55 +0100, Stefan Franke wrote:
> Am 2019-12-13 21:59, schrieb Segher Boessenkool:
> > On Fri, Dec 13, 2019 at 08:55:15PM +0100, Stefan Franke wrote:
> > > Am 2019-12-13 18:58, schrieb Segher Boessenkool:
> > > > On Fri, Dec 13, 2019 at 05:25:41PM +0100, Stefan Franke wrote:
On Thu, 2019-12-19 at 13:21 -0800, Bryan Stenson wrote:
> x-post from here: https://marc.info/?t=15767864485&r=1&w=2
>
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index 6341216d1bc..e6d690b75c0 100644
> --- a/gcc/config/mips/mips.c
> diff --git a/gcc/config/mips/mips.c b/g
On Thu, 2020-01-02 at 12:04 +0100, Martin Liška wrote:
> Hi.
>
> The flag is set based on optimization option:
> gcc/common/config/i386/i386-common.c:{ OPT_LEVELS_2_PLUS, OPT_free, NULL,
> 1 },
>
> and so that it should be also per-function. The only usage of the flag is
> in gate of a RTL p
On Thu, 2020-01-02 at 12:07 +0100, Martin Liška wrote:
> Hi.
>
> The param is changed here:
>
>/* Restrict the amount of work combine does at -Og while retaining
> most of its useful transforms. */
>if (opts->x_optimize_debug)
> SET_OPTION_IF_UNSET (opts, opts_set, param_max_c
On Thu, 2020-01-02 at 12:06 +0100, Martin Liška wrote:
> Hi.
>
> Again, the param is set based on optimize_size:
>
>if (opts->x_optimize_size)
> /* We want to crossjump as much as possible. */
> SET_OPTION_IF_UNSET (opts, opts_set, param_min_crossjump_insns, 1);
>
> So that, the p
On Mon, 2019-12-16 at 17:43 +0100, Georg-Johann Lay wrote:
> Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> Patch 1/3 is the GCC changes: Documentation and new avr-specific
> configure options:
>
> --with-libf7 selects to which level double support from libf7 is added
> to libgcc.
>
> --with-do
On Mon, 2019-12-16 at 17:46 +0100, Georg-Johann Lay wrote:
> Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
>
> Patch 2/3 is the libgcc additions:
>
> --with-libf7 selects which makefile-snips from libf7 to use.
>
> libgcc/
> * config.host (tmake_file) [target=avr]: Add t-libf7,
> t-
On Mon, 2019-12-16 at 17:49 +0100, Georg-Johann Lay wrote:
> Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> Patch 3/3 is the actual libf7 implementation. A great deal of which is
> assembly, together with C + inline assembly for higher routines.
>
> Johann
>
> libgcc/config/avr/libf7/
>
On Wed, 2019-12-18 at 16:30 +0100, Georg-Johann Lay wrote:
> Hi, this patch turns off -fipa-icf-variables because it generates wrong
> code like for PR92606. As there is no target hook that could decide
> whether such optimizations are obsolete, disable such optimizations
> alltogether until PR
On Thu, 2019-12-19 at 15:22 +, Richard Sandiford wrote:
> IFN_DIV_POW2 currently requires all elements to be shifted by the
> same amount, in a similar way as for WIDEN_LSHIFT_EXPR. This patch
> enforces that when building the SLP tree.
>
> If in future targets want to support IFN_DIV_POW2 wi
On Mon, 2019-12-23 at 14:44 +, Richard Sandiford wrote:
> We can't yet vectorise conditional internal functions whose boolean
> condition is fed by a data access (or more generally, by a tree of logic
> ops in which all the leaves are data accesses). Although we should add
> that eventually, w
On Thu, 2020-01-02 at 10:04 +0100, Martin Liška wrote:
> Hi.
>
> The patch is about using Optimization for warn_inline as
> it's affected by -O0.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019
On Fri, 2020-01-03 at 13:26 +0100, Martin Liška wrote:
> Hi.
>
> One another fix where -Ox sets a parameter that
> is not marked with Optimize keyword. Fixed by
> adding the keyword.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
>
On Fri, 2020-01-03 at 16:18 +0100, Martin Liška wrote:
> Hello.
>
> The patch introduces Optimization keyword for various
> parameters that influence an optimization that operates
> on function level (TREE/RTL). I manually grepped for
> each occurrence and verified that it's really used
> within a
On Fri, 2019-11-29 at 20:53 +, Joseph Myers wrote:
> As reported in bug 91226, the libdecnumber code used on the host to
> interpret DFP values in the BID encoding fails, for _Decimal64 and
> _Decimal128, to check for the case where a significand is too large
> and so specified in IEEE 754 to b
On Thu, 2019-12-12 at 15:13 +, Richard Sandiford wrote:
> pass_return_slot::execute has:
>
> /* Ignore internal functions without direct optabs,
>those are expanded specially and aggregate_value_p
>on their result might result in undesirable warnings
On Tue, 2019-12-17 at 10:14 +0100, Andreas Krebbel wrote:
> This suppresses an array out of bounds warning in mkdeps.c as proposed
> by Martin Sebor in the bugzilla.
>
> array subscript 2 is outside array bounds of ‘const char [2]’
>
> Since this warning does occur during bootstrap it currently b
On Mon, 2020-01-06 at 18:12 +0100, Georg-Johann Lay wrote:
> Jeff Law schrieb:
> > On Mon, 2019-12-16 at 17:43 +0100, Georg-Johann Lay wrote:
> > > Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> > > Patch 1/3 is the GCC changes: Documentation and new avr-speci
On Mon, 2019-12-16 at 15:45 +0100, Martin Jambor wrote:
> Hi Jeff,
>
> On Sat, Dec 07 2019, Jeff Law wrote:
> > [...]
> > The whole point behind the uninitialized warning is to capture cases
> > where objects may not be properly initialized. For modern code the
>
On Wed, 2019-12-18 at 16:36 +0100, Georg-Johann Lay wrote:
> Hi, currently device support in avr-gcc is accomplished by injecting a
> specs file my means of -specs=... in dirver self specs.
>
> This patch adds a new avr driver option to omit the addition of
> respective -specs option so give the
On Thu, 2019-12-19 at 16:59 +, Richard Sandiford wrote:
> Normally we only create SVE ACLE functions when arm_sve.h is included.
> But for LTO we need to do it at start-up, so that the functions are
> already defined when streaming in the LTO objects.
>
> One hitch with doing that is that LTO
On Fri, 2020-01-03 at 09:16 +0100, Jakub Jelinek wrote:
> Hi!
>
> As can be seen in the testcase, for the (x >> c) << c optimization into
> x & (-1< as the affected bits are shifted away.
> Furthermore, while match.pd can handle
> ((unsigned long long)(unsigned)(x >> 32))<<32
> for unsigned long l
On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
> Inline should return failure either (newsize > param_large_function_insns)
> OR (newsize > limit). Sometimes newsize is larger than
> param_large_function_insns, but smaller than limit, inline doesn't return
> failure even if the new functio
On Mon, 2020-01-06 at 09:24 +0100, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the following testcase ICEs because rs, while valid
> add_operand is not valid add_cint_operand and so gen_add3_insn fails,
> because it doesn't meet the expander predicates.
>
> Fixed thusly, bootstrapped/r
On Mon, 2020-01-06 at 15:08 +0100, Martin Liška wrote:
> Hi.
>
> As Honza noticed in the PR, we are quite strict about TOP N
> counter invalidation due to multiple values that can't
> fit in a counter. We due it in order to have a reproducible
> builds. I guess we should do a compromise in between
On Mon, 2020-01-06 at 19:23 +0100, Jan Hubicka wrote:
> > On Mon, 2020-01-06 at 15:08 +0100, Martin Liška wrote:
> > > Hi.
> > >
> > > As Honza noticed in the PR, we are quite strict about TOP N
> > > counter invalidation due to multiple values that can't
> > > fit in a counter. We due it in order
On Mon, 2020-01-06 at 11:05 +0100, Martin Liška wrote:
> Hi.
>
> The patch is about explanation what happens when
> a target_clone function calls a function without
> the attribute.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-01-06 Martin Liska
>
> PR ipa/83411
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
runk.
jeff
commit 48e76be17adbf93fe264fc118adbcf2ae6a14806
Author: law
Date: Wed Jan 8 18:46:33 2020 +
* gcc.dg/Wstringop-overflow-27.c: Make testnames unique.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@280016
138bc75d-0d04-0410-961f-82ee72b054a4
diff -
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
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 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
> > &
I was wandering spec chasing down instances where we should be
generating bit-test, bit-set and bit-clear types of instructions for our
target when I ran across a generic missed optimization in this space.
(((1 << N) & C) != 0) -> (N == C')
(((1 << N) & C) == 0) -> (N != C')
Where C is a
On 5/31/2021 11:50 PM, Richard Sandiford wrote:
"H.J. Lu via Gcc-patches" writes:
On Mon, May 31, 2021 at 06:32:04AM -0700, H.J. Lu wrote:
On Mon, May 31, 2021 at 6:26 AM Richard Biener
wrote:
On Mon, May 31, 2021 at 3:12 PM H.J. Lu wrote:
On Mon, May 31, 2021 at 5:46 AM Richard Biener
it 40e484885c10a0c8bd994c5cf7bf247998a4ad6b
Author: Jeff Law
Date: Wed Jun 2 00:56:38 2021 -0400
Fix minor bugs in H8 port logical ops. Prepare for more compare/test
removal
gcc/
* config/h8300/h8300-protos. (compute_a_shift_length): Drop unused
argument fro
bytes).
Committed to the trunk.
Jeff
commit f0d1a675e0f621fc12c7a9db47446ae38289408a
Author: Jeff Law
Date: Sun Jun 6 00:44:13 2021 -0400
Use moves to eliminate redundant test/compare instructions
gcc/
* config/h8300/movepush.md: Change most _clobber_flags
So, as many of you know I left Red Hat a while ago and joined Tachyum.
We're building a new processor and we've come across an issue where I
think we need upstream discussion.
I can't divulge many of the details right now, but one of the quirks of
our architecture is that reg+d addressing
On 6/8/2021 8:08 AM, Michael Matz wrote:
Hello,
On Mon, 7 Jun 2021, Jeff Law wrote:
So, as many of you know I left Red Hat a while ago and joined Tachyum. We're
building a new processor and we've come across an issue where I think we need
upstream discussion.
I can't divu
On 6/8/2021 12:56 AM, Richard Biener wrote:
On Mon, Jun 7, 2021 at 9:00 PM Jeff Law wrote:
So, as many of you know I left Red Hat a while ago and joined Tachyum.
We're building a new processor and we've come across an issue where I
think we need upstream discussion.
I can'
On 6/8/2021 9:06 AM, H.J. Lu wrote:
On Tue, Jun 8, 2021 at 7:56 AM Jakub Jelinek via Gcc-patches
wrote:
On Tue, Jun 08, 2021 at 08:47:26AM -0600, Jeff Law wrote:
Why is the machinery involving STACK_SLOT_ALIGNMENT and
spill_slot_alignment() (for spilling) or get_stack_local_alignment
On 10/15/2021 9:27 AM, Martin Liška wrote:
On 10/14/21 16:27, Jeff Law wrote:
So what's the preferred way to handle this? We're in the process of
evaluating -frename-registers on our target right now and subject to
verification of a couple issues, our inclination is to turn it o
This is a minor missed optimization we found with our internal port.
Given this code:
typedef struct {short a; short b;} T;
extern void g1();
void f(T s)
{
if (s.a < 0)
g1();
}
"s" is passed in a register, but it's still a BLKmode object because the
alignment of T i
On 7/2/2021 10:13 AM, Jeff Law wrote:
This is a minor missed optimization we found with our internal port.
Given this code:
typedef struct {short a; short b;} T;
extern void g1();
void f(T s)
{
if (s.a < 0)
g1();
}
"s" is passed in a register, but
our internal port.
Committed to the trunk.
Jeff
commit 0853f392a213ef2cecc71ef5349aab079e30f5a0
Author: Jeff Law
Date: Tue Jul 27 14:14:05 2021 -0400
Fix argument to pthread_join
gcc/testsuite
* g++.dg/gcov/gcov-threads-1.C: Fix argument to pthread_join.
diff --git
On 2/26/24 17:17, Greg McGary wrote:
The sign-bit-copies of a sign-extending load cannot be known until runtime on
WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM
load. See the fix for PR112758.
2024-02-22 Greg McGary
PR rtl-optimization/113010
So one of the broad goals we've had over the last few months has been to
ensure that every insn has a scheduling type and that every insn is
associated with an insn reservation in the scheduler.
This avoids some amazingly bad behavior in the scheduler. I won't go
through the gory details.
I
On 2/29/24 01:35, Richard Biener wrote:
The following amends the PR114070 fix to optimistically allow
the folding when we cannot expand the current vec_cond using
vcond_mask and we're still before vector lowering. This leaves
a small window between vectorization and lowering where we could
br
On 3/3/24 12:43, Uros Bizjak wrote:
umuldi3_highpart expander does:
if (REG_P (operands[2]))
operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]);
on register_operand predicate, which also allows SUBREG RTX. So,
subregs were emitted without ZERO_EXTEND RTX.
But nowadays we have
On 2/29/24 00:06, Xi Ruoyao wrote:
The vect_int_mod target selector is evaluated with the options in
DEFAULT_VECTCFLAGS in effect, but these options are not automatically
passed to tests out of the vect directories. So this test fails on
targets where integer vector modulo operation is suppor
On 2/25/24 20:30, HAO CHEN GUI wrote:
Hi,
This patch tries to fix a potential problem which is raised by the patch
for PR111267. The volatile asm operand tries to be propagated to a single
set insn with the patch for PR111267. It has potential risk as the behavior
is wrong. Currently set_sr
On 2/29/24 06:28, Robin Dapp wrote:
On 2/29/24 02:38, Li, Pan2 wrote:
So it's going to check if V2SF can be tied to DI and V4QI with SI. I
suspect those are going to fail for RISC-V as those aren't tieable.
Yes, you are right. Different REG_CLASS are not allowed to be tieable in RISC-V.
s
On 2/9/24 03:26, Richard Biener wrote:
The following allows a base term to be derived from an existing
MEM_EXPR, notably the points-to set of a MEM_REF base. For the
testcase in the PR this helps RTL DSE elide stores to a stack
temporary. This covers pointers to NONLOCAL which can be mapped
On 3/3/24 19:56, HAO CHEN GUI wrote:
Hi Jeff,
Thanks for your comments.
在 2024/3/4 6:02, Jeff Law 写道:
Why specifically are you worried here? Propagation of a volatile shouldn't in
and of itself cause a problem. We're not changing the number of volatile
accesses or anything
Excerpt from gcc.sum:
[...]
PASS: gcc.c-torture/execute/20101011-1.c -O0 (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c -O0 execution test
PASS: gcc.c-torture/execute/20101011-1.c -O1 (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c -O1 execution te
On 3/4/24 02:12, HAO CHEN GUI wrote:
Hi Jeff,
在 2024/3/4 11:37, Jeff Law 写道:
Can the same thing happen with a volatile memory load? I don't think that will
be caught by the volatile_insn_p check.
Yes, I think so. If the define rtx contains volatile memory references, it
may hit the
On 3/4/24 09:49, Jakub Jelinek wrote:
On Mon, Mar 04, 2024 at 05:18:39PM +0100, Rainer Orth wrote:
On 2/26/24 17:17, Greg McGary wrote:
The sign-bit-copies of a sign-extending load cannot be known until runtime on
WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM
l
On 2/6/24 04:37, Richard Biener wrote:
The following avoids accessing out-of-bound vector elements when
native encoding a boolean vector with sub-BITS_PER_UNIT precision
elements. The error was basing the number of elements to extract
on the rounded up total byte size involved and the patch b
ckend
actually has distinct patterns for those two cases. So swapping the
operands is neither needed nor advisable.
Regression tested on rv64gc and verified the new tests pass.
Pushing to the trunk.
jeff
commit 10cbfcd60f9e5bdbe486e1c0192e0f168d899b77
Author: Jeff Law
Date: Wed Mar 6 09:
On 3/7/24 07:27, Sam James wrote:
'python' on some systems (e.g. SLES 15) might be Python 2. Prefer python3,
then python, then python2 (as the script still tries to work there).
contrib/ChangeLog:
* dg-extract-results.sh: Check for python3 before python. Check for
python2 last.
OK. An
The issue here is the code we emit for mode-switching can change when -g
is added to the command line. This is caused by processing debug notes
occurring after a call which is the last real statement in a basic block.
Without -g the CALL_INSN is literally the last insn in the block and the
Not sure why nobody's taken care of this yet. Under certain
circumstances python may be needed if you're building a RISC-V compiler.
Here's what I've checked in. Happy to adjust if folks want to wordsmith
it further.
Jeffcommit 7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178
Author: jlaw
Date:
With Jakub's twiddle to the forward propagation pass, the assembly code
for pr59533-1.c has returned to its previous state. Thus I've reverted
my patch which adjusted the expected output.
Jeffcommit 6f7d000fcacef31a6947f95021e445c846170f92
Author: jlaw
Date: Sat Mar 9 21:33:47 2024 -0700
So as I mentioned in the BZ, the case of
t = MIN_EXPR (A, B)
where we know something about the relationship between A and B can be
trivially handled by some existing code in DOM. That existing code
would simplify when A == B. But by testing GE and LE instead of EQ we
can cover more cases wi
Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
positive triggered by loop unrolling.
As I speculated a couple years ago, we could eliminate the comparisons
against bogus pointers. Consider:
[local count: 30530247]:
if (last_12 != &MEM [(void *)"aa" + 3B])
On 3/10/24 3:05 PM, Andrew Pinski wrote:
On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
positive triggered by loop unrolling.
As I speculated a couple years ago, we could eliminate the comparisons
against
601 - 700 of 15555 matches
Mail list logo
