On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote:
> I personally do not see the problem with the .retain attribute, however
> if it is going to be a barrier to getting the functionality committed, I
> am happy to change it, since I really just want the functionality in
> upstream sources.
>
> If a
On Tue, 3 Nov 2020, Nathan Sidwell wrote:
> Here is the implementation of C++20 modules that I have been developing on the
> devel/c++-modules branch over the last few years.
Ow.
> I have bootstrapped and tested on:
> x86_64-linux
> aarch64-linux
> powerpc8le-linux
> powerpc8-aix
>
> Iain
On Thu, 29 Oct 2020, Richard Sandiford via Gcc-patches wrote:
> Hongtao Liu via Gcc-patches writes:
> > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
> > wrote:
> >>
> >> Hongtao Liu via Gcc-patches writes:
> >> > Hi:
> >> > For inline asm, there could be an operand like (not (mem:)),
On Thu, 22 Oct 2020, Alan Modra via Gcc-patches wrote:
Hi!
> On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote:
> > Anyway:
> >
> > + || (outer_code == AND
> > + && rs6000_is_valid_2insn_and (x, mode)))
> > {
> > *total =
On Fri, 23 Oct 2020, Arnaud Charlet wrote:
> > > For future reference, TRT for this kind of problem is to
> > > autoconf for the right struct field name, using AC_CHECK_MEMBER
> > > or AC_CHECK_MEMBERS (then use e.g. #if HAVE_STAT_ST_MTIM / #if
> > > HAVE_STAT_ST_MTIMESPEC, definitely not #if
On Wed, 21 Oct 2020, Iain Sandoe wrote:
> Arnaud Charlet wrote:
>
> > > This patch breaks bootstrap on Darwin platforms.
> > >
> > > Pierre-Marie de Rodat wrote:
> > >
> > > > The modification file time precision now defined by OS.
> > > >
> > > > Tested on x86_64-pc-linux-gnu, committed on
Please excuse a comment from the gallery:
On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches
> wrote:
> > 2020-08-13 Raoni Fassina Firmino
> >
> > gcc/ChangeLog:
> > * config/rs6000/rs6000.md
On Thu, 1 Oct 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Re-enable pr94600-{1,3}.c tests for arm ]
>
> On 10/1/20 7:38 AM, Hans-Peter Nilsson wrote:
> > On Wed, 30 Sep 2020, Tom de Vries wrote:
> >> I've analyzed the compilation on strict-a
On Wed, 30 Sep 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Require non_strict_align in
> pr94600-{1,3}.c ]
>
> On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Sep 2020, Tom de Vries wrote:
> >
> >> Hi,
> >>
> >> Wit
On Thu, 24 Sep 2020, Tom de Vries wrote:
> Hi,
>
> With the nvptx target, we run into:
> ...
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
On Wed, 23 Sep 2020, Ilya Leoshkevich via Gcc wrote:
> Hi,
>
> "Defining How to Split Instructions" in gccint states the following:
>
> The preparation-statements are similar to those statements that are
> specified for define_expand ... Unlike those in define_expand, however,
> these statements
> From: Eric Botcazou
> Date: Fri, 11 Sep 2020 13:09:48 +0200
> > @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> > condition, lose = 1;
> >mark_set_resources (trial, , 0, MARK_SRC_DEST_CALL);
> >mark_referenced_resources (trial, , true);
> > + if
> From: Hans-Peter Nilsson
> Date: Fri, 11 Sep 2020 13:24:18 +0200
> > > @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> > > condition, lose = 1;
> > >mark_set_resources (trial, , 0, MARK_SRC_DEST_CALL);
> > >
> From: Eric Botcazou
> CC: "gcc-patches@gcc.gnu.org"
> Date: Fri, 11 Sep 2020 13:09:48 +0200
> received-spf: None (smtp1.axis.com: no sender authenticity information
> available from domain of postmas...@mail-wr1-f54.google.com) identity=helo;
> client-ip=209.85.221.54;
On Thu, 3 Sep 2020, Alexandre Oliva wrote:
> On Sep 3, 2020, Segher Boessenkool wrote:
> > For instructions that inherently set a condition code register, the
> > @code{compare} operator is always written as the first RTL expression of
> > the @code{parallel} instruction pattern.
>
>
On Mon, 7 Sep 2020, Hu, Jiangping wrote:
> Hi, H-P
>
> Thanks for comment.
>
> > On Sat, 29 Aug 2020, Hu Jiangping wrote:
> >
> > > This patch add 'cd' command before 'make check-gcc' command
> > > when run the testsuite on selected tests.
> >
> > No, don't do that; those targets work fine from
On Tue, 1 Sep 2020, Bin.Cheng via Gcc-patches wrote:
> > Great idea! With explicitly specified -funroll-loops, it's bootstrapped
> > but the regression testing did show one failure (the only one):
> >
> > PASS->FAIL: gcc.dg/sms-4.c scan-rtl-dump-times sms "SMS succeeded" 1
> >
> > It exposes
On Sat, 29 Aug 2020, Hu Jiangping wrote:
> This patch add 'cd' command before 'make check-gcc' command
> when run the testsuite on selected tests.
No, don't do that; those targets work fine from the toplevel
too, and then include the language libs.
> Richard and I agree it would be good for
On Thu, 3 Sep 2020, Hans-Peter Nilsson wrote:
> IMHO stepping into the .md really isn't helpful. Even a pattern
> name in a comment in the generated code would be better.
...and JFTR, yes I noticed there is, or rather line indicator
for example /path/to/mmix.md:211 above gen_adddi3 i
On Thu, 27 Aug 2020, Pip Cet via Gcc wrote:
> I may be missing an obvious workaround, but it seems we currently emit
> a #line directive when including lines from machine description files
> in C files, but never emit a second directive when switching back to
> the generated C file. This makes
On Wed, 26 Aug 2020, Pip Cet via Gcc wrote:
> Note that whether there is a CC-setting variant depends not just on
> the "cc" attr, but also on the precise operands for some values of the
> "cc" attr, which requires hairy C code to figure out.
>
> Is it possible to avoid this situation by avoiding
On Wed, 26 Aug 2020, Jeff Law wrote:
> On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote:
> > On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> > > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > > > The post-reload splitter in
On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > The post-reload splitter introduces the clobber. The wiki
> > suggests that approach if most insns clobber REG_CC, perhaps because of
> > the missed optimizations you
be
able to use the existing machinery in this patch.
BTW, I happened to notice that bugs here are also somewhat more
visible than your ordinary wrong-result bug. :)
> Hans-Peter Nilsson via Gcc-patches writes:
> > Originally I thought to bootstrap this patch on MIPS and SPARC
> >
On Thu, 20 Aug 2020, Senthil Kumar Selvaraj wrote:
> What I didn't understand was the (set-attr "cc")
> part - as far I can tell, this results in (set_attr "cc_enabled" ...) in
> all of the three substituted patterns, so I wondered why not just have
> (set_attr "cc_enabled" ...) in the original
On Wed, 19 Aug 2020, Senthil Kumar Selvaraj wrote:
>
> Hans-Peter Nilsson writes:
>
> > On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> >> As you can deduce from the (set_attr "cc" ..), only constraint
> >> alternatives 0,2,3 and 6 clobber
On Sun, 16 Aug 2020, Pip Cet via Gcc wrote:
> For example, here's what I currently have:
>
> (define_expand "mov"
> [(parallel [(set (match_operand:MOVMODE 0 "nonimmediate_operand" "")
>(match_operand:MOVMODE 1 "general_operand" ""))
> (clobber (reg:CC REG_CC))])]
> ...)
On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> As you can deduce from the (set_attr "cc" ..), only constraint
> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.
Yes, I recognize that.
> My first version of the port adds a post-reload splitter that adds a
> (clobber
Originally I thought to bootstrap this patch on MIPS and SPARC
since they're both delayed-branch-slot targets but I
reconsidered, as neither is a TARGET_FLAGS_REGNUM target. It
seems only visium and CRIS has this feature set, and I see no
trace of visium in neither newlib nor the simulator next
Committed as obvious.
The bitfield-struct t0 in gcc.dg/pr94600-1.c ..-4.c is assigned through
a pointer that is a (volatile-and-pointer-)cast literal, so gcc doesn't
need to be otherwise told that the address is aligned. But, variants
pr94600-5.c ..-8.c are assigned through a "volatile t0 *",
> From: Segher Boessenkool
> Date: Fri, 17 Jul 2020 02:05:19 +0200
> On Tue, Jul 14, 2020 at 04:33:42PM -0500, Segher Boessenkool wrote:
> > > If combine only did lower-cost combinations (perhaps with
> > > Richard Sandifords lower-size-when-tied suggestion), I guess
> > > this wouldn't happen.
(Back from vacation, found that this had an unanswered question,
quoted last.)
> From: Segher Boessenkool
> Date: Tue, 14 Jul 2020 23:58:05 +0200
> Hi!
>
> On Mon, Jul 06, 2020 at 04:01:54AM +0200, Hans-Peter Nilsson via Gcc-patches
> wrote:
> > Most comments, inclu
Committed.
The test makes sense only for targets that return the
"struct { int a, b, c; }" in registers (not in memory).
Starting a skip-construct is IMHO better than another iteration of
that obscuring "{ ... && { ! mytarget-*-* } }". New targets can just
append to the list without additional
Committed.
IV (loop2_unroll) doesn't like the mmix port. The feelings are mutual.
For mmix, gcc.dg/pr30957-1.c fails (runtime and rtl-scan) for these
reasons:
- IV doesn't handle the zero-extension-by-shift sequences generated by
middle-end (expr.c:convert_mode_scalar) in the absence of
Committed.
It looks like gcc.dg/loop-9.c kind-of works as sentinel for sane
move-instruction generation for a port.
Looking at the
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "Decided"
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "without introducing a new
temporary register"
it
Committed.
This test fails for mmix for (almost) the same reason it would fail
for e.g. mipsel-elf: the end-condition of the loop tests against a
register set to a constant, and that register is (one of) the
"unexpected IV" moved out of the loop "without introducing a new
temporary register" and
Committed.
The tests gcc.dg/tree-ssa/loop-1.c and gcc.dg/weak/typeof-2.c
assume this setting and are as a consequence riddled with
exceptions for targets that actually do yield better code when
calling through a register rather than repeatedly the same
symbol. Nonetheless, defining it makes
Committed.
Whoops. When un-disabling visibility support for mmix, I missed that
some of the newly enabled tests were FAILs, for not emitting .hidden
for references to external declarations. This takes care of
gcc.dg/visibility-14.c .. -19.c, and gcc.dg/visibility-23.c.
gcc:
*
Committed.
These FAILs for mmix showed up as regressions for me due to a
flaw in the btest-gcc.sh test-results-accounting: a bug was
recently fixed regarding the naming of dump-files so the names
are again correct. To wit, parts of the tests that were
UNRESOLVED, due to missing dump-files, and
Again, the variables are "privatized" using ASM_PN_FORMAT for MMIX (but
apparently not for other targets) and the line to match looks like:
D.1427 = VEC_PERM_EXPR ;
gcc/testsuite:
* gcc.dg/tree-ssa/vector-4.c: Adjust for mmix.
--- gcc/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c.orig Mon
The variables are "localized" using ASM_PN_FORMAT for MMIX and the
lines to match look like:
Deleted dead store: y::4 = y;
Deleted dead store: x::3 = x;
gcc/testsuite:
* gcc.dg/tree-ssa/ssa-dse-26.c: Adjust for mmix.
--- gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c.orig Wed Feb 12
Looking at the dump and the test, I guess all "64-bit targets" fail
the test for the reasons seen in the comment just above the dg-final,
whose last two lines make it to the patch context. Maybe the xfail
target list can be shortened by removing most targets and use just
"lp64". That doesn't
The expression of interest looks like "e_5 = a::0_1 + b::1_2;" for
mmix-knuth-mmixware, while other targets have a "." instead of the
"::". ISTM the most useful change here is not to disable the test,
but to add an optional character in the matched expression to match
the "extra" ":". Also
In 2012 e2769e908a915ebbc/r192344, I added the following lines, that I
now delete. I've changed my mind: ELF-related targets based on gas,
that support only static linking, have .hidden "for free", regardless
of the visibility of the hidden object in the linked executable. No
regressions for
Committed.
The label of interest here is "b.0_2" for
e.g. x86_64-pc-linux-gnu but "b::1_2" for mmix-knuth-mmixware.
The test seems to be of some interest for mmix (hey, gcc
open-coded 128-bit integer support behind my back!) so I didn't
want to just disable it. I also didn't want to obscure the
Committed.
With the dejagnu status-wrapper, there's a reference to write in
each executable, which for mmix in newlib has a reference to a
variable defined in open, which for mmix in newlib has a
reference to sprintf (oops!) and the dependency-chain goes on;
ad finitum there's a reference to
Funny that default_asm_output_ident_directive isn't the default...
Anyway, since dot-pseudos like .ident are treated as comments by
mmixal, there's nothing lost compatibilitywise by supporting it.
If mmix-knuth-mmixware had included elfos.h this'd have been the
default. There might be enough
Committed.
No dots in labels for MMIX: internal labels instead contain ":".
gcc/testsuite:
* c-c++-common/pr56493.c: Allow ":" in label, for mmix.
--- gcc/gcc/testsuite/c-c++-common/pr56493.c.orig Mon Jan 13 22:30:46 2020
+++ gcc/gcc/testsuite/c-c++-common/pr56493.cSat Jul 25
Committed.
There's no reason anyone would want to use the "patchable function"
feature for MMIX and also no reason to exclude those tests. For MMIX,
the NOP equivalent is SWYM ("swymming" is a healthy exercise).
Text-wise, making the tests pass by adjusting the regexp, is shorter,
and it seems
Another missed attribute-visibility-requirement, causing a failure for
e.g. mmix-knuth-mmixware. Committed as obvious.
gcc/testsuite:
* c-c++-common/builtin-has-attribute-4.c: Require visibility.
--- gcc/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c.orig Mon Jan
13
mmix-knuth-mmixware is a NO_DOT_IN_LABEL target, so it gets a "_"
instead of the "." in the identifier of interest. Also tested and
compared to the output for cris-elf which is "regular" regarding
labels: there are no "false positive" identifiers there. The "." in a
TCL bracket expression
Regular ELF label definitions for this test-case, matched by the
regexps, e.g.:
/* { dg-final { scan-assembler-times {(?n)^_*bar[.$_]constprop[.$_]0:} 1 } } */
typically look like this:
bar_constprop.0:
For MMIX, they look like this:
bar_constprop::0IS @
I think it's better to just skip
I missed updating the line-number when adding that dg-skip-if.
Committed as obvious.
* gcc.dg/cdce3.c: Update matched line-number.
diff --git a/gcc/testsuite/gcc.dg/cdce3.c b/gcc/testsuite/gcc.dg/cdce3.c
index 71aea9b..601ddf0 100644
--- a/gcc/testsuite/gcc.dg/cdce3.c
+++
MMIX has two stacks; the regular one using register $254 as a
convention and the register-stack, pushed and popped by call
instructions (usually). The decision to only report the stack usage
of the regular stack (and not of the register stack) may be updated,
perhaps the sum is better. This
Apparently local labels end up in the gimple dumps. For mmix,
local labels that for other targets look like ".LC0" or "LC.0"
instead look like "LC:0". Committed as obvious.
gcc/testsuite:
* gcc.dg/const-uniq-1.c: Adjust scanned pattern for mmix.
---
The test is gated on effective-target hard_float but what it
really requires is a sqrtf insn (SFmode, not DFmode). (It
indeed passes for mmix-knuth-mmixware if the sqrtf is changed to
sqrt and float to double; there is a DFmode sqrt insn.)
Committed.
gcc/testsuite:
* gcc.dg/cdce3.c:
Committed as obvious, fixing one failure for mmix-knuth-mmixware.
gcc/testsuite:
* gcc.dg/pr87485.c: Require scheduling.
--- gcc/gcc/testsuite/gcc.dg/pr87485.c.orig Mon Jul 20 03:50:14 2020
+++ gcc/gcc/testsuite/gcc.dg/pr87485.c Mon Jul 20 03:50:31 2020
@@ -2,6 +2,7 @@
/* { dg-do
The sole purpose of not providing pseudos and forcing use of
TARGET_ASM_INTEGER is to arrange for assembly output that people can,
instead of using gas, usefullt feed to mmixal (Knuth's assembler). It
uses pseudos with slightly different semantics (BYTE, WYDE, TETRA,
OCTA). Nice when it works,
Another trivial one, committed.
gcc/testsuite:
* gcc.dg/attr-copy-6.c: Require visibility.
--- gcc/gcc/testsuite/gcc.dg/attr-copy-6.c.orig Mon Jan 13 22:30:47 2020
+++ gcc/gcc/testsuite/gcc.dg/attr-copy-6.c Sun Jul 19 05:44:12 2020
@@ -2,6 +2,7 @@
{ dg-do compile }
{
Long-standing FAIL remedied; committed. Maybe better to list
the targets that *do* support arbitrary frame access?
gcc/testsuite:
* gcc.dg/Wno-frame-address.c: Skip for cris and mmix.
--- gcc/gcc/testsuite/gcc.dg/Wno-frame-address.c.orig Mon Jan 13 22:30:47 2020
+++
On Sat, 18 Jul 2020, Jakub Jelinek wrote:
> On Sat, Jul 18, 2020 at 05:04:56PM -0400, David Edelsohn via Gcc-patches
> wrote:
> > H-P,
> >
> > After your patch to the testsuite, the cpp/pragma-eof.c testcase is
> > failing on all targets. Would you please investigate and fix?
>
> That is
Committed as obvious. Gets rid of a spurious failure for mmix.
gcc/testsuite:
* c-c++-common/cpp/pragma-eof.c: Require fopenmp.
diff --git a/gcc/testsuite/c-c++-common/cpp/pragma-eof.c
b/gcc/testsuite/c-c++-common/cpp/pragma-eof.c
index c72be80..9537470 100644
---
(All patches are committed.)
Delayed-branch-slot-filling a.k.a. reorg or dbr, often causes
opportunities for more compare-elimination than were visible for
the cmpelim pass. With cc0, these were caught by the
elimination pass run in "final", thus the missed opportunities
is a regression. A
Comparing to the cc0 version of the CRIS port, I ran a few
microbenchmarks, for example gcc.c-torture/execute/arith-rand.c,
where there's sometimes an addition between an operation of
interest and the test on the result.
Unfortunately this patch doesn't remedy all the performance
regression for
Getting tired of:
make[1]: Entering directory 'x/gccobj/gcc'
Makefile:2682: warning: overriding recipe for target 'gt-cris.h'
xx/gcc/gcc/config/cris/t-cris:29: warning: ignoring old recipe for target
'gt-cris.h'
I'm just going to assume it is just stale cruft no longer (if
ever) needed since
Whoops. This little gem had the effect of making the output
operand (0) constraints disappear but not the input operand (1)
constraints for define_subst:ed patterns, probably because
there's another (match_dup 1) in the output template (not
investigated).
That went surprisingly unnoticed until I
Together with the combine.c patch posted (but remaining a WIP),
all coremark performance regressions are gone for CRIS, compared
to cc0. Unfortunately, I looked further, and found some issues
when running gcc.c-torture/execute/arith-rand.c and
arith-rand-ll.c, in those functions and the
Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on
releases/gcc-10 gave me:
[releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the whole of a
compound object.
Date: Sun Jul 5 20:50:52 2020 +0200
9 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 22:50:43 +0200
> I'll make a simpler patch. Thanks!
You're welcome. So, you'll take care of the updated patch
yourself?
(I'll wait a month before sending an update either way.)
brgds, H-P
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 22:23:59 +0200
> Hi!
>
> On Tue, Jul 07, 2020 at 02:50:09AM +0200, Hans-Peter Nilsson wrote:
> > > On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> > > > TL;DR: fixing a mi
> From: Richard Biener
> Date: Tue, 7 Jul 2020 09:00:22 +0200
> On Tue, Jul 7, 2020 at 6:03 AM Hans-Peter Nilsson via Gcc-patches
> wrote:
> >
> > We say very little about reads and writes to aggregate /
> > compound objects, just scalar objects (i.e. assignments
> From: Martin Sebor
> Date: Wed, 8 Jul 2020 02:09:37 +0200
> On 7/6/20 10:02 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > We say very little about reads and writes to aggregate /
> > compound objects, just scalar objects (i.e. assignments don't
> > cause reads)
> From: Hans-Peter Nilsson
> Date: Tue, 7 Jul 2020 06:01:37 +0200
> gcc:
> PR middle-end/94600
> * expr.c (expand_constructor): Make a temporary also if we're
> storing to volatile memory.
Oops, I dropped attribution here, but this patch is by Rich
We say very little about reads and writes to aggregate /
compound objects, just scalar objects (i.e. assignments don't
cause reads). Let's lets say something safe about aggregate
objects, but only for those that are the same size as a scalar
type.
There's an equal-sounding section (Volatiles) in
The store to the whole of each volatile object was picked apart
like there had been an individual assignment to each of the
fields. Reads were added as part of that; see PR for details.
The reads from volatile memory were a clear bug; individual
stores questionable. A separate patch clarifies
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 01:42:47 +0200
(Regarding is_just_move in combine.c.)
> But it is *not* supposed to be the same as single_set.
>
> > I checked the original commit, c4c5ad1d6d1e1e a.k.a r263067 and
> > it seems parallels-as-sets were just overlooked and that
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 01:42:47 +0200
TL;DR: recognize a parallel with a clobber of TARGET_FLAGS_REGNUM?
> Hi!
>
> On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> > TL;DR: fixing a misdetection of w
> From: Richard Sandiford
> Date: Mon, 6 Jul 2020 11:48:25 +0200
> Out of interest, how do the results change if we still allow the
> combination for equal costs if the new sequence is shorter than
> the original? I think that still counts as "cheaper than",
> but maybe I'm too RISC-centric.
Most comments, including the second sentence in the head comment
of combine_validate_cost, the main decision-maker of the combine
pass, refer to the function as returning true if the new
insns(s) *cheaper* than the old insns, when in fact the function
returned true also if the cost was the same.
e swing between
different functions is larger than this difference; to be dealt
with separately.
Tested cris-elf, x86_64-linux, powerpc64le-linux, 2/3 through
aarch64-linux (unexpectedly slow).
Ok to commit?
2020-07-06 Hans-Peter Nilsson
PR target/93372
* gcc/combine.c (is_
(The previous patch was also committed, FWIW, I just forgot to
mention it.)
Combine likes to change a zero-extension / and + shift as seen
in the test-case source to a logical shift followed by an and of
the shifted mask, like:
lsrq 1,r0
and.d 0x7f,r0
This was observed in the hot loop of
Yet another misnumbering of operands: the asserted non-overlap
would be the only benign operands overlap. "Suddenly" exposed
by g++.dg/cpp0x/pr81325.C when testing unrelated changes
affecting register allocation.
To wit, operands 2 and 1 are the only ones that are safe for
overlap, it's only
The code in cris_select_cc_mode for selecting CC_NZmode was
partly inconsistent with the comment and partly seemed
ambiguous. I couldn't find a reason why I qualified selection
of CC_NZmode on the setting operation once a matching user was
spotted, so I just removed that. The cris.c update was
When cleaning out the multitude of patterns with unknown
coverage, this one went the way of the bathwater. It's use is
barely common enough to mark when diffing libgcc, and has a
minimal impact on performance-testsuites. Anyway, reinstated
with a couple of test-cases. It's suboptimal of
Hi! Good to see you "back"!
On Sat, 20 Jun 2020, Roger Sayle wrote:
> Thanks to you too. Alas, my credentials from the CVS days of GCC almost
> certainly don't
> work any more (in git),
My guess is that your credentials are fine (possibly modulo FSF
assignment issues) if it wasn't for the ssh
On Tue, 9 Jun 2020, Jeff Law via Gcc-patches wrote:
> On Tue, 2020-06-09 at 17:26 +0200, Jakub Jelinek wrote:
> > On Tue, Jun 09, 2020 at 09:18:25AM -0600, Jeff Law wrote:
> > > On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> > > > On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via
> From: Alexandre Oliva
> Date: Tue, 2 Jun 2020 13:29:03 +0200
> Hello, Anthony, H-P,
>
> On May 27, 2020, Anthony Green wrote:
>
> > Hans-Peter Nilsson via Gcc-patches writes:
> >> And here's an improper bug report.
> >>
> >> One of the co
> From: Alexandre Oliva
> Date: Wed, 27 May 2020 16:30:07 +0200
> On May 26, 2020, Hans-Peter Nilsson wrote:
>
> >> Here's a proper patch submission.
>
> > And here's an improper bug report.
>
> :-)
>
> Thanks, H-P,
>
> > xgcc: error: : No
> From: Alexandre Oliva
> Date: Tue, 26 May 2020 15:52:57 +0200
> On May 26, 2020, Richard Biener wrote:
>
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
>
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
>
> Here's a proper patch submission.
And
Not that anyone would notice, except a few maintainers of
targets with delay-slots, and only if the first patch causes
fallout, as the others only touch stuff related to the CRIS target.
The 23 commits have been posted previously, around Jan-Feb. For
reference:
2c2d405 dbr: Filter-out
On Fri, 1 May 2020, Segher Boessenkool wrote:
> On Mon, Apr 27, 2020 at 05:01:34PM -0500, will schmidt wrote:
> > On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> > > +unsigned long
> > > +load_us_offset1 (unsigned char *p)
> > > +{
> > > + return *(unsigned short *)(p
> From: Jeff Law via Gcc-patches
> Date: Tue, 5 May 2020 17:05:01 +0200
> On Wed, 2020-02-12 at 07:47 +0100, Hans-Peter Nilsson wrote:
> > I just rebased and updated the vendors/axis branch
> > axis/cris-decc0 with the following commits, which should bring
> > back
> From: Jeff Law
> Date: Tue, 5 May 2020 16:52:07 +0200
> On Mon, 2020-02-10 at 17:55 +0100, Hans-Peter Nilsson wrote:
> > * config/cris/cris.c (cris_reduce_compare): New function.
> > * config/cris/cris-protos.h (cris_reduce_compare): Add prototype.
> > * con
On Sat, 25 Apr 2020, Eric Botcazou wrote:
> > I very much disagree with this. I think my approach was possibly the
> > only viable one, and definitely the most sensible one for this target.
> > Not only is there nothing meaningful to be gained from separating cc
> > setters and users on m68k given
On Tue, 21 Apr 2020, Gustavo Romero wrote:
> Hi Hans,
Hi Gus,
> On 4/14/20 12:33 AM, Hans-Peter Nilsson wrote:
> > Sadly this patch doesn't fix PR bootstrap/87252; I just checked
> > against f8e72b8d9f2:f81653ba8c1:2dd4ceacd8b (truncated from
> > LAST_UPDATED; I do
On Mon, 6 Apr 2020, Gustavo Romero via Gcc-patches wrote:
> Currently an use of get() method of dump_context singleton in optinfo
> framework causes a new class to be instantiated, which calls the singleton
> dtor when the class is destroyed, freeing memory that is referenced after
> free() is
On Mon, 6 Apr 2020, Gustavo Romero via Gcc-patches wrote:
> When GCC9 is built with older GCC (4.7) on FreeBSD 32-bit on PowerPC an ICE
> is generated on stage 1 when selftests are performed.
>
> After an investigation the root cause was traced to an unnecessary and
> harmful instantiation of a
On Wed, 1 Apr 2020, Martin Li?ka wrote:
> On 4/1/20 7:01 AM, Hans-Peter Nilsson wrote:
> > On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> > > Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> > > detection.") and fix a typo in
On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> that causes compilation errors like:
>
> .../include/plugin-api.h:162:2: error: #error "Could not detect
On Wed, 25 Mar 2020, Jeff Law via Gcc-patches wrote:
The patch you sent, as well as what you committed as r10-7383,
was just a ChangeLog entry.
> Bootstrapped on sh4-linux-gnu and sh4eb-linux-gnu. Regression testing in
> progress (won't finish for ~12 hours). No new test as it's covered by
401 - 500 of 1367 matches
Mail list logo
