The m_ranges[] field in int_range are trees, so they live in GC
space. Since invalid_range is static, it must be marked with GTY
magic. However, calculating invalid_range is not particularly slow,
or on a critical path, so we can just put it in local scope and
recalculate every time.
Tested on x
On Fri, 1 Oct 2021, Qing Zhao wrote:
>
>
> > On Oct 1, 2021, at 10:33 AM, Jason Merrill wrote:
> >
> > On 10/1/21 10:54, Qing Zhao wrote:
> >>> On Sep 30, 2021, at 2:31 PM, Jason Merrill wrote:
> >>>
> >>> On 9/30/21 11:42, Qing Zhao wrote:
> > On Sep 30, 2021, at 1:54 AM, Richard Biener
On 10/1/2021 3:36 PM, Patrick McGehearty via Gcc-patches wrote:
- - - -
New in version 6: Due to an oversight (i.e. coding error), version 5
changed the use of __LIBGCC_TF_EPSILON__ to __LIBGCC_DF_EPSILON__ but
not the other LIBGCC_TF values. For correct execution of the long
double test case
On 10/1/2021 5:08 PM, Marek Polacek via Gcc-patches wrote:
On Fri, Oct 01, 2021 at 11:15:45PM +0200, Jakub Jelinek wrote:
On Fri, Oct 01, 2021 at 04:11:08PM -0400, Marek Polacek via Gcc-patches wrote:
+ auto_diagnostic_group d;
+ if (warning_at (location, OPT_Warray_compare,
+
On 9/29/2021 7:08 PM, Luís Ferreira wrote:
This patch allows the compiler to efficiently generate jump tables instead of
using if-else-if.
Signed-off-by: Luís Ferreira
I'm not sure this is terribly useful. Compilers have the ability to
analyze the underlying code and make sensible decision
Here I attach [PATCH-v2].
On Sun, Oct 3, 2021 at 7:14 AM Nick Huang wrote:
>
> Hi Jason,
>
> I made a little improvement of my fix by including template
> type parameter to not dropping cv-const because they are similar to dependent
> type which you cannot determine whether they are top-level cv-
We do not support this yet.
fail with a sorry instead of ICEing.
tested on x86_64,powerpc64le-linux, x86_64-darwin, cppcoro, folly.
pushed to master as obvious, thanks
Iain
Signed-off-by: Iain Sandoe
PR c++/101765
gcc/cp/ChangeLog:
* coroutines.cc (register_local_var_uses): Em
Hi,
C++20 [expr.await] / 2
An await-expression shall appear only in a potentially-evaluated expression
within the compound-statement of a function-body outside of a handler.
tested on x86_64, powerpc64le-linux, x86_64-darwin, cppcoro and folly,
pushed to master as obvious, thanks
Iain
Signed-off
From: John Eivind Helset
Hi,
The reported ICE occurs when an invalid (non-template) type is found
as the return for an await_suspend.
Fixed by amending build_co_await to ensure that await_suspend return-
type is a template-instantiation before checking to see if it is a
valid coroutine handle t
Hi,
Although it is not immediately evident from the symptoms, the PR is
caused by a variable having a DECL_INITIAL() containing a co_await.
This is not correct, since such expressions have side-effects.
We were marking the overall co_await expression correctly, but if a
consumer of that expressio
Hi,
There was a missing STRIP_NOPS which meant that, in some cases,
an awaiter variable could be hidden by a view-convert-expr.
tested on x86_64, powerpc64le linux and x86_86 darwin.
pushed to master as trivial/obvious.
thanks,
Iain
Signed-off-by: Iain Sandoe
PR c++/99575
gcc/cp/Chang
Hi,
I’ve backported the following fixes
to GCC 11
14ed21f8749ae359690d9c4a69ca38cc45d0d1b0,
8406ed9af2655479a9c8469d7acca2cf5784f5d6,
21b4d0ef543d68187d258415b51d0d6676af89fd,
88974974d8188cf12e87e4ad3d23a8cbdd557f0e,
a45a7ecdf34311587daa2e90cc732adcefac447b,
addf167a23f61c0ec97f6e71577a0623
Dear Fortranners,
when initializing parameter arrays from scalars, we did handle only
the case init->expr_type == EXPR_CONSTANT, which misses the case of
derived types. As a consequence the constructor for the r.h.s. was
not set up, which later led to different ICEs.
To solve this I looked at gf
On Sun, Oct 3, 2021 at 7:27 AM Roger Sayle wrote:
>
>
> My recent attempts to come up with a testcase for my patch to evaluate
> ss_plus in simplify-rtx.c, identified a missed optimization opportunity
> (that's potentially a long-time regression): The RTL optimizers no longer
> place constants in
My recent attempts to come up with a testcase for my patch to evaluate
ss_plus in simplify-rtx.c, identified a missed optimization opportunity
(that's potentially a long-time regression): The RTL optimizers no longer
place constants in the constant pool.
The motivating x86_64 example is the simpl
One more obvious fix that unblocks ASAN bootstrap.
Martin
gcc/ChangeLog:
* toplev.c (toplev::main): Check opt_index if it is a part
of cl_options.
---
gcc/toplev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/toplev.c b/gcc/toplev.c
index d952319ad9
Hi Jason,
I made a little improvement of my fix by including template
type parameter to not dropping cv-const because they are similar to dependent
type which you cannot determine whether they are top-level cv-qualifier or not
until instantiation.
+ if (processing_template_decl
+
On Sat, 2 Oct 2021, 13:50 Daniel Krügler via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Am Fr., 1. Okt. 2021 um 21:57 Uhr schrieb Jonathan Wakely via
> Libstdc++ :
> >
> > Implement the changes from P2162R2 (as a DR for C++17).
> >
> > Signed-off-by: Jonathan Wakely
> >
> > libstdc++-v3/ChangeL
On Wed, 29 Sep 2021, apinski--- via Gcc-patches wrote:
> Even though there is not many computed gotos in the wild and even less
> that would use an integer type, it would still be a good idea to add
> this new error message to both changes and the porting to guide.
Lovely, thank you!
> +Computed
19 matches
Mail list logo
