Here's a general approach to handle PR116701. I considered
adding manual deletions as quoted below and mentioned in the
PR, but seeing the handling of "integer 8" in
fortran-torture-execute I decided to follow that example:
better scan the source for open-statements than relying on
manual annotati
Committed as pre-approved in the bugzilla PR.
Heads-up: I intend to also submit for approval a patch
that adds (the equivalent of)
! { dg-final { remote_file target delete "fort.10" } }
to all running fortran test-cases that has an open-unit-
statement (i.e. can create one of those "anonymous" f
I'd love for (something like) gcc-testresults@ to be usefully
searchable (it can be done but... lacks), so please allow me:
On Fri, 13 Sep 2024, Frank Ch. Eigler wrote:
> diff --git a/contrib/test_summary b/contrib/test_summary
> index 5760b053ec27..867ada4d6b81 100755
> --- a/contrib/test_summar
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
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
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/
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
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
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 (
> 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
> 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
(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
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
__________
> 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
> 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
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
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
> 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
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: 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
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 +++
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
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
> 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
> 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 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: 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
> 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
> 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: 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
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
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 --
...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 --
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
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
> 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
> 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
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
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
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
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
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
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
> 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
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
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-
> 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):
> 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: 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: 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: 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
> 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
>
> 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: 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
> 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
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
Change from v1: The message is changed as per the review.
The powerpc test-case is dropped from the changes as the
part quoted in a comment now does not change and so cannot
cause further confusion. The commit message is tweaked.
It now also mentions clang. I intend to commit this on
Thursday 202
> Date: Mon, 22 Jan 2024 14:33:59 -0500
> From: Marek Polacek
> The problem seems to be more about conversion so
> g++.dg/conversion/reinterpret5.C
> or g++.dg/cpp0x/constexpr-reinterpret3.C seems more appropriate.
>
> > @@ -0,0 +1,49 @@
>
> Please add
>
> PR c++/113545
> > + unsigned const
I was about to write "aren't C++ hackers" but
then again, C++ happened to gcc, and c++11 at that.)
> On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> The problem seems to be more about conversion so
> g++.dg/conversion/reinterpret5.C
> or g++.dg/cp
> 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
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'
> 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
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'
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
> 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
(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
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
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 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
> > >
> 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 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
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
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 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
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.
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
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
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
> 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
> 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
> 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: 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
> 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
> 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:
> 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-*-*
> 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: 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
> 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: 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: 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
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
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
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
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
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
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
> 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
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:
> 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
> 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
1 - 100 of 1004 matches
Mail list logo
