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
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
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, 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
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
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
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
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
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 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 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
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
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
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"
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
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
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
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
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
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 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
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
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
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
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 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.
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
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 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
>>>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
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
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
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
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,
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
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
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 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 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 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)
> > > + {
> > > +
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, 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: 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
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
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663001.html
Thanks,
Jie
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673877.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 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
>
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
>
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
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
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
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 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 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
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
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
> 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
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
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
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
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:
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
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
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
-
> 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
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
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
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)
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 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
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 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
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: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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
94 matches
Mail list logo
