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, 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
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 (fegetroundsi):
On Thu, 3 Feb 2022, David Seifert via Gcc-patches wrote:
> On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > > * `-Werror` can cause issues when a more recent version of GCC
> > > compiles
> > > ? an older version:
> > >
On Fri, 11 Feb 2022, Jonathan Wakely via Gcc-patches wrote:
> diff --git
> a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> index c81344a20e4..25e5ce63b58 100644
> --- a/libstdc++-v3/testsuite/2
On Wed, 12 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag.
I'd love improvements in this area.
But this is a serious concern:
> gcov --conditions:
>
> 3: 17:vo
On Sat, 13 Aug 2022, mtsamis wrote:
> When using SWAR (SIMD in a register) techniques a comparison operation within
*within
> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is
> potential
> to rep
On Mon, 15 Aug 2022, Xi Ruoyao via Gcc-patches wrote:
> Can we make a final solution to this soon? Now the merge window of
> Linux 6.0 is closed and we have two Linux kernel releases not possible
> to be built with Binutils or GCC with new relocation types. This is
> just ugly...
>
> On Fri, 202
> 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
reinstate
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
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 Sandoe
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 globa
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, 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 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:
> .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 < Wha
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 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
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
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 cris-
changed, 6 insertions(+)
diff --git a/gcc/ChangeLog 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
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;
N
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.
* gcc.targ
> 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
> ve
> 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
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 RUNTESTFLAGS=--target_board=
> 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.
> >
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 (
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(+), 26
..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
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 |
;\\\.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/testsu
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
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 3c
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 argument
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/testsuite/gcc.target/cris/syn
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 is
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 simplic
> 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
> 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
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}:
""
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
* 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 a
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
b/gcc/testsuite/gcc.target/cris/cris.ex
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.
---
gcc/testsuite/gcc.target/cris/pr
* 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 cod
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/
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 fit
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 sel-sched-dump
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 around
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 combine-time
* 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.
Also
* 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.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.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 |
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 ("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.
("*movsi_internal
* 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 "*b"
* 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 insertions(+)
* 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 t
* 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 c
* 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 a
* 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. Add
* 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, if
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
> @@
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 pa
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.") c
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 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 buil
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 gcc-re
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 the
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:
> > >
> > >* Designate
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
'
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 VOID
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 next_arg
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 paramete
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
* gcc.dg/uninit-pred-9_
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 ca
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.
>
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
Committed as obvious.
-- >8 --
I noticed my autotester for cris-elf flagging this as a regression.
* gcc.dg/debug/btf/btf-datasec-1.c: Adjust pattern for targets with
symbols having a leading underscore.
---
gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 2 +-
1 file changed, 1
The xpassing change in generated code was as follows, at
r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert
to verify that this suspect was the cause). That was so
much of an improvement that I had to share it! Worth the
testsuite churn anyway. :)
Segher, if you end up reverting r14-9692
On Thu, 4 Apr 2024, David Malcolm wrote:
> Signed-off-by: David Malcolm
> ---
> htdocs/gcc-14/changes.html | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 5cc729c5..397458d5 100644
s; it is greedy. It would be nice to see
> written out what happens in this example though :-)
Yes it would, but I have other things on my plate. Besides,
it's your patch, can't rob you of the fun.
I committed the revert below, but hope to re-apply
(re-revert) it in stage 1, when as per
> From: Jonathan Wakely
> Cc: Hans-Peter Nilsson
> Date: Thu, 1 Feb 2024 15:36:50 +
> I plan to push this to trunk soon.
>
> CC HP for visibility of the change affecting cris-elf. In practice it
> shouldn't make any difference to any sensible code. It only affec
> From: Hans-Peter Nilsson
> Date: Thu, 1 Feb 2024 17:16:47 +0100
> Not speaking for other platforms with default-packed layout
> or where ABI structure layout alignment implies a change due
> to PCC_BITFIELD_TYPE_MATTERS and the "unsigned long"
> bitfield type.
&
> From: Jonathan Wakely
> Date: Thu, 1 Feb 2024 19:24:49 +
> I think I'd prefer to keep the reserved bits together, but a simpler
> way to avoid 'unsigned long' making a difference for
> PCC_BITFIELD_TYPE_MATTERS targets would be to use no more than 16 bits
> but do:
>
>unsigned _M_r
> From: Hans-Peter Nilsson
> Date: Tue, 30 Jan 2024 06:18:45 +0100
> Ping for the xfailed testsuite patch below the review
> (actual constexpr.cc patch to be handled separately):
Ping*2. Again, this is for the xfailed test-case only.
>
> > From: Hans-Peter Nilsson
>
> Date: Mon, 22 Jan 2024 14:33:59 -0500
> From: Marek Polacek
> On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> > I don't really know whether this is the right way to treat
> > CONVERT_EXPR as below, but... Regtested native
> > x86_64-linux
> Date: Wed, 7 Feb 2024 21:11:59 -0500
> From: Marek Polacek
> On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote:
> > On 2/6/24 19:23, Hans-Peter Nilsson wrote:
> > > > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > > > From: Marek Polacek
>
> Date: Thu, 8 Feb 2024 10:44:31 -0500
> From: Marek Polacek
> Cc: ja...@redhat.com, gcc-patches@gcc.gnu.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote:
> > >
> Date: Thu, 8 Feb 2024 11:22:47 -0500
> From: Marek Polacek
> I'm confused; are you planning to use the dg-ice directive I invented
> some years ago?
Please, let's keep the discussion about the test-cases in
that thread.
brgds, H-P
> Date: Wed, 7 Feb 2024 16:32:57 -0500
> From: Jason Merrill
> Incidentally, these testcases seem to require C++14; you can't have a
> switch in a constexpr function in C++11.
Update, v2 (from v1 that had a few requests from Marek
resolved from v0 that was posted together with my patch^Whack):
Bah. Linaro's CI didn't like that there were UNRESOLVEDs
due to this patch. Running it "as usual" didn't show
anything suspicious. Sure, there were "# of unresolved
testcases 3" in the summary (see v2), but no error or other
special message from dejagnu. Perhaps there could be a way
to have dg-
TPTR_TYPE__) &foo); // { dg-error
"conversion from pointer type" }
+ xyzzy(e);
+ unsigned constexpr char f = ifbar((__UINTPTR_TYPE__) &foo); // { dg-error
"conversion from pointer type" }
+ xyzzy(f);
+}
--
2.30.2
> From: Hans-Peter Nilsson
> CC: ,
> Content
> Date: Fri, 16 Feb 2024 11:16:22 +0100
> From: Jakub Jelinek
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we
Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)
On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:
> Tested mmix-knuth-mmixware (where all torture-variants of
> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> x86_64-pc-linux-gnu. Also stepped through the test f
Tested x86_64-linux-gnu. Ok to commit?
Or, does the message need more tweaking?
(If so, suggestions from native speakers?)
FWIW, I found no PR for just the message being bad.
-- >8 --
When you're not regularly exposed to this warning, it is
easy to be misled by its wording, believing that there'
> From: Richard Biener
> Date: Mon, 22 Jan 2024 08:33:47 +0100
> > - "% function might not be inlinable");
> > + "% function is not always inlined"
> > + " unless also declared %");
>
> I don't like the "is not always inlined", maybe simply r
I don't really know whether this is the right way to treat
CONVERT_EXPR as below, but... Regtested native
x86_64-linux-gnu. Ok to commit?
brgds, H-P
-- >8 --
That gcc_unreachable at the default-label seems to be over
the top. It seems more correct to just say "that's not
constant" to whatever'
901 - 1000 of 2388 matches
Mail list logo
