Hi!
OpenMP 5.0 also newly says:
"If one or more of the use_device_ptr or use_device_addr clauses and one or
more map
clauses are present on the same construct, the address conversions of
use_device_addr and
use_device_ptr clauses will occur as if performed after all variables are
mapped accordi
rand is in ISO C, whereas random is only in POSIX, so it makes sense
to use the more portable function everywhere instead of falling back
from one to the other on systems that miss the less portable one.
Tested on x86_64-linux-gnu, native and cross to ppc. Ok to install?
for gcc/testsuite/Chan
On Wed, 7 Aug 2019, Joseph Myers wrote:
On Sat, 22 Jun 2019, Marc Glisse wrote:
as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Could you give a high-level description of
On Thu, 1 Aug 2019 at 15:34, Prathamesh Kulkarni
wrote:
>
> On Thu, 25 Jul 2019 at 11:56, Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 17 Jul 2019 at 18:15, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 17 Jul 2019 at 13:45, Kyrill Tkachov
> > > wrote:
> > > >
> > > > Hi Prathamesh
> > > >
On Mon, 24 Jun 2019, Richard Biener wrote:
> On the patch I'd name _DIV _RDIV (to match the tree code we are dealing
> with). You miss _NEGATE and also the _FIX_TRUNC and _FLOAT in
> case those might trap with -ftrapping-math. There are also internal
Negation (and abs and copysign) can never ra
This test is reported as UNSUPPORTED when it runs on x86_64
and I expect everywhere else except hppa-*-*. There's nothing
PA-RISC specific in it that I can see and it runs successfully,
so I'm thinking I'll enable it everywhere just to get rid of
the UNSUPPORTED result.
Jeff, it's a test you add
I've committed updated for the testcases for PR fortran/91359.
Both files had "! { dg do run }" instead og "! { dg-do run }",
and for some unexplained reason pr91359_1.f and pr91359_2.f
were identical. Patch attached.
2019-08-07 Steven G. Kargl
PR fortran/91359
* pr91359_2.f: Fix missing h
On Wed, Aug 07, 2019 at 05:26:45PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 07, 2019 at 11:21:48PM +0100, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Wed, Aug 07, 2019 at 07:16:03PM +0100, Richard Sandiford wrote:
> > >> The main IRA routine includes the code:
> > >>
>
On Wed, Aug 07, 2019 at 11:21:48PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Wed, Aug 07, 2019 at 07:16:03PM +0100, Richard Sandiford wrote:
> >> The main IRA routine includes the code:
> >>
> >> /* Don't move insns if live range shrinkage or register
> >> pressur
Segher Boessenkool writes:
> Hi Richard,
>
> On Wed, Aug 07, 2019 at 07:16:03PM +0100, Richard Sandiford wrote:
>> The main IRA routine includes the code:
>>
>> /* Don't move insns if live range shrinkage or register
>> pressure-sensitive scheduling were done because it will not
>> im
On Wed, Aug 07, 2019 at 08:37:52PM +0200, Uros Bizjak wrote:
> It looks that combine lost some of its unwanted creativity. Added
> testcase will keep it that way.
Huh, I wonder why it ever did that :-) Strange.
> -;; Combine is quite creative about this pattern.
> (define_insn "*negsi2_1_zext"
On 7/30/19 7:37 AM, Martin Liška wrote:
> Hi.
>
> Thanks to Martin I was able to prepare a proper fix. The issue is that
> cgraph_edge::resolve_speculation can delete this pointer (yes, it's
> super nasty) and so that the caller can't use this->something
> right after the function returns.
>
> Fo
On 7/30/19 8:42 AM, Martin Sebor wrote:
> On 7/30/19 2:44 AM, Richard Biener wrote:
>> On Tue, Jul 30, 2019 at 10:35 AM Jakub Jelinek wrote:
>>>
>>> On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote:
Would you need to LTO stream & merge the bitmaps / maps somehow?
>>>
>>> Yes. A
On Sun, 23 Jun 2019, Marc Glisse wrote:
> For constant expressions, I see a difference between
> constexpr double third = 1. / 3.;
> which really needs to be done at compile time, and
> const double third = 1. / 3.;
> which will try to evaluate the rhs as constexpr, but where the program is
> stil
On Sat, 22 Jun 2019, Marc Glisse wrote:
> as discussed in the PR, this seems like a simple enough approach to handle
> FENV functionality safely, while keeping it possible to implement
> optimizations in the future.
Could you give a high-level description of the implementation approach,
and how
Hi Richard,
On Wed, Aug 07, 2019 at 07:16:03PM +0100, Richard Sandiford wrote:
> The main IRA routine includes the code:
>
> /* Don't move insns if live range shrinkage or register
> pressure-sensitive scheduling were done because it will not
> improve allocation but likely worsen ins
On Wed, Aug 07, 2019 at 10:37:04PM +0200, Jakub Jelinek wrote:
> On Wed, Aug 07, 2019 at 04:30:29PM -0400, Marek Polacek wrote:
> > +/* Complain about an attempt to evaluate inline assembly. */
> > +
> > +static void
> > +inline_asm_in_constexpr_error (location_t loc)
> > +{
> > + error_at (loc,
On Wed, Aug 07, 2019 at 04:30:29PM -0400, Marek Polacek wrote:
> +/* Complain about an attempt to evaluate inline assembly. */
> +
> +static void
> +inline_asm_in_constexpr_error (location_t loc)
> +{
> + error_at (loc, "inline assembly is not a constant expression");
> + inform (loc, "only unev
On Wed, Aug 07, 2019 at 03:38:02PM -0400, Jason Merrill wrote:
> On Wed, Aug 7, 2019, 2:35 PM Marek Polacek wrote:
>
> > On Wed, Aug 07, 2019 at 12:23:25PM -0400, Jason Merrill wrote:
> > > On Wed, Aug 7, 2019, 9:11 AM Marek Polacek wrote:
> > >
> > > > On Tue, Aug 06, 2019 at 09:25:45PM -0400,
When implementing -Wcomma-subscript I failed to realize that a comma in
a template-argument-list shouldn't be warned about.
But we can't simply ignore any commas inside < ... > because the following
needs to be caught:
a[b < c, b > c];
This patch from Jakub fixes it by moving the warning to cp
On Wed, Aug 7, 2019, 2:35 PM Marek Polacek wrote:
> On Wed, Aug 07, 2019 at 12:23:25PM -0400, Jason Merrill wrote:
> > On Wed, Aug 7, 2019, 9:11 AM Marek Polacek wrote:
> >
> > > On Tue, Aug 06, 2019 at 09:25:45PM -0400, Jason Merrill wrote:
> > > > Let's downgrade the errors in earlier standard
It was easier to add the SVE ACLE support without enumerating every
function at build time. This in turn meant that it was easier if the
SVE builtins occupied a distinct numberspace from the existing AArch64
ones, which *are* enumerated at build time. This patch therefore
divides the built-in fun
The Advanced SIMD and SVE permute patterns both split the permute
operation into a base name and a hilo suffix. That works well, but it
means that for "@" patterns, we need to pass the permute code twice,
once for the base name and once for the suffix.
Having a unified name avoids that and also m
We used INSR to handle zero integers but not zero floats.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274193.
Richard
2019-08-07 Richard Sandiford
gcc/
* config/aarch64/constraints.md (Z): Handle floating-point zeros too.
* config/aarch
INSR of GPRs involves a cross-file move while INSR of FPRs doesn't.
We should therefore disparage the GPR version relative to the FPR
version.
The patch also adds MOVPRFX handling, but this is only tested
properly by the ACLE.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
This patch makes the SVE CLASTB GPR alternative more expensive than the
FPR alternative in order to avoid unnecessary cross-file moves. It also
fixes the prefix used to print the FPR; only handles 32-bit and
64-bit elements.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
The reorg showed that we had an unnecessary separation between
the bitwise and max/min reductions for integers, and the
addition and max/min reductions for fp.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274190.
Richard
2019-08-07 Richard Sandiford
gcc
This patch combines the four individual fused multiply-add optabs
into one pattern and uses unspecs instead of rtx codes. This is
part of a series of patches that change the SVE FP patterns so that
they can describe cases in which the predicate isn't all-true.
Tested on aarch64-linux-gnu (with an
This patch makes us use the same define_insn for both the smax/smin
and fmax/fmin optabs. It also continues the process started by
the earlier FP unary patch of moving predicated FP patterns from
rtx codes to unspecs.
There's no need to handle the FMAX and FMIN instructions until
the ACLE patch,
On Wed, Aug 07, 2019 at 09:09:49AM -0700, Steve Kargl wrote:
> On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:
> >
> > DATA statements for logical and character variable compile but do not work:
> >
> > program test
> > character(4) :: c
> > data c / z'41424344' /
> > wri
This patch merges the SVE FP rounding patterns with the other SVE
FP unary patterns.
At the moment, we only generate unary FP operations for full vectors,
so we can use (sqrt:VNx4SF ...) etc. in the rtl pattern. With the ACLE,
it's also possible to generate predicated operations on partial vector
*pred_fold_left_plus_ could no longer match anything, since
UNSPEC_FADDA now takes three operands. Predicated FADDAs should
now go through mask_fold_left_plus_ instead.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274186.
Richard
2019-08-07 Richard Sandif
This patch makes the UNSPEC_COND* names match the instruction mnemonics,
rather than having the previous mixture in which some used instructions
while others used operator names.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274185.
Richard
2019-08-07 Richa
It looks that combine lost some of its unwanted creativity. Added
testcase will keep it that way.
2019-08-07 Uroš Bizjak
PR target/91385
* config/i386/sse.md (*negsi2_1_zext): Simplify insn pattern.
(*negsi2_cmpz_zext): Ditto.
testsuite/ChangeLog:
2019-08-07 Uroš Bizjak
P
On Wed, Aug 07, 2019 at 12:23:25PM -0400, Jason Merrill wrote:
> On Wed, Aug 7, 2019, 9:11 AM Marek Polacek wrote:
>
> > On Tue, Aug 06, 2019 at 09:25:45PM -0400, Jason Merrill wrote:
> > > Let's downgrade the errors in earlier standard modes to pedwarn. Ok with
> > > that change.
> >
> > Works f
The commutative attribute was once used by the SVE conditional binary
expanders, but it's now dead code.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274182.
Richard
2019-08-07 Richard Sandiford
gcc/
* config/aarch64/iterators.md (commutative):
aarch64_classify_vector_mode used properties of a mode to test whether
the mode was a single Advanced SIMD vector, a single SVE vector, or a
tuple of SVE vectors. That works well for current trunk and is simpler
than checking for modes by name.
However, for the ACLE and for planned autovec improv
Some indexed SVE FCMLA operations have a 3-bit register field that
requires one of Z0-Z7. This patch adds a public "y" constraint for that.
The patch also documents "x", which is again intended to be a public
constraint.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
OK t
The main IRA routine includes the code:
/* Don't move insns if live range shrinkage or register
pressure-sensitive scheduling were done because it will not
improve allocation but likely worsen insn scheduling. */
if (optimize
&& !flag_live_range_shrinkage
&& !(flag_sched
The AArch64 port uses define_splits to prefer moving certain float
constants via integer registers over loading them from memory. E.g.:
(set (reg:SF X) (const_double:SF C))
splits to:
(set (reg:SI tmp) (const_int C'))
(set (reg:SF X) (subreg:SF (reg:SI tmp) 0))
The problem with usi
On Wed, 2019-08-07 at 10:40 +, Szabolcs Nagy wrote:
> ---
> ---
> On 31/07/2019 08:25, Richard Sandiford wrote:
> > Steve Ellcey writes:
> > >
> > > 2019-07-30 Steve Ellcey
> > >
> > > * omp-simd-clone.c (simd_clone_adjust_return_type): Remove cal
On Wed, Aug 07, 2019 at 12:32:54PM -0400, Jason Merrill wrote:
> On Tue, Aug 6, 2019, 11:28 PM Marek Polacek wrote:
>
> > In this PR, we are wrongly parsing a constructor if its first parameter
> > begins
> > with a C++11 attribute, e.g.:
> >
> > struct S {
> > S([[maybe_unused]] int a) { }
While trying to use the -flto and -fwhole-program flags I ran into problems
understanding what they do. I would like to update the documentation but I
still don't understand these flags enough to be able to describe their
behaviour. Here is the document section I would like to fix but don't
have
On Tue, Aug 6, 2019, 11:28 PM Marek Polacek wrote:
> In this PR, we are wrongly parsing a constructor if its first parameter
> begins
> with a C++11 attribute, e.g.:
>
> struct S {
> S([[maybe_unused]] int a) { }
> };
>
> If the GNU attribute format is used instead, there's no problem.
>
On Wed, Aug 7, 2019, 9:11 AM Marek Polacek wrote:
> On Tue, Aug 06, 2019 at 09:25:45PM -0400, Jason Merrill wrote:
> > Let's downgrade the errors in earlier standard modes to pedwarn. Ok with
> > that change.
>
> Works for me, here's what I'll apply once it passes testing.
>
> I removed the diagn
On 07/08/2019 17:15, Jakub Jelinek wrote:
On Wed, Aug 07, 2019 at 05:08:28PM +0100, Richard Earnshaw (lists) wrote:
Though, I'm fine if you commit your patch now as a fix and Richi's patch
with the above incremental change is applied on top of it incrementally
as a cleanup.
Jakub
Ok,
On Wed, Aug 07, 2019 at 05:08:28PM +0100, Richard Earnshaw (lists) wrote:
> > Though, I'm fine if you commit your patch now as a fix and Richi's patch
> > with the above incremental change is applied on top of it incrementally
> > as a cleanup.
> >
> > Jakub
> >
>
> Ok, I'll do that.
Thanks
On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:
>
> BOZ problems in the following areas
>
> * use of logical and character variables with BOZ constants
> * comparisons with BOZ constants
> * DATA statements
>
> Comparing 9.1 and trunk:
The comparison is somewhat irrelevant
On 07/08/2019 14:51, Jakub Jelinek wrote:
On Wed, Aug 07, 2019 at 01:42:34PM +0100, Richard Earnshaw (lists) wrote:
Some options are handled differently by the main driver (gcc, g++, etc) from
the back-end compiler programs (cc1, cc1plus, etc) in that in the driver
they do not take an additional
On 8/6/19 11:30 AM, Steve Ellcey wrote:
Ed,
I have run into an ICE that I tracked down to this patch:
commit 02fefffe6b78c4c39169206aa40fb53f367ecba8
Author: emsr
Date: Thu Aug 1 15:25:42 2019 +
2019-08-01 Edward Smith-Rowland <3dw...@verizon.net>
Implement C++20 p0
Hi all,
This patch adds an effective target check to the pointer authentication B key
execution tests. These were failing with an assembler error when run with a
non-recent version of binutils, and this change will instead make them
unsupported in such cases.
Tested with a recent version of bi
On 6/11/19 1:36 AM, Martin Liska wrote:
gcc/ChangeLog:
2019-07-24 Martin Liska
* ipa-icf-gimple.c (func_checker::compatible_types_p):
Do not compare alias sets. It's handled by operand_equal_p.
gcc/testsuite/ChangeLog:
2019-07-24 Martin Liska
* c-c++-common/Ws
On Wed, Aug 7, 2019 at 5:09 AM Martin Liška wrote:
>
> There's one enhanced version where I added HAVE_FCNTL_H.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
I think a better name than fd_exists would be is_valid_fd. If that's
OK with you,
On 8/7/19 7:36 AM, senthilkumar.selva...@microchip.com wrote:
Hi,
gcc/testsuite/c-c++-common/pr60101.c fails with an ICE for the
avr target, because of a gcc_assert firing at reload1.c:4233
The assert (in the patch below) looks bogus to me, as it's in
the if block of
if (! ira
On Wed, Aug 7, 2019 at 2:04 PM Martin Liška wrote:
>
> On 8/7/19 12:51 PM, Jakub Jelinek wrote:
> > On Wed, Aug 07, 2019 at 12:44:28PM +0200, Martin Liška wrote:
> >> On 8/7/19 11:51 AM, Richard Biener wrote:
> >>> I think the simplest way to achieve this is to not copy, aka clear,
> >>> DECL_IS_O
On Wed, 7 Aug 2019, Richard Biener wrote:
> On Mon, 5 Aug 2019, Uros Bizjak wrote:
>
> > On Mon, Aug 5, 2019 at 3:29 PM Richard Biener wrote:
> >
> > > > > > > > > (define_mode_iterator MAXMIN_IMODE [SI "TARGET_SSE4_1"] [DI
> > > > > > > > > "TARGET_AVX512F"])
> > > > > > > > >
> > > > > > > >
On Wed, Aug 07, 2019 at 01:42:34PM +0100, Richard Earnshaw (lists) wrote:
> Some options are handled differently by the main driver (gcc, g++, etc) from
> the back-end compiler programs (cc1, cc1plus, etc) in that in the driver
> they do not take an additional argument, while in the compiler progra
On 7.8.2019 15:09, Martin Liška wrote:
Hi.
There's one enhanced version where I added HAVE_FCNTL_H.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
Hi,
tested this one against the latest trunk and it seems to be working --
as in
On 8/5/19 4:37 PM, Bernd Edlinger wrote:
Hi!
PR 91109 is a wrong-code bug, where LRA is using a scratch register
which is actually not available for use, and thus gets clobbered
when it should not. That seems to be mostly because the live range
info of the cloned schatch register is not workin
On Tue, Aug 06, 2019 at 09:25:45PM -0400, Jason Merrill wrote:
> Let's downgrade the errors in earlier standard modes to pedwarn. Ok with
> that change.
Works for me, here's what I'll apply once it passes testing.
I removed the diagnostic in potential_constant_expression_1/ASM_EXPR so that
we don
On Wed, Aug 7, 2019 at 2:52 PM Richard Biener wrote:
>
> On Wed, 7 Aug 2019, Uros Bizjak wrote:
>
> > On Wed, Aug 7, 2019 at 2:20 PM Uros Bizjak wrote:
> > >
> > > On Wed, Aug 7, 2019 at 1:51 PM Richard Biener wrote:
> > > >
> > > > On Wed, 7 Aug 2019, Richard Biener wrote:
> > > >
> > > > > On
Steve,
BOZ problems in the following areas
* use of logical and character variables with BOZ constants
* comparisons with BOZ constants
* DATA statements
Comparing 9.1 and trunk:
character variables (9.1)
* old style initialisation - not allowed (Incompatible types)
* new style initialis
On Wed, 7 Aug 2019, Uros Bizjak wrote:
> On Wed, Aug 7, 2019 at 2:20 PM Uros Bizjak wrote:
> >
> > On Wed, Aug 7, 2019 at 1:51 PM Richard Biener wrote:
> > >
> > > On Wed, 7 Aug 2019, Richard Biener wrote:
> > >
> > > > On Mon, 5 Aug 2019, Uros Bizjak wrote:
> > > >
> > > > > On Mon, Aug 5, 2019
On Wed, Aug 7, 2019 at 2:20 PM Uros Bizjak wrote:
>
> On Wed, Aug 7, 2019 at 1:51 PM Richard Biener wrote:
> >
> > On Wed, 7 Aug 2019, Richard Biener wrote:
> >
> > > On Mon, 5 Aug 2019, Uros Bizjak wrote:
> > >
> > > > On Mon, Aug 5, 2019 at 3:29 PM Richard Biener wrote:
> > > >
> > > > > > > >
Some options are handled differently by the main driver (gcc, g++, etc)
from the back-end compiler programs (cc1, cc1plus, etc) in that in the
driver they do not take an additional argument, while in the compiler
programs they do. The processing option option CL_DRIVER controls this
alternativ
Hi,
On Wed, 7 Aug 2019, senthilkumar.selva...@microchip.com wrote:
> gcc/testsuite/c-c++-common/pr60101.c fails with an ICE for the
> avr target, because of a gcc_assert firing at reload1.c:4233
>
> The assert (in the patch below) looks bogus to me, as it's in
> the if block of
>
>
On Wed, Aug 7, 2019 at 1:51 PM Richard Biener wrote:
>
> On Wed, 7 Aug 2019, Richard Biener wrote:
>
> > On Mon, 5 Aug 2019, Uros Bizjak wrote:
> >
> > > On Mon, Aug 5, 2019 at 3:29 PM Richard Biener wrote:
> > >
> > > > > > > > > > (define_mode_iterator MAXMIN_IMODE [SI "TARGET_SSE4_1"] [DI
> >
On Tue, Aug 6, 2019 at 5:45 PM Martin Liska wrote:
>
>
> gcc/ChangeLog:
OK.
Richard.
> 2019-07-24 Martin Liska
>
> * fold-const.c (twoval_comparison_p): Replace int
> with bool as a return type.
> (simple_operand_p): Likewise.
> (operand_equal_p): Replace int
On Tue, Aug 6, 2019 at 5:44 PM Martin Liska wrote:
>
>
> gcc/ChangeLog:
So I suppose this isn't to call operand_equal_p on two FIELD_DECLs
but to make two COMPONENT_REFs "more equal"? If so I then
I suggest to make this change "local" to the COMPONENT_REF handling.
This also interacts with path-
Hi.
There's one enhanced version where I added HAVE_FCNTL_H.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 980d84c31f4c27a4f8314808d1ffa548b3c7bcc8 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 6 Aug 2019 13:04:40 +02
On Wed, Aug 7, 2019 at 1:51 PM Richard Biener wrote:
>
> On Wed, 7 Aug 2019, Richard Biener wrote:
>
> > On Mon, 5 Aug 2019, Uros Bizjak wrote:
> >
> > > On Mon, Aug 5, 2019 at 3:29 PM Richard Biener wrote:
> > >
> > > > > > > > > > (define_mode_iterator MAXMIN_IMODE [SI "TARGET_SSE4_1"] [DI
> >
On Tue, Aug 6, 2019 at 5:43 PM Martin Liska wrote:
>
>
> gcc/ChangeLog:
+ /* Virtual table call. */
+ case OBJ_TYPE_REF:
+ {
+ if (!operand_equal_p (OBJ_TYPE_REF_EXPR (arg0),
+ OBJ_TYPE_REF_EXPR (arg1), flags))
+ return fa
On 8/7/19 12:51 PM, Jakub Jelinek wrote:
> On Wed, Aug 07, 2019 at 12:44:28PM +0200, Martin Liška wrote:
>> On 8/7/19 11:51 AM, Richard Biener wrote:
>>> I think the simplest way to achieve this is to not copy, aka clear,
>>> DECL_IS_OPERATOR_* when cloning and removing arguments
>>> (cloning for a
On Tue, Aug 6, 2019 at 5:43 PM Martin Liska wrote:
This warrants a comment like
/* This function originally abstracts from simply comparing
get_deref_alias_set
so that we are sure this still computes the same result after LTO
type merging
is applied. When in LTO type merging is done
On Wed, 7 Aug 2019, Richard Biener wrote:
> On Mon, 5 Aug 2019, Uros Bizjak wrote:
>
> > On Mon, Aug 5, 2019 at 3:29 PM Richard Biener wrote:
> >
> > > > > > > > > (define_mode_iterator MAXMIN_IMODE [SI "TARGET_SSE4_1"] [DI
> > > > > > > > > "TARGET_AVX512F"])
> > > > > > > > >
> > > > > > > >
Hi,
gcc/testsuite/c-c++-common/pr60101.c fails with an ICE for the
avr target, because of a gcc_assert firing at reload1.c:4233
The assert (in the patch below) looks bogus to me, as it's in
the if block of
if (! ira_conflicts_p || reg_renumber[i] >= 0)
For this testcase and for
On Wed, Aug 07, 2019 at 12:44:28PM +0200, Martin Liška wrote:
> On 8/7/19 11:51 AM, Richard Biener wrote:
> > I think the simplest way to achieve this is to not copy, aka clear,
> > DECL_IS_OPERATOR_* when cloning and removing arguments
> > (cloning for a constant align argument should be OK for ex
On 8/7/19 11:51 AM, Richard Biener wrote:
> I think the simplest way to achieve this is to not copy, aka clear,
> DECL_IS_OPERATOR_* when cloning and removing arguments
> (cloning for a constant align argument should be OK for example, as is
> for a constant address). Or simply always when cloning
On 31/07/2019 08:25, Richard Sandiford wrote:
> Steve Ellcey writes:
>>
>> 2019-07-30 Steve Ellcey
>>
>> * omp-simd-clone.c (simd_clone_adjust_return_type): Remove call to
>> build_distinct_type_copy.
>> (simd_clone_adjust_argument_types): Ditto.
>> (simd_clone_adjust): Call
On 8/7/19 12:04 PM, Jakub Jelinek wrote:
> On Wed, Aug 07, 2019 at 11:54:44AM +0200, Martin Liška wrote:
>> The patch is conclusion of long-lasting discussion in the PR.
>> I've just verified that our gcc9 package with the patch attached
>> can build emacs, and so it's fixed.
>
> Richard said he h
On 8/7/19 10:56 AM, Jakub Jelinek wrote:
> On Wed, Aug 07, 2019 at 10:45:08AM +0200, Martin Liška wrote:
>> @@ -155,3 +156,16 @@ lrealpath (const char *filename)
>>/* This system is a lost cause, just duplicate the filename. */
>>return strdup (filename);
>> }
>> +
>> +/* Return true when
On Wed, Aug 7, 2019 at 10:56 AM Martin Liška wrote:
>
> On 8/6/19 5:44 PM, Marc Glisse wrote:
> > On Tue, 6 Aug 2019, Martin Liška wrote:
> >
> >> Anyway, I'm sending patch that considers only such new/delete operators
> >> that are not a clone of an original type. That should make the current
> >
On Wed, Aug 07, 2019 at 11:54:44AM +0200, Martin Liška wrote:
> The patch is conclusion of long-lasting discussion in the PR.
> I've just verified that our gcc9 package with the patch attached
> can build emacs, and so it's fixed.
Richard said he has a patch in testing that he plans to submit toda
Hi.
The patch is conclusion of long-lasting discussion in the PR.
I've just verified that our gcc9 package with the patch attached
can build emacs, and so it's fixed.
Note that the CL_DRIVER instead of CL_LANG_ALL still fails.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests
On Tue, Aug 6, 2019 at 4:48 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Aug 5, 2019 at 10:58 AM Richard Sandiford
> > wrote:
> >>
> >> unmodified_param_1 used tree_to_shwi without first checking
> >> tree_fits_shwi_p. This is needed by the SVE ACLE support and
> >> is har
On Tue, Aug 6, 2019 at 2:42 PM Martin Liška wrote:
>
> On 8/5/19 3:46 PM, Marc Glisse wrote:
> > On Mon, 5 Aug 2019, Martin Liška wrote:
> >
> >> You are right. It can really lead to confusion of the DCE.
> >>
> >> What we have is DECL_ABSTRACT_ORIGIN(decl) which we can use to indicate
> >> opera
On Mon, 5 Aug 2019, Uros Bizjak wrote:
> On Mon, Aug 5, 2019 at 3:29 PM Richard Biener wrote:
>
> > > > > > > > (define_mode_iterator MAXMIN_IMODE [SI "TARGET_SSE4_1"] [DI
> > > > > > > > "TARGET_AVX512F"])
> > > > > > > >
> > > > > > > > and then we need to split DImode for 32bits, too.
> > >
On Wed, Aug 07, 2019 at 10:45:08AM +0200, Martin Liška wrote:
> @@ -155,3 +156,16 @@ lrealpath (const char *filename)
>/* This system is a lost cause, just duplicate the filename. */
>return strdup (filename);
> }
> +
> +/* Return true when FD file descriptor exists. */
> +
> +int
> +fd_
On 8/6/19 5:44 PM, Marc Glisse wrote:
> On Tue, 6 Aug 2019, Martin Liška wrote:
>
>> Anyway, I'm sending patch that considers only such new/delete operators
>> that are not a clone of an original type. That should make the current
>> DCE code more solid.
>
> DECL_IS_REPLACEABLE_OPERATOR_NEW_P see
On 8/6/19 7:02 PM, Martin Jambor wrote:
> Hi,
>
> unfortunately I cannot look into the problem now and I don't have my
> phone set up to review patches in a sane way, but to answer your
> question below...
Thank you Martin for answer. It can definitely wait once you're back
at the office.
>
>
On 8/6/19 6:18 PM, Martin Sebor wrote:
> On 8/6/19 9:55 AM, Martin Liška wrote:
>> On 8/6/19 5:35 PM, Martin Sebor wrote:
>>> On 8/6/19 6:04 AM, Martin Liška wrote:
Hi.
The patch is about proper checking of file descriptors on Windows.
Patch can bootstrap on x86_64-linux-gn
In my original patch to fix PR 53796 I forgot to fix the behavior for
unconnected units when inquiring via filename. This patch fixes that.
Regtested on x86_64-pc-linux-gnu, committed as obvious.
libgfortran/ChangeLog:
2019-08-07 Janne Blomqvist
PR fortran/53796
* io/inquire.
Hi!
This patch adds support for use_device_addr clause and restricts
use_device_ptr clause to pointers or for C++ references to pointers.
Before use_device_ptr handled both pointers and arrays and references to
them, the arrays as remapping just their address, newly the latter is what
is done by u
On Tue, Aug 6, 2019 at 11:03 PM Richard Earnshaw (lists)
wrote:
>
> On 06/08/2019 18:39, Uros Bizjak wrote:
> > Hello!
> >
> >> On Tue, Aug 06, 2019 at 05:49:17PM +0100, Richard Earnshaw (lists) wrote:
> >>> On 06/08/2019 17:39, Segher Boessenkool wrote:
> >> What's wrong with describing the c
94 matches
Mail list logo
