> 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
> 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:
https://gcc.gnu.org/g:c68bd7e8023f65d1dc23237f5a04a863344b1264
commit r15-916-gc68bd7e8023f65d1dc23237f5a04a863344b1264
Author: Hans-Peter Nilsson
Date: Thu May 30 01:57:39 2024 +0200
Revert "resource.cc: Replace calls to find_basic_block with cfgrtl
BLOCK_FOR_INSN"
Th
https://gcc.gnu.org/g:afe48a45b8baa310c8373499b1e5b5407a3e2b94
commit r15-915-gafe48a45b8baa310c8373499b1e5b5407a3e2b94
Author: Hans-Peter Nilsson
Date: Thu May 30 01:57:29 2024 +0200
Revert "resource.cc (mark_target_live_regs): Remove check for bb not found"
This reve
https://gcc.gnu.org/g:c31a9d3152d6119aab83c403308ddb933fe905c5
commit r15-914-gc31a9d3152d6119aab83c403308ddb933fe905c5
Author: Hans-Peter Nilsson
Date: Thu May 30 01:57:16 2024 +0200
Revert "resource.cc: Remove redundant conditionals"
This reve
https://gcc.gnu.org/g:802a98d128f9b0eea2432f6511328d14e0bd721b
commit r15-880-g802a98d128f9b0eea2432f6511328d14e0bd721b
Author: Hans-Peter Nilsson
Date: Tue May 28 23:18:14 2024 +0200
resource.cc: Remove redundant conditionals
No functional change.
- We always have
https://gcc.gnu.org/g:e1abce5b6ad8f5aee86ec7729b516d81014db09e
commit r15-879-ge1abce5b6ad8f5aee86ec7729b516d81014db09e
Author: Hans-Peter Nilsson
Date: Tue May 28 23:17:31 2024 +0200
resource.cc (mark_target_live_regs): Remove check for bb not found
No functional change
https://gcc.gnu.org/g:933ab59c59bdc1ac9e3ca3a56527836564e1821b
commit r15-878-g933ab59c59bdc1ac9e3ca3a56527836564e1821b
Author: Hans-Peter Nilsson
Date: Tue May 28 23:16:48 2024 +0200
resource.cc: Replace calls to find_basic_block with cfgrtl BLOCK_FOR_INSN
...and call
https://gcc.gnu.org/g:84b4ed45ea81ed5c4fb656a17846b26071c23e7d
commit r15-877-g84b4ed45ea81ed5c4fb656a17846b26071c23e7d
Author: Hans-Peter Nilsson
Date: Tue May 28 23:15:57 2024 +0200
resource.cc (mark_target_live_regs): Don't look past target insn, PR115182
The PR115182
> 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
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
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
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
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
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
> 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
https://gcc.gnu.org/g:f6ce85502eb2e4e7bbd9b3c6c1c065a004f8f531
commit r15-311-gf6ce85502eb2e4e7bbd9b3c6c1c065a004f8f531
Author: Hans-Peter Nilsson
Date: Wed May 8 04:11:20 2024 +0200
Revert "Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from
combine i
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
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
ould 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 Richard B's message
the combine imp
https://gcc.gnu.org/g:39f81924d88e3cc197fc3df74204c9b5e01e12f7
commit r14-9904-g39f81924d88e3cc197fc3df74204c9b5e01e12f7
Author: Hans-Peter Nilsson
Date: Wed Apr 10 17:24:10 2024 +0200
Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine
improv
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
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,
https://gcc.gnu.org/g:4c8b3600c4856f7915281ae3ff4d97271c83a540
commit r14-9799-g4c8b3600c4856f7915281ae3ff4d97271c83a540
Author: Hans-Peter Nilsson
Date: Fri Apr 5 02:50:16 2024 +0200
testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement
After r14-9692
https://gcc.gnu.org/g:3b36e86d6af3b305207c1aa6d56c2b350fefba65
commit r14-9798-g3b36e86d6af3b305207c1aa6d56c2b350fefba65
Author: Hans-Peter Nilsson
Date: Fri Apr 5 01:36:54 2024 +0200
testsuite/gcc.dg/debug/btf/btf-datasec-1.c: Handle leading-underscore
I noticed my autotester
> 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
; }
+ xyzzy(e);
+ unsigned constexpr char f = ifbar((__UINTPTR_TYPE__) ); // { dg-error
"conversion from pointer type" }
+ xyzzy(f);
+}
--
2.30.2
> From: Hans-Peter Nilsson
> CC: ,
> Content-Type: text/plain; charset="iso-8859-1"
> Date: Fri, 9 Feb 2024 16:30
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
> 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-gnu.
> 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
> 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 affects
&g
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
On Fri, 19 Jan 2024, LIU Hao wrote:
> ? 2024-01-18 20:54, Jan Beulich ??:
> > I'm sorry, but most of your proposal may even be considered for being
> > acceptable only if you would gain buy-off from the MASM guys. Anything
> > MASM treats as valid ought to be permitted by gas as well (within 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
> 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
s 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/cpp0x/constexpr-reinte
> 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-gnu.
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
> 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
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
On Wed, 10 Jan 2024, Jason Merrill via Gcc wrote:
> On 1/10/24 15:59, Marek Polacek wrote:
> > On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote:
> > > What formatting style do we want for non-trivial lambdas in GCC sources?
> > > I'm thinking the most consistent choice would
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 for na
> 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
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
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
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
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
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
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 thi
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
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
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
> 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.
>
>
> 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
> 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
> 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 "" 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
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:
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,
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
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
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
t-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.
contrib/regression/btest-gcc.sh: Optionally ha
> 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
> 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
> 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
> 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: 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.
> *
> 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: 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
> > > "e
> 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: 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.
>
> 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: Richard Sandiford
> Date: Tue, 24 Oct 2023 11:14:20 +0100
> reload and constrain_operands had some old code to look through unary
> operators. E.g. an operand could be (sign_extend (reg X)), and the
> constraints would match the reg rather than the sign_extend.
>
> This was previously
> From: Thomas Schwinge
> Date: Thu, 19 Oct 2023 12:42:26 +0200
> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
Not sure if that counts as "shared", but I regularly drop
in* newlib to build simulator targets (*-elf, *-newabi).
That's
> From: Thomas Schwinge
> Date: Thu, 19 Oct 2023 12:42:26 +0200
> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
Not sure if that counts as "shared", but I regularly drop
in* newlib to build simulator targets (*-elf, *-newabi).
That's
> Date: Fri, 29 Sep 2023 16:37:21 -0600
> From: Jeff Law
> So this ends up looking a lot like the bits that I had to revert several
> weeks ago :-)
>
> The core issue we have is given an INSN the generic code will cost the
> SET_SRC and SET_DEST and sum them. But that's far from ideal on a
1 - 100 of 1367 matches
Mail list logo
