In a session investigating unexpected fallout from a change, I
noticed reload needs one operand being a register to make an
informed decision. It can happen that there's just a constant
and a memory operand, as in:
(insn 668 667 42 104 (parallel [
(set (mem:SI (plus:SI (reg/v/f:SI
This flips the default for the errata handling for an old version
(TL;DR: workaround: no multiply instruction last on a cache-line).
Newer versions of the CRIS cpu don't have that bug. While the impact
of the workaround is very marginal (coremark: less than .05% larger,
less than .0005% slower)
I'm taking advantage of CRIS being a lesser important target and as
such not subject to the constraints of GCC being in stage 4.
I'm applying this set of CRIS-specific changes that don't have much
expected effect on generated code.
1: cris: Don't default to -mmul-bug-workaround
Avoid the
> From: Richard Sandiford
> Hans-Peter Nilsson via Gcc-patches writes:
> > The mystery isn't so much that there's code mismatching comments or
> > intent, but that this code has been there "forever". There has been a
> > function reg_classes_intersect_p
I'm not seriously submitting this patch for approval. I just thought
it'd be interesting to some people, at least those maintaining ports
still using reload; I know it's reload and major ports don't really
care about that anymore. TL;DR: scroll down for the mystery part.
The *benevolent*
> From: Jonathan Wakely
> Date: Sun, 30 Jan 2022 18:06:28 +0100
> On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson wrote:
> > > From: Jonathan Wakely
> > > But there is nothing target-specific in that code, so it
> > > should be fine to disable them f
(I had to add separation between your reply and mine in the
quoted parts; you may be aware.)
> From: Jonathan Wakely
> Date: Sun, 30 Jan 2022 09:32:08 +0100
> On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++,
> mailto:libstdc%2b...@gcc.gnu.org>> wrote:
> >
These tests have always been failing for my cris-elf
autotester running a simulator; they take about 20 minutes
each, compared to the timeout of 720 seconds, doubled
because they timed out in another simulator setup.
They are the *only* libstdc++ tests that timeout for my
setup so I thought
> From: Jason Merrill via Gcc-patches
> Date: Fri, 17 Dec 2021 04:26:55 +0100
> C++14 changed the definition of 'aggregate' to allow default member
> initializers, but such classes still need to be considered "non-POD for the
> purpose of layout" for ABI compatibility with C++11 code. It seems
> From: Jonathan Wakely via Gcc-patches
> Date: Wed, 19 Jan 2022 02:03:58 +0100
> Tested powerpc64le-linux, powerpc-aix, pushed to trunk.
>
>
> This fixes a testsuite failure
I'm guessing the actual number is in the tens.
> on AIX.
...and by the looks of it, some 60 regressions (as counted
> From: Patrick Palka via Gcc-patches
> Date: Sun, 16 Jan 2022 19:06:48 +0100
> We're going to use the fast_float library in our (compiled-in)
> floating-point std::from_chars implementation for faster and more
> portable parsing of binary32/64 decimal strings.
>
> The single file
Not seeing anyone doing the obvious one-up, so JFTR:
On Mon, 10 Jan 2022, David Malcolm via Gcc wrote:
> On Mon, 2022-01-10 at 17:13 +0100, FX wrote:
> > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c
>
> The purpose of these asm tests is to verify that the analyzer doesn't
> get confused by various
> From: Jeff Law via Gcc-patches
> Date: Wed, 12 Jan 2022 16:58:50 +0100
> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov
> > wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via
> From: Jeff Law via Gcc-patches
> Date: Wed, 12 Jan 2022 16:58:50 +0100
> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov
> > wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via
rnal error messages;
they were more readable without these garments, if only slightly so.
2022-01-11 Hans-Peter Nilsson
* config/cris/cris.c: Quote identifiers in parameters to error
and internal_error, and remove extraneous spaces with punctuation.
* config/cr
k (error-prone) grep-and-eyeball in config/ shows this was the
only file missing the parenthesis. This lets cris-elf configured with
--enable-checking=yes,extra,rtl survive make all-gcc.
2022-01-11 Hans-Peter Nilsson
* config/cris/cris.c (cris_postdbr_cmpelim): Parenthesize
paramet
> From: Richard Sandiford via Gcc-patches
> Date: Thu, 6 Jan 2022 15:48:01 +0100
> If an allocno A in an inner loop L spans a call, a parent allocno AP
> can choose to handle a call-clobbered/caller-saved hard register R
> in one of two ways:
>
> (1) save R before each call in L and restore R
...instead of attribute "noinline".
For cris-elf, testsuite/gcc.dg/sibcall-3.c and sibcall-4.c "XPASS",
without sibcalls being implemented. On inspection, recurser_void2 is
set to be an assembly-level alias for recurser_void1 as in
".set _recurser_void2,_recurser_void1" for both these cases.
The change at r12-4790 should have done the same change for
CRIS as was done for powerpc64*-*-*. (Probably MMIX too but
that may have to wait until the next weekend.)
Committed.
gcc/testsuite:
* gcc.dg/uninit-pred-9_b.c: Correct last adjustment, for CRIS.
---
On Mon, 8 Nov 2021, Maciej W. Rozycki wrote:
> On Sun, 7 Nov 2021, Hans-Peter Nilsson wrote:
> > (I thought you'd use 6cb68940dcf9 and do the same for VAX.)
>
> I could, easily, but being confined to gcc/config/cris I don't expect it
> to be included in the build let alon
Since r12-5056-g3439657b0286, there has been a regression in
test results; an additional 100 FAILs running the g++ and
libstdc++ testsuite on cris-elf, a newlib target. The
failures are linker errors, not finding a definition for
getentropy. It appears newlib has since 2017-12-03
declarations of
> From: "Maciej W. Rozycki"
> Date: Wed, 3 Nov 2021 14:53:58 +0100
> gcc/
> PR middle-end/103059
> * reload.c (find_reloads_address_1): Also accept the ASHIFT form
> of indexed addressing.
> (find_reloads): Adjust accordingly.
> ---
> gcc/reload.c |9
> From: "Maciej W. Rozycki"
> Date: Wed, 3 Nov 2021 14:53:58 +0100
> gcc/
> PR middle-end/103059
> * reload.c (find_reloads_address_1): Also accept the ASHIFT form
> of indexed addressing.
> (find_reloads): Adjust accordingly.
> ---
> gcc/reload.c |9
On Sun, 7 Nov 2021, Maciej W. Rozycki wrote:
> On Fri, 5 Nov 2021, Hans-Peter Nilsson wrote:
>
> > > I was trying to chase another target I could use to regression-test this
> > > with that does do scaled indexed addressing while still using old reload.
> > &
On Wed, 3 Nov 2021, Maciej W. Rozycki wrote:
> Correct a `vax-netbsdelf' target regression ultimately caused by commit
> c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
> LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
> in jump threading registry.")
On Wed, 20 Oct 2021, Richard Biener via Gcc-patches wrote:
> This maps -ftrapv to -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error,
Isn't that UBSAN target-dependent, i.e. not supported on all
targets, whereas -ftrapv is just about universally supported?
I.e. isn't this
On Fri, 1 Oct 2021, Nelson Ribeiro via Gcc wrote:
> Hello.
>
> Firstly I want to apologize for this long post, but in a way this post also
> is meant for documenting the work that I have done hunting down this issue.
> Secondly I must say that I do not have much insights on the GCC internals,
>
On Sat, 25 Sep 2021, Hu Jialun wrote:
> Hello,
>
> Sorry for bumping it again but I guess it was getting overlooked.
>
> I am very junior with mailing list open source contributions so please feel
> free to point out if I have inadvertantly done something in an incorrect way.
>
> The archive of
> From: Martin Liaka
> Date: Wed, 8 Sep 2021 09:29:52 +0200
> On 9/7/21 22:41, Hans-Peter Nilsson wrote:
> > With r12-3379, the testsuite got such a fatal syntax error,
> > causing the gcc test-run to abort at (e.g.):
>
> Thank you for the fix! I haven't noticed
(Committed as obvious.)
Dejagnu is unfortunately brittle: a syntax error in a
directive can abort the test-run for the current "tool"
(gcc, g++, gfortran), and if you don't check for this
condition or actually read the stdout log yourself, your
tools may make you believe the test was successful
> From: Bernhard Reutner-Fischer
> Date: Thu, 12 Aug 2021 09:03:50 +0200
> On Thu, 12 Aug 2021 00:09:21 +0200
> Hans-Peter Nilsson via Fortran wrote:
>
> > I had a file-path to sources with the substring "new" in it,
> > and (only) this test regressed compa
I had a file-path to sources with the substring "new" in it,
and (only) this test regressed compared to results from
another build without "new" in the name.
The test does
! { dg-final { scan-tree-dump-times "new" 4 "original" } }
i.e. the contents of the tree-dump-file .original needs to match
Adding to the growing list, for autotester accounting purposes.
FWIW I see this fails for m68k too:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712395.html
and moxie:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712389.html
and pru:
A simulator can easily spend more than 10 minutes running this
test-case, and the default timeout is at 5 minutes. Better allow
even slower machines; use 4 as the factor.
Regarding relative runtime numbers (very local; mmixware simulator for
mmix-knuth-mmixware): test01 and test05 finish
Commit r12-432, rewriting the dg-stuff, reverted the
adjustment for mmix-knuth-mmixware that I added in r11-2335.
(See those commits for context.)
Hopefully this variant will age better, just skipping it
with a trivial extra line less prone to pile-on. (Not much
is won by covering this generic
Looks like MMIX is the "correct target" too (cf. 2f6bdd51cfe15)
and from
https://gcc.gnu.org/pipermail/gcc-testresults/2021-July/710188.html
it seems powerpc-ibm-aix7.2.3.0 is too, but I've not found
other targets failing.
gcc/testsuite:
PR middle-end/101674
*
I guess the best way to describe these operands, at least for MMIX, is
"ballast". Some targets seem to drag along one or two of the incoming
pattern operands through the rtl passes and not dropping them until
assembly output. Let's stop doing that for MMIX. There really are
*two* unused
An old itch being scratched: the documentation lies; it's not "the
number of registers used as operands", unless the target makes a
special arrangement to that effect, and there's nothing in the guts of
gcc setting up or assuming those semantics.
Instead, see calls.c:expand_call, variable
This bug made me dive into some of the murkier waters of gcc, namely
the source of operand 2 to the "call" pattern. It can be pretty
poisonous, but is unused (either directly or later) by most targets.
The target function_arg (and function_incoming_arg), can unless
specially handled, cause a
Commit r12-2534 was incomplete and (by inspection derived from
an MMIX build) failing for targets without an insn for
compare_and_swap for pointer-size objects, IOW for targets for
which "ATOMIC_POINTER_LOCK_FREE != 2" is true:
x/gcc/libstdc++-v3/src/c++17/memory_resource.cc: In member function
On Wed, 30 Jun 2021, Eli Zaretskii via Gcc-patches wrote:
> > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> > From: Martin Li?ka
> > Date: Wed, 30 Jun 2021 12:11:03 +0200
> > > 4. Menus lost the short descriptions of the sub-sections. Example:
> > >
> > >*
On Wed, 30 Jun 2021, Eli Zaretskii via Gcc-patches wrote:
> > Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> > From: Martin Li?ka
> > Date: Wed, 30 Jun 2021 12:11:03 +0200
> > > 4. Menus lost the short descriptions of the sub-sections. Example:
> > >
> > >*
On Tue, 15 Jun 2021, Martin Sebor wrote:
> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> >
> > > On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
>
On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> > > My objection is to making our policies and tools more restrictive
> > > than they need to be. We shouldn't expect everyone to study whole
> >
On Wed, 2 Jun 2021, Gerald Pfeifer wrote:
> On Tue, 1 Jun 2021, Segher Boessenkool wrote:
> > We haven't had Sender: for a while now.
>
> "a while now" was about four(?) hours when you sent that yesterday. :-)
>
> I know since I still had been using that and was looking for all my
> missing
> From: Hans-Peter Nilsson
> CC: "gcc-patches@gcc.gnu.org"
> Date: Thu, 3 Jun 2021 18:12:25 +0200
> I'd
> prefer to have the patch above committed sooner than the
> conclusion of that discussion. (If you don't get to it,
> I'll do it, after a round of testing.)
> From: Kewen.Lin
> Date: Thu, 3 Jun 2021 07:45:57 +0200
> on 2021/6/2 Hans-Peter Nilsson wrote:
> >> From: Kewen Lin
> >> Date: Wed, 2 Jun 2021 07:04:54 +0200
> >
> >> gcc/ChangeLog:
> >>
> >>* config/cris/cris.md (*addi_r
> From: Kewen Lin
> Date: Wed, 2 Jun 2021 07:04:54 +0200
> gcc/ChangeLog:
>
> * config/cris/cris.md (*addi_reload): Fix empty split condition.
> ---
> gcc/config/cris/cris.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/cris/cris.md
On Tue, 18 May 2021, Richard Earnshaw wrote:
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> > >
> > > Normally we expect the gimple optimizers to fold away comparisons that
> > > are always
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
>
> Normally we expect the gimple optimizers to fold away comparisons that
> are always true, but at some lower optimization levels this is not
> always the case, so the back-end has to be able to generate correct
> code in these cases.
> From: Segher Boessenkool
> Date: Sun, 16 May 2021 18:18:17 +0200
> On Sat, May 15, 2021 at 08:44:29PM +0200, Hans-Peter Nilsson via Gcc-patches
> wrote:
> > When eyeballing the r12-440 / bd1cd0d0e0fe / "Remove
> > CC0" commit, I noticed parts that cou
Ok to commit?
When eyeballing the r12-440 / bd1cd0d0e0fe / "Remove
CC0" commit, I noticed parts that could be improved.
Regarding the first change: at first I thought that just
removing the word "better" was the best choice, as the
compared part (cc0) was apparently removed, but the
paragraph
Committed as obvious.
The typo here, is obviously mistaken removal of lines next
to a line that was validly removed. Targets affected are
those with a delay-slot *and* defining TARGET_FLAGS_REGNUM.
In-tree, a git-grep says the only ones matching are CRIS,
h8300 and visium. The code removal has
Unfortunately it appears that this PR is on nobody's radar.
Xfailing it to get an arguably artificial zero regression
state (since T0=2007-01-05) helps my autotester.
Caveat: the pass/fail state of this test, as long as stack
alignment isn't adjusted, is dependent on the alignment of
the stack at
See PR99212. Now, cris-elf isn't the only target for which this line
shows a failure; pru-unknown-elf and m68k-unknown-linux-gnu are two
others. I'll leave adjustments to the respective maintainers, but
trivially appending more triplets should work: no extra bracketing needed.
A specific
Forgot to mention: no differences in cris-elf test-results at r11-7500.
Beware, tm.texi doesn't tell the whole story: a defined
HARD_FRAME_POINTER_REGNUM (different to FRAME_POINTER_REGNUM) is
supposed to make work easier for reload, being able to easily
tell actual frame-pointer-related
On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>
> The test expects shrink-wrapping of the fsqrt call, but that will only
> occur when there is a usable sqrt insn.
>
> Arrange for dejagnu to add the options that enable the sqrt insn, if
> one is available, and to skip the test otherwise.
>
>
> H-P,
When DWARF_FRAME_REGISTERS isn't defined, the default is
FIRST_PSEUDO_REGISTER which means that if you add faked
registers to the port, used for frame-context related
elimination, room is allocated for them in the register
context used for frame-unwinding, which is wasteful because
they're
It's been 32 ever since the CRIS port was committed.
A TODO-item of mine has been to check whether the
non-default setting of MAX_FIXED_MODE_SIZE makes sense
wrt. performance and/or code-size with a modern gcc. It
doesn't, so it goes. The setting is now the default,
GET_MODE_BITSIZE (DImode)
See comment.
* gcc.target/cris/pr93372-1.c: Adjust expected assembler result
to allow an eliminated stack-frame.
---
gcc/testsuite/gcc.target/cris/pr93372-1.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-1.c
Tested cris-elf and x86_64-linux to eliminate the edit being
fatfingered.
The test is still failing and is a regression on master for
cris-elf: the remedy for (all) other targets wasn't
sufficient. I'm not myself going to put any effort into it
(debug-information being different enough for a
> From: Hans-Peter Nilsson
> Date: Tue, 2 Mar 2021 23:58:08 +0100
> > From: Jeff Law
> > Date: Tue, 2 Mar 2021 23:39:27 +0100
> > On 2/24/21 10:17 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > > Ok to commit? Or is a renaming patch appe
On Wed, 3 Mar 2021, Jonathan Wakely wrote:
> For int, there shouldn't be any need to force the alignment. I don't
> think any ABI supported by GCC allows int members to be aligned to
> less than __alignof__(int).
(sizeof(int) last)
The CRIS ABI does as in default packed, and ISTR there was some
ope-from="jeffreya...@gmail.com";
> x-sender="postmas...@mail-il1-f172.google.com";
> x-conformance=sidf_compatible
> Old-Content-Type: multipart/alternative;
> boundary="_000_08d773b4a6cd248fc44aa1877542afabgmailcom_"
> Content-Type: text/plain
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote:
> > On Feb 26 2021, Thiago Macieira wrote:
> > > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
> > >> On Feb 26 2021, Thiago Macieira via Gcc-patches
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> ints can be used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
> ---
> libstdc++-v3/include/std/barrier | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff
Since 97d6161f6a7fa712 / r11-7370 "libstdc++: More efficient
days from date" I see an additional 81 testsuite-errors for
cris-elf, with this in g++.log for one randomly picked
regressing test:
FAIL: g++.dg/cpp1y/pr57640.C -std=c++2a (test for excess errors)
Excess errors:
I don't know what it is that ix86, x86_64, Solaris and
apparently CRIS has in common here.
According to
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html
m68k-unknown-linux-gnu is also in that bunch, but since
there's a *-*-solaris* in the target specifier and also m68k
vs.
The gcc.misc-tests/outputs.exp tests can take some effort to
digest.
Navigating and debugging causes for failing tests here isn't
helped by the existence of tests with duplicate names.
Let's stop that from happening. This requires that test-run
output is actually reviewed, as Tcl errors don't
The outputs.exp tests check what temporary files are created
and left behind with e.g. -save-temps.
Additional files are created in presence of @file option.
Adding an -I or -L option causes *another* temporary file to
appear. I take it that's deliberate, as there are tests for
that behavior.
All the bits were there, used with a pre-existing
-mmax-stackframe=SIZE which unfortunately seems to lack
test-cases.
Note that the early-return for -mno-prologue-epilogue (what
some targets call -mnaked) is deliberately not clearing
current_function_static_stack_size, as I consider that
> From: Martin Sebor
> Date: Tue, 23 Feb 2021 02:07:59 +0100
> On 2/22/21 5:48 PM, Hans-Peter Nilsson wrote:
> > Looking at commit de05c19d5fd6, that adjustment to these
> > tests apparently assumed that the testsuite is run (only) on
> > targets where structure memor
Looking at commit de05c19d5fd6, that adjustment to these
tests apparently assumed that the testsuite is run (only) on
targets where structure memory layout has padding as per
"natural alignment". For cris-elf, a target with no padding
in structure memory layout, these tests have been failing
See gcc/config/newlib-stdint.h, where targets that have
LONG_TYPE_SIZE == 32, get __INT32_TYPE__ defined to "long
int".
All these tests have "typedef __INT32_TYPE__ int32_t;".
Thus the tests fail for 32-bit newlib targets due to related
warning messages being matched to "aka int" where the
Also, tweak the scan-assembler regexps to include a tab,
lest they may spuriously match file-paths in the emitted
assembly code, should some be added at some point. And, add
"mul", "move" and (non-addi-)"add" to insns that shouldn't
appear.
Committed.
gcc/testsuite:
*
Needed coverage for that *addi_mul pattern. Committed.
gcc/testsuite:
* gcc.target/cris/biap-mul.c: New test.
---
gcc/testsuite/gcc.target/cris/biap-mul.c | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/cris/biap-mul.c
diff --git
Ever since the canonicalization clean-up of (mult X (1 << N)) into
(ashift X N) outside addresses, the CRIS addi patterns have been
unmatched. No big deal.
Unfortunately, nobody thought of adjusting reloaded addresses, so
transforming mult into a shift has to be a kludged for when reload
decides
> From: Richard Biener via Gcc-patches
> Date: Thu, 18 Feb 2021 11:12:26 +0100
> On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches
> wrote:
> >
> > If we're not going to eliminate the clz, it's better for the
> > comparison to use that resu
If we're not going to eliminate the clz, it's better for the
comparison to use that result than its input, so we don't
extend the lifetime of the input. Also, an additional use
of the result is more likely cheaper than a compare of the
input, in particular considering that the clz may have made
> From: Bernd Edlinger
> Date: Tue, 16 Feb 2021 08:35:04 +0100
> Oops,
>
> thanks for fixing this problem.
>
> To my excuse I would like to note,
> that the script error does not happen on x86_64-pc-linux-gnu,
> probably it would only happen when a file is left over.
Sorry but that just
Committed as obvious. Please be more careful; this typo
should have been obvious in "make check" output as below.
Commit-log:
---
Fix typo for istarget in "is_target hppa*-*-hpux*", yielding
an error running the test-suite for any target not matching
powerpc*-*-aix*
On Tue, 19 Jan 2021, Hans-Peter Nilsson wrote:
> On Tue, 19 Jan 2021, Richard Sandiford wrote:
>
> > Hans-Peter Nilsson writes:
> > > On Tue, 19 Jan 2021, Jakub Jelinek wrote:
> > >> I think "IRA target" is not the right term, all targets are IRA
On Tue, 19 Jan 2021, Richard Sandiford wrote:
> Hans-Peter Nilsson writes:
> > On Tue, 19 Jan 2021, Jakub Jelinek wrote:
> >> I think "IRA target" is not the right term, all targets are IRA targets,
> >> but only some are using LRA and others use the old rel
On Tue, 19 Jan 2021, Jeff Law wrote:
> On 1/19/21 5:36 AM, Hans-Peter Nilsson wrote:
> > I'll call the suggested testsuite target-supports predicate
> > "lra" (thanks Andreas S.; of course!), to be used negated here.
> Well we could do that.? But instead I propose we
On Tue, 19 Jan 2021, Jakub Jelinek wrote:
> On Mon, Jan 18, 2021 at 11:50:56PM -0500, Hans-Peter Nilsson wrote:
> > On Mon, 18 Jan 2021, John David Anglin wrote:
> > > The hppa target is a reload target and asm goto is not supported on
> > > reload targets.
>
On Mon, 18 Jan 2021, John David Anglin wrote:
> The hppa target is a reload target and asm goto is not supported on reload
> targets.
> Skip failing tests on hppa.
IIUC the preferred term is "IRA target" or maybe "non-LRA
target", as opposed to "LRA target". The tests fail for
cris-elf too,
> From: Luis Machado via Gcc-patches
> Date: Mon, 11 Jan 2021 15:58:43 +0100
> This seems to have broken the builds on AArch64-Linux Ubuntu 18.04.
>
> make[2]: Entering directory 'binutils-gdb-master-bionic/libiberty'
> rm -f ./libiberty.a pic/./libiberty.a noasan/./libiberty.a
> ar --plugin
> From: Martin Sebor via Gcc-patches
> Date: Fri, 4 Dec 2020 01:49:51 +0100
> On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > Belatedly, here's an updated version, using Martin Sebor's
> > suggested wording from
> > "https://gcc.gnu.org/piperm
, but only for those that are the same size as a scalar
type.
There's an equal-sounding section (Volatiles) in extend.texi,
but this seems a more appropriate place, as specifying the
behavior of a standard qualifier.
gcc:
2020-12-02 Hans-Peter Nilsson
Martin Sebor
PR
On Tue, 24 Nov 2020, Eric Botcazou wrote:
> > I'm intested in any notes, however vague, on that matter. I was
> > a bit surprised to see that myself...that is, after fixing
> > *some* related regressions, like the one in combine. (Did I
> > actually miss something?)
>
> My recollection for the
On Mon, 23 Nov 2020, Jeff Law wrote:
> On 11/23/20 9:49 PM, Hans-Peter Nilsson wrote:
> > On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
> >> This is the primary patch for cc0 removal on the H8 port.? It doesn't
> >> have any of the optimization work and many p
On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
> This is the primary patch for cc0 removal on the H8 port.? It doesn't
> have any of the optimization work and many patterns are simply disabled
> at this time.? It's working well enough to not regress the testsuite.
>
> The H8 is similar to
On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> Done. Here is the updated patch.
Hi. I see a test-case for this kind of construct:
int foo __attribute__((__used__, __section__ (".bar"))) = 42;
and IIUC that it's handled as I'd hope (setting "R" on the named
section, not another derived
On Sun, 15 Nov 2020, Maciej W. Rozycki wrote:
> Hi,
>
> In the course of my recent VAX backend modernisation effort
Hi. That reminds me that VAX is "still" a cc0 target.
Are you aware of anyone planning on that level of modernization?
More than a year ago, there was a major heads-up that all
On Wed, 4 Nov 2020, H.J. Lu wrote:
> .retain is ill-defined. For example,
>
> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> static int xyzzy __attribute__((__used__));
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.c"
> .text
> .retain xyzzy <
On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 1:56 PM Hans-Peter Nilsson wrote:
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> >
> > > On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson
> > > wrote:
> > > >
> > > > On Wed, 4 Nov 20
On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson wrote:
> >
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson
> > > wrote:
> > > >
> > > > On Wed, 4
On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson wrote:
> >
> > 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 bar
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
301 - 400 of 1365 matches
Mail list logo
