Hi Carl,
on 2024/6/22 00:15, Carl Love wrote:
> GCC maintainers:
>
> version 4: Additional dg option updates per the feedback. Retested the
> patch on Power 10, no regressions.
>
> version 3: Updated per the feedback from Peter, Kewen and Segher. Note,
> Peter sugges
Hi
Still no time ?
Thanks
On 06/06/2024 19:02, François Dumont wrote:
No chance ?
On 22/05/2024 06:50, François Dumont wrote:
Ping ?
On 13/05/2024 06:33, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the
Hi,
on 2024/6/22 00:15, Carl Love wrote:
> 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 regressi
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_enumeration_type DIEs into LF_ENUM symbols.
gcc/
* dwarf2codeview.cc (MAX_FIELDLIST_SIZE): Define.
(struct codeview_integer): New structure.
(struct codeview_subtype): Likewise
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translate DW_TAG_const_type and DW_TAG_volatile_type DIEs into
LF_MODIFIER symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_modifier to union.
(write_cv_padding, write_lf_modifier):
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_pointer_type DIEs into LF_POINTER symbols, which get
output into the .debug$T section.
gcc/
* dwarf2codeview.cc (FIRST_TYPE): Define.
(struct codeview_custom_type): New structure.
On 6/17/24 6:17 PM, Mark Harmstone wrote:
gcc/
* dwarf2codeview.cc (get_type_num): Handle typedefs.
Thanks. I've pushed this to the trunk.
jeff
.
Thanks. I've pushed this patch to the trunk.
jeff
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Parse the DW_TAG_variable DIEs, and outputs S_GDATA32 (for global variables)
and S_LDATA32 (static global variables) symbols into the .debug$S section.
gcc/
* dwarf2codeview.cc (S_LDATA32, S_GDATA32): Define.
(struct
> I think the check for TYPE_UNSIGNED should be of TREE_TYPE (@0) rather
> than type here.
Changed
> Or maybe you need `types_match (type, TREE_TYPE (@0))` too.
And use tree_nop_conversion_p (type, TREE_TYPE (@0)) and add view_convert to
rshift.
Bootstrapped and regtested on
Dear all,
the attached patch fixes issues exhibited by the testcase in comment#19 of
PR55978.
First, when passing an allocatable optional dummy array to an optional dummy,
we need to prevent accessing the data component of the array when the argument
is not present, and pass a null pointer
ing this optimization.
The code snippet mentioned above is also included in this patch as a new Zicond
testcase.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_conditional_move): Add a
CONST0_RTX check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zicond-ice-3.c:
This adds an explicit error message for [static] and [static*]
(the same as clang has) instead of the generic "error: expected
expression before ']' token", which is not entirely accurate.
For function definitions the subsequent error "[*] can not be
used outside function prototype scope" is
Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and
document missing _UCRT macro and msvcr71* case.
Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00.
gcc/
* config/i386/mingw-w64.h (CPP_SPEC): Add missing -mcrtdll=
cases: msvcr40*, msvcrtd*.
* config/mingw/mingw32.h
be transformed as:
>> +
>> + vector<4> int sum_v0 = { 0, 0, 0, 0 };
>> + vector<4> int sum_v1 = { 0, 0, 0, 0 };
>> + vector<4> int sum_v2 = { 0, 0, 0, 0 };
>> + vector<4> int sum_v3 = { 0, 0, 0, 0 };
c: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] Ifcvt: Add cond tree reconcile for truncated .SAT_SUB
On Fri, Jun 21, 2024 at 4:45 PM Li, Pan2 wrote:
>
> Thanks Richard for suggestion, tried
The compare_repeat_factors comparator fails qsort checking eventually
because it uses rf2->rank - rf1->rank to compare unsigned numbers
which causes issues for ranks that interpret negative as signed.
Fixed by re-writing the obvious way. I've also fixed the count
comparison which suffers from
This should fix the test failures introduced by the fix for PR115157.
Tested on x86_64 and also tested with -m32.
Fix test errors introduced with fix for PR115157.
Fix tests introduced when fixing PR115157 that assume
sizeof(enum)==sizeof(int)
by adding the flag
The following makes sure to always CSE when there's SLP_TREE_SCALAR_STMTS
as otherwise a chain of two-operator node operations can result in
exponential behavior of the CSE process as likely seen when building
510.parest on aarch64.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
wrote:
>
> Takayuki 'January June' Suwa writes:
> > On 2024/06/20 22:34, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs late in the pipeline.
> >> There are two instances: one between combine
This fixes the test failures introduced by the fix for PR115109.
Tested on x86_64 and also tested with -m32.
Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]
Some tests added to test the type of redeclarations of enumerators
in r15-1394 fail on
On Sat, Jun 22, 2024 at 5:49 AM Collin Funk wrote:
>
> Hi Hongtao,
>
> I submitted a patch silencing -Wshift-overflow on a signed int
> constant here:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654016.html
>
> You OK'd it here:
>
> https://
Hi!
On 2024/06/23 1:49, Richard Sandiford wrote:
Takayuki 'January June' Suwa writes:
On 2024/06/20 22:34, 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
On 6/21/24 5:31 AM, Craig Blackmore 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, -Og.
* gcc.target/riscv/mcpu-7.c: Likewise.
Thanks. I've
On 6/19/24 9:28 PM, demin.han wrote:
We can unify eqne and other comparison operations.
Tested on RV32 and RV64.
gcc/ChangeLog:
* config/riscv/predicates.md (comparison_except_eqge_operator): Only
exclude ge
(comparison_except_ge_operator): Ditto
*
On 6/20/24 10:31 AM, Patrick O'Neill wrote:
This introduces testsuite support infra for removing extensions.
Since z* extensions don't have ordering requirements the logic for
adding/removing those extensions has also been consolidated.
This fixes RVWMO compile testcases failing on Ztso
From: Shengdun Wang
The mcf thread has already linked to -lntdll, and it's confirmed that even
Windows 95 includes ntdll.dll. Additionally, if users do not use any functions
from ntdll directly, the inclusion of -lntdll does not result in linking to it.
Therefore, I propose making it a
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
libstdc++-v3/ChangeLog:
* src/c++11/assert_fail.cc:
---
libstdc++-v3/src/c++11/assert_fail.cc | 13 +
1 file changed, 9
From: Shengdun Wang
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
libstdc++-v3/ChangeLog:
* src/c++11/assert_fail.cc:
---
libstdc++-v3/src/c++11/assert_fail.cc | 13 +
1
From: Shengdun Wang
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
libstdc++-v3/ChangeLog:
* src/c++11/assert_fail.cc:
---
libstdc++-v3/src/c++11/assert_fail.cc | 13 +
1
vation 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 vec a, b:
> > (a ? -1 : 0) != (b ? -1 : 0) --> (a^b) ? -1 : 0
> > (a ? -
When musttail is set, make tree-tailcall give error messages
when it cannot handle a call. This avoids vague "other reasons"
error messages later at expand time when it sees a musttail
function not marked tail call.
In various cases this requires delaying the error until
the call is discovered.
gcc/ChangeLog:
* tree-tailcall.cc (maybe_error_musttail): Print reason to
dump_file.
(find_tail_calls): Print gimple stmt or other reasons that stop
the search for tail calls into dump file.
---
gcc/tree-tailcall.cc | 17 -
1 file changed, 16
gcc/ChangeLog:
* doc/extend.texi: Document [[musttail]]
---
gcc/doc/extend.texi | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b2e41a581dd1..f83e643da19c 100644
--- a/gcc/doc/extend.texi
+++
Move the error reporting for caller attributes to be
after the tail call discovery, so that we can give proper
error messages tagged to the calls.
gcc/ChangeLog:
* tree-tailcall.cc (maybe_error_musttail): Declare.
(suitable_for_tail_opt_p): Take call and report errors.
Enable the tailcall optimization for non optimizing builds,
but in this case only checks calls that have the musttail attribute set.
This makes musttail work without optimization.
This is done with a new late musttail pass that is only active when
not optimizing. The new pass relies on tree-cfg
Some adopted from the existing C musttail plugin tests.
gcc/testsuite/ChangeLog:
* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
*
The musttail error messages are reported to the user, so must be
translated.
gcc/ChangeLog:
* calls.cc (initialize_argument_information): Mark messages
for translation.
(can_implement_as_sibling_call_p): Dito.
(expand_call): Dito.
---
gcc/calls.cc | 56
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
PR83324
gcc/c/ChangeLog:
* c-parser.cc (struct attr_state): Define with musttail_p.
(c_parser_statement_after_labels): Handle [[musttail]]
Some of the cfg fixups in pro_and_epilogue for sibcalls were dependent on
"optimize".
Make them check cfun->tail_call_marked instead to handle the -O0 musttail
case. This fixes the musttail test cases on arm targets.
PR115255
gcc/ChangeLog:
* function.cc
It does nothing currently since statement attributes are handled
directly in the parser.
gcc/c-family/ChangeLog:
* c-attribs.cc (handle_musttail_attribute): Add.
* c-common.h (handle_musttail_attribute): Add.
---
gcc/c-family/c-attribs.cc | 15 +++
- Give error messages for all causes of non sibling call generation
- When giving error messages clear the musttail flag to avoid ICEs
- Error out when tree-tailcall failed to mark a must-tail call
sibcall. In this case it doesn't know the true reason and only gives
a vague message.
Takayuki 'January June' Suwa writes:
> On 2024/06/20 22:34, 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 current
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 noticed there was a warning from clang about int_range's
dtor being marked as final saying the class cannot be inherited from.
So let's mark the few ranger classes as final for those which we know
will be final.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
*
The recent change to relax store motion for variables that cannot have
store data races broke the optimization to share flag vars for stores
that all happen in the same single BB. The following fixes this.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR
Pan
>
>
> -Original Message-----
> From: Richard Biener
> Sent: Friday, June 21, 2024 5:29 PM
> To: Li, Pan2
> Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
> jeffreya...@gmail.com; rdapp@gmail.com
> Subject: Re: [PATCH v1] Ifcvt:
On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod wrote:
>
> 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 mem
This patch adds an alternative to ARC's *movsicc_insn to improve register
allocation by allowing the input operands to be swapped by reversing the
condition of the conditional move. A example of the benefits can be
seen in the expansion of DImode shifts, where x << y currently gen
YunQiang Su 于2024年6月14日周五 20:12写道:
>
> PR 115416
>
> When we build a cross toolchain, while without --with-sysroot,
> target headers are expected in
> ${test_exec_prefix}/${target_noncanonical}/sys-include
> while it is true only with --with-headers option is used. In other
> cases, the path
From: trcrsired
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
Add bits/c++config.h before headers in assert_fail
---
libstdc++-v3/src/c++11/assert_fail.cc | 11 +++
1 file changed, 7
Libstdc++
Sent: 10 June 2023 08:12
To: Hans-Peter Nilsson
Cc: Jonathan Wakely; libstdc++; gcc-patches
Subject: Re: [PATCH] (Re: Splitting up
27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long))
On Sat, 10 Jun 2023, 06:18 Hans-Peter Nilsson via Libstdc++, <
libstd...@gcc.gnu.org>
On Fri, Jun 21, 2024 at 1:11 PM Jeff Law wrote:
>
>
>
> On 6/17/24 3:53 AM, Richard Sandiford wrote:
> > This patch makes target-independent code use force_subreg instead
> > of simplify_gen_subreg in some places. The criteria were:
> >
> > (1) The code is obv
From: trcrsired
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose enabled.
---
libstdc++-v3/src/c++11/assert_fail.cc | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
it_edge
within the loop optimizer, and gimple_split_edge creates the new edge
with UNKNOWN_LOCATION.
This patch tweaks gimple_split_edge to copy edge_in->goto_locus's to the
new edge, so that the edge seen by the analyzer has a useful goto_locus
value, fixing the issue.
Successfully bootstrapped
Hi Hongtao,
I submitted a patch silencing -Wshift-overflow on a signed int
constant here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654016.html
You OK'd it here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654140.html
Are you able to commit it for me please? I do
GCC maintainers:
version 4: Additional dg option updates per the feedback. Retested the patch
on Power 10, no regressions.
version 3: 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
On Tue, 22 Mar 2022, Pokechu22 via Gcc-patches wrote:
> ---
> htdocs/contribute.html | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Sorry this fell through the cracks on our end. I'll shortly push a change
to add the missing closing parenthesis.
All other changes have been
Hi Richard,
Thanks for the review and apologies for taking so long to get back to this.
This revision implements your suggestions from early May, as found at
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650405.html
This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
On 6/17/24 3:53 AM, Richard Sandiford wrote:
This patch makes target-independent code use force_subreg instead
of simplify_gen_subreg in some places. The criteria were:
(1) The code is obviously specific to expand (where new pseudos
can be created), or at least would be invalid to call
Andi Kleen writes:
> 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
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
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
>
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
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
>&g
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
gt;> The test fails if -mdejagnu-cpu= is set to power7, needs to be power8.
>> Patch has been retested on a Power 10 box, it succeeds
>> with 2 passes and no fails.
>
> IMHO Peter's suggestion on power7 (-mdejagnu-cpu=power7) is mainly for
> altivec-1-runnable.c. Both your tes
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
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
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 t
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
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
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
[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
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
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
* 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
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
lso included in this patch as a new Zicond
testcase.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_conditional_move): Add a
CONST0_RTX check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zicond-ice-3.c: New test.
Signed-off-by: Artemiy Volkov
---
gcc/config/ri
eya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] Ifcvt: Add cond tree reconcile for truncated .SAT_SUB
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 (br
whether recog can add a new hard register clobber
The exclusion set was originally a callback function that returned
true for insns that should be ignored. However, for the late-combine
work, I'd also like to be able to skip an entire definition, along
with all its uses.
This patch prepares
ed constants. This meant that any power of 2
greater than 32768 would cause an "insn does not satisfy its
constraints" ICE.
Also, the %p operand modifier barfed on 1<<31, which is sign-
rather than zero-extended to 64 bits. The code is inherently
limited to 32-bit operands -
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/
*
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/
*
do we handle vector lowering then? Would it be
>> > enough to require "any" condition code and thus we expect targets
>> > to implement enough codes so all compares can be handled by
>> > swapping/inversion?
>>
>> I'm not sure TBH. I can see
> >
> > 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
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
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
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
, the
>> series is OK from my POV with that change and with the changes above.
>> Please get sign-off from an x86 maintainer too though.
>
> Thank you for the review and suggestions. Here is the updated version of
> patch 6, based on the comments.
> The x86 and mingw maintainer
> 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 not like you pretty
> > much wrote the entire patch, as
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
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
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
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/tre
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
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
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,
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 +
1 - 100 of 245037 matches
Mail list logo