> diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
> index 718b4bd77df..f67bff0940f 100644
> --- a/gcc/config/riscv/constraints.md
> +++ b/gcc/config/riscv/constraints.md
> @@ -35,6 +35,17 @@
>
> ;; General constraints
>
> +(define_memory_constraint "m"
> + "An addre
On platforms that enable -fshort-enums by default, various switch-enum
analyzer tests fail, because apply_constraints_for_gswitch doesn't
expect the integral promotion type cast. I've arranged for the code
to cope with those casts.
Regstrapped on x86_64-linux-gnu, also tested on arm-eabi with d
__dt_base doesn't get its body from a maybe_return_this caller, it's
rather cloned with the full body within build_clone, and then it's
left alone, without going through finish_function_body or
build_delete_destructor_body, that call maybe_return_this.
Now, this is correct as far as the generate
On targets that have -fshort-enums enabled by default, the type casts
in the pr108251 analyzer tests warn that the byte-aligned enums may
not be sufficiently aligned to be a struct connection *. The function
can't know better, the warning is reasonable, the code doesn't
expected enums to be shor
On arm-eabi targets, c23 stdarg execution tests that pass arguments to
(...) functions (without any named argument), the caller passes
everything on the stack, but the callee expects arguments in
registers. My reading of the AAPCS32 suggests that the caller is
correct, so I've arranged for the c
I've recently patched scev-3.c and scev-5.c because it only passed by
accident on ia32. It also fails on some (but not all) arm-eabi
variants. It seems hard to characterize the conditions in which the
optimization is supposed to pass, but expecting them to fail on ilp32
targets, though probably
When targetm.cxx.cdtor_return_this() holds, cdtors have a
non-VOID_TYPE_P result, but IMHO this ABI implementation detail
shouldn't leak to the abstract language conceptual framework, in which
cdtors don't have return values. For contracts, specifically those
that establish postconditions on res
LGTM
On Sun, Nov 19, 2023 at 1:38 PM Maciej W. Rozycki wrote:
>
> Verify, for Ventana and Zicond targets and the GEU and LEU
> conditional-move operations, that if-conversion triggers via
> `noce_try_cmove' at `-mbranch-cost=4' setting, which makes branchless
> code sequences produced by if-conve
The vec_perm expander was wrongly defined. GCC internal says:
Operand 3 is the “selector”. It is an integral mode vector of the same
width and number of elements as mode M.
With this mistake, the generic code manages to work around and it ends
up creating some very nasty code for a simple __bui
LGTM
On Sun, Nov 19, 2023 at 1:39 PM Maciej W. Rozycki wrote:
>
> Update `riscv_expand_conditional_move' and handle the missing GEU and
> LEU operators there, avoiding an extraneous conditional set operation,
> such as with this output:
>
> sgtua0,a0,a1
> seqza1,a0
>
LGTM
On Sun, Nov 19, 2023 at 1:38 PM Maciej W. Rozycki wrote:
>
> Verify, for Ventana and Zicond targets and the ordered floating-point
> conditional-move operations that already work as expected, that
> if-conversion does *not* trigger at `-mbranch-cost=2' setting, which
> makes original branche
LGTM.
Just one minor comment, I think we don't really need to check rv64 or
rv32 for those compiled without any header file test, but I am fine
with that.
On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote:
>
> Verify, for T-Head, Ventana and Zicond targets and the integer
> conditional-move
LGTM, thanks for those test cases!
On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote:
>
> Verify, for T-Head, Ventana and Zicond targets and the integer
> conditional-move operations that already work as expected, that
> if-conversion does *not* trigger at the respective sufficiently low
>
On Sat, 18 Nov 2023, Jeff Law wrote:
> Is this dependent on any of the other patches in this series? Or is it
> independent and ready to go as-is? I ask becuase it's marked as 13/44 and I
> haven't seen the other 43 patches in the series :-)
>
> If it's independent and been tested, then it's OK
On Sat, Nov 18, 2023 at 1:43 AM waffl3x wrote:
>
> The patch is coming along, I just have a quick question regarding
> style. I make use of IILE's (immediately invoked lambda expression) a
> whole lot in my own code. I know that their use is controversial in
> general so I would prefer to ask inst
LGTM
On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote:
>
> Just choose between EQ and NE at `gen_rtx_fmt_ee' invocation, removing
> an extraneous variable only referred once and improving code clarity.
>
> gcc/
> * config/riscv/riscv.cc (riscv_expand_conditional_move): Remo
LGTM
On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote:
>
> Use `mode0' and `mode1' shorthands respectively for `GET_MODE (op0)' and
> `GET_MODE (op1)' to improve code readability.
>
> gcc/
> * config/riscv/riscv.cc (riscv_expand_conditional_move): Use
> `mode0' and
LGTM
On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote:
>
> In `riscv_expand_conditional_move' `mode' is initialized right away from
> `GET_MODE (dest)', so remove needless references that refrain from using
> the local variable.
>
> gcc/
> * config/riscv/riscv.cc (riscv_exp
LGTM
On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote:
>
> For the NEED_EQ_NE_P `riscv_emit_int_compare' is documented to only emit
> EQ or NE comparisons against zero, however it does not catch incorrect
> use where a non-equality comparison has been requested and falls through
> to the g
LGTM
On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote:
>
> Verify, for short forward branch targets and the conditional-move
> operations that already work as expected, that if-conversion triggers
> via `noce_try_cmove' already at `-mbranch-cost=1' and that extraneous
> instructions such a
LGTM
On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote:
>
> Our `movcc' expander is no longer specific to short forward branch
> targets, so move its associated comment accordingly.
>
> gcc/
> * config/riscv/riscv.md (movcc): Move comment on SFB
> patterns over to...
LGTM
On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote:
>
> Use `nullptr' for consistency rather than 0 to initialize `invert_ptr'.
>
> gcc/
> * config/riscv/riscv.cc (riscv_expand_conditional_move): Use
> `nullptr' rather than 0 to initialize a pointer.
> ---
> gcc
ok
On Sun, Nov 19, 2023 at 1:35 PM Maciej W. Rozycki wrote:
>
> Add generic execution tests for expressions that are expected to expand
> to conditional-move and conditional-add operations where supported. To
> ensure no corner case escapes all relational operators are extensively
> covered for
quick response for this patch set, it's a really huge number of
patches, so I'll review it individually, and feel free to commit
individual one once got LGTM for each single patch :P
On Sun, Nov 19, 2023 at 1:35 PM Maciej W. Rozycki wrote:
>
> Hi,
>
> This patch series has come out from a simpl
Verify, for the generic floating-point NE conditional-add operation,
that if-conversion triggers via `noce_try_addcc' at `-mbranch-cost=3'
setting, which makes branchless code sequences emitted by if-conversion
cheaper than their original branched equivalents, and that extraneous
instructions s
Verify, for the generic floating-point NE conditional-add operation,
that if-conversion does *not* trigger at `-mbranch-cost=2' setting,
which makes original branched code sequences cheaper than their
branchless equivalents if-conversion would emit.
gcc/testsuite/
* gcc.target/r
Verify, for the floating-point NE conditional-move operation, that
if-conversion triggers via `noce_try_cmove' at the respective
sufficiently high `-mbranch-cost=' settings that make branchless code
sequences produced by if-conversion cheaper than their original branched
equivalents, and that e
Verify, for generic, Ventana and Zicond targets and the floating-point
NE conditional-move operation, that if-conversion does *not* trigger at
the respective sufficiently low `-mbranch-cost=' settings that make
original branched code sequences cheaper than their branchless
equivalents if-conver
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers via `noce_try_addcc' at `-mbranch-cost=3' setting, which makes
branchless code sequences emitted by if-conversion cheaper than their
original
We have no FNE.fmt machine instructions, but we can emulate them for the
purpose of conditional-move and conditional-add operations by using the
respective FEQ.fmt instruction and then swapping the data input operands
or complementing the mask for the conditional addend respectively, so
update
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=4' setting, which makes original
branched code sequences cheaper than their branchless equivalents
if-conversion
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=2' setting, which makes original
branched code sequences cheaper than their branchless equivalents
if-conversion w
We have floating-point coditional-set machine instructions for a subset
of FP comparisons, so avoid going through a comparison against constant
zero in `riscv_expand_float_scc' where not necessary, preventing an
extraneous RTL instruction from being produced that counts against the
cost of the
A subsequent change to enable the processing of conditional moves on a
floating-point condition by `riscv_expand_conditional_move' will cause
`riscv_expand_float_scc' to be called for word-mode target RTX with RV64
targets. In that case an invalid insn such as:
(insn 25 24 0 (set (reg:DI 141)
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers (via `cond_move_convert_if_block', which doesn't report) at
`-mbranch-cost=5' setting, which makes branchless code sequences emitted
by if-co
Do not expand floating-point conditional-branch RTL instructions right
away that use a comparison operation that is either directly available
as a machine conditional-set instruction or is NE, which can be emulated
by EQ. This is so that if-conversion sees them in their original form
and can p
Provide RTL expansion of conditional-add operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Use existing `-mmovcc' command
line option to enable this transformation.
gcc/
* config/riscv/ri
In `riscv_expand_conditional_move' we only let integer conditions
through at the moment, even though code has already been prepared to
handle floating-point conditions as well.
Lift this restriction and only bail out if a non-word-mode integer
condition has been requested, as we cannot handle t
Verify, for generic integer conditional-add operations, if-conversion
to trigger via `noce_try_addcc' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their original branched equivalents, and,
where applicable,
Verify, for generic integer conditional-move operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion would emit. Cover all integer
relational opera
Verify, for generic integer conditional-add operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion would emit. Cover all integer
relational operat
Verify, for generic integer conditional-move operations, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their original branched equivalents, and,
where applica
Provide RTL expansion of conditional-move operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Add `-mmovcc' command line option
to enable this transformation, off by default.
For the generic sequences smal
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at
`-mbranch-cost=2' setting, which makes branchless code sequences
produced by if-conversion cheaper than their original branched
equivalents, and that extraneo
Add a `riscv_emit_unary' helper for unary operations, complementing
`riscv_emit_binary'.
gcc/
* config/riscv/riscv-protos.h (riscv_emit_unary): New prototype.
* config/riscv/riscv.cc (riscv_emit_unary): New function.
---
gcc/config/riscv/riscv-protos.h |1 +
gcc/confi
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion does *not* trigger at `-mbranch-cost=1'
setting, which makes original branched code sequences cheaper than their
branchless equivalents if-conversion would emit.
gcc/testsuite/
Code in `riscv_expand_conditional_move' for Ventana and Zicond targets
seems like bolted on as an afterthought rather than properly merged so
as to handle all the cases together.
Fold the existing code pieces together then (observing that for short
forward branch targets no integer comparisons
There is no need for the requirement for conditional-move data input
operands to be stricter for T-Head targets than for short forward branch
targets and limit them to registers only. They are keyed according to
the `sfb_alu_operand' predicate, which lets certain constants through.
Such const
There is no need for the requirement for conditional-move comparison
operands to be stricter for T-Head targets than for other targets and
limit them to registers only. Constants will be reloaded if required
just as with branches or other-target conditional-move operations and
there is no extr
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion does *not* trigger at
`-mbranch-cost=3' setting, which makes original branched code sequences
cheaper than their branchless equivalents if-conversion would emit.
gcc/testsuite/
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless code sequences produced by if-conversion cheaper than their
original branched
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion does *not* trigger at the respective
sufficiently low `-mbranch-cost=' settings that make original branched
code sequences cheaper than their branchless equivalents if-conversion
would emit.
In the non-zero case there is no need for the conditional value used by
Ventana and Zicond integer conditional operations to be specifically 1.
Regardless we canonicalize it by producing an extraneous conditional-set
operation, such as with the sequence below:
(insn 22 6 23 2 (set (reg:DI 141)
Update `riscv_expand_conditional_move' and handle the missing GEU and
LEU operators there, avoiding an extraneous conditional set operation,
such as with this output:
sgtua0,a0,a1
seqza1,a0
czero.eqz a3,a3,a1
czero.nez a1,a2,a1
or
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion triggers via
`noce_try_cmove' at `-mbranch-cost=4' setting, which makes branchless
code sequences produced by if-conversion cheaper than their original
branched equivalents, and that extra
Verify, for Ventana and Zicond targets and the ordered floating-point
conditional-move operations that already work as expected, that
if-conversion does *not* trigger at `-mbranch-cost=2' setting, which
makes original branched code sequences cheaper than their branchless
equivalents if-conversi
Verify, for T-Head, Ventana and Zicond targets and the integer
conditional-move operations that already work as expected, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion che
Verify, for T-Head, Ventana and Zicond targets and the integer
conditional-move operations that already work as expected, that
if-conversion does *not* trigger at the respective sufficiently low
`-mbranch-cost=' settings that make original branched code sequences
cheaper than their branchless e
The generic branch costing model for if-conversion assumes a fixed cost
of COSTS_N_INSNS (2) for a conditional branch, and that one half of that
cost comes from a preceding condition-set instruction, such as with
MODE_CC targets, and then the other half of that cost is for the actual
branch ins
Use `nullptr' for consistency rather than 0 to initialize `invert_ptr'.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`nullptr' rather than 0 to initialize a pointer.
---
gcc/config/riscv/riscv.cc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Just choose between EQ and NE at `gen_rtx_fmt_ee' invocation, removing
an extraneous variable only referred once and improving code clarity.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Remove
extraneous variable for EQ vs NE operation selection.
---
FWIW
Use `mode0' and `mode1' shorthands respectively for `GET_MODE (op0)' and
`GET_MODE (op1)' to improve code readability.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`mode0' and `mode1' for `GET_MODE (op0)' and `GET_MODE (op1)'.
---
gcc/config/riscv/ri
In `riscv_expand_conditional_move' `mode' is initialized right away from
`GET_MODE (dest)', so remove needless references that refrain from using
the local variable.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`mode' for `GET_MODE (dest)' throughout
For the NEED_EQ_NE_P `riscv_emit_int_compare' is documented to only emit
EQ or NE comparisons against zero, however it does not catch incorrect
use where a non-equality comparison has been requested and falls through
to the general case then. Add a safety guard to catch such a case then.
Argua
Our `movcc' expander is no longer specific to short forward branch
targets, so move its associated comment accordingly.
gcc/
* config/riscv/riscv.md (movcc): Move comment on SFB
patterns over to...
(*movcc): ... here.
---
gcc/config/riscv/riscv.md |4 ++--
1
Verify, for short forward branch targets and the conditional-move
operations that already work as expected, that if-conversion triggers
via `noce_try_cmove' already at `-mbranch-cost=1' and that extraneous
instructions such as SNEZ, etc. are not present in output. Cover all
integer relational
Add generic execution tests for expressions that are expected to expand
to conditional-move and conditional-add operations where supported. To
ensure no corner case escapes all relational operators are extensively
covered for integer comparisons and all ordered operators are covered
for floati
Hi,
This patch series has come out from a simple change to add generic
conditional-move and conditional-add expansions for a yet-out-of-tree
target, which has relatively expensive branches and no conditional
operations beyond the base architecture conditional-set instructions. At
one point I
On 11/15/23 17:03, Patrick O'Neill wrote:
Ping.
Testsuite fixup similar to:
https://inbox.sourceware.org/gcc-patches/974e9e5e-8f07-46dd-b9b9-db8aa4685...@gmail.com/T/#t
https://inbox.sourceware.org/gcc-patches/7e78cd70-70c9-41b1-8a98-6977a1034...@rivosinc.com/T/#t
OK.
Jeff
On 11/10/23 11:00, Patrick O'Neill wrote:
On 11/9/23 17:34, Jeff Law wrote:
On 11/3/23 00:18, Patrick O'Neill wrote:
On non-vector targets dejagnu attempts dg-do compile for pr95401.cc.
This produces a command like this:
g++ pr95401.cc pr95401a.cc -S -o pr95401.s
which isn't valid (gcc d
On 11/18/23 03:27, Jakub Jelinek wrote:
Hi!
On Fri, Nov 17, 2023 at 03:01:04PM +0100, Jakub Jelinek wrote:
As a follow-up, I'm considering changing in this routine the popcount
call to IFN_POPCOUNT with 2 arguments and during expansion test costs.
Here is the follow-up which does the rtx c
On 11/17/23 07:01, Jakub Jelinek wrote:
Hi!
Per the earlier discussions on this PR, the following patch folds
popcount (x) == 1 (and != 1) into (x ^ (x - 1)) > x - 1 (or <=)
if the corresponding popcount optab isn't implemented (I think any
double-word popcount or call will be necessarily slo
PR target/112561
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_tuple_move): Fix bug.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr112561.c: New test.
---
gcc/config/riscv/riscv-v.cc | 4
.../gcc.target/riscv/rvv/autovec/pr11
This patch:
- adds support to the analyzer for tracking API-private state
or which we don't have a decl (such as strtok's internal state),
- uses it to implement a new -Wanalyzer-undefined-behavior-strtok which
warns when strtok (NULL, delim) is called as the first call to
strtok after main.
Hi,
this patch implements very basic propaation of return value ranges from VRP
pass. This helps std::vector's push_back since we work out value range of
allocated block. This propagates only within single translation unit. I hoped
we will also do the propagation at WPA stage, but that needs mor
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
>
> Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
> The attached patch implements these.
>
> I was struggling with the way we should handle features that are sort-of
> deleted in a new standard, but not describ
On 11/17/23 15:19, Lewis Hyatt wrote:
Hello-
I often find it convenient to run a new c-c++-common test from the
main build dir like:
$ make -j 2 RUNTESTFLAGS=dg.exp=new-test.c check-gcc-{c,c++}
I noticed that sometimes this produces a corrupted site.exp and then no
tests work until it is re
Hi all,
Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
The attached patch implements these.
I was struggling with the way we should handle features that are sort-of
deleted in a new standard, but not described as such in the standard,
which is why we do not have GFC_STD_F20
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 needed too.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/112607
* include/std/format (basic_format_arg::_S_to_arg_type): Check
value_type for basic_string_view and basic_string
specializations.
* te
Here's an improved version of this patch, which I've pushed to trunk.
Testeed x86_64-linux.
-- >8 --
This optimizes the simple case of formatting a single string, integer
or bool, with no format-specifier (so no padding, alignment, alternate
form etc.)
libstdc++-v3/ChangeLog:
PR libstd
This patch adds support for hardware loops as described in:
https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/cv32e40p_v1.3.2/instruction_set_extensions.html#hardware-loops
.
riscv32-corev-elf (using newlib) regression tested for multilibs:
rv32imc_zicsr-ilp32--
rv32imfc_zicsr-ilp32--
Add warning for the case when a function call can not be instrumened.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi (Wvla-parameter-missing-check): Document warni
Support instrumentation of functions called via pointers. To do so,
record the declaration with the parameter types, so that it can be
retrieved later.
gcc/c:
c-decl.cc (get_parm_info): Record function declaration
for arguments.
c-typeck.cc (process_vm_constraints): Ins
Support instrumentation of function arguments for functions
called via a declaration. We can support only simple size
expressions without side effects, because the run-time
instrumentation is done before the call, but the expressions
are evaluated in the callee.
gcc/c:
* c-typeck.cc (p
When checking compatibility of types during assignment, collect
all pairs of types where the outermost bound needs to match at
run-time. This list is then processed to add runtime checks for
each bound.
gcc/c-family:
* c-opt (fvla-bounds): New flag.
gcc/c:
* c-typeck.cc (struc
This is another revised series for checking for
bounds consistency when assigning VM types.
Based on feedback, I disentangled this from UBSan for
a three reasons:
- I think it makes sense as a stand-alone feature
similar to other run-time instrumentation features
GCC already has.
- Not all c
libstdc++-v3/ChangeLog:
* include/Makefile.am: Install std/generator, bits/elements_of.h
as freestanding.
* include/Makefile.in: Regenerate.
* include/bits/version.def: Add __cpp_lib_generator.
* include/bits/version.h: Regenerate.
* include/precompi
Hi!
For these 3 type-generic macros I'm out of ideas how to satisfy
all the requirements (no use of ({ ... }), not expanding argument multiple
times, not evaluating side-effects multiple times using some small building
blocks, so the following patch introduces 3 new C only builtins which
can be us
Hi!
Another obstackle mentioned in the
https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html
thread is that half of the stdc_{leading,trailing}_{zeros,ones},
stdc_first_{leading,trailing}_{zero,one} and stdc_count_{zeros,ones}
type-generic macros actually need to use the __builtin_
Hi!
In https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html
Florian Weimer raised concern that the type-generic stdbit.h macros
currently being considered suffer from similar problem as old tgmath.h
implementation, in particular that the macros expand during preprocessing
their ar
David Edelsohn writes:
> On Fri, Nov 17, 2023 at 10:17 AM Arsen Arsenović wrote:
>
>>
>> David Edelsohn writes:
>>
>> > On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote:
>> >
>> >>
>> >> David Edelsohn writes:
>> >>
>> >> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović
>> wrote:
>> >
On Fri, 2023-11-17 at 10:21 +0800, chenglulu wrote:
> Pushed to r14-5545.
>
> 在 2023/11/16 下午4:44, Jiahao Xu 写道:
> > Based on SPEC2017 performance evaluation results, it's better to make them
> > equal
> > to the cost of unaligned store/load so as to avoid odd alignment peeling.
> >
> > gcc/Chan
On 11/18/23 09:50, Maciej W. Rozycki wrote:
Verify, for short forward branch, T-Head, Ventana and Zicond targets and
the ordered floating-point conditional-move operations that already work
as expected, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbra
Even if !HAVE_AS_SUPPORT_CALL36, const_call_insn_operand should still
return false when -mexplict-relocs=none -mcmodel=medium to make
loongarch_legitimize_call_address emit la.local or la.global.
gcc/ChangeLog:
* config/loongarch/predicates.md (const_call_insn_operand):
Remove bug
On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote:
> Pushed to r14-5567.
>
> 在 2023/11/16 下午3:27, Lulu Cheng 写道:
> > When compiling with '-mcmodel=medium', the function call is made through
> > 'pcaddu18i+jirl' if binutils supports call36, otherwise the
> > native implementation 'pcalau12i+jirl'
Verify, for short forward branch, T-Head, Ventana and Zicond targets and
the ordered floating-point conditional-move operations that already work
as expected, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless code
Currently I start to work on full coverage testing (with different compile
option test GCC testsuite)
and fix bugs which is highest priority definitely.
I am not able to find the time review this patch on GCC-14 for now.
So conservatively, postpone it to GCC-15.
If we are lucky that I stabliz
Actually, disregard this patch. I'm preparing a better one which also
tackles UB in
month - months{INT_MIN}
weekday - days{INT_MIN}
Best wishes,
Cassio.
On Sat, 18 Nov 2023, 00:19 Cassio Neri, wrote:
> The following functions invoke signed integer overflow (UB) for some
> extreme
> values of d
Fixed on upstream, thanks for reporting, I guess my host GCC is just
too old. It doesn't even not report that bug with -Wall -Wextra..
On Fri, Nov 17, 2023 at 11:41 PM Andreas Schwab wrote:
>
> In file included from
> /daten/riscv64/gcc/gcc-20231117/Build/prev-riscv64-suse-linux/libstdc++-v3/inc
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc
(riscv_target_attr_parser::parse_arch): Use char[] for
std::unique_ptr to prevent mismatched new delete issue.
(riscv_process_one_target_attr): Ditto.
(riscv_process_target_attr): Ditto.
---
gcc/config/risc
1 - 100 of 121 matches
Mail list logo
