On 6/4/21 5:08 PM, Patrick Palka wrote:
Here, when resolving the destructor named by Inner::~Inner
(which is valid only before C++20) we end up in cp_parser_lookup_name to
look up the name Inner relative to the scope Inner. The lookup
naturally finds the injected-class-name Inner, and because
is
On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote:
>
> I was asked to backport the patch for pr98301 to gcc-11. The patches have
> been in mainline for two weeks without any defect reports I could fined. The
> patch for mainline applied with a bit of shift cleanly.
>
> Regstested
A recent change to gcc/c-family/c-attribs.c uses a c99 feature not supported by
most
system versions of snprintf on hppa*-*-hpux*. This change fixes the build.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk.
libiberty/ChangeLog:
PR target/100734
1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTO
operands to vector broadcast from an integer with AVX2.
2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which
won't increase stack alignment requirement and blocks transformation by
the combine pass.
3. Add vec_
We'd like to add vec_duplicate_optab to x86 backend. There are 3 ways
to broadcast an integer constant:
1. Load the full size from constant pool directly.
2. Use AVX2/AVX512 broadcast instruction.
3. Emulate broadcast with SSE2 unpack and shuffle instructions.
A small benchmark:
https://gitlab.
Update vec_duplicate to allow to fail so that backend can only allow
broadcasting an integer constant to a vector when broadcast instruction
is available.
* expr.c (store_constructor): Replace expand_insn with
maybe_expand_insn for vec_duplicate_optab.
* doc/md.texi: Update
Hi all,
I was asked to backport the patch for pr98301 to gcc-11. The patches have
been in mainline for two weeks without any defect reports I could fined. The
patch for mainline applied with a bit of shift cleanly.
Regstested fine on x86_64/f33. Ok for backport gcc-11?
Regards,
Andre
--
Since the PRs are about wrong code, I think the patch should be back
ported to at least GCC11.
Dominique
Le 2021-06-04 17:24, Paul Richard Thomas a écrit :
Hi José,
I can second Dominique's thanks. I applied it to my tree when you
first posted, set the regtest in motion and have not been able
On 04/06/21 21:46 +0100, Jonathan Wakely wrote:
On 04/06/21 21:44 +0100, Jonathan Wakely wrote:
On 04/06/21 18:03 +0100, Jonathan Wakely wrote:
The implementation of P2091R0 was incomplete, so that some range access
CPOs used perfect forwarding where they should not. This fixes it by
consistent
