On Wed, 20 Oct 2021, Richard Biener via Gcc-patches wrote:
> This maps -ftrapv to -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error,
Isn't that UBSAN target-dependent, i.e. not supported on all
targets, whereas -ftrapv is just about universally supported?
I.e. isn't this pa
On Wed, 3 Nov 2021, Maciej W. Rozycki wrote:
> Correct a `vax-netbsdelf' target regression ultimately caused by commit
> c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
> LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
> in jump threading registry.") c
On Sun, 7 Nov 2021, Maciej W. Rozycki wrote:
> On Fri, 5 Nov 2021, Hans-Peter Nilsson wrote:
>
> > > I was trying to chase another target I could use to regression-test this
> > > with that does do scaled indexed addressing while still using old reload.
> > &
On Mon, 8 Nov 2021, Maciej W. Rozycki wrote:
> On Sun, 7 Nov 2021, Hans-Peter Nilsson wrote:
> > (I thought you'd use 6cb68940dcf9 and do the same for VAX.)
>
> I could, easily, but being confined to gcc/config/cris I don't expect it
> to be included in the buil
On Wed, 2 Jun 2021, Gerald Pfeifer wrote:
> On Tue, 1 Jun 2021, Segher Boessenkool wrote:
> > We haven't had Sender: for a while now.
>
> "a while now" was about four(?) hours when you sent that yesterday. :-)
>
> I know since I still had been using that and was looking for all my
> missing gcc-re
On Sat, 25 Sep 2021, Hu Jialun wrote:
> Hello,
>
> Sorry for bumping it again but I guess it was getting overlooked.
>
> I am very junior with mailing list open source contributions so please feel
> free to point out if I have inadvertantly done something in an incorrect way.
>
> The archive of the
On Wed, 30 Jun 2021, Eli Zaretskii via Gcc-patches wrote:
> > Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> > From: Martin Li?ka
> > Date: Wed, 30 Jun 2021 12:11:03 +0200
> > > 4. Menus lost the short descriptions of the sub-sections. Example:
> > >
> > >* Designate
Commit r12-2534 was incomplete and (by inspection derived from
an MMIX build) failing for targets without an insn for
compare_and_swap for pointer-size objects, IOW for targets for
which "ATOMIC_POINTER_LOCK_FREE != 2" is true:
x/gcc/libstdc++-v3/src/c++17/memory_resource.cc: In member function
'
This bug made me dive into some of the murkier waters of gcc, namely
the source of operand 2 to the "call" pattern. It can be pretty
poisonous, but is unused (either directly or later) by most targets.
The target function_arg (and function_incoming_arg), can unless
specially handled, cause a VOID
An old itch being scratched: the documentation lies; it's not "the
number of registers used as operands", unless the target makes a
special arrangement to that effect, and there's nothing in the guts of
gcc setting up or assuming those semantics.
Instead, see calls.c:expand_call, variable next_arg
I guess the best way to describe these operands, at least for MMIX, is
"ballast". Some targets seem to drag along one or two of the incoming
pattern operands through the rtl passes and not dropping them until
assembly output. Let's stop doing that for MMIX. There really are
*two* unused paramete
Looks like MMIX is the "correct target" too (cf. 2f6bdd51cfe15)
and from
https://gcc.gnu.org/pipermail/gcc-testresults/2021-July/710188.html
it seems powerpc-ibm-aix7.2.3.0 is too, but I've not found
other targets failing.
gcc/testsuite:
PR middle-end/101674
* gcc.dg/uninit-pred-9_
Commit r12-432, rewriting the dg-stuff, reverted the
adjustment for mmix-knuth-mmixware that I added in r11-2335.
(See those commits for context.)
Hopefully this variant will age better, just skipping it
with a trivial extra line less prone to pile-on. (Not much
is won by covering this generic ca
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
>
> Normally we expect the gimple optimizers to fold away comparisons that
> are always true, but at some lower optimization levels this is not
> always the case, so the back-end has to be able to generate correct
> code in these cases.
>
On Tue, 18 May 2021, Richard Earnshaw wrote:
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> > >
> > > Normally we expect the gimple optimizers to fold away comparisons that
> > > are always
Committed as obvious.
-- >8 --
I noticed my autotester for cris-elf flagging this as a regression.
* gcc.dg/debug/btf/btf-datasec-1.c: Adjust pattern for targets with
symbols having a leading underscore.
---
gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 2 +-
1 file changed, 1
The xpassing change in generated code was as follows, at
r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert
to verify that this suspect was the cause). That was so
much of an improvement that I had to share it! Worth the
testsuite churn anyway. :)
Segher, if you end up reverting r14-9692
On Thu, 4 Apr 2024, David Malcolm wrote:
> Signed-off-by: David Malcolm
> ---
> htdocs/gcc-14/changes.html | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 5cc729c5..397458d5 100644
s; it is greedy. It would be nice to see
> written out what happens in this example though :-)
Yes it would, but I have other things on my plate. Besides,
it's your patch, can't rob you of the fun.
I committed the revert below, but hope to re-apply
(re-revert) it in stage 1, when as per
> From: Jonathan Wakely
> Cc: Hans-Peter Nilsson
> Date: Thu, 1 Feb 2024 15:36:50 +
> I plan to push this to trunk soon.
>
> CC HP for visibility of the change affecting cris-elf. In practice it
> shouldn't make any difference to any sensible code. It only affec
> From: Hans-Peter Nilsson
> Date: Thu, 1 Feb 2024 17:16:47 +0100
> Not speaking for other platforms with default-packed layout
> or where ABI structure layout alignment implies a change due
> to PCC_BITFIELD_TYPE_MATTERS and the "unsigned long"
> bitfield type.
&
> From: Jonathan Wakely
> Date: Thu, 1 Feb 2024 19:24:49 +
> I think I'd prefer to keep the reserved bits together, but a simpler
> way to avoid 'unsigned long' making a difference for
> PCC_BITFIELD_TYPE_MATTERS targets would be to use no more than 16 bits
> but do:
>
>unsigned _M_r
> From: Hans-Peter Nilsson
> Date: Tue, 30 Jan 2024 06:18:45 +0100
> Ping for the xfailed testsuite patch below the review
> (actual constexpr.cc patch to be handled separately):
Ping*2. Again, this is for the xfailed test-case only.
>
> > From: Hans-Peter Nilsson
>
> Date: Mon, 22 Jan 2024 14:33:59 -0500
> From: Marek Polacek
> On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> > I don't really know whether this is the right way to treat
> > CONVERT_EXPR as below, but... Regtested native
> > x86_64-linux
> Date: Wed, 7 Feb 2024 21:11:59 -0500
> From: Marek Polacek
> On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote:
> > On 2/6/24 19:23, Hans-Peter Nilsson wrote:
> > > > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > > > From: Marek Polacek
>
> Date: Thu, 8 Feb 2024 10:44:31 -0500
> From: Marek Polacek
> Cc: ja...@redhat.com, gcc-patches@gcc.gnu.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote:
> > >
> Date: Thu, 8 Feb 2024 11:22:47 -0500
> From: Marek Polacek
> I'm confused; are you planning to use the dg-ice directive I invented
> some years ago?
Please, let's keep the discussion about the test-cases in
that thread.
brgds, H-P
> Date: Wed, 7 Feb 2024 16:32:57 -0500
> From: Jason Merrill
> Incidentally, these testcases seem to require C++14; you can't have a
> switch in a constexpr function in C++11.
Update, v2 (from v1 that had a few requests from Marek
resolved from v0 that was posted together with my patch^Whack):
Bah. Linaro's CI didn't like that there were UNRESOLVEDs
due to this patch. Running it "as usual" didn't show
anything suspicious. Sure, there were "# of unresolved
testcases 3" in the summary (see v2), but no error or other
special message from dejagnu. Perhaps there could be a way
to have dg-
TPTR_TYPE__) &foo); // { dg-error
"conversion from pointer type" }
+ xyzzy(e);
+ unsigned constexpr char f = ifbar((__UINTPTR_TYPE__) &foo); // { dg-error
"conversion from pointer type" }
+ xyzzy(f);
+}
--
2.30.2
> From: Hans-Peter Nilsson
> CC: ,
> Content
> Date: Fri, 16 Feb 2024 11:16:22 +0100
> From: Jakub Jelinek
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we
Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)
On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:
> Tested mmix-knuth-mmixware (where all torture-variants of
> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> x86_64-pc-linux-gnu. Also stepped through the test f
Tested x86_64-linux-gnu. Ok to commit?
Or, does the message need more tweaking?
(If so, suggestions from native speakers?)
FWIW, I found no PR for just the message being bad.
-- >8 --
When you're not regularly exposed to this warning, it is
easy to be misled by its wording, believing that there'
> From: Richard Biener
> Date: Mon, 22 Jan 2024 08:33:47 +0100
> > - "% function might not be inlinable");
> > + "% function is not always inlined"
> > + " unless also declared %");
>
> I don't like the "is not always inlined", maybe simply r
I don't really know whether this is the right way to treat
CONVERT_EXPR as below, but... Regtested native
x86_64-linux-gnu. Ok to commit?
brgds, H-P
-- >8 --
That gcc_unreachable at the default-label seems to be over
the top. It seems more correct to just say "that's not
constant" to whatever'
> 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 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
> 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
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
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
101 - 200 of 1204 matches
Mail list logo
