Ping for the xfailed testsuite patch below the review
(actual constexpr.cc patch to be handled separately):
> From: Hans-Peter Nilsson
> Date: Tue, 23 Jan 2024 05:55:00 +0100
>
> > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > From: Marek Polacek
>
> > The
> From: Jiufu Guo
> Date: Wed, 6 Dec 2023 17:27:58 +0800
> Hi,
>
> The issue mentioned in PR112525 would be able to be handled by
>
> updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx.
>
> https://gcc.gnu.org/bu
No test-case, but the regress-367 from r14-6674-g4759383245ac97 is
"back" to regress-10 for cris-elf+cris-sim with this patch applied
to gcc from that revision.
Also, I wonder why none of those other targets with a MEM for
EH_RETURN_HANDLER_RTX with an address relative to
frame_pointer_rtx (as opp
Tested for mmix and observing the increased timeout in the .log
file - and the test passing.
Ok to commit? Or better suggestions?
-- >8 --
Testing for mmix (a 64-bit target using Knuth's simulator). The test
is largely pruned for simulators, but still needs 5m57s on my laptop
from 3.5 years ag
I'm not completely sure I got the intent of the "log2_limit",
or whether "limit" is sane to decrease like this; it just
looked like an obvious and safe reduction. Also, I verified
the 10+ minute runtime, on this same host (clocked at 11:43.61
elapsed time) for a r12-2797-g307e0d40367996 build that
On Sat, 30 Dec 2023, Jonathan Wakely wrote:
> On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> > Or perhaps the cause is known?
>
> Not to me. It probably is a target codegen bug, since all this test really
> does is emulate a wide integer type using masks and shifts.
On Sat, 30 Dec 2023, Hans-Peter Nilsson wrote:
> On Sat, 30 Dec 2023, Jonathan Wakely wrote:
>
> > On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> > > Or perhaps the cause is known?
> >
> > Not to me. It probably is a target codegen bug, since all this
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 for native,
w/wo. RUN_FRACTION defined to see that it worked as intended.
You may wonder what about the "sibling" tests inline-mem-cm
On Tue, 2 Jan 2024, Jeff Law wrote:
>
> On 1/1/24 20:22, 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 for native
On Tue, 12 Dec 2023, Maciej W. Rozycki wrote:
> Hi,
>
> This patch quasi-series makes it possible for individual test cases
> identified as being slow to request more time via the GCC test harness by
> providing a test execution timeout factor, applied to the tool execution
> timeout set glob
> From: Patrick Palka
> Date: Tue, 2 Jan 2024 12:48:26 -0500
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and release
> branches (r14-205 was backported everywhere)?
>
> -- >8 --
>
> The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
> inadvertently increased the exe
On Wed, 3 Jan 2024, Maciej W. Rozycki wrote:
> On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote:
>
> > > The test execution timeout is different from the tool execution timeout
> > > where it is GCC execution that is being guarded against taking excessive
> > >
On Wed, 3 Jan 2024, Jacob Bachmeyer wrote:
> Comments before I start on an implementation?
I'd suggest to await the conclusion of the debate: I *think*
I've proved that dg-timeout-factor is already active as intended
(all parts of a test), specifically when the compilation result
is executed (f
On Tue, 19 Dec 2023, Jeff Law wrote:
>
> So the strub tests in c-c++-common are problematical. They get run twice,
> once for C, once for C++. Yet the name of the test is the same in both runs.
> (by the name, I mean the name emitted into the dejagnu summary and log files).
>
> Thus if you have
(Sorry, never a bringer of good news...)
> From: Jonathan Wakely
> Date: Mon, 8 Jan 2024 01:15:50 +
> Tested x86_64-linux and aarch64-linux. Pushed to trunk.
>
> -- >8 --
>
> This change ensures that char and wchar_t arguments are formatted
> consistently when using integer presentation t
> From: Hans-Peter Nilsson
> Date: Mon, 8 Jan 2024 17:24:35 +0100
> For some reason, this (r14-6990-g74a0dab18292be) breaks a
> build of (newlib targets) at least cris-elf and arm-eabi:
...aaand, just now fixed in r14-7007-geb846114ed7c49.
(Thanks!)
brgds, H-P
> From: Alexandre Oliva
> Date: Thu, 30 Nov 2023 01:41:55 -0300
> On Nov 29, 2023, Hans-Peter Nilsson wrote:
>
> >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1
> >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts
> From: Martin Uecker
> Cc: richard.guent...@gmail.com
> Am Montag, dem 27.11.2023 um 08:36 -0700 schrieb Jeff Law:
> >
> > On 11/23/23 10:05, Hans-Peter Nilsson wrote:
> > > > From: Hans-Peter Nilsson
> > > > Date: Thu, 16 Nov 2023 05:24:06
> Date: Sun, 19 Nov 2023 17:47:56 -0700
> From: Jeff Law
> Locally we have had this enabled at -O1 and above to encourage testing,
> but I'm thinking that for the trunk enabling at -O2 and above is the
> right thing to do.
Yes.
> Thoughts, comments, recommendations?
Sounds great!
It'd be ni
> From: Hans-Peter Nilsson
> Date: Thu, 30 Nov 2023 18:09:10 +0100
> I intend to post two alternative patches to get this
> resolved:
> 1: Move the tests to gcc.target/i386/scev-[3-5].c
> 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed
>only on h8300-*-*
> From: Hans-Peter Nilsson
> Date: Thu, 30 Nov 2023 18:09:10 +0100
Richard B.:
> > > In the end we might need to move/duplicate the test to some
> > > gcc.target/* dir and restrict it to a specific tuning.
>
> I intend to post two alternative patches to get
> From: Hans-Peter Nilsson
> Date: Thu, 30 Nov 2023 18:09:10 +0100
> I intend to post two alternative patches to get this
> resolved:
> 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed
>only on h8300-*-* and ia32.
(Except as mentioned, the XPASS issue does not ap
> Date: Fri, 1 Dec 2023 08:09:08 -0700
> From: Jeff Law
> On 11/30/23 18:08, Hans-Peter Nilsson wrote:
> >> Date: Sun, 19 Nov 2023 17:47:56 -0700
> >> From: Jeff Law
> >
> >> Locally we have had this enabled at -O1 and above to encourage testing
> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> From: Richard Biener
> On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:
>
> > > From: Hans-Peter Nilsson
> > > Date: Thu, 30 Nov 2023 18:09:10 +0100
> >
> > Richard B.:
> > > > > In
> Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET)
> From: Richard Biener
> On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote:
> > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> > > From: Richard Biener
> > > I read from your messages that the testcases pass on arm
On Fri, 6 Jan 2023, YunQiang Su wrote:
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
> when build libsanitizer in LLVM. Thus
>FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
> instead of
>FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
> in
On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote:
>
>
> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote:
> > From: Tsukasa OI
> >
> > This built-in does not imply the 'Xgnuzihintpausestate' extension.
> > It does not change architectural state (because all HINTs are prohibited
> > from doi
On Tue, 29 Aug 2023, Tsukasa OI wrote:
> On 2023/08/29 8:09, Hans-Peter Nilsson wrote:
> > On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote:
> >>
> >>
> >> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote:
> >>> From: Tsukasa
> From: Martin Uecker
> Date: Tue, 31 Oct 2023 20:05:09 +0100
> Reduce false positives for -Wnonnull for VLA parameters [PR98541]
>
> This patch limits the warning about NULL arguments to VLA
> parameters declared [static n].
>
> PR c/98541
>
> gcc/
>
> From: Szabolcs Nagy
> Date: Fri, 3 Nov 2023 15:36:08 +
I don't see others commenting on this patch, and you're not
mentioning this aspect, so I wonder:
> * config/aarch64/aarch64.h (EH_RETURN_TAKEN_RTX): Define.
> (EH_RETURN_STACKADJ_RTX): Change to R5.
> (EH_RETURN_HANDL
> From: Dimitar Dimitrov
> Date: Tue, 14 Nov 2023 22:00:14 +0200
> The -w option was used in gcc.dg/20020206-1.c to ignore warnings if the
> '-fprefetch-loop-arrays' option is not supported by target.
>
> When commit r14-5380-g5c432b0efab54e removed the -w option, some targets
> (arm-none-eabi,
> From: Martin Uecker
> Date: Tue, 07 Nov 2023 06:56:25 +0100
> Am Montag, dem 06.11.2023 um 21:01 -0700 schrieb Jeff Law:
> >
> > On 11/6/23 20:58, Hans-Peter Nilsson wrote:
> > > This patch caused a testsuite regression: there's now an
> > > "
> From: Jonathan Wakely
> Date: Thu, 16 Nov 2023 08:12:39 +
> PR libstdc++/111667
> * include/Makefile.am: Add new header.
> * include/Makefile.in: Regenerate.
> * include/bits/out_ptr.h: New file.
> * include/bits/shared_ptr.h (__is_shared_ptr): Move definition
> From: Jonathan Wakely
> Date: Thu, 16 Nov 2023 17:20:09 +
> PR libstdc++/112564
> * include/std/stacktrace (formatter::format): Format according
> to format-spec.
> * include/std/thread (formatter::format): Use _Align_right as
> default.
> * testsuite/19_
> From: Jonathan Wakely
> Date: Mon, 20 Nov 2023 11:55:22 +
> The changelog entry does say "Change compile test to run."
Wow, it's right there. The doh:est of doh:s on me. Sorry
for wasting your time on that.
> > PS. Sorry, I have no idea why regarding the underlying multi-target problem
> From: David Malcolm
> Date: Thu, 16 Nov 2023 09:28:54 -0500
> How is this looking for trunk?
>
> Thanks
> Dave
>
>
> David Malcolm (4):
> options: add gcc/regenerate-opt-urls.py
> Add generated .opt.urls files
> opts: add logic to generate options-urls.cc
> options: wire up options-u
> From:
> Date: Tue, 24 Oct 2023 17:11:24 +0300
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
>
> The discussion in the PR was centered around ext
I added that xfail in February for { ilp32 && c++98_only } and it
looks like it's moved on to lp64 now. :-/ Noted by Rainer
Orth, see the PR.
Tested cris-elf and x86_64-pc-linux-gnu w/wo. -m32.
Ok to commit?
-- >8 --
The conditions under which this this bogus warning is
emitted has changed to no
> From: Hans-Peter Nilsson
> Date: Thu, 16 Nov 2023 05:24:06 +0100
>
> > From: Martin Uecker
> > Date: Tue, 07 Nov 2023 06:56:25 +0100
>
> > Am Montag, dem 06.11.2023 um 21:01 -0700 schrieb Jeff Law:
> > >
> > > On 11/6/23 20:58, Hans-Peter Nils
enough about that as I also diff
the test-logs for my manual testing. The biggest problem was then
that each run can't be done in parallel.
Hans-Peter Nilsson (3):
contrib/regression/btest-gcc.sh: Handle multiple options.
contrib/regression/btest-gcc.sh: Simplify option handling
Deliberately not using getopt. Tested by adding a line right after this
code echoing $dashj, $add_passes_despite_regression, and $1 (then exit)
and checking that I got it right for combinations of -j j4
--add-passes-despite-regression.
-- >8 --
This is a long-standing bug: passing "-j --add-passe
Tested as with the previous patch.
-- >8 --
* btest-gcc.sh (Option handling): Break out shifts from each
option alternative.
---
contrib/regression/btest-gcc.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib/regression/btest-gcc.sh b/contrib/regre
Somewhat trivial, still tested on several runs (for
cris-elf): two starting from the same state, with/without
--handle-xpass-as-fail; the one "without" showing no change
in state compared to an unpatched baseline (with the same
input-state), and the one with --handle-xpass-as-fail some
XPASSing tes
While looking at the various targets, I found that the m32r
target has two options implemented as opposites:
-mbranch-cost=1 and -mbranch-cost=2, that have a bug that
makes them yield their functionally opposite effect;
i.e. -mbranch-cost=$arg, arg={1, 2} yields BRANCH_COST(x, y)
3-$arg. Anyway, t
In a recent all-target test-round investigating XPASSes for
this file, I noticed this line XPASSing for MMIX. From the
commit history it's obvious it was left out from related
target-xfail tweaks, now the last target xfailing a bogus
warning for this line.
* gcc.dg/uninit-pred-9_b.c: Remo
> From: Jonathan Wakely
> Date: Thu, 23 Nov 2023 17:51:38 +
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/111055
> * include/bits/ranges_base.h (from_range_t): Define new tag
> type.
> (from_range): Define new tag object.
> * include/bits/version.def (ranges_to_con
> From: Rainer Orth
> Date: Tue, 28 Nov 2023 16:13:35 +0100
> Richard Biener writes:
>
> > On Sun, 19 Nov 2023, Jeff Law wrote:
> >
> >>
> >>
> >> On 11/19/23 00:30, Alexandre Oliva wrote:
> >> >
> >> > I've recently patched scev-3.c and scev-5.c because it only passed by
> >> > accident on
> From: Qing Zhao
> Date: Tue, 19 Sep 2023 14:19:09 +
> > On Sep 17, 2023, at 12:36 PM, Hans-Peter Nilsson via Gcc-patches
> > wrote:
> >> From: Sam James
> >> Date: Sun, 17 Sep 2023 05:00:37 +0100
> >> Did some bug ever get filed for th
Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
For arm-eabi, notably lacking any atomic support for the
default multilib, with --target_board=arm-sim it regressed
29_atomics/atomic_flag/cons/value_init.cc with the expected
linker failure due to lack of __atomic_test_and_set - which
is a
Ok to commit?
-- >8 --
A recent patch made __atomic_test_and_set no longer fall
back to emitting non-atomic code, but instead will then emit
a call to __atomic_test_and_set, thereby exposing the need
to gate also this test on support for atomics, similar to
r14-3980-g62b29347c38394.
libstdc++-v3:
> Date: Tue, 26 Sep 2023 01:56:55 +
> From: waffl3x
> Signed-off-by: waffl3x
I think I've read that you have to put your actual name in
the DCO; using an alias (presumably) as above would be
wrong.
Ah, it's on https://gcc.gnu.org/dco.html - the *second* DCO
link; under "Signed-off-by", on
> Date: Wed, 3 Jul 2024 12:46:46 -0600
> From: Jeff Law
> The late-combine patch has triggered a previously latent bug in reorg.
>
> Basically we have a sequence like this in the middle of reorg before we
> start relaxing delay slots (cris-elf, gcc.dg/torture/pr98289.c)
[...]
> Pushing to the
CC to both the combine maintainer and the RA maintainer for
verdict on whether this is the true correction or just a
"fix"; whether REG_POINTER must be present or is just an
optimization hint. And I almost forgot, the late-combine
author! At least I hope to clarify the commit log based on
your re
Heads-up to xtensa maintainers, who might similarly want to move the
option-override to TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (and call it
from TARGET_OPTION_OVERRIDE).
Regarding disabling that optimization: with the brief description per
the below, I think I've done due diligence when it comes to
Regarding shortening it: no need to duplicate what's in the git commit
log, just keep it at the minimum for at-a-glance use.
-- >8 --
* config/cris/cris.cc (cris_option_override_after_change): Fix up
comment regarding disabling late_combine.
---
gcc/config/cris/cris.cc | 7 +++
> From: Hans-Peter Nilsson
> Date: Fri, 12 Jul 2024 02:11:45 +0200
>
> > Date: Wed, 3 Jul 2024 12:46:46 -0600
> > From: Jeff Law
>
> > The late-combine patch has triggered a previously latent bug in reorg.
> >
> > Basically we have a sequence
Committed.
-- >8 --
With r15-1619-g3b9b8d6cfdf593, there's a XPASS and a FAIL
for this test-case for cris-elf. Looking at the generated
code, _foo is indeed no longer saved in a register for CRIS.
While that looks like a regression, coremark results are the
same around this revision, so simply adj
> From: Hans-Peter Nilsson
> Date: Mon, 15 Jul 2024 05:06:43 +0200
> With r15-1619-g3b9b8d6cfdf593, there's a XPASS and a FAIL
> for this test-case for cris-elf. Looking at the generated
> code, _foo is indeed no longer saved in a register for CRIS.
> While that
> Date: Wed, 15 May 2024 11:38:58 +0200 (CEST)
> From: Richard Biener
> The following removes the profile based heuristic limiting sinking
> and instead uses post-dominators to avoid sinking to places that
> are executed under the same conditions as the earlier location which
> the profile based
On Mon, 20 May 2024, Jiufu Guo wrote:
> Hi,
>
> For PR96866, when printing asm code for modifier "%a", an addressable
> operand is required. While the constraint "X" allow any kind of
> operand even which is hard to get the address directly. e.g. extern
> symbol whose address is in TOC.
> An err
Regtested cris-elf. Ok to commit?
-- >8 --
The PR115182 regression is that a delay-slot for a conditional branch,
is no longer filled with an insn that has been "sunk" because of
r15-518-g99b1daae18c095, for cris-elf w. -O2 -march=v10.
There are still sufficient "nearby" dependency-less insns th
Regtested cris-elf. Ok to commit?
-- >8 --
...and call compute_bb_for_insn in init_resource_info and
free_bb_for_insn in free_resource_info.
I put a gcc_unreachable in that else-clause for a failing
find_basic_block in mark_target_live_regs after the comment that says:
/* We didn't find the
Regtested cris-elf. Ok to commit?
-- >8 --
No functional change.
A "git diff -wb" (ignore whitespace diff) shows that this
commit just removes a "if (b != -1)" after a "gcc_assert (b
!= -1)" and also removes the subsequent "else" clause.
* resource.cc (mark_target_live_regs): Remove red
Regtested cris-elf. Ok to commit?
-- >8 --
No functional change.
- We always have a target_hash_table and bb_ticks because
init_resource_info is always called. These conditionals are
an ancient artifact: it's been quite a while since
resource.cc was used elsewhere than exclusively from reorg.cc
> Date: Mon, 27 May 2024 12:57:53 -0600
> From: Jeff Law
> > * resource.cc: Include cfgrtl.h. Use BLOCK_FOR_INSN (insn)->index
> > instead of calling find_basic_block (insn). Assert for not -1.
> > (find_basic_block): Remove function.
> > (init_resource_info): Call compute_bb_fo
> From: Hans-Peter Nilsson
> Date: Mon, 27 May 2024 19:51:47 +0200
> 2: Does not depend on 1, but corrects an incidentally found wart:
> find_basic_block calls fails too often. Replace it with "modern"
> insn-to-basic-block cross-referencing.
>
> 3: Just a
> Date: Wed, 29 May 2024 20:07:22 -0600
> From: Jeff Law
> > There appears to be only a single supported SPARC machine in
> > cfarm: cfarm216, and I currently can't reach it due to what
> > appears to be issues at my end. I guess I'll either fix
> > that or breathe life into sparc-elf+sim.
> Or
> Date: Wed, 29 May 2024 21:23:58 -0600
> Cc: gcc-patches@gcc.gnu.org
> I don't bother with qemu.exp at all. I've set up binfmt handlers so
> that I can execute foreign binaries.
>
> So given a root filesystem, I can chroot into it and do whatever I need.
> As far as dejagnu is concerned it
I verified that the patch still works around the issue at
r15-2881-g4bcb480d103b.
brgds, H-P
> From: Hans-Peter Nilsson
> Date: Fri, 12 Jul 2024 03:17:39 +0200
>
> CC to both the combine maintainer and the RA maintainer for
> verdict on whether this is the true correction or
I stumbled on this being a regression for cris-elf as well;
the patch expectedly fixes the test-case for CRIS as well.
It's been a week since the patch was posted and as I see no
replies, I'm pinging this in behalf of Dimitar.
> From: Dimitar Dimitrov
> Date: Mon, 5 Aug 2024 21:29:35 +0300
> Th
> From: Sam James
> Date: Tue, 13 Aug 2024 18:17:29 +0100
> Hans-Peter Nilsson writes:
>
> > I stumbled on this being a regression for cris-elf as well;
> > the patch expectedly fixes the test-case for CRIS as well.
> > It's been a week since the patch was
______
> From: Libstdc++ on behalf of
> Jonathan Wakely via Libstdc++
> Sent: 10 June 2023 08:12
> To: Hans-Peter Nilsson
> Cc: Jonathan Wakely; libstdc++; gcc-patches
> Subject: Re: [PATCH] (Re: Splitting up
> 27_io/basic_istream/ignore/wchar_t/94749.c
Regtested cris-elf, both an older newlib (FWIW: before the
getentropy issue that I hoped to investigate before
summer...maybe next summer) and a fresh checkout, both
with/without --enable-newlib-iconv. I'm pleasantly
surprised that it works (there are no regressions) with
newlib iconv enabled comp
(CC to the dejagnu project as a heads-up)
Regtested cris-elf with a fresh newlib checkout where 2640
libstdc++-v3 tests otherwise fail due to the stubbed newlib
_getentropy. Ok to commit?
-- >8 --
Newer newlib trigger warnings about certain functions not implemented
(_getentropy) when testing li
> Date: Wed, 14 Aug 2024 20:58:04 -0500
> From: Jacob Bachmeyer
> Reply-To: jcb62...@gmail.com
> Hans-Peter Nilsson wrote:
> > (CC to the dejagnu project as a heads-up)
> >
> > Regtested cris-elf with a fresh newlib checkout where 2640
> > libstdc++-v3 tes
> Date: Wed, 14 Aug 2024 22:12:23 -0500
> From: Jacob Bachmeyer
> Done and pushed to Savannah as commit
> ed301dbd6a3d769670503ccfda1ea31b58d02547. Please confirm that this
> solves the problem.
Confirmed*...
> (Also note that you can now run DejaGnu from a Git checkout, simply use
> the "r
As noticed when verifying the dejagnu fix. Tested cris-elf
with a new newlib that arranges to emit the mentioned
warning, with/without the update in dejagnu to handle the
miniscule "in". Ok to commit?
-- >8 --
All testsuite compiler-calls pass default_target_compile in the
dejagnu installation (
The only thing that's changed with the patch in v2 since the
first version (pinged once) is the commit message. CC to
the nexts-of-kin as a heads-up.
Regtested cross to cris-elf and native x86_64-linux-gnu at
r15-3043-g64028d626a50. The gcc.dg/guality/pr54200.c
magically being fixed was also not
Ping...
> From: Hans-Peter Nilsson
> Date: Mon, 19 Aug 2024 00:28:30 +0200
>
> As noticed when verifying the dejagnu fix. Tested cris-elf
> with a new newlib that arranges to emit the mentioned
> warning, with/without the update in dejagnu to handle the
> miniscul
On Sun, 2 Jun 2024, Kewen Lin wrote:
> This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
> defines in mmix port.
This is fine once prerequisites are in place.
If I may add a nit: In these target change commit messages, add
a hint as to which defaulted hook or macro the removed macro now
> Date: Sat, 8 Jun 2024 11:10:21 -0600
> From: Jeff Law
> >>>resource.cc: Replace calls to find_basic_block with cfgrtl
> >>> BLOCK_FOR_INSN
> >>>resource.cc (mark_target_live_regs): Remove check for bb not found
> >>>resource.cc: Remove redundant conditionals
> >>
> >> I had to
On Mon, 22 Apr 2024, Alexandre Oliva wrote:
> [Revamped version of this patch, combined with others, to follow]
>
> On Mar 10, 2021, Hans-Peter Nilsson wrote:
Time flies...
> > On Wed, 10 Mar 2021, Alexandre Oliva wrote:
> Is mmix a sqrt_insn effec
On Tue, 23 Apr 2024, Manolis Tsamis wrote:
> diff --git a/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c
> b/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c
...
> +/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through
> noce_convert_multiple_sets" 6 "ce
> From: Hans-Peter Nilsson
> Date: Thu, 11 Apr 2024 01:16:32 +0200
I committed this revert of a revert, as r15-311, as the
prerequisite was also revert-reverted, in r15-268.
-- >8 --
This reverts commit 39f81924d88e3cc197fc3df74204c9b5e01e12f7.
---
gcc/testsuite/gcc.target/cris/pr
I thought I had already committed this, but it looks like it
was left dangling when the make_more_copies patch (now
committed) was in limbo and I disabled late-combine for
(coremark) performance reasons. FWIW that's still a reason
at r15-3386-gaf1500dd8c00 (2.6% regression).
Tested cris-elf with/
Tested adding 0..more-than-four environment variables,
running cris-sim+cris-elf. I also checked that foo stays
the same generated code regardless of the new code: this is
not obviously true as foo is "just" noinline, not __noipa__.
Ok to commit?
-- >8 --
This test awkwardly "blinks"; xfails and
Ping...
> From: Hans-Peter Nilsson
> Date: Thu, 5 Sep 2024 17:44:52 +0200
>
> Tested adding 0..more-than-four environment variables,
> running cris-sim+cris-elf. I also checked that foo stays
> the same generated code regardless of the new code: this is
> not obviously
On Tue, 3 Sep 2013, Richard Biener wrote:
> I think the warning can be completely implemented inside struct-layout.c
> for example in finish_bitfield_representative (if you pass that the first
> field
> in the group, too). Of course that is at the expense of warning for
> struct declarations rath
> From: Bernd Edlinger
> Date: Wed, 4 Sep 2013 10:15:22 +0200
> Even driver code rarely uses bit-fields for register access,
> because that is inherently non-portabe. Reason: the bit
> positions are completely different on little- and big-endian
> targets. Most drivers I have seen use some macros
> MIME-Version: 1.0
> From: Benjamin De Kosnik
> Date: Fri, 28 Sep 2012 22:02:46 +0200
> There's no reason for this unintentional ABI breakage with this
> configure flag.
> 2012-09-28 Benjamin Kosnik
>
> * acinclude.m4 (GLIBCXX_ENABLE_PARALLEL): Remove ENABLE_PARALLEL.
> * i
Fixing this bug, which effectively caused 0 to be emitted instead of
constants requiring more than one actual insn to generate (through the
base-plus-offset support, kind-of macro insns), i.e. like "LDA
$2,#0lx" instead of "LDA $2,#ff", gets rid of 193 of the
regressions from (some-early-ti
> From: Dodji Seketeli
> Date: Mon, 8 Oct 2012 14:12:04 +0200
> Jason Merrill writes:
>
> > OK.
>
> Thanks. Committed to trunk at revision r192199.
This caused a build failure, see PR54860.
brgds, H-P
On Tue, 9 Oct 2012, Ian Lance Taylor wrote:
> Patch bootstrapped and ran libbacktrace and Go testsuites on
> x86_64-unknown-linux-gnu. Committed to mainline.
Trying x86_64 host gcc 4.1.2 (--target=rl78-elf but not the issue) at
r192285:
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONF
On Tue, 9 Oct 2012, Ian Lance Taylor wrote:
> It's an incorrect warning from an old version of GCC. Fixed like so.
> Bootstrapped and ran libbacktrace testsuite on
> x86_64-unknown-linux-gnu. Committed to mainline.
Another two in libbackend/elf.c, committed as obvious after
build passed the poin
> From: Jakub Jelinek
> Date: Tue, 2 Oct 2012 14:56:29 +0200
> 2012-10-02 Jakub Jelinek
>
> cp/
> * cp-tree.h (SIZEOF_EXPR_TYPE_P): Define.
> * tree.c (cp_tree_equal): Handle SIZEOF_EXPR with
> SIZEOF_EXPR_TYPE_P.
...etc.
Looks like this caused a regression; PR54897,
On Thu, 4 Oct 2012, Jason Merrill wrote:
> Recent versions of binutils seem to have started putting ' around the version
> number in bfd/configure.in, which was confusing gcc configure. This patch
> allows us to detect the version number again.
>
> OK for trunk?
>
I committed my already-approved
> From: Hans-Peter Nilsson
> Date: Thu, 11 Oct 2012 02:13:32 +0200
> There's now an "excess error":
>
> x/libstdc++-v3/testsuite/23_containers/bitset/45713.cc:24:55:
> error: size of array 'test' is not an integral constant-expression
> int test
The md.texi entry for nonlocal_goto_receiver says "A typical reason
why you might need this pattern is if some value, such as a pointer to
a global table, must be restored when the frame pointer is restored.
Note that a nonlocal goto only occurs within a unit-of-translation, so
a global table point
Back then, I must've missed that INCOMING_REGNO / OUTGOING_REGNO are
used to map return-value-register/s too. Fixes:
FAIL: gcc.dg/builtin-apply4.c execution test
...
FAIL: gcc.dg/builtin-return-1.c execution test
...
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O0 execution test
FAIL: gcc.
When running the test-suite for these tests on an instrumented mmix
simulator (plus gcc and newlib patches to match) that, instead of
silently allocating zeros, barfs on accesses beyond the defined stack,
these tests fail because of that check. There are no stack parameters
to copy, so there's jus
1001 - 1100 of 2382 matches
Mail list logo
