Since the standard range adaptors are specified to derive from the empty
class view_base, making their first data member store the underlying
view is suboptimal, for if the underlying view also derives from
view_base then the two view_base subobjects will be adjacent, thus
preventing the compiler f
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (subrange::_M_end): Give it
[[no_unique_adcress]].
* testsuite/std/ranges/subrange/sizeof.cc: New test.
---
libstdc++-v3/include/bits/ranges_util.h | 2 +-
.../testsuite/std/ranges/subrange/sizeof.cc | 28 ++
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::_M_bound): Give it
[[no_unique_address]].
* testsuite/std/ranges/iota/iota_view.cc: Check that an
unbounded iota_view has minimal size.
---
libstdc++-v3/include/std/ranges | 2 +-
libstdc+
libstdc++-v3/ChangeLog:
* testsuite/std/ranges/adaptors/sizeof.cc: New test.
---
.../testsuite/std/ranges/adaptors/sizeof.cc | 49 +++
1 file changed, 49 insertions(+)
create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
diff --git a/libstdc++-v3/tes
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553809.html
Thanks
Gui Haochen
On 14/9/2020 上午 11:01, HAO CHEN GUI wrote:
Hi,
Jump tables are put into text or rodata section originally. On some
platforms, it gains the performance benefit from absolute addre
Segher,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553486.html
Thanks
Gui Haochen
On 9/9/2020 下午 4:55, HAO CHEN GUI wrote:
Hi Segher,
Thanks for your advice. I removed macros defined in linux64.h and
linux.h. So they take relative jump tables b
Hi,
this patch implements basic builtins handling to ipa-modref.
It breaks three additional Fortran testcases due to Fortran frontend
TBAA bugs as discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554936.html
Otherwise it bootstraps and regtests x86_64-linux. With cc1plus I no
Hi,
ipa-reference, ipa-pure-const and ipa-modref could use the knowledge
about bulitins which is currently harwired into
ref_maybe_used_by_call_p_1, call_may_clobber_ref_p_1 and the PTA
computation. This patch breaks out logic implemented in the first two
into a form of a simple descriptor that ca
Hi,
this patch fixes a pasto in modref_summary::useful_p that made
ipa-modref to give up on tracking stores when all load info got lost.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-09-27 Jan Hubicka
* ipa-modref.c (modref_summary::useful_p): Fix testing of stor
> On 9/21/20 10:10 AM, Richard Biener wrote:
>
> > > I see, so you would expect call to alsize to initialize things in
> > > array15_unkonwn type? That would work too.
> > Yes, that's my expectation. But let's see what fortran folks say.
>
> RFC patch attached; I think the following should work
* Jonathan Wakely via Libstdc:
> We can't use __libc_single_threaded to replace __gthread_active_p
> everywhere. If we replaced the uses of __gthread_active_p in std::mutex
> then we would elide the pthread_mutex_lock in the code below, but not
> the pthread_mutex_unlock:
>
> std::mutex m;
> m
On 9/25/20 6:50 PM, Segher Boessenkool wrote:
On Fri, Sep 25, 2020 at 03:34:49PM -0500, will schmidt wrote:
On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
No, it cannot.
This is used for pdepd/pextd/cntlzdm/cnttzdm/cfuged, all of which do
need 64-bit registers to do anything sane
Since MOVDIRI and MOVDIR64B write to memory, similar to UNSPEC_MOVNT,
use SET operation in MOVDIRI and MOVDIR64B patterns with UNSPEC instead
of UNSPECV.
gcc/
PR target/97184
* config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
(UNSPEC_MOVDIRI): This.
(UNSPECV_M
13 matches
Mail list logo
