On Tue, 24 Mar 2020, Hans-Peter Nilsson wrote:
> The new argument is default 0, so make use of that: do not patch
> all those files where 0 is fine.
Oops, I was tricked by the comment; it's not actually "default 0"
in the C++ sense. And you have an overloaded function with
d
Please excuse some cheap points:
On Mon, 23 Mar 2020, kamlesh kumar via Gcc-patches wrote:
> Attached patch fixes.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877.
> ChangeLog Entry.
>
> 2020-03-23 Kamlesh Kumar
>
> * rtl.h : Defined Tuple for bundling rtx, mode and
>
On Sat, 29 Feb 2020, Jeff Law wrote:
>
> Wow, I think I wrote the v850 port back in circa 1997 and this bug has been
> latent all this time. Vlad's IRA changes twiddled register allocation in just
> the right way to expose this bug.
>
> I'm not sure what I was thinking, but apparently I made a
On Tue, 11 Feb 2020, Richard Biener wrote:
> Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
> diff --git a/gcc/testsuite/gcc.dg/pr93661.c b/gcc/testsuite/gcc.dg/pr93661.c
> new file mode 100644
> index 000..e311ba545c4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr93661.c
>
* config/cris/cris.c (cris_select_cc_mode): Return CC_NZmode for
NEG too. Correct comment.
* config/cris/cris.md ("neg2"): Rename from
"neg2".
While gcc seems to prefer transforming tests on the result of
reversible operations, into tests on the original, it also can
work with the destination,
* config/cris/cris-modes.def (CC_ZnN): New CC_MODE.
* config/cris/cris.c (cris_rtx_costs): Handle pre-split bit-test
* config/cris/cris.md (ZnNNZSET, ZnNNZUSE): New mode_iterators.
(znnCC, rznnCC): New code_attrs.
("*btst"): Iterator over ZnNNZSET instead of NZVCSET. Remove
obseolete comment.
* config/cris/cris.md
("si3"):
Rename from "si3".
("clzsi2"):
Rename from "clzsi2".
("bswapsi2"):
Rename from "bswapsi2".
("*uminsi3"): Rename from "*uminsi3".
Enables dropping of compares with zero of the result, through
any CCmode substitution.
---
gcc/config/cris/cris.md | 8
1 file
* config/cris/cris.md ("*expanded_andsi"):
Rename from "*expanded_andsi".
("*iorsi3"): Similar from "*iorsi3".
Decorate "cc" attribute to make "cc".
("*iorhi3"): Similar from "*iorhi3".
("*iorqi3"): Similar from "*iorqi3".
("*expanded_andhi"): Similar from
"*expanded_andhi". Add quick cc-setting
* config/cris/cris.md ("*adddi3"): Rename from "*adddi3".
cris: Enable 32-bit addition to set condition codes.
("*subdi3"): Similarly from "*subdi3".
("*addsi3"): Similarly from "*addsi3".
("*subsi3"): Similarly from "*subsi3".
("*addhi3"): Similarly from "*addhi3" and decorate the
"cc" attribute
* config/cris/cris.md
("extendsi2"):
Rename from "extendsi2".
("zero_extendsi2"):
Similar, from "zero_extendsi2".
Enable dropping of compares with zero of the result, through the
three CCmode substitutions and the cmpelim pass.
---
gcc/config/cris/cris.md | 4 ++--
1 file changed, 2
* config/cris/cris.md ("anz", "anzvc", "acc"): New define_subst_attrs.
("movhi"): Rename from
"movhi". Rename "cc" attribute to "cc".
("movqi"): Similar from
"movqi". Correct contents of, and rename "cc" attribute to
"cc".
("*b"): Rename from "b".
("*b"): Rename from "b".
("*b"): Rename from
* config/cris/cris.md ("cc"): Comment on new use.
("cc_enabled"): New attribute.
("enabled"): Make default fall back to cc_enabled.
("setnz", "ccnz", "setnzvc", "ccnzvc", "setcc", ""): New
default_subst_attrs.
("setnz_subst", "setnzvc_subst", "setcc_subst"): New default_subst.
Prepare for cmpelim pass to eliminate redundant compare insns.
* config/cris/cris-modes.def: New file.
* config/cris/cris-protos.h (cris_select_cc_mode): Declare.
(cris_notice_update_cc): Remove left-over declaration.
* config/cris/cris.c (TARGET_CC_MODES_COMPATIBLE): Define.
(cris_select_cc_mode,
* config/cris/cris.md ("movsi"): For a zero-source post-reload,
generate a clobberless variant.
("*mov_fromzero_split"): New split.
("*mov_fromzero"): New insn.
A separated follow-up to the previous change: Also emit moves
from zero as not clobbering condition-codes.
---
gcc/config/cris/cris.md
* config/cris/cris.md ("movsi"): For memory destination
post-reload, generate clobberless variant.
("*mov_tomem_split"): New split.
("*mov_tomem"): New insn.
("enabled", mov_tomem_enabled): Define and use to exclude "x" ->
"Q>m" for less-than-SImode.
In preparation for compare-elimination (for it
* config/cris/cris.h (REVERSIBLE_CC_MODE): Define to true.
For some reason (like a buglet in the user in jump.c), defining this makes
a beneficial difference in ledf2, thus this is separated to its own commit.
Also, add comment on (not defining) REVERSE_CONDITION.
---
gcc/config/cris/cris.h | 3
* config/cris/cris.c (TARGET_FLAGS_REGNUM): Define.
This made a whole lot of difference regarding regressions in the
delay-slot filling. Before this, comparing __lshrdi3 for v10
before/after decc0ration and other nearby functions was worse by
several missing delay-slot fills; now down to 1.
PR target/93372
* config/cris/cris.md (zcond): New code_iterator.
("*cbranch4_btstq"): New insn_and_split.
As the added FIXME says, the new insn_and_split generates only a
small subset of the bit-tests that can be matched by "*btst" and
that were emitted by the undecc0rated cris.md at
I just rebased and updated the vendors/axis branch
axis/cris-decc0 with the following commits, which should bring
back compare-elimination results to that of cc0 on master.
With the exception of the bit-test patterns (btst / btstq which
is more of a "combine" matter), everything is centered
I was using ira-conflicts.c:print_hard_reg_set with a local
patch to gdbinit.in in a debug-session, and noticed the
erroneous output. I see there's an almost identical function in
ira-color.c and on top of that, there's another function by the
same name and with similar semantics in
On Thu, 6 Feb 2020, Segher Boessenkool wrote:
> Instead of "git am" I had "patch -p1 <",
May I suggest "git apply" instead of the good old patch program.
(The "-p1" is of course built-in and you never have to do a
manual roll-back or separate --dry-run pass.)
brgds, H-P
Random spotting. Exposes the missed benefit for delay-slot
filling of a splitter for indexed addressing mode (the [rN+M]
one). To be considered for common instructions and perhaps only
for suitable M; at least +-63 is obious (when there's a register
available) as both the original and the add
PR target/93372
* gcc.target/cris/pr93372-3.c, gcc.target/cris/pr93372-4.c,
gcc.target/cris/pr93372-6.c, gcc.target/cris/pr93372-7.c,
gcc.target/cris/pr93372-9.c, gcc.target/cris/pr93372-10.c,
gcc.target/cris/pr93372-11.c, gcc.target/cris/pr93372-12.c,
gcc.target/cris/pr93372-13.c,
* gcc.target/cris/pr93372-2.c, gcc.target/cris/pr93372-5.c,
gcc.target/cris/pr93372-8.c: New tests.
These tests fails miserably both at being an example of cc0
eliminating compare instructions, and post-cc0-CRIS at showing a
significant improvement. They're here to track suboptimal
comparison
This test was separated from the posted and approved patch named
"dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs"
and applied: it doesn't fail yet. It differs from the posted
version in that function "g" is commented-out; see the added
comment.
---
To simplify separating the cc0-specific xfails, let's have an
effective-target.
This likely fits all targets.
---
gcc/testsuite/gcc.target/cris/cris.exp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/testsuite/gcc.target/cris/cris.exp
* config/cris/cris.c (cris_reduce_compare): New function.
* config/cris/cris-protos.h (cris_reduce_compare): Add prototype.
* config/cris/cris.md ("cbranch4", "cbranchdi4", "cstoredi4")
(cstore4"): Apply cris_reduce_compare in expanders.
The decc0ration work of the CRIS port made me look closer
Stuff I broke out from the CRIS decc0ration work;
compare-decanonicalization and tests that would be regressions
in a future timeline, but fixed later on.
Besides the first patch, nothing you'd normally care about, and
perhaps for people doing CC0 work: the test-cases and the cc0
effective-target
Committed as obvious.
gcc:
* md.texi (Define Subst): Match closing paren in example.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index cec74ea78..66c5eea3b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -10545,7 +10545,7 @@ generated with the following @code{define_subst}:
> From: Segher Boessenkool
> Date: Mon, 27 Jan 2020 23:52:21 +0100
> Hi!
>
> On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> > I intend to put back as many as I find use for, of those
> > anonymous patterns in a controlled manner, with self-conta
> From: Jeff Law
> Date: Fri, 20 Sep 2019 17:38:38 +0200
Hi. I'm not going to question
> The first step in that process is to drop support for cc0.
but could you please elaborate on...
> [cc0 support in gcc core]
> code is broken in various ways,
> particularly WRT exceptions.
...that last
Compared to the cc0 version, I noticed a regression in
delay-slot-filling for CRIS for several functions in libgcc with
a similar layout, one being lshrdi3, where with cc0 all
delay-slots were filled, as exposed by the test-case. I ended
up including the thankfully-small lshrdi3 as-is, for
gcc:
* target.def (flags_regnum): Also mention effect on delay slot filling.
* doc/tm.texi: Regenerate.
Noticed the "hard way" dealing with performance fallout for the
CRIS decc0ration.
Previously, the documentation blurb only mentioned an effect on
compare elimination. The technical contents
PR target/93372
* gcc.target/cris/sync-2s.c, gcc.target/cris/sync-2i.c: XFAIL.
Unfortunately, some assembly-code-matches have to be xfailed
until the port is improved to use other than straight
compare-insns.
---
gcc/testsuite/gcc.target/cris/sync-2i.c | 5 +++--
gcc:
* config/cris: Remove shared-library and CRIS v32 support.
Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
Essentially everything is gone, including functions and
target-specific definitions and most obvious knock-on effects,
like removing unused functions and
gcc:
* config/cris/t-elfmulti: Remove crisv32 multilib.
Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
gcc/config/cris/t-elfmulti | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/config/cris/t-elfmulti b/gcc/config/cris/t-elfmulti
index
468..4ac2ee45fbf 100644
--- a/gcc/testsuite/gcc.dg/sibcall-10.c
+++ b/gcc/testsuite/gcc.dg/sibcall-10.c
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson*/
-/* { dg-do run { xfail { { amdgcn*-*-* cris-*-* crisv32-*-* csky-*-* h8300-*-*
hpp
ifnc \\\$r9-\\\$r10-\\\$r11-\\\$r12" } } */
/* Sanity check for asm register operands in syscall failed for
- cris-axis-linux-gnu due to regmove bug.
+ cris-axis-linux-gnu due to a regmove bug.
Hans-Peter Nilsson . */
extern void lseek64 (int, long long, int);
diff --git a/gcc/testsuite/g
libgcc:
* config.host: Remove support for crisv32-*-* and cris*-*-linux.
* config/cris/libgcc-glibc.ver, config/cris/t-linux: Remove.
Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
libgcc/config.host | 9 -
libgcc/config/cris/libgcc-glibc.ver
..000
--- a/gcc/config/cris/linux.h
+++ /dev/null
@@ -1,150 +0,0 @@
-/* Definitions for GCC. Part of the machine description for CRIS.
- Copyright (C) 2001-2020 Free Software Foundation, Inc.
- Contributed by Axis Communications. Written by Hans-Peter Nilsson.
-
-This file is part of GCC
gcc:
* config.gcc: Remove support for crisv32-*-* and cris-*-linux*.
Or really, move from the obsolete targets section, to
unsupported targets section, and remove crisv32-*-* and
cris-*-linux* from the rest.
---
gcc/config.gcc | 28 ++--
1 file changed, 2 insertions(+),
This patchset is applied to vendors/axis/cris-decc0.
The intent is to apply it myself to master, once master opens
for stage 1, before the planned destruction of cc0 targets that
was announced last September. I've earlier obsoleted the
crisv32-* and cris-*-linux* sub-ports as no longer relevant
> From: "Richard Earnshaw (lists)"
> Date: Tue, 21 Jan 2020 14:36:32 +0100
> Correction, the branch should be named /, so the push
> should be
>
> git push vendors/ /
>
> For example, for the ARM vendor, the push would be
>
> git push vendors/ARM ARM/
>
> R.
>
> > will work as expected.
>
gcc/testsuite:
* gcc.target/cris/asm-v8.S, gcc.target/cris/inasm-v8.c,
gcc.target/cris/sync-1.c: Apply effective_target_march_option.
Oops. A few stragglers, same as recent update: differing
-march=... options is an error, noticed with e.g.
"make check
> From: Hans-Peter Nilsson
> Date: Tue, 21 Jan 2020 02:47:57 +0100
> (I did not use gcc-git-customization.sh or git-fetch-vendor.sh before
> XX, so there's presumably nothing to clean up.)
Bah; "before 24b178184f260a6ec1516cfb8bb8876874a078a7".
brgds, H-P
> From: "Richard Earnshaw (lists)"
> Date: Fri, 17 Jan 2020 12:21:07 +0100
> As far as possible, I've made the script automatically restructure any
> existing fetch or push lines that earlier versions of the scripts may
> have created - the gcc-git-customization.sh script will convert all
>
With march_option in place, here's the rest. (And yes, that
cris-linux line in the last context goes away in the patchset
putting that target down.)
gcc/testsuite:
* gcc.dg/torture/pr26515.c (cris*-*-*): Conditionalize
-march=v10 option on target ! march_option.
*
libgcc:
* config/cris/arit.c (DS): Apply attribute __fallthrough__.
Without this, there are, for each compilation of arit.c, 30ish
occurrences of "this statement may fall through
[-Wimplicit-fallthrough=]", for lines that look like
case 32: DS; case 31: DS; case 30: DS; case 29: DS;
TL;DR: See subject. Verbosity follows.
The git transition is mostly for the better. Thanks to those
investing time and effort. There's always fallout. Here's one
dustcloud:
In the distant past with svn, there messages to gcc-cvs@ were
somewhat like git show --stat, i.e. without the actual
hangeLog b/gcc/ChangeLog
index 423899d3988..b4c45a45087 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2020-01-17 Hans-Peter Nilsson
+
+ * config.gcc : Add crisv32-*-* and cris-*-linux*
+
2020-01-17 Richard Sandiford
* gimplify.c (gimplify_return_expr): Use pol
testsuite:
* lib/target-supports.exp (effective_target_march_option): New.
I see no (other) way to, depending on the absence of an option,
add an option for a specific target. Specifically, I don't see
how to do this with dg-skip-if and its friends.
For gcc.dg/torture/pr26515.c and
100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-17 Hans-Peter Nilsson
+
+ * gcc_update : Use git log "--pretty=tformat:%p:%t:%H",
+ not "--pretty=%p:%t:%H".
+
2020-01-16 Andreas Schwab
* gcc-git-customization.sh: Avoi
Ping. I personally would prefer it being on gcc.gnu.org but
will arrange for an alternative, if that for some reason would
be inappropriate. FWIW, the PDF weighs in at a whopping 474174
bytes.
> From: Hans-Peter Nilsson
> Date: Mon, 11 Nov 2019 13:10:41 +0100
>
> > From:
On Thu, 7 Nov 2019, Egeyar Bagcioglu wrote:
> On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> > On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
> > > +proc dg-require-target-object-format { args } {
> > > +if { [gcc_target_object_format] == [lindex $args 1] } {
> > > + return
> From: Gerald Pfeifer
> Date: Sun, 10 Nov 2019 14:53:23 +0100
> Hi H-P,
>
> it appears this download is gone. Do you have an alternate location?
Wha...? No, not at the moment.
>http://ftp.axis.se/pub/users/hp/pgccfd/;>
While I could certainly enter a ticket and hope to get it
> From: Richard Sandiford
> Date: Tue, 1 Oct 2019 09:51:51 +0200
> Hans-Peter Nilsson writes:
> > My autotester for cris-elf complains about a build-breaking
> > commit in the revision range (working:breaking) 276299:276359
> Fixed as below. I also belate
> From: Richard Sandiford
> Date: Wed, 11 Sep 2019 21:02:26 +0200
> This series of patches introduces some classes and helpers for handling
> multiple ABIs in the same translation unit. At the moment "ABI" maans
> specifically the choice of call-clobbered registers
[...]
> The series also
I didn't expect this to be contested and not by a frequent
reviewer, but since you took the time to express yourself, I'll
do the same.
On Wed, 21 Aug 2019, Segher Boessenkool wrote:
> On Tue, Aug 20, 2019 at 04:05:40PM -0400, Hans-Peter Nilsson wrote:
> > On Tue, 20 Aug 2019, Jose E.
On Tue, 20 Aug 2019, Jose E. Marchesi wrote:
> > On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > > --- a/configure
> > > +++ b/configure
> Yeah by mistake I used a Debian patched autoconf 2.96. Will regenerate
> using vanilla autoconf for subsequent versions of
> From: Richard Biener
> Date: Tue, 13 Aug 2019 09:50:34 +0200
> 2019-08-13 Richard Biener
>
> PR testsuite/91419
> * lib/target-supports.exp (natural_alignment_32): Amend target
> list based on BIGGEST_ALIGNMENT.
> (natural_alignment_64): Targets not
> From: Jakub Jelinek
> Date: Sat, 10 Aug 2019 12:12:46 +0200
> I ran the gcc/ subdirectory ChangeLogs through following script that doesn't
> seem to have false positives ATM
except one...
> # Date not separated from name by two spaces, but just one.
[...]
> # Email not wrapped in <>s.
> grep
Has there been a change of policy so it's a valid option to use
gcc/ChangeLog for testsuite changes? I was about to move a
semi-randomly spotted misplaced entry, and when checking if
there were others, I noticed that there's like tens of them, so
I thought better ask.
(IMHO it's confusing to
Thu, 06 Jun 2019 00:59:40 -0700 (PDT)
> References: <201906051938.x55jcssw016...@ignucius.se.axis.com>
> <18571728.MIQ1nkMWVm@polaris>
> From: Richard Biener
> Date: Thu, 6 Jun 2019 09:59:29 +0200
> Cc: Hans-Peter Nilsson ,
> GCC Patches
> Old-Content-Type
> Date: Thu, 6 Jun 2019 16:04:47 +0200
> From: Hans-Peter Nilsson
> When bitsizetype objects end
> up on the target, they use the actual Pmode and not the larger
> precision mode.
Oops, a half-way-done email slipped away, this part still needs
to be investigated.
I don't re
> From: Eric Botcazou
> Date: Wed, 05 Jun 2019 22:03:04 +0200
> > This issue exists, not just for targets that can have their
> > MAX_FIXED_MODE_SIZE more-or-less easily tweaked higher, but also
> > for the 'bit-container' targets where it *can't* be set higher.
> >
> > Let's please DTRT and
> From: Richard Biener
> Date: Wed, 29 May 2019 15:04:42 +0200
> On Tue, May 28, 2019 at 5:43 PM Hans-Peter Nilsson
> wrote:
> >
> > TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
> > MAX_FIXED_MODE_SIZE, search for the largest fitting size from
>
TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
MAX_FIXED_MODE_SIZE, search for the largest fitting size from
scalar_int_mode modes supported by the target using
targetm.scalar_mode_supported_p.
-
In initialize_sizetypes, MAX_FIXED_MODE_SIZE is used as an upper
limit to the
> From: Janne Blomqvist
> Date: Thu, 23 May 2019 23:43:23 +0300
> On Thu, May 23, 2019 at 5:21 AM Hans-Peter Nilsson
> wrote:
> >
> > There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
> > that on inspection was due to it having acquired a truncation
&g
This test regressed for cris-elf (testing in a simulator) with
the fixing of libstdc++/83237, as the part suggested to be
wrapped in #ifndef was *added* to the existing test and causes a
timeout. Tsk tsk. Please don't pile-on existing tests, instead
add a *separate* test-file.
>From what I
There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
that on inspection was due to it having acquired a truncation
call through the runtime. I updated that and the new tests that
had "Fortran runtime error: required ftruncate or chsize support
not present" messages in gfortran.log, ran
Ping, on behalf of Martin, CC:ing diagnostics maintainers.
On Fri, 3 May 2019, Martin Li?ka wrote:
> Hi.
>
> The patch prints all values requested in multiple --help options.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> From: Vladimir Makarov
> Date: Tue, 21 May 2019 17:05:50 -0400
> Yes, the patch is ok to commit. Thank you for working on the problem.
>
> It is hard to reproduce the same problem in LRA as LRA mostly follows
> IRA decisions.
>
> I'll probably do the analogous patch for LRA on this week.
I was looking into why I couldn't trivially move cris-elf to
"use init_array". It appeared that it wasn't the hooks into
that machinery that went wrong, but that a compiler bug is
plaguing __libc_init_array. It's been there since at least
4.7-era, hiding under the covers of the __init_array
On Tue, 14 May 2019, Richard Sandiford wrote:
> Several SVE patterns need define_insn_and_splits that generate the
> same insn_code, but with different operands. That's probably a
> niche requirement, but it's cropping up often enough on the ACLE
> branch that I think it would be good to have a
> Date: Tue, 30 Apr 2019 11:37:17 -0600
> From: Jeff Law
> On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
> > Here's the follow-up, getting rid of the observed
> > alignment-padding in execute/930126-1.c: the x parameter in f
> > spuriously being runtime-aligned to
Regarding this sometimes-add--latomic(-in-testsuite) that is
revisited:
When is it appropriate to make the user add -latomic to link
their program? Perhaps different answers for fortran and C++.
I'm guessing "always when using any atomic construct" for C.
I had a grep-look in gcc/doc before
> Date: Mon, 11 Feb 2019 10:22:12 +0100
> From: Jakub Jelinek
> Is PREFERRED_STACK_BOUNDARY what we want here? Shouldn't that be
> STACK_BOUNDARY, or PARM_BOUNDARY? Though, PARM_BOUNDARY on cris is 32...
Hm.
I wish there was a better distinction both in the code and in
peoples minds between
> Date: Mon, 11 Feb 2019 07:38:14 +0100
> From: Richard Biener
> >+ HOST_WIDE_INT min_parm_align
> >+= STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY;
>
> Shouldn't it be MIN (...) of BOTH?
That *does* seem logical... Take 2 as follows, in testing as
before.
Ok to
Spotted while in a recent gdb session. JFTR, not mine... Committed.
Index: ChangeLog
===
--- ChangeLog (revision 268759)
+++ ChangeLog (revision 268760)
@@ -1,3 +1,8 @@
+2019-02-11 Hans-Peter Nilsson
+
+ * config/cris
> Date: Mon, 11 Feb 2019 02:05:11 +0100
> From: Hans-Peter Nilsson
> Regtested on cris-elf, where it "introduces" gcc.dg/pr84877.c
Correction: "no regressions" (not introduced by this proposed
patch, I misread).
brgds, H-P
Here's the follow-up, getting rid of the observed
alignment-padding in execute/930126-1.c: the x parameter in f
spuriously being runtime-aligned to BITS_PER_WORD. I separated
this change because this is an older issue, a change introduced
in r94104 where BITS_PER_WORD was chosen perhaps because
> Date: Thu, 10 Jan 2019 00:06:01 +0100
> From: Jakub Jelinek
> 2019-01-09 Jakub Jelinek
>
> PR middle-end/84877
> PR bootstrap/88450
> * function.c (assign_stack_local_1): Revert the 2018-11-21 changes.
> (assign_parm_setup_block): Do the argument slot realignment
On Tue, 18 Dec 2018, Andi Kleen wrote:
> > Yes, take g++.dg/tree-prof/morefunc.C as an example:
> > - int i;
> > - for (i = 0; i < 1000; i++)
> > + int i, j;
> > + for (i = 0; i < 100; i++)
> > +for (j = 0; j < 50; j++)
> > g += tc->foo();
> > if (g<100) g++;
> > }
> > @@
On Tue, 18 Dec 2018, Uecker, Martin wrote:
> Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > > On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote:
> > > > Right. This is the classic example and
On Mon, 17 Dec 2018, Hans-Peter Nilsson wrote:
> On Mon, 17 Dec 2018, Wilco Dijkstra wrote:
> > H-P:
> > > So, changing from R18 to R11 for aarch64 seems right, as the
> > > latter is call-clobbered and the former is call-saved IIUC.
> >
> > The AArch
On Mon, 17 Dec 2018, Wilco Dijkstra wrote:
> H-P:
> > So, changing from R18 to R11 for aarch64 seems right, as the
> > latter is call-clobbered and the former is call-saved IIUC.
>
> The AArch64 ABI defines x18 as platform specific:
>
On Wed, 12 Dec 2018, Wilco Dijkstra wrote:
> I've not seen such an alternative implementation (-fno-trampolines is
> ignored on all targets I tried), but it wouldn't affect the ABI since you can
> only take the address of a nested function when you're the parent function.
Regarding the
> Date: Tue, 27 Nov 2018 23:25:55 +
> From: Jonathan Wakely
> This resolves a longstanding issue where the lock policy for shared_ptr
> reference counting depends on compilation options when the header is
> included, so that different -march options can cause ABI
> changes.
> [...]
Thank you
Hej!
On Sun, 25 Nov 2018, Krister Walfridsson wrote:
> On Sun, 25 Nov 2018, Maya Rashish wrote:
>
> > gcc/config.host | 4 ++
> > gcc/config/host-netbsd.c | 85
> > gcc/config/x-netbsd | 4 ++
> > 3 files changed, 93 insertions(+)
> > create
On Tue, 13 Nov 2018, Maciej W. Rozycki wrote:
> On Sun, 11 Nov 2018, Fredrik Noring wrote:
>
> > ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:71:1:
> > note: in expansion of macro ?COMPILER_CHECK?
> >71 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct
This patch should have no visible effect. It was approved in the BZ and
is what remains of PR54005. _M_i is declared "alignas(_S_alignment) _Tp
_M_i;" and is_lock_free is supposed to refer to the *type* not the
specific *object*. (Note how the actual address of the object is not
used in the
> Date: Fri, 21 Sep 2018 12:21:31 +0100
> From: Jonathan Wakely
> Here's the corrected patch, any objections to this?
Quite the contrary; LGTM.
brgds, H-P
> Date: Thu, 20 Sep 2018 15:22:23 +0100
> From: Jonathan Wakely
> On 20/09/18 15:36 +0200, Christophe Lyon wrote:
> >On Wed, 19 Sep 2018 at 23:13, Rainer Orth
> >wrote:
> >>
> >> Hi Christophe,
> >>
> >> > I have noticed failures on hypot-long-double.cc on arm, so I suggest we
> >> > add:
>
I tried to update newlib (from an old copy from couple of years ago),
but got curious regressions localized to tests related to ffs
handling:
--- regress.prev2018-09-13 18:49:04.130070398 +0200
+++ regress 2018-09-13 22:59:25.551637529 +0200
@@ -0,0 +1,5 @@
+gcc.sum
I've back-ported these two patches to the gcc-8-branch to
restore buildability. Tested at r264184, committed r264351.
PR target/85666
* config/mmix/mmix.c (mmix_assemble_integer): Handle byte-size
non-CONST_INT rtx:es using assemble_integer_with_op ".byte".
The mythical MMIX hardware engineers have wisely understood the
need to automatically disable speculation when a speculated
execution path transitions to kernel mode. There might be
mythical talk about using a bit in a configuration register to
enable even that, but that's just speculation and
Until location views (in gcc-8), there apparently was no need to
emit single bytes of data as anything but bare CONST_INTs,
neither actual data nor dwarf2 debug. With location views,
there's a field within dwarf2 records for inlined subroutines
that as assembly code looks as follows in context
It's IMO never a good idea to call leaf_function_p in port-specific
code. Sooner or later, you'll need that information in a context
where calling leaf_function_p is either a bad idea (it does a linear
walk over all emitted insns in a function) or invalid (called when
global context is within a
Nothing ever speculated here, move along... Regtested for
cris-elf, observing the maintenance-provoking test-cases now
passing.
PR target/86779
* config/cris/cris.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Redefine
to speculation_safe_value_not_needed.
Index:
These pthread_mutex_t were obviously meant to be
__gthread_mutex_t. See other declarations. Not being that,
broke cris-elf build at r264070, restored with this patch. Also
regtested on native x86_64-pc-linux-gnu.
I'm not sure know why no other bare-iron target saw this, but
perhaps it's
501 - 600 of 1367 matches
Mail list logo
