Hi Richi,
Thanks for the comments!
on 2021/5/7 下午5:43, Richard Biener wrote:
> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> When I was investigating density_test heuristics, I noticed that
>> the current rs6000_density_test could be used for single scalar
>>
Hi,
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569790.html
This is the updated version with one new parameter costing_for_scalar
passed by init_cost hook, instead of checking the passed data point
identity.
Bootstrapped/regtested on powerpc64le-linux-gnu P9.
Is it ok for trunk?
BR,
Hi,
This patch is to move rs6000_vect_nonmem (target cost_data
related information) into target cost_data struct.
Following Richi's comments in the thread[1], we can gather
data from add_stmt_cost invocations. This is one pre-step
to centralize target cost_data related stuffs.
Is it ok for trun
Hi Will,
Thanks for the comments!
on 2021/5/7 下午7:43, will schmidt wrote:
> On Fri, 2021-05-07 at 10:28 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> When I was investigating density_test heuristics, I noticed that
>> the current rs6000_density_test could be used for single scalar
>> itera
For MIPSr6, we may wish to use compact-branches only.
Currently, we have to use `always' option, while it is mark as conflict
with pre-R6.
cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
Just ignore -mcompact-branches=always for pre-R6.
This patch also defines
__mip
For R6+ target, it allows to configure gcc to use compact branches only
if avaiable.
gcc/ChangeLog:
* config.gcc: add -with-compact-branches=policy build option.
* doc/install.texi: Likewise.
* config/mips/mips.h: Likewise.
---
gcc/config.gcc | 13 +++--
gc
MIPS release 6 requires the lw/ld/sw/sd can work with
unaligned address, while it can be implemented by
full hardware or trap&emulate.
Since it is may be fully done by hardware, we add an
option -m(no-)unaligned-access, the kernel may need it.
gcc/ChangeLog:
* config/mips/mips.h (ISA_HAS
On 5/7/21 12:33 PM, Patrick Palka wrote:
This PR is about CTAD but the underlying problems are more general;
CTAD is a good trigger for them because of the necessary substitution
into constraints that deduction guide generation entails.
In the testcase below, when generating the implicit deducti
PR tree-optimization/42587
* gcc.target/i386/pr42587.c: New test.
---
gcc/testsuite/gcc.target/i386/pr42587.c | 35 +
1 file changed, 35 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/i386/pr42587.c
diff --git a/gcc/testsuite/gcc.target/i386/pr4
On Sat, May 8, 2021 at 7:18 AM H.J. Lu wrote:
>
> PR tree-optimization/42587
> * gcc.target/i386/pr42587.c: New test.
> ---
> gcc/testsuite/gcc.target/i386/pr42587.c | 35 +
> 1 file changed, 35 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/i
On 5/7/21 9:03 PM, Andrew MacLeod wrote:
+ else
+{
+ range_on_entry (r, bb, name);
+ // See if there was a deref in this block, if applicable
+ if (!cfun->can_throw_non_call_exceptions && r.varying_p () &&
+ m_cache.m_non_null.non_null_deref_p (name, bb))
+ r
(failed to join gcc, so posting here)
Is there any private email where one can file complaints re
project-maintainers (or "those who are supervising the maintainers") ?
Is there any information about the process for such complaints?
Related Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100
Hi,
the attached Ada testcase happens to stumble on the call to gcc_unreachable in
operator_bitwise_xor::op1_range. My understanding is that there is nothing
wrong going on and that it's safe to let it go through.
Tested on x86-64/Linux, OK for mainline and 11 branch?
2021-05-08 Eric Botcaz
On Sat, May 8, 2021 at 7:25 AM H.J. Lu wrote:
>
> On Sat, May 8, 2021 at 7:18 AM H.J. Lu wrote:
> >
> > PR tree-optimization/42587
> > * gcc.target/i386/pr42587.c: New test.
> > ---
> > gcc/testsuite/gcc.target/i386/pr42587.c | 35 +
> > 1 file changed, 35
On Sat, May 8, 2021 at 8:49 AM abebeos via Gcc-patches
wrote:
>
> Is there any private email where one can file complaints re
> project-maintainers (or "those who are supervising the maintainers") ?
>
> Is there any information about the process for such complaints?
>
> Related Issue: https://gcc.
On 5/7/21 6:21 AM, Richard Biener wrote:
On Fri, May 7, 2021 at 12:17 PM Richard Biener wrote:
canonicalize_constructor_val was setting TREE_ADDRESSABLE on bases
of ADDR_EXPRs but that's futile when we're dealing with CTOR values
in debug stmts. This rips out the code which was added for Java
16 matches
Mail list logo