> 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
> From: Vineet Gupta
> Date: Thu, 28 Sep 2023 14:43:41 -0700
Please forgive my daftness, but...
> ```
> foo2:
> sext.w a6,a1 <-- this goes away
> beq a1,zero,.L4
> li a5,0
> li a0,0
> .L3:
> addwa4,a2,a5
> addwa5,a3,a5
>
Ping.
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 19:08:16 +0200
>
> s/atomic-exchange/atomic-cmpxchg-word/g.
> Tested as v1.
>
> Ok to commit?
> -- >8 --
> These tests actually use a form of atomic compare and exchange
> operation, not just atomic l
Ping.
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 19:04:55 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 4 Oct 2023 17:15:28 +0200
>
> > New version coming up.
>
> Using pointer-sized int instead of int,
> __atomic_compare_exchange
s/atomic-exchange/atomic-cmpxchg-word/g.
Tested as v1.
Ok to commit?
-- >8 --
These tests actually use a form of atomic compare and exchange
operation, not just atomic loading and storing. Some targets (not
supported by e.g. libatomic) have atomic loading and storing, but not
compare and
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 17:15:28 +0200
> New version coming up.
Using pointer-sized int instead of int,
__atomic_compare_exchange instead of __atomic_exchange,
renamed to atomic-cmpxchg-word from atomic-exchange, and
updating a comment that already seemed r
> From: Jonathan Wakely
> Date: Wed, 4 Oct 2023 09:29:43 +0100
> The new dg-require proc checks for __atomic_exchange, which is not the
> same as compare-exchange, and not the same as test-and-set on
> atomic_flag. Does it just happen to be true for arm that the presence
> of __atomic_exchange
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL:
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> Maybe we need a new variant of dg-require-thread-fence ?
Yes: many of the dg-require-thread-fence users need
something stronger. Tested arm-eabi together with the next
patch (2/2) with
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL:
> 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
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:
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
> 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
> From: Sam James
> Date: Mon, 18 Sep 2023 08:21:45 +0100
> Hans-Peter Nilsson writes:
>
> >> From: Sam James
> >> Date: Sun, 17 Sep 2023 05:00:37 +0100
> >
> >> Hans-Peter Nilsson via Gcc-patches writes:
> >> > The situation was descr
> From: Sam James
> Date: Sun, 17 Sep 2023 05:00:37 +0100
> Hans-Peter Nilsson via Gcc-patches writes:
>
> >> Date: Tue, 29 Aug 2023 15:42:27 -0400
> >> From: Marek Polacek via Gcc-patches
> >
> >> Surely, there must be no ABI impact, the optio
> Date: Tue, 29 Aug 2023 15:42:27 -0400
> From: Marek Polacek via Gcc-patches
> Surely, there must be no ABI impact, the option cannot cause
> severe performance issues,
> Currently, -fhardened enables:
...
> -ftrivial-auto-var-init=zero
> Thoughts?
Regarding -ftrivial-auto-var-init=zero, I
> Date: Thu, 7 Sep 2023 00:11:04 +0100
> From: Jonathan Wakely via Gcc-patches
> On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely wrote:
> > I don't think there's a bug. $is_hosted is true for
> > --enable-hosted-libstdcxx which is on by default.
>
> And IIRC __STDC_HOSTED__ is defined unless you
> From: Jonathan Wakely
> Date: Wed, 6 Sep 2023 23:30:08 +0100
> On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely wrote:
> >
> > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > wrote:
> > >
> > > > Date: Fri, 1 Sep 2023
1 - 100 of 1349 matches
Mail list logo
