On Fri, May 16, 2025 at 1:05 AM Jeff Law wrote:
>
>
>
> On 5/15/25 11:18 AM, Richard Sandiford wrote:
> > The start_sequence/end_sequence interface was a big improvement over
> > the previous state, but one slightly awkward thing about it is that
> > you have to call get_insns before end_sequence
On Thu, May 15, 2025 at 8:22 PM Andrew Pinski wrote:
>
> I noticed that fowprop does not dump when forward_propagate_into_comparison
> did a change to the assign statement.
> I am actually using it to help guide changing/improving/add match patterns
> instead of depending on doing a tree "combiner
On Thu, May 15, 2025 at 7:02 PM Andrew MacLeod wrote:
>
> Recent changes to get_range_from_bitmask can sometimes turn a small
> range into an undefined one if the bitmask indicates the bits make all
> values impossible.
>
> range_cast () was not expecting this and checks for UNDEFINED before
> pef
On Thu, May 15, 2025 at 7:30 PM Jonathan Wakely wrote:
> When the last format argument to a Tcl proc is named 'args' it has
> special meaning and is a list that accepts any number of arguments[1].
> This means when "" is passed to the proc and then we expand "$args" we
> get an empty list formatt
While evaluating Shreya's logical AND synthesis work on spec2017 I ran
into a code quality regression where combine was failing to eliminate a
redundant sign extension.
I had a hunch the problem would be with the multiple sets of the same
pseudo register in the AND synthesis path. I was right
On 5/15/25 8:35 PM, Kito Cheng wrote:
Hm, it really doesn't make too much sense to get that warning, but
I can reproduce that when I compile with gcc 13 (and newer)...and
seems like a known issue [1][2]...
I still hadn't managed to convince myself the code was wrong. It looked
more like
* git.html: Note that devel/omp/gcc-15 exists, and that the
corresponding gcc-14 branch is now stale.
---
htdocs/git.html | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 8edaa254..0b55a970 100644
--- a/htdocs
Hm, it really doesn't make too much sense to get that warning, but
I can reproduce that when I compile with gcc 13 (and newer)...and
seems like a known issue [1][2]...
However I don't really like that approach, could you change the
argument type of get_riscv_ext_info to `const char *` to suppr
It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
On Fri, May 16, 2025 at 10:02 AM liuhongt wrote:
>
> The patch tries to solve miss vectorization for below case.
>
> void
> foo (int* a, int* restrict b)
> {
> b[0] = a[0] * a[64];
> b[1] = a[65] * a[1];
> b[2] = a[2] * a[66];
>
The patch tries to solve miss vectorization for below case.
void
foo (int* a, int* restrict b)
{
b[0] = a[0] * a[64];
b[1] = a[65] * a[1];
b[2] = a[2] * a[66];
b[3] = a[67] * a[3];
b[4] = a[68] * a[4];
b[5] = a[69] * a[5];
b[6] = a[6] * a[70];
b[7] = a[7] * a[71];
}
On 5/15/25 11:18 AM, Richard Sandiford wrote:
The start_sequence/end_sequence interface was a big improvement over
the previous state, but one slightly awkward thing about it is that
you have to call get_insns before end_sequence in order to get the
insn sequence itself:
I can't even remember
Here's the test run. No regressions.
BTW, there are some differences between runs. I _think_ this is due to
running them in separate days, and having run 'make install' in between,
which seems to have made some tests that would normally fail now succeed
but that's unrelated to the feature, and i
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of the array,
regardless of it being really a poin
gcc/ChangeLog:
* Makefile.in (USER_H): Add .
* ginclude/stdcountof.h: Add countof macro.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-stdcountof.c: Add tests for .
Signed-off-by: Alejandro Colomar
---
gcc/Makefile.in | 1 +
gcc/ginclude/stdcount
Hi,
Here's the patch set. This time, feature complete, and fully tested
with no regressions. I'll send a reply with the test results in a
moment.
v22 changes:
- Move Link: tags to above the changelog, as Jason requested.
- Update the tests for -pedantic-errors. Some tests are now errors
It has been standardized in C2y.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_sizeof_or_countof_expression):
Add -Wpedantic diagnostic for _Countof in <= C23 mode.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compat.c
* gcc.dg/countof-no-compat.c
* gcc.dg/counto
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
coroutines.exp was basically only there to add -std=c++20 to all the tests;
removing it lets us use the general support for running tests under multiple
standards. Doing this revealed that some tests that specifically run in
C++17 mode were
On Thu, 15 May 2025 at 18:32, Ville Voutilainen
wrote:
>
> On Thu, 15 May 2025 at 18:19, Jason Merrill wrote:
>
> > > @@ -3347,8 +3347,6 @@ cp_fold (tree x, fold_flags_t flags)
> > > || id_equal (DECL_NAME (callee), "as_const")))
> > > {
> > > r = CALL_EXPR_ARG (x,
On 5/13/25 02:22, Tobias Burnus wrote:
[snip]
How about the attached patch? With it, running
./contrib/gcc-changelog/git_update_version.py \
--suffix '.omp' -c \
--exclude-branch=origin/releases/gcc-15 \
--last-commit=0b76b58a5875d519f95a5af661fb64e42a42ed8e
works where --last-c
Hi Andre,
Am 15.05.25 um 22:13 schrieb Andre Vehreschild:
LGTM!
it's great that you reviewed the patch, as I was touching
original code next to yours... ;-)
Thanks for the Patch.
Pushed as r16-669-gd31ab498b12ebb.
Thanks,
Harald
- Andre
Andre Vehreschild * ve...@gmx.de
Am 15. Mai 2025
LGTM!
Thanks for the Patch.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 15. Mai 2025 22:36:19 schrieb Harald Anlauf :
Dear all,
the attached patch fixes missing default-initialization of function
results of derived type that happens under some conditions, see PR.
The logic when default initia
On Thu, May 15, 2025 at 9:45 PM Rainer Orth
wrote:
> Hi Tomasz,
>
> >> I've a local patch in tree to support __float128 on SPARC, so I'll try
> >> with an unmodified tree first. However, 2 days ago I could bootstrap
> >> with that included just fine.
> >>
> > Is __float128 a distinct type from l
Hi Tomasz,
>> I've a local patch in tree to support __float128 on SPARC, so I'll try
>> with an unmodified tree first. However, 2 days ago I could bootstrap
>> with that included just fine.
>>
> Is __float128 a distinct type from long double, in case when both are
> 128bit?
> I have assumed that
On Thu, May 15, 2025 at 7:46 PM Rainer Orth
wrote:
> Hi Jonathan,
>
> > On Thu, 15 May 2025 at 15:02, Rainer Orth
> wrote:
> >>
> >> Hi Jonathan,
> >>
> >> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
> >> >> > sparc-sun-solaris2.11:
> >> >> >
> >> >> > In file included
On Thu, May 15, 2025 at 12:34 PM Dimitar Dimitrov wrote:
>
> After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
> following RTL for pru-unknown-elf:
>
> (insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
> (and:QI (reg:QI 1 r0.b1 [orig:1855 _20
Dear all,
the attached patch fixes missing default-initialization of function
results of derived type that happens under some conditions, see PR.
The logic when default initialization is to be applied is rather
contorted, and reversing the order of two cases fixed the issue.
Regtesting revealed
After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
following RTL for pru-unknown-elf:
(insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
(and:QI (reg:QI 1 r0.b1 [orig:1855 _201 ] [1855])
(const_int 3 [0x3])))
(nil))
...
When a paradoxical subreg is detected, validate_subreg exits early, thus
skipping the important checks later in the function.
Fix by continuing with the checks instead of declaring early that the
paradoxical subreg is valid.
One of the newly allowed subsequent checks needed to be disabled for
par
Commit r16-160-ge6f89d78c1a752 exposed that validate_subreg is
skipping important checks for paradoxical subregs, which manifested as a
regression for pru-unknown-elf. This patch series is enabling some of
the skipped checks, and adds one more for hardware subreg mode validity.
Changes since v1:
An updated version of patch, that takes a safer approach on not declaring a
special formatter for __float128 if its long double is possibly IEEE 128.
Please let me know if that version addressed the problem on sparc. I
thinking there are more sparc machines in compiler farm, so I am going to
check
Hi,
I apologize for the chrum that this patch created. I have added this static
assert to detect environments where __float128 is same as long double.
>From original commit message:
>We also provide formatter<__float128, _CharT> that formats via __flt128_t.
>As this type may be disabled (-mno-floa
On 5/15/25 5:12 PM, Jonathan Wakely wrote:
On Thu, 15 May 2025 at 16:12, Jonathan Wakely wrote:
On Thu, 15 May 2025 at 16:11, Luc Grosheintz wrote:
Without would make sense to me, because whenever I wrote an
identifier with _ I felt like I was presenting the user with
a name that they sh
Give the `define_insn` rules used in lowering `cbranch4` to RTL
more descriptive and consistent names: from now on, each rule is named
after the AArch64 instruction that it generates. Also add comments to
document each rule.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Rename to
+CC @pinskia
On 5/10/25 06:55, Jeff Law wrote:
>
> On 5/9/25 2:27 PM, Vineet Gupta wrote:
>> gcc/ChangeLog:
>>
>> * emit-rtl.cc (next_nonnote_nondebug_insn): Update comments.
>>
>> Signed-off-by: Vineet Gupta
>> ---
>> gcc/emit-rtl.cc | 6 +-
>> 1 file changed, 5 insertions(+), 1 dele
I noticed that fowprop does not dump when forward_propagate_into_comparison
did a change to the assign statement.
I am actually using it to help guide changing/improving/add match patterns
instead of depending on doing a tree "combiner" here.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/Chang
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-15.1.
Hi Jonathan,
> On Thu, 15 May 2025 at 15:02, Rainer Orth
> wrote:
>>
>> Hi Jonathan,
>>
>> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
>> >> > sparc-sun-solaris2.11:
>> >> >
>> >> > In file included from
>> >> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format
Subject: [PATCH] cobol: One additional edit to
testsuite/cobol.dg/group1/check_88.cob [PR120251]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Missed one edit. This fixes that.
gcc/testsuite/ChangeLog:
PR cobol/120251
* cobol.dg/group
When the last format argument to a Tcl proc is named 'args' it has
special meaning and is a list that accepts any number of arguments[1].
This means when "" is passed to the proc and then we expand "$args" we
get an empty list formatted as "{}". My r16-537-g3e2b83faeb6b14 change
broke all uses of d
This is the result of using a regexp to replace instances of:
= get_insns ();
end_sequence ();
with:
= end_sequence ();
where the indentation is the same for both lines, and where there
might be blank lines inbetween.
gcc/
* asan.cc (asan_clear_shadow): Use the return value of
This patch mops up obvious redundancies that weren't caught by the
automatic regexp replacements in earlier patches. It doesn't do
anything with genemit.cc, since that will be part of a later series.
gcc/
* config/arm/arm.cc (arm_gen_load_multiple_1): Simplify use of
end_sequence.
The start_sequence/end_sequence interface was a big improvement over
the previous state, but one slightly awkward thing about it is that
you have to call get_insns before end_sequence in order to get the
insn sequence itself:
To get the contents of the sequence just made, you must call
`get_
This is the result of using a regexp to replace:
rtx( |_insn *) = end_sequence ();
return ;
with:
return end_sequence ();
gcc/
* asan.cc (asan_emit_allocas_unpoison): Directly return the
result of end_sequence.
(hwasan_emit_untag_frame): Likewise.
* config/
This series makes end_sequence return the insn sequence that
it ends, so that callers don't need to call get_insns separately.
It also updates many callers to take advantage of the new return value.
Although this kind of refactoring/API change can in general make
backports harder, I think in this
On 5/9/25 13:27, Vineet Gupta wrote:
> FRM mode switching state machine has DYN as default state which it also
> fallsback to after transitioning to other states such as DYN_CALL.
> Currently TARGET_MODE_EMIT generates a FRM restore on any transition to
> DYN leading to spurious/extraneous FRM rest
bitmask_intersection should not return immediately if the current mask
is unknown.
Unknown often means it is the default for a range, and this may interact
in interesting ways with the other bitmask, producing more precise results.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pus
cpplib-15.1-b20250316.zh_CN.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Recent changes to get_range_from_bitmask can sometimes turn a small
range into an undefined one if the bitmask indicates the bits make all
values impossible.
range_cast () was not expecting this and checks for UNDEFINED before
peforming the cast. It also needs to check for it after the cast
This patch is split into 4 parts in case one of them causes any issues,
it'll be easier to track.
In an attempt to make bitmasks on ranges a bit more consistent,
get_bitmask_from_range has uses outside value-range.cc. This patch
simply moves the static function into a constructor for irange_b
This patch improves op1_range for bitwise and operations. Previously we
did some basic attempts to determine a range but they often we not very
precise.
This leverages the previous changes and recognizes that any known bit on
the LHS of an AND that falls within the MASK must also be known in o
Bitmasks for constants are currently created only for trailing zeros.
There is no reason not to also include leading 1's in the value that are
also known.
Given a range such as [5,7], possible values in binary are 0101,
0110, 0111. we can conclude that not only are the leading
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/cpplib/zh_CN.po
(This file, 'cpp
On Sat, 10 May 2025 09:42:16 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/10/25 6:30 AM, Jiawei wrote:
This patch introduces support for RISC-V Profiles RV20 and RV22 [1],
enabling developers to utilize these profiles through the -march option.
[1] https://github.com/riscv/riscv-profiles/re
On 5/12/25 11:21 AM, Maciej W. Rozycki wrote:
On Tue, 25 Feb 2025, Maciej W. Rozycki wrote:
Address this issue by recursing into COMPONENT_REF tree nodes until the
outermost one has been reached, which is supposed to be a MEM_REF one,
accumulating the offset as we go, fixing a commit e0dae4d
On 5/14/25 6:26 AM, Nathaniel Shead wrote:
On Tue, May 13, 2025 at 12:40:30PM -0400, Jason Merrill wrote:
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start wit
0001-cobol-Don-t-display-0xFF-HIGH-VALUE-characters-in-te.patch
Description: Binary data
Extract the hardcoded values for the minimum PC-relative displacements
into named constants and document them.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_128MiB): New constant.
(BRANCH_LEN_N_128MiB): Likewise.
(BRANCH_LEN_P_1MiB): Likewise.
(BRANCH_LE
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more obvious
in the next commit.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add `cmpbr` to the list of extensions.
* gcc.target/aarch64/cmpbr.c: N
Move the rules for CBZ/TBZ to be above the rules for
CBB/CBH/CB. We want them to have higher priority
because they can express larger displacements.
gcc/ChangeLog:
* config/aarch64/aarch64.md (aarch64_cbz1): Move
above rules for CBB/CBH/CB.
(*aarch64_tbz1): Likewise.
gcc/
Make the formatting of the RTL templates in the rules for branch
instructions more consistent with each other.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): Reformat.
(cbranchcc4): Likewise.
(condjump): Likewise.
(*compare_condjump): Likewise.
(aar
Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
extension.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (cmpbr): New
option.
* config/aarch64/aarch64.h (TARGET_CMPBR): New macro.
* doc/invoke.texi (cmpbr): New option.
---
gcc/config
Add rules for lowering `cbranch4` to CBB/CBH/CB when
CMPBR extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_1Kib): New constant.
(BRANCH_LEN_N_1Kib): Likewise.
(cbranch4): Emit CMPBR instructions if possible.
(cbranch4): New expand rul
On 5/15/25 10:36 AM, Ville Voutilainen wrote:
This is a follow-up to the earlier patch that adds std::to_underlying to the
set of stdlib functions that are folded. We don't seem to need to handle
the same-type case specially, the folding will just do the right thing.
Also fix up the mistake of n
The rules for conditional branches were spread throughout `aarch64.md`.
Group them together so it is easier to understand how `cbranch4`
is lowered to RTL.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Move.
(*compare_condjump): Likewise.
(aarch64_cb1): Likewise.
The `far_branch` attribute only ever takes the values 0 or 1, so make it
a `no/yes` valued string attribute instead.
gcc/ChangeLog:
* config/aarch64/aarch64.md (far_branch): Replace 0/1 with
no/yes.
(aarch64_bcond): Handle rename.
(aarch64_cbz1): Likewise.
This patch series adds support for the CMPBR extension. It includes the
new `+cmpbr` option and rules to generate the new instructions when
lowering conditional branches.
Testing done:
`make bootstrap; make check`
Karl Meakin (9):
AArch64: place branch instruction rules together
AArch64: refo
On Thu, 15 May 2025 at 18:19, Jason Merrill wrote:
> > @@ -3347,8 +3347,6 @@ cp_fold (tree x, fold_flags_t flags)
> > || id_equal (DECL_NAME (callee), "as_const")))
> > {
> > r = CALL_EXPR_ARG (x, 0);
> > - if (!same_type_p (TREE_TYPE (x), TREE_TYPE (r)))
>
On Thu, 15 May 2025 at 16:12, Jonathan Wakely wrote:
>
> On Thu, 15 May 2025 at 16:11, Luc Grosheintz wrote:
> >
> > Without would make sense to me, because whenever I wrote an
> > identifier with _ I felt like I was presenting the user with
> > a name that they shouldn't know about.
> >
> > A pe
On Thu, 15 May 2025 at 16:11, Luc Grosheintz wrote:
>
> Without would make sense to me, because whenever I wrote an
> identifier with _ I felt like I was presenting the user with
> a name that they shouldn't know about.
>
> A pedantic question: Can I also fix the line below, or do
> you prefer to
Without would make sense to me, because whenever I wrote an
identifier with _ I felt like I was presenting the user with
a name that they shouldn't know about.
A pedantic question: Can I also fix the line below, or do
you prefer to be strict about one semantic change per commit?
On 5/15/25 2:40
On Thu, May 15, 2025 at 4:07 PM Jonathan Wakely wrote:
> On Thu, 15 May 2025 at 13:56, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, May 15, 2025 at 2:53 PM Jonathan Wakely
> wrote:
> >>
> >> On Thu, 15 May 2025 at 13:43, Tomasz Kaminski
> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, May 15, 20
On 5/14/25 4:48 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/14/25 2:44 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/12/25 7:53 PM, Patrick Palka wrot
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Import didn't like differences in DECL_DECLARED_CONSTEXPR_P due to implicit
constexpr, breaking several g++.dg/modules tests; we should handle that
along with DECL_MAYBE_DELETED. For which we need to stream the bit.
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Patrick pointed out that if the parm/arg types aren't complete yet at this
point, it would affect the type_has_converting_constructor and
TYPE_HAS_CONVERSION tests. I don't have a testcase, but it makes sense for
safety.
PR c++/995
Status
==
The GCC 14 branch is now frozen for the GCC 14.3 release, a release
candidate is being prepared.
All changes to the branch require release manager approval.
Previous Report
===
https://gcc.gnu.org/pipermail/gcc/2025-April/245990.html
This is a follow-up to the earlier patch that adds std::to_underlying to the
set of stdlib functions that are folded. We don't seem to need to handle
the same-type case specially, the folding will just do the right thing.
Also fix up the mistake of not tweaking the cmdline switch doc in the earlie
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The modules tests have used their own version of the code to run tests under
multiple standard versions; they should use the same one as other tests.
I'm not sure about continuing to run modules tests in C++17 mode, but I
guess we might as
On Wed, May 14, 2025 at 02:46:15AM +, Kugan Vivekanandarajah wrote:
> Adding Eugene and Andi to CC as Sam suggested.
>
> > On 13 May 2025, at 12:57 am, Richard Sandiford
> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Kugan Vivekanandarajah writes:
> >>
> Hi,
>
> starting with GCC 15 the order is not unique for any symtab_nodes but
> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
> if only so that people can reliably match entries about new clones to
> those about removed nodes (if any).
>
> Bootstrapped and tested on x8
On Thu, 15 May 2025 at 15:02, Rainer Orth wrote:
>
> Hi Jonathan,
>
> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
> >> > sparc-sun-solaris2.11:
> >> >
> >> > In file included from
> >> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format.cc:29:
> >> > /var/gcc/reg
On Thu, 15 May 2025 at 13:56, Tomasz Kaminski wrote:
>
>
>
> On Thu, May 15, 2025 at 2:53 PM Jonathan Wakely wrote:
>>
>> On Thu, 15 May 2025 at 13:43, Tomasz Kaminski wrote:
>> >
>> >
>> >
>> > On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely wrote:
>> >>
>> >> On 15/05/25 14:35 +0200, Tomasz K
Hi Jonathan,
>> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
>> > sparc-sun-solaris2.11:
>> >
>> > In file included from
>> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format.cc:29:
>> > /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/incl
> On 15 May 2025, at 14:01, Alice Carlotti wrote:
>
> On Thu, May 08, 2025 at 09:41:08PM +0800, Yangyu Chen wrote:
>>
>>
>>> On 8 May 2025, at 18:36, Richard Sandiford
>>> wrote:
>>>
>>> Yangyu Chen writes:
> On 6 May 2025, at 17:49, Alfie Richards wrote:
>
> On 06/05/2025
On Thu, May 15, 2025 at 2:53 PM Jonathan Wakely wrote:
> On Thu, 15 May 2025 at 13:43, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely
> wrote:
> >>
> >> On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
> >> >Please also add the message to dg-error check in
On Thu, 15 May 2025 at 13:43, Tomasz Kaminski wrote:
>
>
>
> On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely wrote:
>>
>> On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
>> >Please also add the message to dg-error check in format_kind_neg.cc.
>> >With that LGTM.
>>
>> Yes, already done locally. H
We should also back-port this commit to GCC-14.
Thanks,
Yangyu Chen
On 6/9/2024 07:07, Zhao Dingyi wrote:
This patch aims to add the missing instruction types to the XiangShan-Nanhu
scheduler model.
The current XiangShan -Nanhu model lacks the trap, atomic trap, fcvt_i2f, and
fcvt_f2i instruc
On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely wrote:
> On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
> >Please also add the message to dg-error check in format_kind_neg.cc.
> >With that LGTM.
>
> Yes, already done locally. Here's what I'm testing now.
>
Any reason to not put the whole message
On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
Please also add the message to dg-error check in format_kind_neg.cc.
With that LGTM.
Yes, already done locally. Here's what I'm testing now.
commit 3c154b2d95d30580c18aa0fedd9e67200867653f
Author: Jonathan Wakely
AuthorDate: Thu May 15 11:0
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from
No strong preference, but Ville's argument sounds reasonable.
On Thu, May 15, 2025 at 12:25 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:
> Mild preference against; use the names from the standard, not the
> implementation, in such diagnostics.
>
> to 15. toukok. 2025 klo 13.20 Jonat
Please also add the message to dg-error check in format_kind_neg.cc.
With that LGTM.
On Thu, May 15, 2025 at 2:19 PM Jonathan Wakely wrote:
> On Thu, 15 May 2025 at 12:15, Daniel Krügler
> wrote:
> >
> > Am Do., 15. Mai 2025 um 13:00 Uhr schrieb Jonathan Wakely <
> jwak...@redhat.com>:
> >>
> >
On Thu, 15 May 2025 at 12:15, Daniel Krügler wrote:
>
> Am Do., 15. Mai 2025 um 13:00 Uhr schrieb Jonathan Wakely
> :
>>
>> Although Clang trunk has been adjusted to handle our std::format_kind
>> definition (because they need to be able to compile the GCC 15.1.0
>> release), it's probably better
On Thu, May 08, 2025 at 09:41:08PM +0800, Yangyu Chen wrote:
>
>
> > On 8 May 2025, at 18:36, Richard Sandiford
> > wrote:
> >
> > Yangyu Chen writes:
> >>> On 6 May 2025, at 17:49, Alfie Richards wrote:
> >>>
> >>> On 06/05/2025 09:36, Yangyu Chen wrote:
> > On 6 May 2025, at 16:01, Al
During the GCC compilation, some warnings about temporary object dangling
references emerged. They appeared in these code lines in riscv-common.cc:
const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext_info =
get_riscv_ext_info (ext) and auto &ext_info = get_riscv_ext_info (search
Am Do., 15. Mai 2025 um 13:00 Uhr schrieb Jonathan Wakely <
jwak...@redhat.com>:
> Although Clang trunk has been adjusted to handle our std::format_kind
> definition (because they need to be able to compile the GCC 15.1.0
> release), it's probably better to not rely on something that they might
>
Although Clang trunk has been adjusted to handle our std::format_kind
definition (because they need to be able to compile the GCC 15.1.0
release), it's probably better to not rely on something that they might
start diagnosing again in future.
Define the primary template in terms of an immediately
Mild preference against; use the names from the standard, not the
implementation, in such diagnostics.
to 15. toukok. 2025 klo 13.20 Jonathan Wakely
kirjoitti:
> On Thu, 15 May 2025 at 11:14, Jonathan Wakely wrote:
> >
> > On Wed, 14 May 2025 at 20:18, Luc Grosheintz
> wrote:
> > >
> > > The s
On Thu, 15 May 2025 at 11:14, Jonathan Wakely wrote:
>
> On Wed, 14 May 2025 at 20:18, Luc Grosheintz wrote:
> >
> > The standard states that the IndexType must be a signed or unsigned
> > integer. This mandate was implemented using `std::is_integral_v`. Which
> > also includes (among others) cha
On Wed, 14 May 2025 at 20:18, Luc Grosheintz wrote:
>
> The standard states that the IndexType must be a signed or unsigned
> integer. This mandate was implemented using `std::is_integral_v`. Which
> also includes (among others) char and bool, which neither signed nor
> unsigned integers.
>
> libs
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from
1 - 100 of 109 matches
Mail list logo
