Re: [PATCH] middle-end/100464 - avoid spurious TREE_ADDRESSABLE in folding debug stmts

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

Re: [GOVERNANCE] Where to file complaints re project-maintainers?

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:

Re: [PATCH v2] Add a test for PR tree-optimization/42587

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,

[patch] Remove call to gcc_unreachable in range-op.cc

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

[GOVERNANCE] Where to file complaints re project-maintainers?

(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:

Re: [PATCH] tweak range-on-exit.

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)) +

[PATCH v2] Add a test for PR tree-optimization/42587

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

[PATCH] x86: Add a test for PR tree-optimization/42587

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

Re: [PATCH] c++: argument pack expansion inside constraint [PR100138]

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

[PATCH v2] MIPS: R6: load/store can process unaligned address

MIPS release 6 requires the lw/ld/sw/sd can work with unaligned address, while it can be implemented by full hardware or trap 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

[PATCH v5 2/2] MIPS: add builtime option for -mcompact-branches

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 +++--

[PATCH v5 1/2] MIPS: Not trigger error for pre-R6 and -mcompact-branches=always

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

Re: [PATCH] rs6000: Make density_test only for vector version

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 >>

[PATCH] rs6000: Move rs6000_vect_nonmem into target cost_data

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

[PATCH 2/2 v2] rs6000: Guard density_test only for vector version

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?

[PATCH 1/2] vect: Add costing_for_scalar parameter to init_cost hook

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 >>