Hi,
As mentioned in PR, for the following test-case:
typedef unsigned char uint8_t;
static inline uint8_t
x264_clip_uint8(uint8_t x)
{
uint8_t t = -x;
uint8_t t1 = x & ~63;
return (t1 != 0) ? t : x;
}
void
mc_weight(uint8_t *restrict dst, uint8_t *restrict src, int n)
{
for (int x = 0;
On Wed, Oct 06, 2021 at 10:09:31AM -0300, Raphael M Zinsly wrote:
> On 05/10/2021 19:03, Segher Boessenkool wrote:
> >So what is new or different in v3 compared to v2?
>
> gcc/testsuite/gcc.target/powerpc/unwind-backchain.c:
> - Added a comment explaining why test only on *-linux targets.
>
"Roger Sayle" writes:
> Hi Richard,
>
> All excellent suggestions. The revised patch below implements all of
> your (and Andreas') recommendations. I'm happy to restrict GCC's support
> for saturating arithmetic to integer types, even though I do know of one
> target (nvptx) that supports
We set the upper and lower bounds in an irange whenever we call
set_varying (). Unfortunately, we create a new tree for the bounds each
time, and this is quite expensive.. creating a lot of unnecessary work.
This patch will use the values of TYPE_MIN_VALUE and TYPE_MAX_VALUE if
possible,
On Wed, Oct 06, 2021 at 12:39:01PM +0100, Kwok Cheung Yeung wrote:
> In secion 2.3.1 of the OpenMP 5.0 spec, it says:
>
> 3. For functions within a declare target block, the target trait is added to
> the beginning of the set...
>
> But OpenMP in Fortran doesn't have the notion of a declare
This patch provides an intersect to irange which accepts a wide_int
lower and upper bound instead of an irange.
This both prevents us from having to creates trees when we needs a
temporary irange of single bounds.
This is also a bit more efficient as we can do the intersect directly in
the
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bootstrap and break on
the warning, you can see that the
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64
The following makes more stmts consumable with the GIMPLE FE
when dumping with -gimple. In particular addresses in GIMPLE
operand position require wrapping with _Literal.
The TDF_ flag space is now exhausted and I've removed overlaps
and re-ordered things as to how it is supposed to work and
Early ping for this patch.
(I still plan to review Harald's pending patch soon, unless someone
beats me:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580810.html )
On 01.10.21 02:43, Tobias Burnus wrote:
Hi all,
this patch fixes a bunch of issues with CLASS.
* * *
Side remark: I
This is the first in a set of performance improvements. Over the summer
a few things have snuck in that are slowing down EVRP.
A recent change introduced a frequent check for zero and non-zero which
has caused a lot of extra temporary trees to be created.
This patch makes the check more
[Here go the bits by Richi, tested on x86-64 Linux, and ongoing tests
on aarch64 and ppc64le.]
There is a lot of fall-out from this patch, as there were many threading
tests that assumed the restrictions introduced by this patch were valid.
Some tests have merely shifted the threading to after
On 05/10/2021 19:03, Segher Boessenkool wrote:
On Tue, Oct 05, 2021 at 03:32:52PM -0300, Raphael Moreira Zinsly wrote:
Without dwarf2 unwind tables available _Unwind_Backtrace() is not
able to return the full backtrace.
This patch adds a fallback function on powerpc to get the backtrace
by
> On 05/10/2021 21:57 Iain Sandoe wrote:
>
>
> This fixes a bootstrap fail because saw_static_libcxx was unused for
> targets without support for -Bstatic/dynamic.
>
> The fix applied pushes the -static-libstdc++ back onto the command
> line, which allows a target to substitute a static
One of the cases which causes ranger to bog down is processing large
switch statements.
We create ranges for each individual case, and at meet points need to
intersect those ranges and combine them. As Switches get larger, the
number of subranges at meets points increase and this becomes a
(Nice optimisations!)
Kyrylo Tkachov writes:
> Hi Tamar,
>
>> -Original Message-
>> From: Tamar Christina
>> Sent: Wednesday, September 29, 2021 5:19 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: nd ; Richard Earnshaw ;
>> Marcus Shawcroft ; Kyrylo Tkachov
>> ; Richard Sandiford
>>
>>
On Okt 05 2021, Aldy Hernandez via Gcc-patches wrote:
> From 5abe65668f602d53b8f3dc515508dc4616beb048 Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez
> Date: Tue, 5 Oct 2021 15:03:34 +0200
> Subject: [PATCH] Loosen loop crossing restriction in threader.
>
> Crossing loops is generally
On Wed, 6 Oct 2021, Patrick Palka wrote:
> On Tue, 5 Oct 2021, Jason Merrill wrote:
>
> > On 10/5/21 15:17, Patrick Palka wrote:
> > > On Mon, 4 Oct 2021, Patrick Palka wrote:
> > >
> > > > When passing a function template as the argument to a function NTTP
> > > > inside a template, we resolve
> 2021-08-23 Martin Jambor
>
> * params.opt (param_ipa_cp_profile_count_base): New parameter.
> * ipa-cp.c (max_count): Replace with base_count, replace all
> occurrences too, unless otherwise stated.
> (ipcp_cloning_candidate_p): identify mostly-directly called
>
On Tue, 5 Oct 2021, Jason Merrill wrote:
> On 10/5/21 15:17, Patrick Palka wrote:
> > On Mon, 4 Oct 2021, Patrick Palka wrote:
> >
> > > When passing a function template as the argument to a function NTTP
> > > inside a template, we resolve it to the right specialization ahead of
> > > time via
On Wed, 6 Oct 2021, Richard Biener via Gcc-patches wrote:
> Currently the frontend rejects those addresses as not lvalues
> because the C frontend doens't expect MEM_REF or TARGET_MEM_REF
> to appear (but they would be valid lvalues there). The following
> fixes that by amending lvalue_p.
>
>
I forgot to ask if with this patch this overload:
template
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
return std::__to_address(__ptr.base().operator->());
else
return
> Recursive call graph edges, even when they are hot and important for
> the compiled program, can never have frequency bigger than one, even
> when the actual time savings in the next recursion call are not
> realized just once but depend on the depth of recursion. The current
> IPA-CP effect
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote:
>
> On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
> -Wmaybe-uninitialized certainly suffers from a high rate of false
> positives (I count 40 open PRs). Even after all this time debugging
> it I still struggle with the code for it
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/std/functional: Include .
* include/std/version (__cpp_lib_move_only_function): Define.
* include/bits/mofunc_impl.h: New file.
*
Here is another proposal with the __to_address overload.
I preferred to let it open to any kind of __normal_iterator
instantiation cause afaics std::vector supports fancy pointer types. It
is better if __to_address works fine also in this case, no ?
libstdc++: Overload std::__to_address
Please review my small doc patch. Thank you.
Diane
On 9/15/21, 5:02 PM, "Diane Meirowitz"
wrote:
doc: improve -fsanitize=undefined description
gcc/ChangeLog:
* doc/invoke.texi: add link to
UndefinedBehaviorSanitizer
On Wed, Oct 06, 2021 at 12:39:01PM +0100, Kwok Cheung Yeung wrote:
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -11599,8 +11599,11 @@ omp_construct_selector_matches (enum tree_code
> *constructs, int nconstructs,
> }
> }
>if (!target_seen
> - && lookup_attribute ("omp
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
commit 9069eb28d45baaa8baf5e3790b03b0e2cc5b49b3
Author: Igor Tsimbalist
Date: Fri Nov 17 22:34:50 2017 +0100
Enable building libsanitizer with Intel CET
libsanitizer/
* acinclude.m4: Add enable.m4 and cet.m4.
* Makefile.in: Regenerate.
*
On 10/6/21 11:03 AM, Aldy Hernandez wrote:
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Okay, thanks. I see what you mean that reducing it to a test case
is challenging. I'll see if I can find some time to distill it to
something useful.
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actual argument that corresponds to a dummy argument that
is an INTENT (OUT) assumed-rank array, it
On 10/6/2021 10:22 AM, Aldy Hernandez via Gcc-patches wrote:
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote:
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
-Wmaybe-uninitialized certainly suffers from a high rate of false
positives (I count 40 open PRs). Even after all this
On 10/5/2021 10:15 AM, Hans-Peter Nilsson wrote:
On Sat, 25 Sep 2021, Hu Jialun wrote:
Hello,
Sorry for bumping it again but I guess it was getting overlooked.
I am very junior with mailing list open source contributions so please feel
free to point out if I have inadvertantly done
On 10/1/21 16:58, Jonathan Wakely wrote:
An initializer-list constructor taking a non-const lvalue cannot be
called with a temporary, so the array's lifetime probably doesn't end
with the full expression. -Winit-list-lifetime should not warn for that
case.
PR c++/102482
---
libsanitizer/asan/asan_globals.cpp| 19 --
libsanitizer/asan/asan_interceptors.h | 7 ++-
libsanitizer/asan/asan_mapping.h | 2 +-
.../sanitizer_linux_libcdep.cpp | 4
.../sanitizer_common/sanitizer_mac.cpp| 12
I am checking in these patches to merge with upstream commit:
commit fdf4c035225de52f596899931b1f6100e5e3e928
Author: H.J. Lu
Date: Fri Sep 10 06:24:36 2021 -0700
[sanitizer] Support Intel CET
1. Include in sanitizer_common/sanitizer_asm.h to mark Intel CET
support when Intel
On 10/6/21 05:06, Jakub Jelinek wrote:
On Tue, Oct 05, 2021 at 10:40:45PM -0400, Jason Merrill wrote:
I've switched to handling bases via binfo as discussed on IRC and added
spaceship-synth14.C to test proper base handling with virtual <=>. Here's
what I'm committing:
Thanks a lot.
I see
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64
On 10/6/21 15:52, Patrick Palka wrote:
On Wed, 6 Oct 2021, Patrick Palka wrote:
On Tue, 5 Oct 2021, Jason Merrill wrote:
On 10/5/21 15:17, Patrick Palka wrote:
On Mon, 4 Oct 2021, Patrick Palka wrote:
When passing a function template as the argument to a function NTTP
inside a template,
On Oct 5, 2021, Pierre-Marie de Rodat wrote:
> * gcc-interface/utils.c (handle_strub_attribute): New.
> (gnat_internal_attribute_table): Add strub.
FTR, this is just a dummy. The actual implementation was submitted
along with the language- and machine-independent infrastructure at
On 10/1/21 16:10, Patrick Palka wrote:
Here we're crashing when level-lowering the variadic constraints on the
template template parameter TT because tsubst_pack_expansion expects
processing_template_decl to be set during a partial substitution.
bootstrapped and regtested on
Merged revision: fdf4c035225de52f596899931b1f6100e5e3e928
---
libsanitizer/MERGE| 2 +-
libsanitizer/asan/asan_allocator.cpp | 15 -
libsanitizer/asan/asan_allocator.h| 2 -
libsanitizer/asan/asan_debugging.cpp | 5 +-
Hi!
For the few long double types that do have padding bits, e.g. on x86
the clear_type_padding_in_mask computed mask is
ff ff ff ff ff ff ff ff ff ff 00 00 for 32-bit and
ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 for 64-bit.
Instead of doing __builtin_clear_padding on both operands that
On Tue, Oct 05, 2021 at 10:40:45PM -0400, Jason Merrill wrote:
> I've switched to handling bases via binfo as discussed on IRC and added
> spaceship-synth14.C to test proper base handling with virtual <=>. Here's
> what I'm committing:
Thanks a lot.
I see spaceship-synth8.C is accepted without
Currently the frontend rejects those addresses as not lvalues
because the C frontend doens't expect MEM_REF or TARGET_MEM_REF
to appear (but they would be valid lvalues there). The following
fixes that by amending lvalue_p.
The change also makes the dumping of the source of the testcase
valid
46 matches
Mail list logo
