Hi.
We have zero_p in the API, but we don't have non_zero_p. Instead we use
a non-API function range_is_nonnull. I've fixed this.
I have also gotten rid of the duplicity of using the non-API
range_is_null in favor of value_range_base::zero_p().
Furthermore, there's value_range*::set_null
Richard Biener writes:
> On May 29, 2019 10:21:46 PM GMT+02:00, Jeff Law wrote:
>>On 5/24/19 6:45 AM, Richard Biener wrote:
>>[ Aggressive snipping ]
>>
>>> As said in my first review I'd just check whether for the
>>> edge we want to thread through the definition comes from a CMP.
>>> Suppose y
On May 29, 2019 10:21:46 PM GMT+02:00, Jeff Law wrote:
>On 5/24/19 6:45 AM, Richard Biener wrote:
>[ Aggressive snipping ]
>
>> As said in my first review I'd just check whether for the
>> edge we want to thread through the definition comes from a CMP.
>> Suppose you have
>>
>> # val_1 = PHI
>>
On May 29, 2019 10:18:01 PM GMT+02:00, Jeff Law wrote:
>On 5/23/19 6:11 AM, Richard Biener wrote:
>> On Thu, 23 May 2019, Jiufu Guo wrote:
>>
>>> Hi,
>>>
>>> Richard Biener writes:
>>>
On Tue, 21 May 2019, Jiufu Guo wrote:
>
> +}
> +
> + if (TREE_CODE_CLASS (gimple_assign_r
On May 29, 2019 10:12:31 PM GMT+02:00, Jeff Law wrote:
>On 5/23/19 6:05 AM, Jiufu Guo wrote:
>> Hi,
>>
>> Richard Biener writes:
>>
>>> On Tue, 21 May 2019, Jiufu Guo wrote:
>>>
>
+/* Return true if PHI's INDEX-th incoming value is a CMP, and the
>CMP is
+ defined in the inco
Jeff Law writes:
> On 5/23/19 6:11 AM, Richard Biener wrote:
>> On Thu, 23 May 2019, Jiufu Guo wrote:
>>
>>> Hi,
>>>
>>> Richard Biener writes:
>>>
On Tue, 21 May 2019, Jiufu Guo wrote:
>
> +}
> +
> + if (TREE_CODE_CLASS (gimple_assign_rhs_code (def)) != tcc_comparison)
>>
чт, 9 мая 2019 г. в 00:10, Jonathan Wakely :
>
> On 06/05/19 14:19 +0300, Antony Polukhin wrote:
> >@@ -924,14 +984,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > template
> > struct is_default_constructible
> > : public __is_default_constructible_safe<_Tp>::type
> >-{ };
> >+{
> >+
Hi,
This patch updates test cases to use the new powerpc_future_ok effective target.
Tested on powerpc64le-unknown-linux-gnu with no problems. Is this okay for
trunk?
Thanks,
Bill
2019-05-29 Bill Schmidt
Michael Meissner
* gcc.target/powerpc/cpu-future.c: Require po
Hi,
This patch from Mike Meissner adds procs to target-supports.exp to support
-mcpu=future.
Tested in conjunction with the next patch (test cases) with no problems.
Is this okay for trunk?
Thanks,
Bill
2019-05-29 Michael Meissner
* lib/target-supports.exp (check_powerpc_future_hw
Hi,
This patch adds basic infrastructure for prefixed and PC-relative addresses,
including new predicates and functions to detect when they apply.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2019-05-29 Bill Schmidt
The Go frontend is currently supposed to use C++98. This patch by
Than McIntosh removes a range based for loop that snuck in recently.
This fixes PR 90669. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
Hi,
Here's another version of the -mprefixed-addr patch. I've attempted to address
Segher's comments, other than the suggestion to merge OPTION_MASK_P8_FUSION_SIGN
into OPTION_MASK_P8_FUSION, which I think is too big a rat's nest for this patch
series.
Bootstrapped and tested on powerpc64le-unkn
On 23/05/19 07:39 +0200, François Dumont wrote:
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
it and there is a detectable issue with libbacktrace then I generate a
compilation error. I want to avoid users defining it but having no
On 29/05/19 23:53 +0100, Jonathan Wakely wrote:
On 29/05/19 15:32 -0700, Thomas Rodgers wrote:
* include/pstl/algorithm_fwd.h: Synchronize with
upstream PSTL project.
* include/pstl/algorithm_impl.h: Likewise.
* include/pstl/execution_defs.h: Likewise.
* i
On 29/05/19 15:32 -0700, Thomas Rodgers wrote:
* include/pstl/algorithm_fwd.h: Synchronize with
upstream PSTL project.
* include/pstl/algorithm_impl.h: Likewise.
* include/pstl/execution_defs.h: Likewise.
* include/pstl/execution_impl.h: Likewise.
*
On 29/05/19 15:30 -0700, Thomas Rodgers wrote:
* include/pstl/glue_memory_impl.h: Rename all macros of the form
_PSTL_(.*)_H to _PSTL_\U\1_H.
* include/pstl/numeric_impl.h: Likewise.
* include/pstl/glue_memory_defs.h: Likewise.
* include/pstl/execution_def
* include/pstl/algorithm_fwd.h: Synchronize with
upstream PSTL project.
* include/pstl/algorithm_impl.h: Likewise.
* include/pstl/execution_defs.h: Likewise.
* include/pstl/execution_impl.h: Likewise.
* include/pstl/glue_algorithm_impl.h: Likewise.
* include/pstl/glue_memory_impl.h: Rename all macros of the form
_PSTL_(.*)_H to _PSTL_\U\1_H.
* include/pstl/numeric_impl.h: Likewise.
* include/pstl/glue_memory_defs.h: Likewise.
* include/pstl/execution_defs.h: Likewise.
* include/pstl/utils.h: Li
Writing a commit log for the lang/gcc9 port on FreeBSD I noticed a
few edits around the LTO improvements in the GCC 9 release notes
(which, by the way, was a nice summary).
Honza, I went ahead and committed these, but will be happy to
refine/update should I have misunderstood anything or you'd li
On 29/05/19 15:45 +0100, Jonathan Wakely wrote:
Add support for additional sources of randomness to std::random_device,
to allow using RDSEED for Intel CPUs and rand_s for Windows. When
supported these can be selected using the tokens "rdseed" and "rand_s".
For *-w64-mingw32 targets the "default"
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:22 PM Marc Glisse wrote:
Hello,
I noticed this one with BIT_NOT_EXPR a while ago. C++ testcase because I
haven't looked at gimplefe yet...
OK. I wonder if there's any issue with -ftrapv and negate/abs of
INT_MIN contain
The fix for PR 1 only added a workaround to filesystem::status, but
filesystem::symlink_status is also affected by the _wstat bug and needs
the same workaround.
The recent change to optimize path::parent_path() means that the
workaround can be simplified to just use parent_path().
PR
Parsing a complete string is more efficient than appending each
component one-by-one.
* src/c++17/fs_path.cc (path::parent_path()): Create whole path at
once instead of building it iteratively.
Tested powerpc64le-linux and x86_64-w64-mingw32, committed to trunk.
commit ed3d2a78
On Wed, May 29, 2019 at 03:26:27PM -0500, Bill Schmidt wrote:
> >> @@ -36379,6 +36391,7 @@ static struct rs6000_opt_mask const
> >> rs6000_opt_masks[] =
> >>{ "power9-vector", OPTION_MASK_P9_VECTOR, false,
> >> true },
> >>{ "powerpc-gfxopt", OPTION_MASK
On Mon, 20 May 2019, Richard Biener wrote:
On Mon, May 20, 2019 at 10:16 AM Marc Glisse wrote:
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
Hello,
2 pieces:
- the first one handles the case where the denominator is negative. It
doesn't h
Concur
Ville Voutilainen writes:
> On Wed, 29 May 2019 at 23:00, Jonathan Wakely wrote:
>> Does anybody think we should keep __gnu_cxx::size_t,
>> __gnu_cxx::input_iterator_tag, __gnu_cxx::vector, __gnu_cxx::pair etc.
>> or should I go ahead and commit this?
>
> +1 go ahead.
On 5/29/19 8:16 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, May 29, 2019 at 07:42:38AM -0500, Bill Schmidt wrote:
>> * rs6000-cpus.def (OTHER_FUSION_MASKS): New #define.
>> (ISA_FUTURE_MASKS_SERVER): Add OPTION_MASK_PREFIXED_ADDR. Mask off
>> OTHER_FUSION_MASKS.
> Two spaces afte
On 5/24/19 6:45 AM, Richard Biener wrote:
[ Aggressive snipping ]
> As said in my first review I'd just check whether for the
> edge we want to thread through the definition comes from a CMP.
> Suppose you have
>
> # val_1 = PHI
> if (val_1 != 0)
>
> and only one edge has a b_3 = d_5 != 0 con
On 5/23/19 6:11 AM, Richard Biener wrote:
> On Thu, 23 May 2019, Jiufu Guo wrote:
>
>> Hi,
>>
>> Richard Biener writes:
>>
>>> On Tue, 21 May 2019, Jiufu Guo wrote:
+}
+
+ if (TREE_CODE_CLASS (gimple_assign_rhs_code (def)) != tcc_comparison)
+return false;
+
>>>
On 5/23/19 6:05 AM, Jiufu Guo wrote:
> Hi,
>
> Richard Biener writes:
>
>> On Tue, 21 May 2019, Jiufu Guo wrote:
>>
>>>
>>> +/* Return true if PHI's INDEX-th incoming value is a CMP, and the CMP is
>>> + defined in the incoming basic block. Otherwise return false. */
>>> +static bool
>>> +
On 5/21/19 7:44 AM, Jiufu Guo wrote:
> Hi,
>
> This patch implements a new opportunity of jump threading for PR77820.
> In this optimization, conditional jumps are merged with unconditional jump.
> And then moving CMP result to GPR is eliminated.
>
> It looks like below:
>
>
> p0 = a CMP b
On Wed, 29 May 2019 at 23:00, Jonathan Wakely wrote:
> Does anybody think we should keep __gnu_cxx::size_t,
> __gnu_cxx::input_iterator_tag, __gnu_cxx::vector, __gnu_cxx::pair etc.
> or should I go ahead and commit this?
+1 go ahead.
These using-declarations appear to have been added for simplicity when
moving the non-standard extensions from namespace std to namespace
__gnu_cxx. Dumping all these names into namespace __gnu_cxx allows
uses like __gnu_cxx::size_t and __gnu_cxx::pair, which serve no useful
purpose, but allows cr
Hi,
this is a variant of testcase I have comitted. Once Martin implements SRA
part, we could add next variant that drops -fno-tree-sra.
It seems odd that constant propagation only happens in fre3.
I woud expect fre1 to discover this already.
The IL before fre1 and 3 differs only by:
test ()
{
On 23/05/19 07:39 +0200, François Dumont wrote:
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
it and there is a detectable issue with libbacktrace then I generate a
compilation error. I want to avoid users defining it but having no
On 5/29/19 6:36 AM, Richard Biener wrote:
> On Tue, 28 May 2019, Jiufu Guo wrote:
>
>> Hi,
>>
>> This patch implements a new opportunity of jump threading for PR77820.
>> In this optimization, conditional jumps are merged with unconditional
>> jump. And then moving CMP result to GPR is eliminated.
On 29/05/19 19:45 +0200, François Dumont wrote:
On 5/29/19 12:06 AM, Jonathan Wakely wrote:
On 23/05/19 07:39 +0200, François Dumont wrote:
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user
define
Thanks for making this opt-in.
it and there
On 5/9/19 10:54 PM, Hongtao Liu wrote:
> On Fri, May 10, 2019 at 3:55 AM Jeff Law wrote:
>>
>> On 5/6/19 11:38 PM, Hongtao Liu wrote:
>>> Hi Uros and GCC:
>>> This patch is to fix ix86_expand_sse_comi_round whose implementation
>>> was not correct.
>>> New implentation aligns with _mm_cmp_roun
Hi!
On Wed, May 29, 2019 at 01:08:28PM -0500, Bill Schmidt wrote:
> +/* Whether a given VALUE is a valid 16- or 34-bit signed offset. EXTRA is
> the
> + amount that we can't touch at the high end of the range (typically if the
> + address is split into smaller addresses, the extra covers the
These do not need to be public.
2019-05-29 Uroš Bizjak
* config/i386/sse.md (*save_multiple): Rename from
save_multiple.
(*restore_multiple): Rename from restore_multiple.
(*restore_multiple_and_return): Rename from
restore_multiple_and_return.
(*restore_multiple_leave_
On Wed, May 29, 2019 at 01:15:52PM +0200, Thomas Koenig wrote:
>
> the attached patch fixes the wrong-code regression due to the
> inline argument repacking patch, r271377.
>
> What had gone wrong? gfortran used to pack and unpack arrays
> unconditionally passed to old-style assumed size or .
On 5/23/19 6:05 AM, Yoshinori Sato wrote:
> I ported linux kernel to Renesas RX.
>
> rx-*-elf target output a binary different from the standard ELF.
> It has the same format as the Renesas compiler.
>
> But the linux kernel requires the standard ELF format.
> I want to define a rx-*-linux target
On Wed, May 29, 2019 at 10:14:58AM -0600, Jeff Law wrote:
> On 5/29/19 3:46 AM, Martin Liška wrote:
> > Hi.
> >
> > The patch is about a small change in .gdbinit file.
> >
> > Ready for trunk?
> > Martin
> >
> > gcc/ChangeLog:
> >
> > 2019-05-29 Martin Liska
> >
> > * gdbinit.in: Fix 'p
On 5/29/19 1:12 PM, Jakub Jelinek wrote:
On Wed, May 29, 2019 at 12:31:52PM -0400, Jason Merrill wrote:
On 5/24/19 4:21 AM, Jakub Jelinek wrote:
The second patch fixes that by special casing void type MODIFY_EXPR, I
believe if we have void type MODIFY_EXPR, then it can't be an lvalue.
Any exp
Hi,
This short patch introduces the eI constraint. It also adds the
SIGNED_16BIT_OFFSET_P
convenience macro that will be used in subsequent patches.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is
this okay for trunk?
Thanks,
Bill
2019-05-29 Bill Schmidt
On 5/22/19 3:34 PM, Martin Sebor wrote:
> -Wreturn-local-addr detects a subset of instances of returning
> the address of a local object from a function but the warning
> doesn't try to handle alloca or VLAs, or some non-trivial cases
> of ordinary automatic variables[1].
>
> The attached patch ex
On 5/29/19 12:06 AM, Jonathan Wakely wrote:
On 23/05/19 07:39 +0200, François Dumont wrote:
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
Thanks for making this opt-in.
it and there is a detectable issue with libbacktrace then I g
On Wed, May 29, 2019 at 12:31:52PM -0400, Jason Merrill wrote:
> On 5/24/19 4:21 AM, Jakub Jelinek wrote:
> > The second patch fixes that by special casing void type MODIFY_EXPR, I
> > believe if we have void type MODIFY_EXPR, then it can't be an lvalue.
>
> Any expression with void type is a prva
Hi Jakub!
On Mon, 27 May 2019 18:49:20 +0200, Jakub Jelinek wrote:
> On Sun, May 26, 2019 at 07:43:04PM +0200, Thomas Schwinge wrote:
> > On Tue, 18 Oct 2005 03:01:40 -0400, Jakub Jelinek wrote:
> > > --- gcc/omp-low.c.jj 2005-10-15 12:00:06.0 +0200
> > > +++ gcc/omp-low.c 2005-10-1
On 5/23/19 3:23 PM, Paolo Carlini wrote:
Hi,
one more, rather straightforward, simply use the location stored in the
declarator. Tested x86_64-linux.
OK.
Jason
On 5/24/19 4:21 AM, Jakub Jelinek wrote:
The second patch fixes that by special casing void type MODIFY_EXPR, I
believe if we have void type MODIFY_EXPR, then it can't be an lvalue.
Any expression with void type is a prvalue, so let's not limit this to
MODIFY_EXPR.
Jason
On 5/29/19 1:21 AM, Richard Biener wrote:
> On Tue, May 28, 2019 at 5:34 PM Martin Sebor wrote:
>>
>> On 5/21/19 3:53 AM, Richard Biener wrote:
>>> On Tue, May 21, 2019 at 4:13 AM Martin Sebor wrote:
On 5/20/19 3:16 AM, Richard Biener wrote:
> On Mon, May 20, 2019 at 10:16 AM Marc G
On Thu, May 30, 2019 at 12:44:35AM +0930, Alan Modra wrote:
> On Wed, May 29, 2019 at 07:40:46AM -0500, Segher Boessenkool wrote:
> > All necessary linker (and binutils and GAS) support is upstream already,
> > right?
>
> I believe so, except gold support is lacking right now.
Excellent :-)
> >
On 5/28/19 4:44 PM, Paolo Carlini wrote:
Hi,
On 28/05/19 16:47, Jason Merrill wrote:
On 5/10/19 10:29 AM, Paolo Carlini wrote:
Hi,
a while ago Martin noticed that an unintended consequence of an old
tweak of mine - which avoided redundant error messages emitted from
cp_parser_init_declarato
On 5/29/19 12:12 PM, Jeff Law wrote:
On 5/29/19 9:58 AM, Aldy Hernandez wrote:
On 5/29/19 9:24 AM, Richard Biener wrote:
On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
As per the API, and the original documentation to value_range,
VR_UNDEFINED and VR_VARYING should never have equivale
On 5/29/19 3:46 AM, Martin Liška wrote:
> Hi.
>
> The patch is about a small change in .gdbinit file.
>
> Ready for trunk?
> Martin
>
> gcc/ChangeLog:
>
> 2019-05-29 Martin Liska
>
> * gdbinit.in: Fix 'ptc' command. Add tt
> that prints TREE_TYPE($).
> ---
> gcc/gdbinit.in | 1
On 5/29/19 9:58 AM, Aldy Hernandez wrote:
> On 5/29/19 9:24 AM, Richard Biener wrote:
>> On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
>>>
>>> As per the API, and the original documentation to value_range,
>>> VR_UNDEFINED and VR_VARYING should never have equivalences. However,
>>> equiv_
On Wed, May 29, 2019 at 04:02:55PM +0200, Thomas Koenig wrote:
> > As I said earlier in the PR, I don't like -fbroken-callers option much,
> > as the option name doesn't hint what it is doing at all.
> >
> > The following patch renames the option and makes it into a 3 state option,
> > with the de
On 5/29/19 7:24 AM, Richard Biener wrote:
> On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
>>
>> As per the API, and the original documentation to value_range,
>> VR_UNDEFINED and VR_VARYING should never have equivalences. However,
>> equiv_add is tacking on equivalences blindly, and there
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Finnish team of translators. The file is available at:
https://translationproject.org/latest/gcc/fi.po
(This file, 'gcc-9.1.0.fi.po', has jus
On Wed, May 29, 2019 at 09:57:50AM -0600, Jeff Law wrote:
> > FAIL: gcc.dg/builtin-object-size-1.c execution test
> > FAIL: gcc.dg/builtin-object-size-5.c scan-assembler-not abort
I admit I haven't looked at the details here, but wonder if the optimization
couldn't be done only in the DCE passes p
On 5/29/19 9:24 AM, Richard Biener wrote:
On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
As per the API, and the original documentation to value_range,
VR_UNDEFINED and VR_VARYING should never have equivalences. However,
equiv_add is tacking on equivalences blindly, and there are vario
On 5/29/19 7:36 AM, Richard Biener wrote:
>
> The following tries to address PR90648 by performing final
> value replacement from DCE when DCE knows the final value
> computation is not used during loop iteration. This fits
> neatly enough into existing tricks performed by DCE like
> removing unu
On 5/29/19 7:40 AM, Segher Boessenkool wrote:
> Hi Bill,
>
> On Thu, May 23, 2019 at 09:11:44PM -0500, Bill Schmidt wrote:
>> (1) When a function uses PC-relative code generation, all direct calls
>> (other than
>> sibcalls) that the function makes to local or external callees should appear
>> a
On Wed, May 29, 2019 at 07:40:46AM -0500, Segher Boessenkool wrote:
> All necessary linker (and binutils and GAS) support is upstream already,
> right?
I believe so, except gold support is lacking right now.
> >pld 12,0(0),1
> >.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
>
> Are we
On Wed, May 29, 2019 at 04:42:14PM +0200, Thomas Schwinge wrote:
> Any comments on my question, please?
>
> On Tue, 09 Apr 2019 17:51:46 +0200, I wrote:
> > On Tue, 29 Nov 2016 17:47:08 -0800, Cesar Philippidis
> > wrote:
> > > One notable difference between the trunk and gomp4 implementation of
Hi Jakub,
>> > So, something similar to what your patch does, but don't substitute the
>> > actual
>> > CPU count, but a command to determine the number of CPUs?
>>
>> I'm not convinced that would work reliably: you can easily have one set
>> of commands on one machine, but a slightly different o
Hi All,
This patch implements the __yield(), __wfe(), __wfi(), __sev() and
__sevl() ACLE (hint) intrinsics for AArch64 as yield, wfe, wfi, sev and
sevl (hint) instructions respectively.
The instructions are documented in the ArmARM[1] and the intrinsics
specification are published on the Arm w
Hi Jakub!
Ping.
On Fri, 21 Dec 2018 11:41:07 +0100, I wrote:
> On Sat, 10 Nov 2018 09:11:18 -0800, Julian Brown
> wrote:
> > This patch [...] replaces usage
> > of several magic constants in target.c with named macros
>
> > --- a/libgomp/libgomp.h
> > +++ b/libgomp/libgomp.h
> > @@ -902,6 +902
Hi All,
This patch implements the __yield(), __wfe(), __wfi(), __sev() and
__sevl() ACLE (hint) intrinsics for all ARM targets.
The intrinsics specification are published on the Arm website [1].
[1]
https://developer.arm.com/docs/ihi0053/latest/arm-c-language-extensions-21-architecture-specifi
Hello,
The patch reworks some of the VRND and VCVT code added for the FP16
extension support to remove the redundant UNSPECS and related
constructs.
Tested for arm-none-linux-gnueabihf with native bootstrap and make check
and for arm-none-eabi with cross-compiled check-gcc on an
ARMv8.4-A emulato
Hello,
The initial implementation of the FP16 extension added HFmode support to
a limited number of the standard names. Following
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00168.html , this patch
extends the HFmode support to the names implemented by the ARM
and l expanders: btrunc, ceil, ro
On Wed, May 29, 2019 at 04:32:41PM +0200, Rainer Orth wrote:
> > I'd prefer not to determine the CPU count at configure time, the build
> > directory can be on some network filesystem and tested sometimes on one
> > machine, sometimes on another one, hw can be upgraded etc.
>
> somewhat agreed for
* testsuite/util/testsuite_api.h: Remove names of unused parameters.
Tested x86_64-linux, committed to trunk.
commit 0ea1c74e5df4214d4ab03ef264f53e4ef4aa1d87
Author: Jonathan Wakely
Date: Wed May 29 15:19:14 2019 +0100
Avoid -Wunused-parameter warnings from testsuite utility
Add support for additional sources of randomness to std::random_device,
to allow using RDSEED for Intel CPUs and rand_s for Windows. When
supported these can be selected using the tokens "rdseed" and "rand_s".
For *-w64-mingw32 targets the "default" token will now use rand_s, and
for other i?86-*-
Hi Jakub!
Any comments on my question, please?
On Tue, 09 Apr 2019 17:51:46 +0200, I wrote:
> On Tue, 29 Nov 2016 17:47:08 -0800, Cesar Philippidis
> wrote:
> > One notable difference between the trunk and gomp4 implementation of the
> > tile clause is that gomp4 errors on negative value tile a
Hi Jakub!
Any comments on this, please?
On Wed, 10 Apr 2019 15:00:06 +0200, I wrote:
> In context of PR90030 "Fortran OpenACC subarray data alignment" (which
> actually is reproducible for OpenMP with nvptx offloading in the very
> same way, see below), can you please explain the reason for the s
Hi Jakub,
> On Wed, May 29, 2019 at 04:13:41PM +0200, Rainer Orth wrote:
>> Prompted by extremely long libgomp make check times due to missing
>> parallelism, I noticed that the current support to restrict testcase
>> parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
>> Inste
Hi Jakub!
Any comments on my questions, please?
On Thu, 02 May 2019 16:03:09 +0200, I wrote:
> I'm currently working on other pending OpenACC 'deviceptr' clause patches
> from our backlog, and I noticed the following, which I don't understand.
> You reviewed and approved this patch, could you ple
On Wed, May 29, 2019 at 04:13:41PM +0200, Rainer Orth wrote:
> Prompted by extremely long libgomp make check times due to missing
> parallelism, I noticed that the current support to restrict testcase
> parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
> Instead of adding spec
Thanks for finding this Christoph, I had this failure a while ago but it
stopped happening so I thought all was good. I have a fix ready.
Sam
On 29/05/2019 12:22, Christophe Lyon wrote:
> On Wed, 29 May 2019 at 11:23, Sam Tebbs wrote:
>> The libgcc changes have been acknowledged off-list. Commi
Prompted by extremely long libgomp make check times due to missing
parallelism, I noticed that the current support to restrict testcase
parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
Instead of adding special cases for all sorts of tools to determine the
number of cores, I
> > but we do not optimize it. I.e. optimized dump has:
> >
> > test ()
> > {
> > struct bar * barptr.0_1;
> > struct foo * fooptr.1_2;
> > int _6;
> >
> >[local count: 1073741824]:
> > barptr.0_1 = barptr;
> > barptr.0_1->val2 = 1;
> > fooptr.1_2 = fooptr;
> > MEM[(struct foo *)f
Hi Jakub,
As I said earlier in the PR, I don't like -fbroken-callers option much,
as the option name doesn't hint what it is doing at all.
The following patch renames the option and makes it into a 3 state option,
with the default being a middle-ground, where it avoids the tail calls in
functio
Alejandro Martinez Vicente writes:
> Turns out I was missing a few bits and pieces. Here is the updated patch and
> changelog.
>
> Alejandro
>
>
> 2019-05-29 Alejandro Martinez
>
> * config/aarch64/aarch64-c.c: Added TARGET_SVE2.
> * config/aarch64/aarch64-sve2.md: New file.
>
Ping.
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00477.html
Thanks,
Kyrill
On 5/10/19 10:32 AM, Kyrill Tkachov wrote:
Hi all,
This patch fixes the failing gcc.dg/vect/slp-reduc-sad-2.c testcase on
aarch64
by implementing a vec_init optab that can handle two half-width
vectors producing
On Wed, May 29, 2019 at 3:40 PM Nick Clifton wrote:
>
> Hi Guys,
>
> I would like to bring over a few additions that have recently been
> made to the binutils versions of the Makefile.def and configure.ac
> files. Any objections ?
>
> Note - I did run a toolchain bootstrap after applying
Turns out I was missing a few bits and pieces. Here is the updated patch and
changelog.
Alejandro
2019-05-29 Alejandro Martinez
* config/aarch64/aarch64-c.c: Added TARGET_SVE2.
* config/aarch64/aarch64-sve2.md: New file.
(avg3_floor): New pattern.
(avg3_ceil)
Hi Guys,
I would like to bring over a few additions that have recently been
made to the binutils versions of the Makefile.def and configure.ac
files. Any objections ?
Note - I did run a toolchain bootstrap after applying this patch
locally and that went OK...
Cheers
Nick
./ChangeLo
The following tries to address PR90648 by performing final
value replacement from DCE when DCE knows the final value
computation is not used during loop iteration. This fits
neatly enough into existing tricks performed by DCE like
removing unused malloc/free pairs.
There's a few complications,
On Tue, May 28, 2019 at 10:28:07AM +, David CARLIER wrote:
> -- Forwarded message -
> From: David CARLIER
> Date: Tue, 28 May 2019 at 10:16
> Subject: Re: [PATCH] Fix few build warnings with LLVM toolchain
> To: Segher Boessenkool
>
>
> All right, here an updated version, ho
> > /* ??? Array types are not properly unified in all cases as we have
> > spurious changes in the index types for example. Removing this
> > causes all sorts of problems with the Fortran frontend. */
> > if (TREE_CODE (type1) == ARRAY_TYPE
> > && TREE_CODE (type2) == ARRAY_T
On Wed, May 29, 2019 at 3:21 PM Jan Hubicka wrote:
>
> >
> > Please also see if there are testcases that do anything meaningful
> > and FAIL after instead of
> >
> > /* Do access-path based disambiguation. */
> > if (ref1 && ref2
> > && (handled_component_p (ref1) || handled_component_p
On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
>
> As per the API, and the original documentation to value_range,
> VR_UNDEFINED and VR_VARYING should never have equivalences. However,
> equiv_add is tacking on equivalences blindly, and there are various
> regressions that happen if I fix
>
> Please also see if there are testcases that do anything meaningful
> and FAIL after instead of
>
> /* Do access-path based disambiguation. */
> if (ref1 && ref2
> && (handled_component_p (ref1) || handled_component_p (ref2)))
>
> doing
>
> /* Do access-path based disambiguation
Hi!
On Wed, May 29, 2019 at 07:42:38AM -0500, Bill Schmidt wrote:
> * rs6000-cpus.def (OTHER_FUSION_MASKS): New #define.
> (ISA_FUTURE_MASKS_SERVER): Add OPTION_MASK_PREFIXED_ADDR. Mask off
> OTHER_FUSION_MASKS.
Two spaces after a full stop (here and later again).
> +/* ISA mas
On Tue, May 28, 2019 at 5:43 PM Hans-Peter Nilsson
wrote:
>
> TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
> MAX_FIXED_MODE_SIZE, search for the largest fitting size from
> scalar_int_mode modes supported by the target using
> targetm.scalar_mode_supported_p.
>
> -
> In initi
On Wed, May 29, 2019 at 12:53:30AM +, Joseph Myers wrote:
> On Fri, 24 May 2019, Segher Boessenkool wrote:
>
> > IMO the best we can do is use what we already have: what CVS or SVN used
> > as the committer identity. *That* info is *correct* at least.
>
> CVS and SVN have a local identity.
On Wed, 29 May 2019, Jan Hubicka wrote:
> > On Mon, 27 May 2019, Jan Hubicka wrote:
> >
> > > Hi,
> > > this is minimal version of patch adding just the pointer compare.
> > > Bootstrapped/regtested x86_64-linux, makes sense? :)
> >
> > Yes, obviously.
>
> Thanks, i will go ahead with installin
Hi,
This patch adds the undocumented switch -mprefixed-addr and a little of the
basic
infrastructure around it. It also includes a couple of lines in the same code
regions to disable P8 fusion for -mcpu=future.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is thi
1 - 100 of 124 matches
Mail list logo
