On Linux/x86_64,
11f73c82f178beb9f3f29cbfe2e0a5e592e40b69 is the first bad commit
commit 11f73c82f178beb9f3f29cbfe2e0a5e592e40b69
Author: Uros Bizjak
Date: Tue Jul 15 05:05:10 2025 +0800
x86: Convert MMX integer loads from constant vector pool
caused
FAIL: gfortran.dg/guality/arg1.f90
LGTM!
Thanks!
在 2025/7/15 上午11:57, Xi Ruoyao 写道:
When TARGET_VECTORIZE_VEC_PERM_CONST is called, target may be the
same pseudo as op0 and/or op1. Loading the selector into target
would clobber the input, producing wrong code like
vld $vr0, $t0
vshuf.w $vr0, $vr0, $vr1
So don't
I would like to backport patch r15-2928-gbf891fcabca7a5 which is
available from GCC-15.
In general, if -mcpu=power9, float128 hardware is available, but in the
case the user explicitly does -mno-float128-hardware or runs on a machine
that doesn't enable float128 by default (i.e. big endian Linux a
On Thu, Jul 17, 2025 at 1:19 AM Jonathan Wakely wrote:
> The __promoted_t alias is only defined when __cpp_fold_expressions is
> defined, which might not be the case for some hypothetical C++17
> compilers.
>
> Change the 3-arg std::hypot to just use __gnu_cxx::__promote_3 which is
> always avail
On Thu, Jul 17, 2025 at 1:16 AM Jonathan Wakely wrote:
> Add comments documenting what it does and how it does it.
>
> Also reorder the if-else in operator++ so that we check whether to
> iterate over code units in the local buffer before checking whether to
> refill that buffer. That seems the m
On Thu, Jul 17, 2025 at 9:43 AM H.J. Lu wrote:
>
> There is no need to change mode for XOR in ix86_expand_ternlog now.
> Whatever reasons for it in the first place no longer exist. Tested
> on x86-64 with -m32. There are no regressions.
Ok.
>
> * config/i386/i386.cc (ix86_expand_ternlog)
Updated the testcase for the prefetch write too.
gcc/ChangeLog:
* config/riscv/riscv-ext-mips.def (DEFINE_RISCV_EXT):
Added mips prefetch extension.
* config/riscv/riscv-ext.def: Likewise.
* config/riscv/riscv-ext.opt: Generated file.
* config/riscv/riscv.md (prefet
Fixed the regress that caused "pr118241.c" failure and tested "runtest --tool
gcc
--target_board='riscv-sim/-march=rv64gc_zba_zbb_zbc_zbs/-mabi=lp64/-mcmodel=medlow'
riscv.exp" and 32 bit too
lint warnings can be ignored for riscv-ext.opt.
gcc/ChangeLog:
* config/riscv/riscv-e
There is no need to change mode for XOR in ix86_expand_ternlog now.
Whatever reasons for it in the first place no longer exist. Tested
on x86-64 with -m32. There are no regressions.
* config/i386/i386.cc (ix86_expand_ternlog): Don't change mode
for XOR.
Signed-off-by: H.J. Lu
-
Fixes typo in lex.cc. Could someone help commit?
gcc/cp/ChangeLog:
* lex.cc (init_operators): Fix typo.
---
gcc/cp/lex.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/lex.cc b/gcc/cp/lex.cc
index 08a634830f5..053d0ee0647 100644
--- a/gcc/cp/lex.cc
+++ b/gcc/c
From: John Ericson
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
use the output of:
$(CC) -print-sysroot
It is just used in one spot, in an AIX code-path. I just made (within
make) a shell variable to use instead.
I don't have
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_CFLAGS logi
On Wed, Jul 16, 2025 at 12:55 PM John Ericson wrote:
>
> This dates back to the creation of top-level `libgcc` in
> fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
> does nothing.
>
> Andrew Pinksi adds:
>
> > So looking into this further, MACHMODE_H used part of LIBGCC_DEPS
The __promoted_t alias is only defined when __cpp_fold_expressions is
defined, which might not be the case for some hypothetical C++17
compilers.
Change the 3-arg std::hypot to just use __gnu_cxx::__promote_3 which is
always available.
libstdc++-v3/ChangeLog:
PR libstdc++/121097
Add comments documenting what it does and how it does it.
Also reorder the if-else in operator++ so that we check whether to
iterate over code units in the local buffer before checking whether to
refill that buffer. That seems the more natural way to structure the
function.
libstdc++-v3/ChangeLog
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_CFLAGS logi
On Wed, Jul 16, 2025 at 3:48 PM John Ericson
wrote:
>
> From: John Ericson
>
> My goal is to be able to build libgcc cleanly in isolation --- today one
> needs to figure `make ...` misc things in the gcc subdir.
>
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patc
I stopped using state_diagram::m_show_tags in r16-2211-ga5d9debedd2f46
but forgot to remove the field. Do so now.
Spotted by Filip Kastl via clang's -Wunused-private-field.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-2308-g69d1fb86194c38.
gcc/ChangeLog:
Tested with "doxygen contrib/gcc.doxy"
Pushed to trunk as r16-2307-g48b572ce868829.
contrib/ChangeLog:
* gcc.doxy (INPUT): Add directory "gcc/text-art".
Signed-off-by: David Malcolm
---
contrib/gcc.doxy | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/gcc.doxy
From: John Ericson
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
use the output of:
$(CC) -print-sysroot
It is just used in one spot, in an AIX code-path. I just made (within
make) a shell variable to use instead.
I don't have
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_CFLAGS logi
> On Jul 16, 2025, at 17:47, Jakub Jelinek wrote:
>
> On Wed, Jul 16, 2025 at 09:22:19PM +, Qing Zhao wrote:
>> Yes, the above solution could also resolve the undefined behavior issue. We
>> can certainly go
>> with this approach.
>
> Another option is to use .ACCESS_WITH_SIZE (with diff
On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
> On 7/11/25 5:49 PM, Marek Polacek wrote:
> > On Thu, Jul 10, 2025 at 02:13:06PM -0400, Jason Merrill wrote:
> > > On 7/9/25 4:27 PM, Marek Polacek wrote:
> > > > On Tue, Jul 08, 2025 at 12:15:03PM -0400, Jason Merrill wrote:
> > > > >
On Wed, Jul 16, 2025 at 09:22:19PM +, Qing Zhao wrote:
> Yes, the above solution could also resolve the undefined behavior issue. We
> can certainly go
> with this approach.
Another option is to use .ACCESS_WITH_SIZE (with different flags compared to
the FAM cases) solely on reads from the
> On Jul 16, 2025, at 16:38, Jakub Jelinek wrote:
>
> On Tue, Jul 15, 2025 at 06:39:42PM +, Qing Zhao wrote:
>> I re-implemented the patch based on B to fix PR120929, however, the approach
>> B brings undefined behavior into the application.
>>
>> (Actually, I met this issue in the previ
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_thread_file` cache variable first. I adm
On Tue, Jul 15, 2025 at 06:39:42PM +, Qing Zhao wrote:
> I re-implemented the patch based on B to fix PR120929, however, the approach
> B brings undefined behavior into the application.
>
> (Actually, I met this issue in the previous implementation but forgot to
> documented it.
> This iss
The return type checking needs to skip over the Lvalue part of the VAR
parameter or variable.
gcc/m2/ChangeLog:
PR modula2/120497
* gm2-compiler/M2Range.mod (IsAssignmentCompatible): Remove from
import list.
(FoldTypeReturnFunc): Rewrite to skip the Lvalue of a v
r15-6789-ge7f98d9603808b added a new RTL pass for hardreg PRE for the hard
register
of FPM_REGNUM, this pass could get expensive if you have a large number of
basic blocks
and the hard register was never alive so it does nothing in the end.
In the aarch64 case, FPM_REGNUM is only used for FP8 rel
Current array bound checker only instruments ARRAY_REF, and the INDEX
information is the 2nd operand of the ARRAY_REF.
When extending the array bound checker to pointer references with
counted_by attributes, the hardest part is to get the INDEX of the
corresponding array ref from the offset comput
For example:
struct PP {
size_t count2;
char other1;
char *array2 __attribute__ ((counted_by (count2)));
int other2;
} *pp;
specifies that the "array2" is an array that is pointed by the
pointer field, and its number of elements is given by the field
"count2" in the same structure.
C FE
Fix PR120929:
incorrectly returned the size of *_1 for a
GIMPLE_ASSIGN of type:
ptr = *_1;
This is only OK when _1 is set to .ACCESS_WITH_SIZE, since that builtin
expresses the size of *_1 in the form of _1.
gcc/ChangeLog:
* tree-object-size.cc (is_ptr_access_with_size): New routine.
Hi,
This is the 8th version of the patch set to extend "counted_by" attribute
to pointer fields of structures, which fixes PR120929:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
The 8th version of the patch has the following difference compared to the 7th
version:
1. Add the fix for PR1
On Wed, 16 Jul 2025, 14:53 Luc Grosheintz, wrote:
> The second bug report in PR121061 is that the conversion of custom
> OtherIndexType to IndexType is incorrectly not done via r-value
> references.
>
> This commit fixes the forwarding issue, adds a custom IndexType called
> RValueInt, which only
On Wed, 16 Jul 2025, 14:46 Luc Grosheintz, wrote:
> PR121061 consists of two bugs for mdspan related code. This commit fixes
> the first one. Namely, when passing custom IndexType as an array or
> span, the conversion to int must be const. Prior to this commit the
> constraint incorrectly also al
On Wed, 16 Jul 2025, 14:48 Luc Grosheintz, wrote:
> PR121061 shows that the test coverage for custom integer types is
> insufficient. Custom IndexTypes are passed to mdspan related objects in
> one of two ways:
>
> * as a template parameter pack,
> * or as an array/span.
>
> These two cases h
This dates back to the creation of top-level `libgcc` in
fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
does nothing.
Andrew Pinksi adds:
> So looking into this further, MACHMODE_H used part of LIBGCC_DEPS
> because of TM_H and r0-78222-gfa9585134f6f58 moved away from incl
Although cherry picked as described. The cherry pick does not include
the command option (-fm2-strict-type-reason) introduced in:
gcc/m2/gm2-lang.cc, gcc/m2/lang.opt and gcc/doc/gm2.texi from the
original patch.
This patch provides follow on fixes for undetected type violations
which can occur
When VN iterates we can end up with unreachable inserted expressions
in the expression tables which in turn will not be added to their
value by PREs compute_avail. This will later ICE when we pick
them up and want to generate them. Deal with this by giving up.
Bootstrap and regtest running on x8
No functional changes.
[patch 1/4] gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_vector_logical_operator):
Use CONST_VECTOR_P instead of open coding it.
(ix86_expand_int_sse_cmp): Ditto.
(ix86_extract_perm_from_pool_constant): Ditto.
(ix86_split_to_parts): Ditto.
The following makes us never consider vector(1) T types for
vectorization and ensures this during SLP build. This is a
long-standing issue for BB vectorization and when we remove
early loop vector type setting we lose the single place we have
that rejects this for loops.
Once we implement partial
On Wed, Jul 16, 2025 at 5:15 PM H.J. Lu wrote:
>
> Since only glibc targets support -mfentry, warn -pg without -mfentry only
> on glibc targets.
>
> gcc/
>
> PR target/120881
> PR testsuite/121078
> * config/i386/i386-options.cc (ix86_option_override_internal):
> Wa
On Wed, Jul 16, 2025 at 6:00 AM Richard Sandiford
wrote:
>
> Andrew Pinski writes:
> > r15-6789-ge7f98d9603808b added a new RTL pass for hardreg PRE for the hard
> > register
> > of FPM_REGNUM, but this pass does nothing if there can be any FPM_REGNUM
> > register in it.
> > So let's set HARDRE
From: Dhruv Chawla
This is a script that makes it easier to visualize the output from make.
It filters out most of the output, leaving only (mostly) messages about
files being compiled, installed and linked. It is not 100% accurate in
the matching, but I feel it does a good enough job.
To use it
gcc/ChangeLog:
PR target/117015
* config/s390/s390-protos.h (s390_expand_int_spaceship): New
function.
(s390_expand_fp_spaceship): New function.
* config/s390/s390.cc (s390_expand_int_spaceship): New function.
(s390_expand_fp_spaceship): New function
During jump bypassing also consider insns of the form
(insn 25 57 26 9 (parallel [
(set (reg:CCZ 33 %cc)
(compare:CCZ (reg:SI 60 [ _9 ])
(const_int 0 [0])))
(clobber (scratch:SI))
]) "spaceship-fp-4.c":27:1 1746 {*tstsi_cconly_ext
Since only glibc targets support -mfentry, warn -pg without -mfentry only
on glibc targets.
gcc/
PR target/120881
PR testsuite/121078
* config/i386/i386-options.cc (ix86_option_override_internal):
Warn -pg without -mfentry only on glibc targets.
gcc/testsuite/
On Mon, Jul 14, 2025 at 11:03 PM Uros Bizjak wrote:
>
> On Tue, Jul 15, 2025 at 3:43 AM H.J. Lu wrote:
> >
> > For MMX 16-bit, 32-bit and 64-bit constant vector loads from constant
> > vector pool:
> >
> > (insn 6 2 7 2 (set (reg:V1SI 5 di)
> > (mem/u/c:V1SI (symbol_ref/u:DI ("*.LC0") [fl
On Wed, 2025-07-16 at 15:58 +0200, Martin Jambor wrote:
> Hello David,
>
> On Fri, Jul 11 2025, David Malcolm wrote:
> > In r16-1631-g2334d30cd8feac I added support for capturing state
> > information from -fanalyzer in XML form, and adding a way to
> > visualize
> > these states in HTML output.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch implements consteval blocks, as specified by P2996.
They aren't very useful without define_aggregate, but having
a reviewed implementation on trunk would be great.
consteval {} can be anywhere where a member-declarat
This pattern enables the combine pass (or late-combine, depending on the case)
to merge a float_extend'ed vec_duplicate into a (possibly negated) minus-mult
RTL instruction.
Before this patch, we have six instructions, e.g.:
vsetivli zero,4,e32,m1,ta,ma
fcvt.s.h fa5,fa5
vfmv.v.f
From: Pan Li
Like the avg3_floor pattern, the avg3_ceil has the
similar issue that lack of the RVV DImode support.
Thus, this patch would like to support the DImode by
the standard name, with the iterator V_VLSI_D.
The below test suites are passed for this patch series.
* The rv64gcv fully regr
On Wed, 16 Jul 2025 at 15:00, Luc Grosheintz wrote:
>
>
>
> On 7/15/25 13:43, Tomasz Kaminski wrote:
> > On Tue, Jul 15, 2025 at 1:35 PM Jonathan Wakely wrote:
> >
> >> OK here are the details for all of the failing tests ...
> >>
> >> std/containers/views/mdspan/aligned_accessor/access.pass.cpp
On 7/15/25 13:43, Tomasz Kaminski wrote:
On Tue, Jul 15, 2025 at 1:35 PM Jonathan Wakely wrote:
OK here are the details for all of the failing tests ...
std/containers/views/mdspan/aligned_accessor/access.pass.cpp
std/containers/views/mdspan/aligned_accessor/ctor.conversion.from.default_a
Hello David,
On Fri, Jul 11 2025, David Malcolm wrote:
> In r16-1631-g2334d30cd8feac I added support for capturing state
> information from -fanalyzer in XML form, and adding a way to visualize
> these states in HTML output. The data was optionally captured in SARIF
> output (with "xml-state=yes"
These three commits fix PR121061. The first prepares the tests, and then
the next two each fix one of the bugs reported in PR121061.
One issue to consider is that the effect of Layout::mapping::operator()
is specified to be equivalent to [1]:
return ((static_cast(i) * stride(P)) + ... + 0);
Wh
PR121061 shows that the test coverage for custom integer types is
insufficient. Custom IndexTypes are passed to mdspan related objects in
one of two ways:
* as a template parameter pack,
* or as an array/span.
These two cases have different requirements on the (constness of) custom
IndexTypes
The second bug report in PR121061 is that the conversion of custom
OtherIndexType to IndexType is incorrectly not done via r-value
references.
This commit fixes the forwarding issue, adds a custom IndexType called
RValueInt, which only allows conversion to int via r-value reference.
PR li
PR121061 consists of two bugs for mdspan related code. This commit fixes
the first one. Namely, when passing custom IndexType as an array or
span, the conversion to int must be const. Prior to this commit the
constraint incorrectly also allowed non-const conversion. This commit
updates all related
When having a _BitInt induction we should make sure to not create
the step vector elements as _BitInts but as vector element typed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR tree-optimization/121116
* tree-vect-loop.cc (vectorizable_induction): Use
The following disables loop masking when we are using an even/odd
widening operation in a reduction because the loop mask then aligns
to the wrong elements.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
If a target implements both even/odd and hi/lo widening we might
want to change s
Hi Mike,
On 16/07/25 7:37 am, Michael Meissner wrote:
> On Tue, Jul 15, 2025 at 08:11:05AM -0500, Segher Boessenkool wrote:
>> Hi!
>>
>> On Tue, Jul 01, 2025 at 12:14:32PM -0400, Michael Meissner wrote:
>>> This patch adds the support that can be used in developing GCC support
>>> for potential fu
PR target/121121
* config/riscv/riscv.cc (riscv_allocate_and_probe_stack_space):
Use temp2 instead of temp1 for the CFA note.
---
gcc/config/riscv/riscv.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv
Andrew Pinski writes:
> r15-6789-ge7f98d9603808b added a new RTL pass for hardreg PRE for the hard
> register
> of FPM_REGNUM, but this pass does nothing if there can be any FPM_REGNUM
> register in it.
> So let's set HARDREG_PRE_REGNOS to include all zeros if !TARGET_FP8.
> Now the pass will on
On Wed, Jul 16, 2025 at 2:06 PM Jonathan Wakely wrote:
> On Wed, 16 Jul 2025 at 12:30, Tomasz Kaminski wrote:
> >
> >
> >
> >
> > On Wed, Jul 16, 2025 at 12:05 PM Jonathan Wakely
> wrote:
> >>
> >> Add comments documenting what it does and how it does it.
> >>
> >> Also reorder the if-else in o
From: Richard Sandiford
SME uses a lazy save system to manage ZA. The idea is that,
if a function with ZA state wants to call a "normal" function,
it can leave its state in ZA and instead set up a lazy save buffer.
If, unexpectedly, that normal function contains a nested use of ZA,
that nested u
On Wed, 16 Jul 2025 at 12:30, Tomasz Kaminski wrote:
>
>
>
>
> On Wed, Jul 16, 2025 at 12:05 PM Jonathan Wakely wrote:
>>
>> Add comments documenting what it does and how it does it.
>>
>> Also reorder the if-else in operator++ so that we check whether to
>> iterate over code units in the local b
The patterns did not accept inline immediate constants, even though the
hardware instructions do, which has lead to some errors in some patches I'm
working on.
Also the VCC update RTL was using the wrong operands in the wrong places. This
appears to have been harmless(?) but is definitely not int
On Wed, Jul 16, 2025 at 12:05 PM Jonathan Wakely wrote:
> Add comments documenting what it does and how it does it.
>
> Also reorder the if-else in operator++ so that we check whether to
> iterate over code units in the local buffer before checking whether to
> refill that buffer. That seems the
On 16/07/25 00:55, Jose E. Marchesi wrote:
Hi Jose,
On 15/07/25 22:55, Jose E. Marchesi wrote:
Hi Piyush.
This form of the script looks generally good to me.
May be a good time to move to the second stage of the project, which
if
I am not mistaken consists in creating some dejagnu infrastructu
On Wed, Jul 16, 2025 at 1:15 PM Jonathan Wakely wrote:
> On Wed, 16 Jul 2025 at 11:47, Tomasz Kaminski wrote:
> >
> >
> >
> > On Wed, Jul 16, 2025 at 12:07 PM Jonathan Wakely
> wrote:
> >>
> >> This change was part of by P2697R1 (Interfacing bitset with string_view)
> >> and should be slightly
On Wed, Jul 16, 2025 at 12:56 PM Jakub Jelinek wrote:
> On Mon, Jul 14, 2025 at 12:11:18PM +0200, Tomasz Kaminski wrote:
> > We have a preference to use [[likely]] attribute when possible.
>
> Done.
>
> > > + for (; __first != __last; ++__first, ++__result)
> > > + {
> > > +
On Wed, 16 Jul 2025 at 11:47, Tomasz Kaminski wrote:
>
>
>
> On Wed, Jul 16, 2025 at 12:07 PM Jonathan Wakely wrote:
>>
>> This change was part of by P2697R1 (Interfacing bitset with string_view)
>> and should be slightly cheaper to instantiate.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * inclu
On 15/07/25 23:03, David Faust wrote:
+DEVELOPMENT
+===
+
+Development dependencies are specified in `pyproject.toml`, which can be used
+with any suitable Python virtual environment manager.
+
+To run the test suite:
+
+python3 -m pytest
Can the tests be run without a pyproject.to
On Mon, Jul 14, 2025 at 12:11:18PM +0200, Tomasz Kaminski wrote:
> We have a preference to use [[likely]] attribute when possible.
Done.
> > + for (; __first != __last; ++__first, ++__result)
> > + {
> > + if constexpr (is_array_v<_Tp>)
> > + std::reloc
On Wed, Jul 16, 2025 at 12:07 PM Jonathan Wakely wrote:
> This change was part of by P2697R1 (Interfacing bitset with string_view)
> and should be slightly cheaper to instantiate.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/bitset (__bitset::__string) [__cpp_lib_bitset]:
> Chang
On Wed, 16 Jul 2025 at 10:54, Tomasz Kamiński wrote:
>
> Do not advertise library support for constexpr exceptions, as our
> solution to throwing by __throw_* functions from ,
> caues constant evaluation to fail, as these functions are not constexpr.
>
> PR libstdc++/121114
>
> libstdc++-v
Asking std::is_constructible_v, NonTrivial*> gives an
error, rather than answering the query. The problem is that the
constructor for std::bitset("010101") is not constrained to only accept
pointers to char-like types, and for the second parameter (which has a
default argument) std::basic_string_vi
This change was part of by P2697R1 (Interfacing bitset with string_view)
and should be slightly cheaper to instantiate.
libstdc++-v3/ChangeLog:
* include/std/bitset (__bitset::__string) [__cpp_lib_bitset]:
Change alias to refer to basic_string_view instead.
---
Tested x86_64-linu
Add comments documenting what it does and how it does it.
Also reorder the if-else in operator++ so that we check whether to
iterate over code units in the local buffer before checking whether to
refill that buffer. That seems the more natural way to structure the
function.
libstdc++-v3/ChangeLog
On Tue, 8 Jul 2025 at 08:20, Jonathan Wakely wrote:
>
>
>
> On Tue, 8 Jul 2025, 08:04 Tomasz Kaminski, wrote:
>>
>> LGTM. Thanks.
>>
>> On Mon, Jul 7, 2025 at 11:09 PM Nathan Myers wrote:
>>>
>>> This adds the new bitset constructor from string_view
>>> defined in P2697 to the debug version of t
Do not advertise library support for constexpr exceptions, as our
solution to throwing by __throw_* functions from ,
caues constant evaluation to fail, as these functions are not constexpr.
PR libstdc++/121114
libstdc++-v3/ChangeLog:
* include/bits/version.def (constexpr_exceptio
Hi!
The following patch attempts to implement the
C++26 P3378R2 - constexpr exception types
paper.
This is quite complicated, because most of these classes which should
be constexpr-ized use solely or mostly out of line definitions in
libstdc++, both for historical, code size and dual ABI reasons,
Kwok Cheung Yeung wrote:
Date: Wed, 27 Nov 2024 21:49:12 +
Subject: [PATCH 01/11] openmp: Refactor handling of iterators
Move code to calculate the iteration size and to generate the iterator
expansion loop into separate functions.
Use OMP_ITERATOR_DECL_P to check for iterators in clause de
Le 16/07/2025 à 00:05, Steve Kargl a écrit :
On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote:
Regression tested on x86_64-pc-linux-gnu.
OK for master?
Yes, with one observation below.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1561936daf1..af62e
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673877.html
Thanks,
Jie
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663001.html
Thanks,
Jie
On Mon, Jul 14, 2025 at 11:01 PM Andrew Pinski wrote:
>
> While starting to improve if-conv, I noticed that predicated
> was only being set once inside a loop and accessed right below.
> This became this way due to r14-8869-g8636c538b68068 and before
> it was needed since it was accessed via 2 loo
On Mon, Jul 14, 2025 at 11:00 PM Andrew Pinski wrote:
>
> This is a small compile time optimization, as match and simplify will generate
> the same thing but with rhs and lhs being the same we can return early instead
> of having to go through match and simplify. This might not show up that much
>
On Mon, Jul 14, 2025 at 7:04 PM Andrew Pinski wrote:
>
> For possible reductions, ifconv currently handles if the addition
> is on one side of the if. But in the case of PR 119920, the reduction
> addition is on both sides of the if.
> E.g.
> ```
> if (_27 == 0)
> goto ; [50.00%]
> else
>
Please refer "MIPS RV64 P8700/P8700-F Multiprocessing System Programmer’s
Guide" for more info on the extension at
https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf
lint warnings can be ignored for riscv-ext.opt.
gcc/ChangeLog:
* confi
>>>I fixed various nits in the ChangeLog to make the pre-commit hooks happy
and pushed this to the trunk.
Thanks a lot Jeff for fixing the Changelog and .md misinformatted (we use
VS Code or VI with tab 4 spaces).
and also use git-fix-changelog.py and check_GNU_style.py formatting ,which
still loo
On 7/9/25 14:43, Jonathan Wakely wrote:
On Thu, 3 Jul 2025 at 11:35, Luc Grosheintz wrote:
This commit implements and tests the function is_sufficiently_aligned
from P2897R7.
libstdc++-v3/ChangeLog:
* include/bits/align.h (is_sufficiently_aligned): New function.
* includ
94 matches
Mail list logo
