Re-sending because my patch doesn't seem to appear on the archive
This matches to what netbsd is doing with its own copy of GCC,
it can be simpler.
PR target/87221:
config/netbsd-elf.h (NETBSD_STARTFILE_SPEC): use crtbeginS.o for PIE
(NETBSD_ENDFILE_SPEC): use crtendS.o for PIE
---
gcc/config/
Hi,
this patch fixes handling of TYPE_USER_ALIGN. I tried to drop it
completely from LTO streaming and clear it in free lang data but it
breaks one ubsan testcase:
FAIL: c-c++-common/ubsan/pr63802.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none output pattern test
FAIL: c-c++-common/ub
On November 9, 2018 10:00:08 AM GMT+01:00, Jan Hubicka wrote:
>Hi,
>this patch fixes handling of TYPE_USER_ALIGN. I tried to drop it
>completely from LTO streaming and clear it in free lang data but it
>breaks one ubsan testcase:
>
>FAIL: c-c++-common/ubsan/pr63802.c -O2 -flto -fno-use-linker-p
On 11/8/18 9:50 PM, Jeff Law wrote:
> On 11/8/18 1:48 PM, Jakub Jelinek wrote:
>> On Thu, Nov 08, 2018 at 01:43:29PM -0700, Jeff Law wrote:
>>> On 11/8/18 1:27 AM, Martin Liška wrote:
libsanitizer/ChangeLog:
2018-11-08 Martin Liska
PR sanitizer/87892
* (all fi
On Fri, Nov 09, 2018 at 10:12:32AM +0100, Martin Liška wrote:
> Ok, then I'm going to install following patch.
Thanks.
> 2018-11-09 Martin Liska
>
> PR sanitizer/87892
> * sanitizer_common/sanitizer_linux_libcdep.cc (defined): Return
> 1 when CPU_COUNT macro is not defined.
Hi Uros
Thanks for the remarks!
I improve the patch as attached to address the issues you mentioned:
1. No changes to substs any more.
2. Adopt established approach (e.g "rcp14") to
handle zero masks.
I'd like to explain our motivation of combining vfixupimm patterns: there will
be a lot of new x
On 11/8/18 4:47 PM, Martin Sebor wrote:
On 11/08/2018 04:52 AM, Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not depend on ra
On Fri, Nov 9, 2018 at 10:54 AM Wei Xiao wrote:
>
> Hi Uros
>
> Thanks for the remarks!
> I improve the patch as attached to address the issues you mentioned:
> 1. No changes to substs any more.
> 2. Adopt established approach (e.g "rcp14") to
> handle zero masks.
>
> I'd like to explain our motiv
On Nov 8, 2018, Jeff Law wrote:
>> PR rtl-optimization/86438
>> * gcc.dg/torture/pr86438.c: New.
> OK.
Thanks. I ended up tweaking the test a bit further, when it occurred to
me that I might be able to trigger the same problem with -m32, but no
such luck. Here's the test I'm installing, inste
On 07/11/2018 23:02, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 05, 2018 at 06:16:16PM +, Renlin Li wrote:
>> Sorry, this is not correct. Instructions scheduled between x and x+1
>> directly use hard register r1.
>> It is not IRA/LRA assigning r1 to the operands.
>>
>>
>> To reproduce th
(Third attempt to put this on the mailing list now -- today is not a good day
for my email skills :-[)
Hi there,
This patch has caused a few g++ and libstdc++ regression test failures on arm,
I've included the g++ failures below.
Do you mind looking into this?
Cheers,
Matthew
dg-cmp-results
On 09/11/18 10:28, Matthew Malcomson wrote:
(Third attempt to put this on the mailing list now -- today is not a good day
for my email skills :-[)
Hi there,
This patch has caused a few g++ and libstdc++ regression test failures on arm,
I've included the g++ failures below.
Do you mind look
Hi Jakub,
Bootstrapping r265942 on darwin failed with
In file included from
/Applications/Xcode-6.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/stdio.h:490,
from ../../../work/libgomp/affinity-fmt.c:28:
../../../work/libgomp/affinit
Hi all,
In this testcase the codegen for VLA SVE is worse than it could be due to
unrolling:
fully_peel_me:
mov x1, 5
ptrue p1.d, all
whilelo p0.d, xzr, x1
ld1dz0.d, p0/z, [x0]
faddz0.d, z0.d, z0.d
st1dz0.d, p0, [x0]
cntd
On Nov 8, 2018, JonY <10wa...@gmail.com> wrote:
> No, no. By quick I just mean using -Wl,--large-address-aware on an
> existing gcc install, nothing complex. Sorry about not making it clear.
Ah, good!
> I now understand the problem, thanks for the clarification about the
> patch. Patch is OK.
This patch simplifies the table of CPUs supported in GCC by making
use of the new alias feature. Most of the changes are fairly
straight-forward:
- arm7tdmi and arm7tdmi-s are the same thing.
- arm710t, arm720t and arm740t differ only in features external to the core
- arm920 and arm920t are the s
On 11/02/2018 06:01 PM, Sam Tebbs wrote:
> On 11/02/2018 05:35 PM, Sam Tebbs wrote:
>
>> Hi all,
>>
>> This patch adds support for the Armv8.3-A pointer authentication instructions
>> that use the B-key (pacib*, autib* and retab). This required adding builtins
>> for
>> pacib1716 and autib1716, a
On Fri, Nov 09, 2018 at 11:34:48AM +0100, Dominique d'Humières wrote:
> Bootstrapping r265942 on darwin failed with
>
> In file included from
> /Applications/Xcode-6.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/stdio.h:490,
> from .
On 11/02/2018 05:31 PM, Sam Tebbs wrote:
> Hi all,
>
> The -mbranch-protection option combines the functionality of
> -msign-return-address and the BTI features new in Armv8.5 to better reflect
> their relationship. This new option therefore supersedes and deprecates the
> existing -msign-return-a
On Fri, Nov 09, 2018 at 12:04:54PM +0100, Jakub Jelinek wrote:
> On Fri, Nov 09, 2018 at 11:34:48AM +0100, Dominique d'Humières wrote:
> > Bootstrapping r265942 on darwin failed with
> >
> > In file included from
> > /Applications/Xcode-6.2.app/Contents/Developer/Platforms/MacOSX.platform/Develop
The old __sync builtins have been deprecated for a long time now in
favor of the __atomic builtins following the C++11/C11 memory model.
This patch converts libgfortran to use the modern __atomic builtins.
At the same time I weakened the consistency to acquire-release as that
should be enough for
On Thu, Nov 8, 2018 at 4:27 PM Jeff Law wrote:
>
> On 11/8/18 8:14 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:56 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
>
>
>
> >>
On Thu, Nov 8, 2018 at 4:30 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 10:24 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:53 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
>
>
On Fri, 9 Nov 2018 at 11:32, Kyrill Tkachov wrote:
>
>
> On 09/11/18 10:28, Matthew Malcomson wrote:
> > (Third attempt to put this on the mailing list now -- today is not a good
> > day for my email skills :-[)
> >
> > Hi there,
> >
> > This patch has caused a few g++ and libstdc++ regression te
On Thu, Nov 8, 2018 at 5:03 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:39 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
> >>
> >> [Richard, you're right. An overloaded debug() is better than
> >> this->dump(). Anyone who thinks different is wrong. End of
From: Christoph Muellner
The aarch64 ISA specification allows a left shift amount to be applied
after extension in the range of 0 to 4 (encoded in the imm3 field).
This is true for at least the following instructions:
* ADD (extend register)
* ADDS (extended register)
* SUB (extended registe
On Thu, Nov 8, 2018 at 5:55 PM Renlin Li wrote:
>
> Hi Richard,
>
> On 11/08/2018 12:09 PM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 12:02 PM Renlin Li wrote:
> >>
> >> Hi all,
> >>
> >> When allow-store-data-races is enabled, ifcvt would prefer to generated
> >> conditional select and un
Patches welcome!
On Fri, Nov 9, 2018, 12:30 Richard Biener On Thu, Nov 8, 2018 at 4:27 PM Jeff Law wrote:
> >
> > On 11/8/18 8:14 AM, Richard Biener wrote:
> > > On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez
> wrote:
> > >>
> > >>
> > >>
> > >> On 11/8/18 9:56 AM, Richard Biener wrote:
> > >>>
On Fri, Nov 9, 2018 at 8:11 AM Prathamesh Kulkarni
wrote:
>
> On Tue, 6 Nov 2018 at 16:04, Richard Biener
> wrote:
> >
> > On Mon, Nov 5, 2018 at 3:11 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 5 Nov 2018 at 18:14, Richard Biener
> > > wrote:
> > > >
> > > > On Mon, Nov 5, 2018 at
On Fri, Nov 9, 2018 at 11:47 AM Kyrill Tkachov
wrote:
>
> Hi all,
>
> In this testcase the codegen for VLA SVE is worse than it could be due to
> unrolling:
>
> fully_peel_me:
> mov x1, 5
> ptrue p1.d, all
> whilelo p0.d, xzr, x1
> ld1dz0.d, p0/z, [x0
On 11/09/2018 10:48 AM, Alexandre Oliva wrote:
> On Nov 8, 2018, JonY <10wa...@gmail.com> wrote:
>
>> No, no. By quick I just mean using -Wl,--large-address-aware on an
>> existing gcc install, nothing complex. Sorry about not making it clear.
>
> Ah, good!
>
>> I now understand the problem, th
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-11-09 Richard Biener
PR tree-optimization/87953
* tree-vect-loop.c (vectorizable_reduction): For analysis
always pass ops[0] to vectorizable_condition.
diff --git a/gcc/tree-vect-loop.c b/gc
On Mon, 15 Oct 2018 at 10:12, Christophe Lyon
wrote:
>
>
>
> On Fri, 12 Oct 2018 at 11:54, Richard Earnshaw (lists)
> wrote:
>>
>> On 11/10/18 14:34, Christophe Lyon wrote:
>> > The new arm-uclinuxfdpiceabi target behaves pretty much like
>> > arm-linux-gnueabi. In order the enable the same set
On 11/9/18 6:37 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 5:03 PM Aldy Hernandez wrote:
On 11/8/18 9:39 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone who thinks
ChangeLog:
-mm-dd Stafford Horne
* MAINTAINERS (CPU Port Maintainers): Add myself for or1k.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ba8c8040967..cc7d4bddee8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,7 @@ nds
Hi!
Tested on x86_64-linux, committed to trunk.
2018-11-09 Jakub Jelinek
* gcc.dg/gomp/workshare-reduction-1.c: New test.
* gcc.dg/gomp/workshare-reduction-2.c: New test.
* gcc.dg/gomp/workshare-reduction-3.c: New test.
* gcc.dg/gomp/workshare-reduction-4.c: Ne
I've committed this obvious fix to trunk as r265968 (a copy&paste error).
gcc/ChangeLog:
* json.cc (selftest::test_writing_literals): Fix comment.
---
gcc/json.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/json.cc b/gcc/json.cc
index a0c43956..46b6ef6 100644
-
Hi,
On Thu, 8 Nov 2018, Martin Liška wrote:
> > That seems better. But still, why declare this in system.h? It seems
> > hash-table.h seems more appropriate.
>
> I need to declare it before I'll poison it. As system.h is included very
> early, one can guarantee that there will be no usage be
Hi Sudi
On 11/08/2018 06:53 PM, Sudakshina Das wrote:
Hi Mihail
On 08/11/18 10:02, Ramana Radhakrishnan wrote:
On 07/11/2018 17:49, Mihail Ionescu wrote:
Hi All,
This is a backport from trunk for GCC 8 and 7.
SVN revision: r264595.
Regression tested on arm-none-eabi.
gcc/ChangeLog
2018-
Ilya Leoshkevich wrote:
> + /* Return unannotated constant pool references, so that the corresponding
> + entries are added to the back-end-managed pool. Not doing so would
> result
> + in those entries being placed in the middle-end-managed pool, which
> would
> + in turn prevent
The existing setting of max_cond_insns for most cores is non-optimal.
Thumb-2 IT has a maximum limit of 4, so 5 means emitting 2 IT sequences.
Also such long sequences of conditional instructions can increase the number
of executed instructions significantly, so using 5 for max_cond_insns is
non-op
PR79262 has been fixed for almost all AArch64 cpus, however the example is still
vectorized in a few cases, resulting in lower performance. Increase the cost of
vector-to-scalar moves so it is more similar to the other vector costs. As a
result
-mcpu=cortex-a53 no longer vectorizes the testcase -
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on
practically
any target.
I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
from GCC as it's confusing and useless.
OK for commit
This adds value_range_base, a base class of class value_range
with all members but the m_equiv one.
I have looked into the sole GC user, IPA propagation, and replaced
the value_range use there with value_range_base since it also
asserted the equiv member is always NULL.
This in turn means I hav
Ping.
I'd like to commit this. The discussion seems to have ended up with the
conclusion that this is a reasonable approach.
paul
> On Nov 1, 2018, at 3:13 PM, Paul Koning wrote:
>
> A number of test cases contain declarations like:
> void *memcpy();
> which currently are silently
Hi!
The earlier patch doesn't work, because there were still expressions
where handle could be still cast to integer of different size if it
happened to be a pointer, or an invalid cast of e.g. aggregate to
integer.
The following patch so far only tested on a simplified code should
handle it prop
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time errors
for simple expressions like &global_char + 0x
On Fri, 2018-11-09 at 12:11 +0100, Jakub Jelinek wrote:
> On Fri, Nov 09, 2018 at 12:04:54PM +0100, Jakub Jelinek wrote:
> > On Fri, Nov 09, 2018 at 11:34:48AM +0100, Dominique d'Humières
> > wrote:
> > > Bootstrapping r265942 on darwin failed with
> > >
> > > In file included from /Applications/X
On Fri, Nov 09, 2018 at 08:14:27AM -0600, Wilco Dijkstra wrote:
> PR79262 has been fixed for almost all AArch64 cpus, however the example is
> still
> vectorized in a few cases, resulting in lower performance. Increase the cost
> of
> vector-to-scalar moves so it is more similar to the other vec
On Mon, Jan 22, 2018 at 09:22:27AM -0600, Richard Biener wrote:
> On Mon, Jan 22, 2018 at 4:01 PM, Wilco Dijkstra
> wrote:
> > PR79262 has been fixed for almost all AArch64 cpus, however the example is
> > still
> > vectorized in a few cases, resulting in lower performance. Increase the
> > co
Richard,
Olivier tells me he talked to you briefly at the Cauldron about allowing
custom multilib sets to be configured from custom Makefile fragments
supplied at configure time, and that you was somewhat receptive to the
idea. I have implemented this as follows, for ARM targets only so far,
usin
On Sun, Nov 4, 2018 at 7:33 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Add a new pass to automatically instrument changes to variables
> with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
> field into an Processor Trace log, which allows log over head
> logging of informatin
This libgo patch changees RLIM_INFINITY from 0x to -1
on GNU/Linux. 0x is arguably the correct value, but
in the gc toolchain's syscall package the value is -1. So we are
compatible. New programs should be using the golang.org/x/sys/unix
package anyhow. This fixe
Hi
This patch adds -march=armv8.5-a to the Arm backend.
(https://developer.arm.com/products/architecture/cpu-architecture/a-profile/exploration-tools)
Armv8.5-A also adds two new security features:
- Speculation Barrier instruction
- Execution and Data Prediction Restriction Instructions
These are
Hi.
After I added 2 new options, I would like to include a new master option.
It's minimal version which only disables optimizations that we are aware of
and can potentially cause problems for live-patching.
Martin
>From dd52cd0249fc30cf6d7bf01a8826323277817b78 Mon Sep 17 00:00:00 2001
From: marx
Hi Jakub,
> On 9 Nov 2018, at 06:37, Jakub Jelinek wrote:
> +#if defined (HAVE_INTTYPES_H) && defined (PRIx64)
> + else if (sizeof (gomp_integral (handle)) == sizeof (uint64_t))
> + sprintf (buf, "0x" PRIx64, (uint64_t) gomp_integral (handle));
s/0x/0x%/?
Iain
On 11/09/2018 03:02 AM, Aldy Hernandez wrote:
On 11/8/18 4:47 PM, Martin Sebor wrote:
On 11/08/2018 04:52 AM, Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use
On Fri, Nov 09, 2018 at 07:33:44AM -0800, Iain Sandoe wrote:
> > On 9 Nov 2018, at 06:37, Jakub Jelinek wrote:
>
> > +#if defined (HAVE_INTTYPES_H) && defined (PRIx64)
> > + else if (sizeof (gomp_integral (handle)) == sizeof (uint64_t))
> > + sprintf (buf, "0x" PRIx64, (uint64_t) go
On 09/11/2018 15:07, Alexandre Oliva wrote:
> Richard,
>
> Olivier tells me he talked to you briefly at the Cauldron about allowing
> custom multilib sets to be configured from custom Makefile fragments
> supplied at configure time, and that you was somewhat receptive to the
> idea. I have implem
Hi Richard,
On 11/09/2018 11:48 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 5:55 PM Renlin Li wrote:
Hi Richard,
*However*, after I rebased my patch on the latest trunk.
Got the following dump from ifcvt:
[local count: 1006632961]:
# i_20 = PHI
# ivtmp_18 = PHI
a_10
On 05/11/18 12:41, Richard Biener wrote:
> On Mon, Nov 5, 2018 at 1:07 PM Andre Vieira (lists)
> wrote:
>>
>>
>> Hi,
>>
Hi,
Thank you for the quick response! See inline responses below.
>> This patch enables targets to describe DR_TARGET_ALIGNMENT as a
>> compile-time variable. It does so by tu
> 2018-11-08 Rainer Orth
>
> * affinity.c: Include , .
> (gomp_display_affinity_place): Remove cpusetp.
> * teams.c: Include .
This fixed AIX bootstrap failure also.
Thanks, David
> Am 09.11.2018 um 14:43 schrieb Ulrich Weigand :
>
> Ilya Leoshkevich wrote:
>
>> + /* Return unannotated constant pool references, so that the corresponding
>> + entries are added to the back-end-managed pool. Not doing so would
>> result
>> + in those entries being placed in the mid
Hi Dave,
is the patch OK, or do you still have questions?
Thanks
Bernd.
On 11/2/18 10:48 PM, Bernd Edlinger wrote:
> On 11/2/18 9:40 PM, David Malcolm wrote:
>> On Sun, 2018-08-05 at 16:59 +, Bernd Edlinger wrote:
>>> Hi!
>>>
>>>
>>> My other patch with adds assertions to varasm.c regarding
Bootstrapped and regtested on s390x-redhat-linux.
r265490 allowed the compiler to choose in a more flexible way whether to
use load or load-address-relative-long (LARL) instruction. When it
chose LARL for literal pool references, the latter ones were rewritten
by pass_s390_early_mach to use UNSPE
One of the concerns noted at Cauldron about -fsave-optimization-record
was the size of the output files.
This file implements compression of the -fsave-optimization-record
output, using zlib.
I did some before/after testing of this patch, using SPEC 2017's
502.gcc_r with -O3, looking at the sizes
Richard Biener wrote:
>Marc Glisse wrote:
>> Let's try with C = DBL_MIN and x = 婊BL_MAX. I don't believe it involves
>> signed zeros or infinities, just an underflow. First, the result depends on
>> the rounding mode. And in the default round-to-nearest, both divisions give
>> 0, and thus compare t
On 11/07/2018 03:43 PM, Jeff Law wrote:
On 11/6/18 5:06 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg02081.html
I thought I'd already ACK's this one...
OK.
You did but I made changes afterwards in response to Joseph's
comment. I've committed the final patch i
Hi
I am posting this patch on behalf of Carey (cc'ed). I also have some
review comments that I will make as a reply to this later.
This implements a new AArch64 specific back-end pass that helps optimize
branch-dense code, which can be a bottleneck for performance on some Arm
cores. This is achi
Ilya Leoshkevich wrote:
>gcc_assert (GET_CODE (x) != SYMBOL_REF
> - || !CONSTANT_POOL_ADDRESS_P (x));
> + || !CONSTANT_POOL_ADDRESS_P (x)
> + || s390_symbol_relative_long_p (x));
Hmm, it's a bit weird that this routine now uses a different check
than the other tw
A couple of very minor issues with the new support for CPU
aliases.
* config/arm/parsecpu.awk (/alias/): Tighten invisible alias
matching criteria. Remove unused array initializer.
Committed.
diff --git a/gcc/config/arm/parsecpu.awk b/gcc/config/arm/parsecpu.awk
index ba2dee5fdcb
Hi James,
> We have 7 unique target tuning structures in the AArch64 backend, of which
> only one has a 2x ratio between scalar_int_cost and vec_to_scalar_cost. Other
> ratios are 1, 3, 8, 3, 4, 6.
I wouldn't read too much in the exact value here - the costs are simply
relative to
other values f
+/* Handle the "copy" attribute by copying the set of attributes
+ from the symbol referenced by ARGS to the declaration of *NODE. */
+
+static tree
+handle_copy_attribute (tree *node, tree name, tree args,
+ int flags, bool *no_add_attrs)
+{
+ /* Break cycles in circular
Hi James,
>On Mon, Jan 22, 2018 at 09:22:27AM -0600, Richard Biener wrote:
>> It would be better to dissect this cost into vec_to_scalar and vec_extract
>> where
>> vec_to_scalar really means getting at the scalar value of a vector of
>> uniform values
>> which most targets can do without any ins
Hi, Martin,
thanks a lot for the previous two new options for live-patching.
I have two more questions below:
1. do we still need new options to disable the following:
A. unreachable code/variable removal?
B. Visibility changes with -flto and/or -fwhole-program?
2. for this new patch,
On 11/9/18 9:19 AM, Richard Biener wrote:
This adds value_range_base, a base class of class value_range
with all members but the m_equiv one.
First of all, thanks so much for doing this!
I have looked into the sole GC user, IPA propagation, and replaced
the value_range use there with value_
Committed as obvious. I had inserted this line to check effects of the
-fdec flags and forgot to delete it before my previous commit.
Author: jvdelisle
Date: Fri Nov 9 17:29:33 2018
New Revision: 265979
URL: https://gcc.gnu.org/viewcvs?rev=265979&root=gcc&view=rev
Log:
2018-11-09 Jerry DeLisl
> Am 09.11.2018 um 18:30 schrieb Ulrich Weigand :
>
> Ilya Leoshkevich wrote:
>
>> gcc_assert (GET_CODE (x) != SYMBOL_REF
>> - || !CONSTANT_POOL_ADDRESS_P (x));
>> + || !CONSTANT_POOL_ADDRESS_P (x)
>> + || s390_symbol_relative_long_p (x));
>
> Hmm, it's a bit weird t
On 09/11/18 12:18, Richard Biener wrote:
On Fri, Nov 9, 2018 at 11:47 AM Kyrill Tkachov
wrote:
Hi all,
In this testcase the codegen for VLA SVE is worse than it could be due to
unrolling:
fully_peel_me:
mov x1, 5
ptrue p1.d, all
whilelo p0.d, xzr, x1
On 11/7/18, Jeff Law wrote:
> On 11/6/18 9:37 AM, Hafiz Abid Qadeer wrote:
>> Hi All,
>> I was investigating a character set related problem with windows hosted
>> GDB and I tracked it down to a typo in iconv.m4. This typo caused
>> libiconv detection to fail and related support was not built into
Hello Wilco,
Would you have further thoughts on the patches proposed in
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01453.html
?
There was:
1) * config/aarch64/aarch64.c (PROBE_STACK_FIRST_REG) : Redefine as
R9_REGNUM instead of 9.
(PROBE_STACK_SECOND_REG): Redefine as R10_REGNUM
Hi Richard,
On Fri, Nov 09, 2018 at 04:27:22PM +0100, Richard Biener wrote:
> > Passes bootstrap and test suite on x86_64-linux, also
> > bootstrapped and tested gcc itself with full -fvartrace
> > and -fvartrace-locals instrumentation.
>
> So how is this supposed to be used? I guess in a
> edit
Hi Sudi,
On 09/11/18 15:33, Sudakshina Das wrote:
Hi
This patch adds -march=armv8.5-a to the Arm backend.
(https://developer.arm.com/products/architecture/cpu-architecture/a-profile/exploration-tools)
Armv8.5-A also adds two new security features:
- Speculation Barrier instruction
- Execution a
Hi Christoph,
On 09/11/18 11:38, christoph.muell...@theobroma-systems.com wrote:
From: Christoph Muellner
The aarch64 ISA specification allows a left shift amount to be applied
after extension in the range of 0 to 4 (encoded in the imm3 field).
This is true for at least the following instruc
Hi Jakub,
> On 9 Nov 2018, at 07:40, Jakub Jelinek wrote:
>
> On Fri, Nov 09, 2018 at 07:33:44AM -0800, Iain Sandoe wrote:
>>> On 9 Nov 2018, at 06:37, Jakub Jelinek wrote:
>>
>>> +#if defined (HAVE_INTTYPES_H) && defined (PRIx64)
>>> + else if (sizeof (gomp_integral (handle)) == sizeof
On 11/9/18 10:57 AM, Eric Gallager wrote:
> On 11/7/18, Jeff Law wrote:
>> On 11/6/18 9:37 AM, Hafiz Abid Qadeer wrote:
>>> Hi All,
>>> I was investigating a character set related problem with windows hosted
>>> GDB and I tracked it down to a typo in iconv.m4. This typo caused
>>> libiconv detecti
Hi Uros,
> On 8 Nov 2018, at 23:53, Uros Bizjak wrote:
>
> Attached patch fixes PR87928, where we ICE in ix86_compute_frame_layout in
> I will commit the patch to mainline SVN early next week to allow
> Darwin and Ming/Cygwin maintainers some time to test the patch on
> their targets.
Bootst
On 9 November 2018 16:33:22 CET, "Martin Liška" wrote:
>Hi.
>
>After I added 2 new options, I would like to include a new master
>option.
>It's minimal version which only disables optimizations that we are
>aware of
>and can potentially cause problems for live-patching.
I think you attached the w
Many thanks for your prompt review, Maciej!
> > * gcc/config/mips/mips.c (mips_reorg_process_insns)
> > (mips_option_override): Default to working around R5900
> > errata only if the processor was selected explicitly.
>
> I think this only describes the `mips_option_override' par
On 9/5/18 5:52 AM, a...@codesourcery.com wrote:
> This patch contains the GCN port of libgcc. I've broken it out just to keep
> both parts more manageable.
>
> We have the usual stuff, plus a "gomp_print" implementation intended to
> provide
> a means to output text to console without using the
This patch by Than McIntosh fixes a typo in cmd/cgo in the gccgo name
mangling recipe. The code to implement new-style gccgo name mangling
had a recipe that didn't quite match the one in the compiler
(incorrect handling for '.'). This showed up as a failure in the
gotools cgo test if the directory
On 9/5/18 7:40 AM, Andrew Stubbs wrote:
> This part initially failed to send due to size.
>
> This is the main portion of the GCN back-end, plus the configuration
> adjustments needed to build it.
>
> The config.sub patch is here so people can try it, but I'm aware that
> needs to
> be committed
The short loop bug under certain conditions causes loops to
execute only once or twice, due to a hardware bug in the R5900 chip.
`-march=r5900' already enables the R5900 short loop workaround.
However, the R5900 ISA and most other MIPS ISAs are mutually
exclusive since R5900-specific instructions
On 9/5/18 7:42 AM, Andrew Stubbs wrote:
> This part initially failed to send due to size.
>
> Here's part 2.
>
> 0021-gcn-port-pt2.patch
[ ... ]
You've already addressed Joseph's comments in a follow-up.
>
> diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
> new file mode 100644
> inde
On 10/31/18 10:27 AM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
>
> With the C++ bits approved I'm still looking for a review/approval
> of the remaining changes: the C front end and the shared c-family
> handling of the new built-in.
I thought I acked th
On 11/5/18 4:20 PM, Bernd Edlinger wrote:
> On 11/5/18 1:28 AM, H.J. Lu wrote:
>> On Sun, Nov 4, 2018 at 10:02 AM Jeff Law wrote:
>>> On 10/22/18 9:08 AM, Bernd Edlinger wrote:
Hi!
This makes c_strlen avoid an unsafe strlen folding of const arguments
with non-const offset. Cur
On 11/8/18 6:33 AM, Wilco Dijkstra wrote:
> Hi,
>
>> But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
>> libraries. It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
>> 2 ULP even.
>
> You can't add ULP errors in general - a tiny difference in the input can
> m
I've had this lying around. Recent changes in that file reminded me to
push it.
Essentially the v850 pushes arguments for variadic functions rather than
passing them in args, similarly to the nds32. So we need to guard the
test in a similar manner.
Committed to the trunk.
Jeff
commit cc9a0d23
On Fri, 09 Nov 2018 07:07:06 PST (-0800), ol...@adacore.com wrote:
Richard,
Olivier tells me he talked to you briefly at the Cauldron about allowing
custom multilib sets to be configured from custom Makefile fragments
supplied at configure time, and that you was somewhat receptive to the
idea.
On 25/10/18 13:36 +0100, Jonathan Wakely wrote:
On 25/10/18 14:30 +0200, Marc Glisse wrote:
On Tue, 23 Oct 2018, Jonathan Wakely wrote:
+ template
+inline void
+__relocate_a(_Tp* __dest, _Up* __orig, _Allocator& __alloc)
I find it a little surprising that this overload for single ob
1 - 100 of 136 matches
Mail list logo
