Hi
Here is the patch to fix the 2nd point of this mail below.
I prefer to qualify _Rb_tree_impl move constructor based on
std::is_nothrow_move_constructible<_Base_key_compare> so that the logic
of copying _Compare rather than moving it stays an implementation detail
of _Rb_tree_key_co
C2X adds BOOL_MAX and BOOL_WIDTH macros to . As GCC only
supports values 0 and 1 for _Bool (regardless of the number of bits in
the representation, other bits are padding bits and if any of them are
nonzero, the representation is a trap representation), the values of
those macros can just be hardc
On 02/07/2020 18:00, Jakub Jelinek wrote:
On Thu, Jul 02, 2020 at 05:15:20PM +0100, Andrew Stubbs wrote:
This patch, originally by Kwok, auto-adjusts the default OpenMP target
arguments to set num_threads(1) when there are no parallel regions. There
may still be multiple teams in this case.
The
The obsolescent (=legacy) assigned GOTO should only allow scalar integer
variables. Check for proper conditions.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports?
Thanks,
Harald
PR fortran/95709 - ICE in gfc_resolve_code, at fortran/resolve.c:11807
The legacy "assigned GOTO" accep
And one more like the previous patch.
Tested x86_64-linux, committed to trunk.
commit 5079855e7ebe8fd4a7f9005dd75fa35f8cd54daa
Author: Jonathan Wakely
Date: Thu Jul 2 21:27:12 2020 +0100
libstdc++: Require c++98_only effective target for a test
This test checks a conversion whi
These tests verify that including C++11 headers fails to compile in
C++98 mode. They use { dg-options "-std=gnu++98" } so that they are
explicitly run in C++98 mode. This change also adds a target selector so
that the tests will be skipped even if the dg-options directive is
filtered out or overrid
On 2020-07-01, Fāng-ruì Sòng wrote:
On 2020-07-01, Martin Liška wrote:
On 6/30/20 5:32 PM, Fāng-ruì Sòng wrote:
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option lik
> So this variant combined with the rest of the patch is OK then.
Thanks. It occurred to me that using string_constant might be slightly better
(iti is already used by gimple_fold_builtin_memchr in the same file).
* gimple-fold.c (gimple_fold_builtin_memory_op): Fold calls that were
On Tue, 16 Jun 2020, Martin Liška wrote:
> libgcc/ChangeLog:
>
> * libgcov-util.c (read_gcda_finalize): Remove const operator.
> (merge_wrapper): Add both counts and use them properly.
> (topn_to_memory_representation): New function.
> (gcov_merge): Covert on disk represent
These tests fail with AIX double double. Use different floating point
values that behave less surprisingly.
libstdc++-v3/ChangeLog:
PR libstdc++/91153
PR target/93224
* testsuite/29_atomics/atomic_float/1.cc: Use different values
for tests.
* testsuite/29_a
On 7/2/20 3:10 PM, Roger Sayle wrote:
> Hi Tom,
>
> Beware of doing something just because the default target hook does it that
> way.
Well, what I'm saying is that if the default target hook doesn't assume
tree_fits_uhwi_p (size), the safest solution is to do the same in the
nvptx target hook
On Thu, Jul 02, 2020 at 05:15:20PM +0100, Andrew Stubbs wrote:
> This patch, originally by Kwok, auto-adjusts the default OpenMP target
> arguments to set num_threads(1) when there are no parallel regions. There
> may still be multiple teams in this case.
>
> The result is that libgomp will not at
Jakub's partial implementation of consteval virtual had trouble with the
current ABI requirement that we omit the vtable slot for a consteval virtual
function; it's difficult to use the normal code for constant evaluation and
also magically make the slots disappear if the vtables get written out.
This patch, originally by Kwok, auto-adjusts the default OpenMP target
arguments to set num_threads(1) when there are no parallel regions.
There may still be multiple teams in this case.
The result is that libgomp will not attempt to launch GPU threads that
will never get used.
OK to commit?
Mark,
A quick test with
const char hint [] = _(" [see %<-fno-allow-invalid-boz%>]");
reproduces the failure.
const char *hint = _(" [see %<-fno-allow-invalid-boz%>]");
seems to work. I will do a full bootstrap test with that change later today.
Do you want me to commit it if it works or do y
On Thu, 2 Jul 2020, Martin Liška wrote:
> All right, you convinced me and I'm going to install the patch.
I'm fraid this may have broke i386-unknown-freebsd-11.4 (with clang 10.0
as bootstrap compiler, though that doesn't appear to be the trigger here):
/scratch/tmp/gerald/OBJ-0702-1130/./prev-g
On 7/1/20 3:25 PM, Jason Merrill wrote:
On 7/1/20 3:31 PM, Martin Sebor wrote:
The attached patch avoids null pointer checking for the first
argument to calls to the member operator() of lambda objects
emitted by the C++ front end. This avoids both the spurious
-Wnonnull warnings for such calls
On Thu, Jul 2, 2020 at 3:22 PM xiezhiheng wrote:
>
> Hi,
>
> This is a fix for pr94442.
> I modify get_inner_reference to handle the case for MEM[ptr, off].
> I extract the "off" and add it to the recorded offset, then I build a
> MEM[ptr, 0] and return it later.
>
> diff --git a/gcc/expr.c b/gcc/
On Thu, Jul 2, 2020 at 8:56 AM Mark Eggleston
wrote:
>
> On 02/07/2020 13:25, David Edelsohn wrote:
> > On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
> > wrote:
> >> I've committed the change from array to pointer. Does this fix your builds?
> >>
> >> On 02/07/2020 08:18, Mark Eggleston wrote:
>
On 7/1/20 3:06 PM, Roger Sayle wrote:
>
> The following patch adds support for the popc and mul.wide instructions to
> the nvptx backend.
> I've a follow-up patch for supporting mul.hi instructions, but those changes
> require some minor
> tweaks to GCC's middle-end, so I'll submit those pieces
Hi,
This is a fix for pr94442.
I modify get_inner_reference to handle the case for MEM[ptr, off].
I extract the "off" and add it to the recorded offset, then I build a
MEM[ptr, 0] and return it later.
diff --git a/gcc/expr.c b/gcc/expr.c
index 3c68b0d754c..8cc18449a0c 100644
--- a/gcc/expr.c
+++
Hi Tom,
Beware of doing something just because the default target hook does it that way.
See https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549128.html
which fixes PR middle-end/90597 by correcting default_vector_alignment to do
it the same way as proposed by this nvptx backend patch.
Many t
On 02/07/2020 13:56, Mark Eggleston wrote:
On 02/07/2020 13:25, David Edelsohn wrote:
On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
I've committed the change from array to pointer. Does this fix your
builds?
On 02/07/2020 08:18, Mark Eggleston wrote:
On 01/07/2020 20:07, David Ede
On 02/07/2020 13:25, David Edelsohn wrote:
On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
I've committed the change from array to pointer. Does this fix your builds?
On 02/07/2020 08:18, Mark Eggleston wrote:
On 01/07/2020 20:07, David Edelsohn wrote:
This patch breaks bootstrap.
Ap
This guards externalizing a SLP node when it fails to code generate
to actually have scalar defs we can use. It also makes failure
to do so not fell the whole SLP instance but instead try this again
on the parent.
This is the variant I installed.
2020-07-02 Richard Biener
PR tree-opt
Hi Thomas and Dominique,
The patch looks fine to me. If Dominique has nothing to report then it is
OK for trunk.
Thanks
Paul
On Thu, 2 Jul 2020 at 11:15, wrote:
> Le 2020-06-30 23:39, Thomas Koenig a écrit :
> > OK,
> >
> > so here is an updated version, which includes the updated test cases
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, July 2, 2020 5:17 PM
> To: Yangfei (Felix)
> Cc: Richard Biener ; Richard Biener
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95961] vect: ICE: in exact_div, at poly-int.h:2182
>
On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
>
> I've committed the change from array to pointer. Does this fix your builds?
>
> On 02/07/2020 08:18, Mark Eggleston wrote:
> > On 01/07/2020 20:07, David Edelsohn wrote:
> >> This patch breaks bootstrap.
> >
> > Apologies. I didn't see this
On 6/29/20 7:19 PM, Roger Sayle wrote:
> This patch addresses the ICE in gcc.dg/attr-vector_size.c during make -k
> check on
> nvptx-none. The actual ICE looks like:
>
> testsuite/gcc.dg/attr-vector_size.c:29:1: internal compiler error: in
> tree_to_shwi, at tree.c:7321
> 0xf53bf2 tree_to_shwi(
I already had removed your change. I hope that you did not re-break bootstrap.
You should be re-producing the breakage and then confirming the fix,
not randomly applying patches and asking others if you didn't break it
again. That is not appropriate for GCC development.
Thanks David
On Thu, Ju
On 01/07/2020 23:01, Jerry DeLisle wrote:
On 6/27/20 1:40 AM, Thomas Koenig via Fortran wrote:
Hi Mark,
Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec.
A warning that the lower bound is being used for a mission dimension
is output unless suppressed by using -Wno-miss
> Omar Tahir writes:
> > Hi Richard,
> >
> > From: Richard Sandiford
> >> > @@ -3719,6 +3722,7 @@ static unsigned int rest_of_handle_sched (void)
> >> > { #ifdef INSN_SCHEDULING
> >> > + first_moveable_pseudo = last_moveable_pseudo;
> >> >if (flag_selective_scheduling
> >> >&& ! may
On Thu, Jul 2, 2020 at 12:27 PM Eric Botcazou wrote:
>
> > Sorry for the ping-pong but why's using a new char[len] type problematic?
>
> Because the type may be incompatible with that of the STRING_CST, so we would
> need to build a new STRING_CST with the new type.
I see.
> > That said, I do li
> Sorry for the ping-pong but why's using a new char[len] type problematic?
Because the type may be incompatible with that of the STRING_CST, so we would
need to build a new STRING_CST with the new type.
> That said, I do like p2 more even if we need to special-case STRING_CST
> sources at the e
I've committed the change from array to pointer. Does this fix your builds?
On 02/07/2020 08:18, Mark Eggleston wrote:
On 01/07/2020 20:07, David Edelsohn wrote:
This patch breaks bootstrap.
Apologies. I didn't see this when I built the compiler the with
bootstrap on x86_64. I'll endevour to
Le 2020-06-30 23:39, Thomas Koenig a écrit :
OK,
so here is an updated version, which includes the updated test cases.
Anything else? OK for trunk?
Nothing to report!-)
Thanks for the patch,
Dominique
This guards externalizing a SLP node when it fails to code generate
to actually have scalar defs we can use. It also makes failure
to do so not fell the whole SLP instance but instead try this again
on the parent.
Bootstrap / regtest running on x86_64-unknown-linux-gnu and should
fix an ICE obser
On Thu, Jul 2, 2020 at 11:03 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following testcase ICEs, because during the cfg cleanup, we see:
> switch (i$e_11) [33.33%], case -3: [33.33%], case 0:
> [33.33%], case 2: [33.33%]>
> ...
> lab2:
> __builtin_unreachable ();
> where lab2
This fixes lane extraction for internal def vectorized shifts
with an effective scalar shift operand by always using lane zero
of the first vector stmt.
It also fixes a SLP build issue noticed on the testcase where
we end up building unary vector ops with the only operand built
form scalars which
"Yangfei (Felix)" writes:
> Hi,
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Wednesday, July 1, 2020 9:03 PM
>> To: Yangfei (Felix)
>> Cc: Richard Biener ; Richard Biener
>> ; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH PR95961] vect: I
Hi!
The OpenMP 5 standard requires that if some loop in OpenMP loop nest refers
to some outer loop's iterator variable, then the subtraction of the
multiplication
factors for the outer iterator multiplied by the outer increment modulo the
inner increment is 0. For loops with non-constants in any
On Thu, Jul 2, 2020 at 10:20 AM Martin Liška wrote:
>
> On 6/30/20 3:03 PM, Richard Biener wrote:
> > Now to simply restore previous behavior for this particular case we should
> > probably make expand_vector_comparison walk immediate uses as you do
> > but then call expand_vector_condition for ea
Hi!
The following testcase ICEs, because during the cfg cleanup, we see:
switch (i$e_11) [33.33%], case -3: [33.33%], case 0:
[33.33%], case 2: [33.33%]>
...
lab2:
__builtin_unreachable ();
where lab2 is FORCED_LABEL. The way it works, we go through the case labels
and when we reach the
On Wed, Jul 1, 2020 at 11:59 PM Martin Jambor wrote:
>
> Hi,
>
> the mechanism generating debug info for removed parameters did not
> adjust index of the argument in the call statement to take into
> account extra arguments IPA-SRA might have produced when splitting a
> strucutre. This patch addr
On Wed, Jul 1, 2020 at 11:06 PM Eric Botcazou wrote:
>
> > Hmm, that's a good question - so would your patch be replaceable by
> > simply amending var_decl_component_p by
> >
> > (var_decl_component_p (TREE_OPERAND (src, 0))
> >
> >|| TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST)
> >
> >
Such problematic components can be specified by means of a component clause
but they cannot be fully supported by the type system. They had initially
been forbidden, then we decided to accept them by working around the type
system, but this is very fragile and, for example, any static aggregate
On Wed, Jul 1, 2020 at 10:02 PM Jeff Law wrote:
>
> On Mon, 2020-06-29 at 08:58 +0200, Richard Biener wrote:
> > On Sat, Jun 27, 2020 at 4:52 PM Marc Glisse wrote:
> > > On Fri, 26 Jun 2020, Jeff Law via Gcc-patches wrote:
> > >
> > > > In theory yes, but there are cases where paths converge (lik
On 6/30/20 3:03 PM, Richard Biener wrote:
Now to simply restore previous behavior for this particular case we should
probably make expand_vector_comparison walk immediate uses as you do
but then call expand_vector_condition for each VEC_COND_EXPR use,
making that return whether it "consumed" the
On 7/1/20 4:01 PM, Jan Hubicka wrote:
On 7/1/20 3:15 AM, Martin Liška wrote:
On 6/30/20 3:24 PM, Nathan Sidwell wrote:
On 6/30/20 8:53 AM, Martin Liška wrote:
Yes, if there's a real need for a solid compression, then I would use a
generic compressor of a final streamed file.
for avoidance
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, July 1, 2020 9:03 PM
> To: Yangfei (Felix)
> Cc: Richard Biener ; Richard Biener
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95961] vect: ICE: in exact_div, at poly-int.h:2182
On 01/07/2020 20:07, David Edelsohn wrote:
This patch breaks bootstrap.
Apologies. I didn't see this when I built the compiler the with
bootstrap on x86_64. I'll endevour to get it fixed as soon as possible.
regards,
Mark
It is not portable to use _( ... ) to initialize an array.
In file
51 matches
Mail list logo
