On Fri, Jun 21, 2024 at 5:53 AM wrote:
>
> From: Pan Li
>
> The zip benchmark of coremark-pro have one SAT_SUB like pattern but
> truncated as below:
>
> void test (uint16_t *x, unsigned b, unsigned n)
> {
> unsigned a = 0;
> register uint16_t *p = x;
>
> do {
> a = *--p;
> *p = (ui
Monday, June 10, 2024 7:03 PM
Richard Sandiford wrote:
> Thanks for the update. Parts 1-5 look good to me. Some minor comments
> below about part 6:
>
> If the TARGET_DLLIMPORT_DECL_ATTRIBUTES condition can be dropped, the
> series is OK from my POV with that change and with the changes above.
We can optimize (vec_cond eq/ne vec_cond) when vec_cond is a
result of (vec CMP vec). The optimization is because of the
observation that in vec_cond, (-1 != 0) is true. So, we can
generate vec_cond of xor of vec resulting in a single
VEC_COND_EXPR instead of 3.
The patch adds match pattern for ve
On Jun 20, 2024, Christophe Lyon wrote:
> Maybe using
> if ((unsigned)b[i] >= BITS) \
> would be clearer?
Heh. Why make it simpler if we can make it unreadable, right? :-D
Thanks, here's another version I've just retested on x-arm-eabi. Ok?
I'm not sure how to credit your suggestion. It's n
On Fri, Jun 21, 2024 at 9:12 AM Eikansh Gupta wrote:
>
> We can optimize (vec_cond eq/ne vec_cond) when vec_cond is a
> result of (vec CMP vec). The optimization is because of the
> observation that in vec_cond, (-1 != 0) is true. So, we can
> generate vec_cond of xor of vec resulting in a single
Oleg Endo writes:
> On Thu, 2024-06-20 at 14:34 +0100, Richard Sandiford wrote:
>>
>> I tried compiling at least one target per CPU directory and comparing
>> the assembly output for parts of the GCC testsuite. This is just a way
>> of getting a flavour of how the pass performs; it obviously isn
Alex Coplan writes:
> Hi Richard,
>
> I had a quick look through the patch and noticed a couple of minor typos.
> Otherwise looks like a nice cleanup!
Thanks for the review! I've fixed the typos in my local copy.
Richard
> On 20/06/2024 14:34, Richard Sandiford wrote:
>> rtl-ssa has routines f
Richard Biener writes:
> [...]
> I wonder if you can amend doc/passes.texi, specifically noting differences
> between fwprop, combine and late-combine?
Ooh, we have a doc/passes.texi? :) Somehow missed that.
How about the patch below?
Thanks,
Richard
diff --git a/gcc/doc/passes.texi b/gcc/do
On Tue, 22 Mar 2022, Pokechu22 via Gcc-patches wrote:
> --- a/htdocs/branch-closing.html
> +++ b/htdocs/branch-closing.html
> @@ -54,7 +54,7 @@ is listed in "Known to work" or "Known to fail" as
> applicable.
> If the bug is a regression that is not fixed on all subsequent
> release branches and
---
htdocs/news.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index 4a6c2ab3..471b31b7 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -168,7 +168,7 @@
BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate
Languag
Thanks Richard for comments.
> to match this by changing it to
> /* Unsigned saturation sub, case 2 (branch with ge):
>SAT_U_SUB = X >= Y ? X - Y : 0. */
> (match (unsigned_integer_sat_sub @0 @1)
> (cond^ (ge @0 @1) (convert? (minus @0 @1)) integer_zerop)
> (if (INTEGRAL_TYPE_P (type) && TY
From: Justin Squirek
This patch fixes a spurious error in the compiler when checking for style for
token separation where two square brackets are next to each other.
gcc/ada/
* csets.ads (Identifier_Char): New function - replacing table.
* csets.adb (Identifier_Char): Rename and
From: Piotr Trojanek
When the expression of aspect Default_Component_Value includes a declare
expression with current type instance, we attempted to recursively froze
that type, which itself caused an infinite recursion, because we didn't
properly manage the scope of declare expression.
This pat
From: Piotr Trojanek
Code cleanup; semantics is unaffected.
gcc/ada/
* sem_ch3.adb (Add_Interface_Tag_Components): Simplify with No.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_ch3.adb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada
From: Eric Botcazou
The problem is that the handling of the interaction between packing and
aliased/atomic/independent components of an array type is tied to that of
the interaction between a component clause and aliased/atomic/independent
components, although the semantics are different: packing
From: Eric Botcazou
This adds the missing guard to prevent the reduction from being used when
the target does not provide or cannot synthesize a high-part multiply.
gcc/ada/
* gcc-interface/trans.cc (gnat_to_gnu) : Fix formatting.
* gcc-interface/utils2.cc: Include optabs-query.
From: Steve Baird
In some cases, a predefined operator (e.g., the "+" operator for an
integer type) is incorrectly treated as being directly visible when
it is not. This can lead to both accepting operator uses that should
be rejected and also to incorrectly rejecting legal constructs as ambiguou
From: Eric Botcazou
The assertion fails because the Original_Node of the expression has no Etype
since its an unanalyzed identifier.
gcc/ada/
* accessibility.adb (Accessibility_Level): Apply the processing to
Expr when its Original_Node is an unanalyzed identifier.
Tested on x8
From: Javier Miranda
When a package has the declaration of a derived tagged
type T with private null extension that inherits a public
function F with controlling result, and a derivation of T
is declared in the public part of another package, overriding
function F may be rejected by the compiler.
From: Eric Botcazou
The Do_Range_Check flag is properly set on the Expression of the EWA node
built for the declare expression, so this instructs Generate_Index_Checks
to look into this Expression.
gcc/ada/
* checks.adb (Generate_Index_Checks): Add specific treatment for
index e
From: Bob Duff
The only substantive change is to remove Activation_Chain_Entity
from N_Generic_Package_Declaration. The comment in sinfo.ads suggesting
this change was written in 1993!
Various pieces of missing documentation are added to Sinfo and Einfo.
Also other minor cleanups.
gcc/ada/
From: Eric Botcazou
This occurs when the bounds of the array component depend on a discriminant
and the component reference is not nested, that is to say the component is
not (referenced as) a subcomponent of a larger record.
In this case, Analyze_Selected_Component does not build the actual sub
From: Doug Rupp
The conditional installation resulted in a semantic change, and
although it is likely what is ultimately wanted (since HW interrupts
are being reworked on VxWorks). However it must be done in concert
with other modifications for the new formulation of HW interrupts and
not in isol
From: Eric Botcazou
This implements modulo reduction for nonbinary modular multiplication with
small moduli by means of the standard division-free algorithm also used in
the optimizer, but with fewer constraints and therefore better results.
For the sake of consistency, it is also used for the '
From: Ronan Desplanques
gcc/ada/
* sem_util.adb (Examine_Array_Bounds): Add missing return
statements. Fix criterion for a string literal being empty.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_util.adb | 4 +++-
1 file changed, 3 insertions(+), 1 dele
From: Eric Botcazou
The processing of primitive operations is now always uniform for tagged and
untagged types, but the code contains left-overs from the time where it was
specific to tagged types, in particular for the handling of subtypes.
gcc/ada/
* einfo.ads (Direct_Primitive_Operat
From: Javier Miranda
When a non-overridable aspect is explicitly specified for a
non-tagged derived type, the compiler blows up processing an
object declaration of an object of such type.
gcc/ada/
* sem_ch13.adb (Analyze_One_Aspect): Fix code locating the entity
of the parent ty
From: Eric Botcazou
The Address Sanitizer considers that the padding at the end of a justified
modular type may be accessed through the object, but it is never accessed
and therefore can always be reused.
gcc/ada/
* gcc-interface/decl.cc (gnat_to_gnu_entity) : Set
the TYPE_JUSTI
On 2024-06-21 12:24 juzhe.zhong wrote:
>
>+ if (*group.shape == shapes::loadstore
>+ || *group.shape == shapes::indexed_loadstore
>+ || *group.shape == shapes::vundefined
>+ || *group.shape == shapes::misc
>+ || *group.shape == shapes::vset
>+ || *group.shape == shapes::
From: Eric Botcazou
This is the minimal fix to avoid the crash.
gcc/ada/
* bcheck.adb (Check_Consistency_Of_Sdep): Guard against path to ALI
file not found.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/bcheck.adb | 10 +++---
1 file changed, 7 insertion
From: Eric Botcazou
We set DECL_BIT_FIELD optimistically during the translation of record types
and clear it afterward if needed, but fail to clear other attributes in the
latter case, which fools the logic of the Address Sanitizer.
gcc/ada/
* gcc-interface/utils.cc (clear_decl_bit_fiel
From: Javier Miranda
When the interpolated expression is a call to an ambiguous call
the frontend does not reject it; erroneously accepts the call
and generates code that calls to one of them.
gcc/ada/
* sem_ch2.adb (Analyze_Interpolated_String_Literal): Reject
ambiguous functio
From: Eric Botcazou
It occurs when the body of a protected subprogram is processed, because the
references to the components of the type have not been properly expanded.
gcc/ada/
* gcc-interface/trans.cc (Subprogram_Body_to_gnu): Also return early
for a protected subprogram in -
Include the invalid path in the error message.
gcc/ada/
* make.adb (Scan_Make_Arg): Adjust error message.
* gnatls.adb (Search_RTS): Likewise.
* switch-b.adb (Scan_Debug_Switches): Likewise.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/gnatls.adb |
"Maciej W. Rozycki" writes:
> Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
> with a register, because the value of -1 is actually a valid reference
> to register 0 in the case where it has not been assigned a quantity.
>
> Using -1 makes `REG_QTY (REGNO (folded_arg1
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a warning from one of the test allocators:
warning: base class 'class std::allocator<__gnu_test::copy_tracker>' should be
explicitly initialized in the copy constructor [-Wextra]
libstdc++-v3/ChangeLog:
* testsuite/util/testsuit
Pushed to trunk now. Backport to gcc-14 needed too.
On Thu, 20 Jun 2024 at 16:27, Jonathan Wakely wrote:
>
> This unfortunately means we can never increase __cpp_lib_chrono again
> for the old string ABI, but I don't see any alternative (except
> supporting chrono::tzdb for the old string, which
Pushed to trunk now.
On Wed, 19 Jun 2024 at 17:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Not pushed yet. backports will be needed too.
>
> -- >8 --
>
> Due to PR c++/85723 the std::is_trivial trait is true for types with a
> deleted default constructor, so the use of std::is_trivial in
YunQiang Su writes:
> We check gcc_cv_as_mips_explicit_relocs if
> gcc_cv_as_mips_explicit_relocs_pcrel
> only, while gcc_cv_as_mips_explicit_relocs is used by later code.
>
> Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> as it has been in Binutils for more than 20
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/backward/backward_warning.h: Adjust comments to
> suggest as another alternative to .
> * include/backward/strstream (
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> These were deprecated in C++17 and std::wstring_convert is planned for
> removal in C++26.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/locale_conv.h (wstring_convert): Ad
Pusahed to trunk now.
On Thu, 20 Jun 2024 at 16:41, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This member function was previously deprecated, but that was reverted by
> P2875R4, approved earlier this year in Tokyo. Since it's not going to be
> deprecated in C++26, and so pr
I see, it's operator== overloaded.
LGTM.
juzhe.zh...@rivai.ai
From: wangf...@eswincomputing.com
Date: 2024-06-21 17:03
To: juzhe.zhong; gcc-patches
CC: kito.cheng; jinma.contrib
Subject: Re: Re: [PATCH 2/3] RISC-V: Add Zvfbfmin and Zvfbfwma intrinsic
On 2024-06-21 12:24 juzhe.zhong wrote:
>
Tested x86_64-linux. Pushed to trunk. Probably worth backporting.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (uninitialized_default_construct)
(uninitialized_default_construct_n, uninitialized_value_construct)
(uninitialized_value_construct_n): Qu
Pushed to trunk now. I might backport this later too.
On Thu, 20 Jun 2024 at 16:39, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> LWG 3305 was approved earlier this year in Tokyo. We need to give an
> error if using std::any_cast, but std::any_cast is valid
> (but always retur
On Fri, Jun 21, 2024 at 10:21 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > [...]
> > I wonder if you can amend doc/passes.texi, specifically noting differences
> > between fwprop, combine and late-combine?
>
> Ooh, we have a doc/passes.texi? :) Somehow missed that.
Yeah, I also us
On Fri, Jun 21, 2024 at 10:50 AM Li, Pan2 wrote:
>
> Thanks Richard for comments.
>
> > to match this by changing it to
>
> > /* Unsigned saturation sub, case 2 (branch with ge):
> >SAT_U_SUB = X >= Y ? X - Y : 0. */
> > (match (unsigned_integer_sat_sub @0 @1)
> > (cond^ (ge @0 @1) (convert?
Oops, this patch series actually depends on
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html which
was posted separately, but needs to be applied before 4/4 in this
series.
On Thu, 20 Jun 2024 at 16:35, Jonathan Wakely wrote:
>
> We still have __is_arithmetic in after this,
> but
On Thu, 20 Jun 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 17 Jun 2024, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Fri, 14 Jun 2024, Richard Biener wrote:
> >> >
> >> >> On Fri, 14 Jun 2024, Richard Sandiford wrote:
> >> >>
> >> >> > Richard Biene
On 21/06/2024 08:57, Alexandre Oliva wrote:
> On Jun 20, 2024, Christophe Lyon wrote:
>
>> Maybe using
>> if ((unsigned)b[i] >= BITS) \
>> would be clearer?
>
> Heh. Why make it simpler if we can make it unreadable, right? :-D
>
> Thanks, here's another version I've just retested on x-arm-eabi
Hi,
Sorry about the delay in my answer! The patch looks good to me :) Will
you push it as part of your patchset?
Kindly,
Arthur
On 6/3/24 05:00, Kewen Lin wrote:
Joseph pointed out "floating types should have their mode,
not a poorly defined precision value" in the discussion[1],
as he and
Hi Arthur,
on 2024/6/21 18:17, Arthur Cohen wrote:
> Hi,
>
> Sorry about the delay in my answer! The patch looks good to me :) Will you
> push it as part of your patchset?
>
Thanks for the review! Since this one doesn't necessarily depend on
"09/52 Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE wit
Hi Carl,
on 2024/6/20 00:13, Carl Love wrote:
> GCC maintainers:
>
> version 2: Updated per the feedback from Peter, Kewen and Segher. Note,
> Peter suggested the -mdejagnu-cpu= value must be power7.
> The test fails if -mdejagnu-cpu= is set to power7, needs to be power8. Patch
> has been
Hi Jeff,
on 2024/6/13 10:19, Jiufu Guo wrote:
> Hi,
>
> Sometimes, a complicated constant is built via 3(or more)
> instructions. Generally speaking, it would not be as fast
> as loading it from the constant pool (as the discussions in
> PR63281):
> "ld" is one instruction. If consider "address
Hi Carl,
on 2024/6/20 00:18, Carl Love wrote:
> GCC maintainers:
>
> The dg options for this test should be the same as for altivec-2-runnable.c.
> This patch updates the dg options to match
> the settings in altivec-2-runnable.c.
>
> The patch has been tested on Power 10 with no regression f
Hi Haochen,
on 2024/5/24 14:02, HAO CHEN GUI wrote:
> Hi,
> This patch implemented optab_isinf for SFDF and IEEE128 by test
> data class instructions.
>
> Compared with previous version, the main change is to narrow
> down the predict for float operand according to review's advice.
> https://
> Michal Jires writes:
>
> No performance data?
Michal has bachelor thesis on the topic which has some statistics
https://dspace.cuni.cz/handle/20.500.11956/183051?locale-attribute=en
>
> > +
> > +static const md5_checksum_t INVALID_CHECKSUM = {
> > + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
These tests check the sched2 dump, so skip them for optimization levels
that do not enable sched2.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mcpu-6.c: Skip for -O0, -O1, -Og.
* gcc.target/riscv/mcpu-7.c: Likewise.
---
gcc/testsuite/gcc.target/riscv/mcpu-6.c | 1 +
gcc/testsuite
LGTM, thanks :)
On Fri, Jun 21, 2024 at 7:33 PM Craig Blackmore <
craig.blackm...@embecosm.com> wrote:
> These tests check the sched2 dump, so skip them for optimization levels
> that do not enable sched2.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/mcpu-6.c: Skip for -O0, -O1, -O
For outer loop vectorization of a data reference in the inner loop
we have to look at both steps to see if they preserve alignment.
What is special for this testcase is that the outer loop step is
one element but the inner loop step four and that we now use SLP
and the vectorization factor is one.
On Fri, 21 Jun 2024, YunQiang Su wrote:
> > Then GCC emits the wrong trap instruction, wherever it comes from and
> > whatever has caused it. The correct ones for integer division by zero
>
> Thanks so much. It is not the bug of Linux kernel or GCC.
> It is a bug of me ;) and qemu.
>
> Qemu di
Hi!
Here is an incremental patch which adds support for string concatenation
in the parsing of gnu::base64 #embed parameter and emits it as well
in -E -fdirectives-only preprocessing, e.g.
cat embed-do.c; ./cc1 -quiet -E -fdirectives-only embed-do.c -nostdinc
#embed "/usr/src/gcc/gcc/tree-ssa-dce.
On Fri, 21 Jun 2024, Richard Sandiford wrote:
> > We check gcc_cv_as_mips_explicit_relocs if
> > gcc_cv_as_mips_explicit_relocs_pcrel
> > only, while gcc_cv_as_mips_explicit_relocs is used by later code.
> >
> > Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> > as it
When adding validation of .sarif files against the schema
(PR testsuite/109360) I discovered various issues where we were
generating invalid .sarif files.
Specifically, in
c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c
the relatedLocations for the "note" diagnostics were missing
This patch extends the dg directive verify-sarif-file so that if
the "jsonschema" tool is available, it will be used to validate the
generated .sarif file.
Tested with jsonschema 3.2 with Python 3.8
With the previous patch, all files generated by the DejaGnu testsuite
validate.
There were no val
With the earlier rework of VRP which removed the array_bounds pass, it
is now possible to invoke a different VRP for any pass. This patch adds
the ability to call fast_vrp with the final_pass flag set, and remove
invoke the remove_unreachable object to remove __builtin_unreachable
calls if it i
I found that I was frequently writing the same hunk of code which checks
the result of set_range_info() and and prints the global range to the
dump_file when it is updated.
This routine only returns true if the value provided improves the
range. Ie, 'old_value' intersect 'new_value' != '
This patch changes the algorithm for fast VRP. When looking at PR
114855, although VRP is not the main culrpit, it is taking about 600
seconds out of the 10,000.. far more than it should. That test case has
about 400,000 basic blocks, and when we get into that size, some of the
tables and such
This patch adds
--param=vrp-block-limit=N
When the basic block counter for a function exceeded 'N' , VRP is
invoked with the new fast_vrp algorithm instead. This algorithm uses a
lot less memory and processing power, although it does get a few less
things.
Primary motivation is cases
Hi all,
it turned out that 'declare target' with 'link' clause was broken in multiple
ways.
The main fix is the attached patch, i.e. namely pushing the variables already to
the offload-vars list already in the FE.
When implementing it, I noticed:
* C has a similar issue when using nested funct
On Fri, 21 Jun 2024 at 12:14, Richard Earnshaw (lists)
wrote:
>
> On 21/06/2024 08:57, Alexandre Oliva wrote:
> > On Jun 20, 2024, Christophe Lyon wrote:
> >
> >> Maybe using
> >> if ((unsigned)b[i] >= BITS) \
> >> would be clearer?
> >
> > Heh. Why make it simpler if we can make it unreadable,
Evgeny Karpov writes:
> Monday, June 10, 2024 7:03 PM
> Richard Sandiford wrote:
>
>> Thanks for the update. Parts 1-5 look good to me. Some minor comments
>> below about part 6:
>>
>> If the TARGET_DLLIMPORT_DECL_ATTRIBUTES condition can be dropped, the
>> series is OK from my POV with that c
On Fri, 21 Jun 2024, Maciej W. Rozycki wrote:
> > Yeah, agreed FWIW. This was necessary while the feature was relatively
> > new, and while we still supported IRIX as, but I can't see any reasonable
> > justification for using such an ancient binutils with modern GCC.
> >
> > Getting rid of -mno
Maciej W. Rozycki 于2024年6月21日周五 20:55写道：
>
> On Fri, 21 Jun 2024, Richard Sandiford wrote:
>
> > > We check gcc_cv_as_mips_explicit_relocs if
> > > gcc_cv_as_mips_explicit_relocs_pcrel
> > > only, while gcc_cv_as_mips_explicit_relocs is used by later code.
> > >
> > > Maybe, it is time for use to
Maciej W. Rozycki 于2024年6月21日周五 22:00写道：
>
> On Fri, 21 Jun 2024, Maciej W. Rozycki wrote:
>
> > > Yeah, agreed FWIW. This was necessary while the feature was relatively
> > > new, and while we still supported IRIX as, but I can't see any reasonable
> > > justification for using such an ancient b
> >
> > And FAOD I think a stub check has to remain even after the removal and
> > just cause `configure' to bail out if an unsupported obsolete version of
> > GAS has been identified.
> >
Ohh, I think that we shouldn't remove it now, as I have figure out
the PCREL patch,
and I am still waiting
Richard Biener writes:
> On Thu, 20 Jun 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Mon, 17 Jun 2024, Richard Sandiford wrote:
>> >
>> >> Richard Biener writes:
>> >> > On Fri, 14 Jun 2024, Richard Biener wrote:
>> >> >
>> >> >> On Fri, 14 Jun 2024, Richard Sandiford wrote
On 6/20/24 7:34 AM, Richard Sandiford wrote:
No-op moves are given the code NOOP_MOVE_INSN_CODE if we plan
to delete them later. Such insns shouldn't be costed, partly
because they're going to disappear, and partly because targets
won't recognise the insn code.
gcc/
* rtl-ssa/changes
On 6/20/24 7:34 AM, Richard Sandiford wrote:
All uses of xs_hi_nonmemory_operand allow constraint "i",
which means that they allow consts, symbol_refs and label_refs.
The definition of xs_hi_nonmemory_operand accounted for consts,
but not for symbol_refs and label_refs.
gcc/
* config/
On 6/20/24 7:34 AM, Richard Sandiford wrote:
The iq2000 test and branch instructions had patterns like:
[(set (pc)
(if_then_else
(eq (and:SI (match_operand:SI 0 "register_operand" "r")
(match_operand:SI 1 "power_of_2_operand" "I"))
(const
On 6/20/24 7:34 AM, Richard Sandiford wrote:
rtl-ssa has routines for scanning forwards or backwards for something
under the control of an exclusion set. These searches are currently
used for two main things:
- to work out where an instruction can be moved within its EBB
- to work out whethe
Thanks Richard for suggestion, tried the (convert? with below gimple stmt but
got a miss def ice.
To double confirm, the *type_out should be the vector type of lhs, and we only
need to build
one cvt stmt from itype to otype here. Or just return the call directly and set
the type_out to the v_oty
Presently, the code fragment:
int x[5];
void
d(int a, int b, int c) {
for (int i = 0; i < 5; i++)
x[i] = (a != b) ? c : a;
}
causes an ICE when compiled with -O2 -march=rv32i_zicond:
test.c: In function 'd':
test.c: error: unrecognizable insn:
11 | }
| ^
(insn 8 5 9 2 (set (reg:S
On 6/20/24 7:34 AM, Richard Sandiford wrote:
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
The pass currently has a single objective: remove definitions by
substituting into all uses. The pre-
* Running a test compiled with AVX512 instructions requires
avx512f_runtime not just avx512f.
* The 'reduce2' test violated an invariant of fixed_size_simd_mask and
thus failed on all targets without 16-Byte vector builtins enabled (in
bits/simd.h).
Signed-off-by: Matthias Kretz
libstdc++-v3/C
mkoffload's generated .c file looks much nicer with '#embed'.
This patch depends on Jakub's #embed patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
It might be a tiny bit faster than currently (or not); however,
once #embed has a large-file mode, it should also speed up
t
On 6/19/24 9:43 PM, Christoph Müllner wrote:
Hi Jeff,
the test should probably also be skipped on -Oz:
=== gcc: Unexpected fails for rv64imafdc lp64d medlow ===
FAIL: gcc.target/riscv/zbs-ext-2.c -Oz scan-assembler-times andi\t 1
FAIL: gcc.target/riscv/zbs-ext-2.c -Oz
[I messed up copying from the build system, picking up an old version.
Changes to v1 (bottom of the diff): fopen is no longer required.]
Tobias Burnus wrote:
mkoffload's generated .c file looks much nicer with '#embed'.
This patch depends on Jakub's #embed patch at
https://gcc.gnu.org/pipermail
On Fri, 21 Jun 2024 at 16:07, Matthias Kretz wrote:
>
>
> * Running a test compiled with AVX512 instructions requires
> avx512f_runtime not just avx512f.
>
> * The 'reduce2' test violated an invariant of fixed_size_simd_mask and
> thus failed on all targets without 16-Byte vector builtins enabled
On 21/06/2024 16:30, Tobias Burnus wrote:
[I messed up copying from the build system, picking up an old version.
Changes to v1 (bottom of the diff): fopen is no longer required.]
Tobias Burnus wrote:
mkoffload's generated .c file looks much nicer with '#embed'.
This patch depends on Jakub's #e
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:28, Jonathan Wakely wrote:
>
> I think the new conditions are correct. They're certainly an improvment
> on just checking __is_scalar without considering what we're assigning it
> to.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> As noted in the PR, the
This series (and the patch it depends on) have been pushed to trunk now.
On Fri, 21 Jun 2024 at 10:31, Jonathan Wakely wrote:
>
> Oops, this patch series actually depends on
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html which
> was posted separately, but needs to be applied b
Hi Feng,
Pre-commit has flagged a build-failure for patch 2/3:
https://github.com/ewlu/gcc-precommit-ci/issues/1786#issuecomment-2181962244
When applied to 9a76db24e04 i386: Allow all register_operand SUBREGs in
x86_ternlog_idx.
Re-confirmed locally with 5320bcbd342 xstormy16: Fix
xs_hi_nonm
On 6/20/24 7:45 PM, Andi Kleen wrote:
There are much faster/optimized modern hashes for good collision detection over
MD5 especially when it's not needed to be cryptographically secure. Pick
something from smhasher.
Also perhaps the check sum should be cached in the file? I assume it's
cheap to
Kewen:
On 6/21/24 03:36, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/20 00:13, Carl Love wrote:
>> GCC maintainers:
>>
>> version 2: Updated per the feedback from Peter, Kewen and Segher. Note,
>> Peter suggested the -mdejagnu-cpu= value must be power7.
>> The test fails if -mdejagnu-cpu= is s
GCC maintainers:
Per the discussion of the dg header changes for test files altivec-1-runnable.c
and altivec-2-runnable.c it was decided it would be best to change the names of
the two tests to better align them with the tests that they are better aligned
with.
This patch is dependent on the t
Kewen:
On 6/21/24 03:37, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/20 00:18, Carl Love wrote:
>> GCC maintainers:
>>
>> The dg options for this test should be the same as for altivec-2-runnable.c.
>> This patch updates the dg options to match
>> the settings in altivec-2-runnable.c.
>>
>> The
GCC maintainers:
version 2, update the dg options per the feedback. Retested the patch on Power
10 with no regressions.
This patch updates the dg options.
The patch has been tested on Power 10 with no regression failures.
Please let me know if this patch is acceptable for mainline. Thanks.
FWIW I suspect not handling lockfile errors could be a show stopper
even for an initial implementation. It's not that uncommon that people
press Ctrl-C. flock on systems that have it would be a safer
alternative.
> There are many things to do and I think it is better to do that in trunk
> rahte
On Fri, Jun 21, 2024 at 06:59:05PM +0200, Michal Jireš wrote:
> > The lockfiles scare me a bit. What happens when they get lost, e.g.
> > due to a compiler crash? You may need some recovery for that.
> > Perhaps it would be better to make the files self checking, so that
> > partial files can be de
1 - 100 of 115 matches
Mail list logo
