On Sat, 9 Mar 2024 at 12:18, Jonathan Wakely wrote:
>
>
>
> +template
>> + __wait_result_type
>> + __wait_for(const __platform_wait_t* __addr, __wait_args __args,
>> +const chrono::duration<_Rep, _Period>& __rtime) noexcept
>> +{
>> + if (!__rtime.count())
With Jakub's twiddle to the forward propagation pass, the assembly code
for pr59533-1.c has returned to its previous state. Thus I've reverted
my patch which adjusted the expected output.
Jeffcommit 6f7d000fcacef31a6947f95021e445c846170f92
Author: jlaw
Date: Sat Mar 9 21:33:47 2024 -0700
Not sure why nobody's taken care of this yet. Under certain
circumstances python may be needed if you're building a RISC-V compiler.
Here's what I've checked in. Happy to adjust if folks want to wordsmith
it further.
Jeffcommit 7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178
Author: jlaw
Date:
The issue here is the code we emit for mode-switching can change when -g
is added to the command line. This is caused by processing debug notes
occurring after a call which is the last real statement in a basic block.
Without -g the CALL_INSN is literally the last insn in the block and the
> Am 10.03.2024 um 04:14 schrieb pan2...@intel.com:
>
> From: Pan Li
>
> This patch would like to fix one ICE in vectorizable_store when both the
> loop_masks and loop_lens are enabled. The ICE looks like below when build
> with "-march=rv64gcv -O3".
>
> during GIMPLE pass: vect
> test.c:
From: Pan Li
This patch would like to fix one ICE in vectorizable_store when both the
loop_masks and loop_lens are enabled. The ICE looks like below when build
with "-march=rv64gcv -O3".
during GIMPLE pass: vect
test.c: In function ‘d’:
test.c:6:6: internal compiler error: in
> Am 09.03.2024 um 09:36 schrieb Jakub Jelinek :
>
> Hi!
>
> Before the recent PR111267 r14-8319 fwprop changes, fwprop would never try
> to propagate what was not considered PROFITABLE, where the profitable part
> actually was partly about profitability, partly about very good reasons
> not
> Am 09.03.2024 um 09:28 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase ICEs, because update-address-taken subpass of
> fre5 rewrites
> _BitInt(128) b;
> vector(16) unsigned char _3;
>
> [local count: 1073741824]:
> _3 = MEM [(char * {ref-all})p_2(D)];
> MEM [(char *
On Thu, 16 Nov 2023 at 13:49, Jonathan Wakely wrote:
> From: Thomas Rodgers
>
> These two patches were written by Tom earlier this year, before he left
> Red Hat. We should finish reviewing them for GCC 14 (and probably squash
> them into one?)
>
> Tom, you mentioned further work that changes
Hi!
The following testcase ICEs, because update-address-taken subpass of
fre5 rewrites
_BitInt(128) b;
vector(16) unsigned char _3;
[local count: 1073741824]:
_3 = MEM [(char * {ref-all})p_2(D)];
MEM [(char * {ref-all})] = _3;
b ={v} {CLOBBER(eos)};
to
_BitInt(128) b;
Hi!
When I've added the -mnoreturn-no-callee-saved-registers option
to i386.opt, I forgot to regenerate i386.opt.urls and Mark's
CI kindly reminded me of that.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
verified
This adds cost computation for some insn combiner patterns
and improves a few other nits.
Johann
--
AVR: Add cost computation for some insn combine patterns.
gcc/
* config/avr/avr.cc (avr_rtx_costs_1) [PLUS]: Determine cost for
usum_widenqihi and add_zero_extend1.
I don't know if this affects other targets than arm-none-eabi, so I
used arm-*-*. If you think it should be *-*-* or some other target
selector, please let me know what to use instead.
Ok for releases/gcc-13?
--
On arm-none-eabi, the test case fails with
The earlier patch for PR112938 arranged for volatile parms to be made
indirect in internal strub wrapped bodies.
The first problem that remained, more evident, was that the indirected
parameter remained volatile, despite the indirection, but it wasn't
regimplified, so indirecting it was
ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR tree-optimization/113681
*
Hi!
Before the recent PR111267 r14-8319 fwprop changes, fwprop would never try
to propagate what was not considered PROFITABLE, where the profitable part
actually was partly about profitability, partly about very good reasons
not to actually propagate and partly for cases where propagation is
On Sat, Mar 9, 2024 at 1:07 AM Torbjörn SVENSSON
wrote:
>
> I don't know if this affects other targets than arm-none-eabi, so I
> used arm-*-*. If you think it should be *-*-* or some other target
> selector, please let me know what to use instead.
>
> Ok for releases/gcc-13?
Most likely should
Thanks Richard for comments.
> That said, the assert you run into should be only asserted during transform,
> not during analysis.
Good to learn that the assertion is only valid during transform, I guess we may
have almost
the same case in vectorizable_load. I will try to test only allow
18 matches
Mail list logo
