Hi!
Apparently clang++ 3.2 and later (including current trunk, according to
godbolt https://godbolt.org/g/ekDs6H ) has a bug in its C++ parser that
it fails to properly parse the recent ubsan.h.
I've committed a workaround for that as obvious, after
bootstrapping/regtesting it on x86_64-linux and
Hi!
bootstrap-ubsan revealed many
../../gcc/ira-costs.c:1747:20: runtime error: member access within null pointer
of type 'cost_classes *[107]'
issues. The problem is that cost_classes_ptr is sometimes NULL, but
in those cases we have early exit:
if (! allocno_p)
{
On Mon, 19 Jun 2017, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds -fsanitize=pointer-overflow support,
> which adds instrumentation (included in -fsanitize=undefined) that checks
> that pointer arithmetics doesn't wrap. If the offset on ptr p+ off when
> treating
> it as signed value
On Tue, Jun 20, 2017 at 4:54 AM, Jack Howarth wrote:
> The following change from gcc-7-branch and trunk needs to be backported
> to gcc-6-branch to allow the Xcode 9 clang compiler to bootstrap it. Tested
> on 10.12 with Xcode 9 beta. Okay for gcc-6-branch?
Ok.
> Jack
> In the patches Jeff is going to post, we have (at least for
> -fasynchronous-unwind-tables which is on by default on e.g. x86)
> precise unwind info even with the new stack check mode.
> ira.c currently has:
>/* We need the frame pointer to catch stack overflow exceptions if
> t
On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote:
> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
>> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>> >
>> > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
>> > while it is shorter, is it actually faster or as s
On Tue, Jun 20, 2017 at 09:41:43AM +0200, Richard Biener wrote:
> On Mon, 19 Jun 2017, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following patch adds -fsanitize=pointer-overflow support,
> > which adds instrumentation (included in -fsanitize=undefined) that checks
> > that pointer arithmetics do
> As some of you are likely aware, Qualys has just published fairly
> detailed information on using stack/heap clashes as an attack vector.
> Eric B, Michael M -- sorry I couldn't say more when I contact you about
> -fstack-check and some PPC specific stuff. This has been under embargo
> for the l
On Tue, 20 Jun 2017, Jakub Jelinek wrote:
> On Tue, Jun 20, 2017 at 09:41:43AM +0200, Richard Biener wrote:
> > On Mon, 19 Jun 2017, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > The following patch adds -fsanitize=pointer-overflow support,
> > > which adds instrumentation (included in -fsaniti
> Out of curiousity, does the old Alpha/VMS stack-checking API meet the
> requirements? From what I recall, I think it does.
No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it
because of valgrind. I'd personally rather change valgrind but...
--
Eric Botcazou
On 19/06/17 20:04, Jeff Law wrote:
> On 06/19/2017 11:50 AM, Joseph Myers wrote:
>> On Mon, 19 Jun 2017, Jeff Law wrote:
>>
>>> A key point to remember is that you can never have an allocation
>>> (potentially using more than one allocation site) which is larger than a
>>> page without probing the
Hi Andrew,
On 20/06/17 06:06, Andrew Pinski wrote:
On Tue, Feb 28, 2017 at 4:29 AM, Kyrill Tkachov
wrote:
Hi all,
For the testcase in this patch we currently generate:
foo:
mov w1, 0
ldaxr w2, [x0]
cmp w2, 3
bne .L2
stxrw3, w1, [x
> On 19 Jun 2017, at 13:35, Richard Biener wrote:
>
> On Mon, 19 Jun 2017, Christophe Lyon wrote:
>
>> Hi Richard,
>>
>> On 16 June 2017 at 14:18, Richard Biener wrote:
>>> On Wed, 14 Jun 2017, Richard Biener wrote:
>>>
niter estimates are not kept up-to-date (they reference gimpl
On 05/23/2017 03:26 PM, Martin Sebor wrote:
On 05/23/2017 04:48 AM, Aldy Hernandez wrote:
+ void Union (wide_int x, wide_int y);
+ bool Union (const irange &r);
+ bool Union (const irange &r1, const irange &r2);
+
+ // THIS = THIS ^ [X,Y]. Return TRUE if result is non-empty.
+ bool Int
Hi Joesph,
Thanks for your review and valuable comments on this issue.
Please find attached the patch that merges x86-intrinsics for AArch64 and PPC
architectures.
>> it would seem to me to be a bad idea to duplicate the
>> implementation for more and more architectures.
Merged the implementati
On Fri, Jun 16, 2017 at 11:03 AM, Richard Biener
wrote:
> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>> Hi,
>> This patch computes and caches data dependence relation in a hash table
>> so that it can be queried multiple times later for partition dependence
>> check.
>> Bootstrap and test
On Fri, Jun 16, 2017 at 11:10 AM, Richard Biener
wrote:
> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>> Hi,
>> This patch checks and records if partition can be executed in parallel by
>> looking if there exists data dependence cycles. The information is needed
>> for distribution because
On Fri, Jun 16, 2017 at 6:15 PM, Bin.Cheng wrote:
> On Fri, Jun 16, 2017 at 11:21 AM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>>> Hi,
>>> For now, loop distribution handles variables used outside of loop as
>>> reduction.
>>> This is inaccurate because all p
On Mon, Jun 12, 2017 at 6:03 PM, Bin Cheng wrote:
> Hi,
> This is the main patch rewriting loop distribution in order to handle hmmer.
> It improves loop distribution by versioning loop under runtime alias check
> conditions.
> As described in comments, the patch basically implements distribution
On 06/19/2017 04:13 PM, Jakub Jelinek wrote:
> On Mon, Jun 19, 2017 at 03:50:42PM +0200, Martin Liška wrote:
>> @@ -858,6 +862,117 @@ sanitize_asan_mark_poison (void)
>> }
>> }
>>
>
> Missing function comment.
>
>> +static tree
>> +rewrite_usage_of_param (tree *op, int *walk_subtrees, voi
Hi James,
Thanks for the approval.
>> From an AArch64 perspective, this is OK - but please wait for an ARM
>> approval before you commit it.
Can anyone from ARM comment on the patch so that it can be committed
upstream if no issues.
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00504.html
Than
On 19/06/17 18:07, Jeff Law wrote:
> As some of you are likely aware, Qualys has just published fairly
> detailed information on using stack/heap clashes as an attack vector.
> Eric B, Michael M -- sorry I couldn't say more when I contact you about
> -fstack-check and some PPC specific stuff. This
On Tue, Jun 20, 2017 at 11:23:36AM +0200, Martin Liška wrote:
> > Then something needs to be done for debugging too. If it is without VTA,
> > then probably just having DECL_VALUE_EXPR is good enough, otherwise
> > (VTA) you probably don't want that (or can reset it at that point), but
> > instead
FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for errors, line 10)
FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++14 (test for errors, line 10)
FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++14 (test for excess errors)
On Tue, Jun 20, 2017 at 10:26 AM, Hurugalawadi, Naveen
wrote:
> Hi James,
>
> Thanks for the approval.
>
>>> From an AArch64 perspective, this is OK - but please wait for an ARM
>>> approval before you commit it.
>
> Can anyone from ARM comment on the patch so that it can be committed
> upstream i
On Tue, 20 Jun 2017, Alan Hayward wrote:
>
> > On 19 Jun 2017, at 13:35, Richard Biener wrote:
> >
> > On Mon, 19 Jun 2017, Christophe Lyon wrote:
> >
> >> Hi Richard,
> >>
> >> On 16 June 2017 at 14:18, Richard Biener wrote:
> >>> On Wed, 14 Jun 2017, Richard Biener wrote:
> >>>
>
>
This patch updates the release notes to mention that -mfpu=auto has been
added and that it is now the default.
Committed.
R.
? htdocs/backends.html~
? htdocs/index.html.~1.866.~
? htdocs/readings.html.~1.261.~
? htdocs/svn.html.~1.183.~
? htdocs/svn.html~
Index: htdocs/gcc-8/changes.html
On Tue, Jun 20, 2017 at 10:03 AM, Uros Bizjak wrote:
> On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote:
>> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
>>> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>>> >
>>> > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe st
Tested on m68k, installed on trunk and gcc-7 branch.
Andreas.
PR target/80970
* config/m68k/m68k.md (bsetdreg, bchgdreg, bclrdreg): Use "=d"
instead of "+d".
Index: config/m68k/m68k.md
===
--- config/m68k/m68
Attempts to apply a removal or replacement fix-it hint to a source
range that covers multiple lines currently lead to nonsensical
results from the printing code in diagnostic-show-locus.c.
We were already filtering them out in edit-context.c (leading
to -fdiagnostics-generate-patch not generating
Improve the dup pattern to prefer vector registers. When doing a dup
after a load, the register allocator thinks the costs are identical
and chooses an integer load. However a dup from an integer register
includes an int->fp transfer which is not modelled. Adding a '?' to
the integer variant mea
Hi Martin,
I did a little investigation into this. Please correct me if I missed anything.
I build a native arm-linux-gnueabihf toolchain in armhf hardware.
It's ILP32. So in this situation:
HOST_WIDE_INT is long, which is 32-bit.
integer type 32-bit as well, so target_int_max () == LONG_MAX
SIMD moves are currently emitted as ORR. Change this to use the MOV
pseudo instruction just like integer moves (the ARM-ARM states MOV is the
preferred disassembly), improving readability of -S output.
Passes bootstrap, OK for commit?
ChangeLog:
2017-06-20 Wilco Dijkstra
* config/aar
On Tue, Jun 20, 2017 at 12:18 PM, Richard Biener
wrote:
> On Tue, Jun 20, 2017 at 10:03 AM, Uros Bizjak wrote:
>> On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote:
>>> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>
> Al
On Tue, Jun 20, 2017 at 11:57:59AM +0100, Wilco Dijkstra wrote:
> Improve the dup pattern to prefer vector registers. When doing a dup
> after a load, the register allocator thinks the costs are identical
> and chooses an integer load. However a dup from an integer register
> includes an int->fp
On Wed, 14 Jun 2017, Richard Biener wrote:
>
> This fixes the [f]open use in libgfortran. Doesn't fix the ones
> in libsanitizer because those appearantly use a copy because they
> need to rename stuff...
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk
> and branches?
Pin
On Wed, 14 Jun 2017, Richard Biener wrote:
>
> The following patch makes sure we build the 32bit multilib libgcov with
> large file support on x86_64-linux. libgcov.h ends up using auto-host.h
> via including tconfig.h which is only valid for the main multilib
> (and on x86_64 doesn't need expli
On Tue, Jun 20, 2017 at 12:06:29PM +0100, Wilco Dijkstra wrote:
> SIMD moves are currently emitted as ORR. Change this to use the MOV
> pseudo instruction just like integer moves (the ARM-ARM states MOV is the
> preferred disassembly), improving readability of -S output.
>
> Passes bootstrap, OK
On Wed, 7 Jun 2017, Richard Biener wrote:
> On Fri, 19 May 2017, Richard Biener wrote:
>
> >
> > This is a repost (unchanged) of the simple-object ELF support for
> > early LTO debug transfer from IL object to a separate debug-only object
> > file.
> >
> > Bootstrapped and tested on x86_64-unk
On Wed, 7 Jun 2017, Richard Biener wrote:
> On Fri, 19 May 2017, Richard Biener wrote:
>
> >
> > This is a repost of the main part of the early LTO debug support.
> > The only changes relative to the last post is in the dwarf2out.c
> > pieces due to Jasons review and Jakubs introduction of
> > D
On Fri, Jun 16, 2017 at 6:10 PM, Bill Schmidt
wrote:
> Hi,
>
> PR71815 identifies a situation where SLSR misses opportunities for
> PHI candidates when code hoisting is enabled (which is now on by
> default). The basic problem is that SLSR currently uses an overly
> simple test for profitability
On Tue, Jun 20, 2017 at 11:15 AM, Bin.Cheng wrote:
> On Fri, Jun 16, 2017 at 11:03 AM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>>> Hi,
>>> This patch computes and caches data dependence relation in a hash table
>>> so that it can be queried multiple times lat
On Mon, Jun 19, 2017 at 5:59 PM, Bin.Cheng wrote:
> On Mon, Jun 19, 2017 at 4:16 PM, Richard Biener
> wrote:
>> On Mon, Jun 19, 2017 at 3:34 PM, Bin.Cheng wrote:
>>> On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener
>>> wrote:
On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote:
> Hi,
>>>
On Tue, Jun 20, 2017 at 11:18 AM, Bin.Cheng wrote:
> On Fri, Jun 16, 2017 at 11:10 AM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>>> Hi,
>>> This patch checks and records if partition can be executed in parallel by
>>> looking if there exists data dependence cy
On Tue, Jun 20, 2017 at 11:20 AM, Bin.Cheng wrote:
> On Fri, Jun 16, 2017 at 6:15 PM, Bin.Cheng wrote:
>> On Fri, Jun 16, 2017 at 11:21 AM, Richard Biener
>> wrote:
>>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
Hi,
For now, loop distribution handles variables used outside of l
James Greenhalgh wrote:
>
> Does this introduce a dependency on a particular binutils version, or have
> we always supported this alias?
>
> The patch looks OK, but I don't want to introduce a new dependency so please
> check how far back this is supported.
Well gas/testsuite/gas/aarch64/alias.s
On 06/20/2017 01:10 PM, Uros Bizjak wrote:
> 74,99% a.outa.out [.] test_or
> 12,50% a.outa.out [.] test_movb
> 12,50% a.outa.out [.] test_movl
Could you try notl/notb/negl/negb as well, please?
Thanks,
Florian
On 06/19/2017 01:11 PM, Jan Hubicka wrote:
>> Ok, you're right that we can preserve the predictor. However, let's consider
>> following test-case:
>>
>> static
>> int baz(int a)
>> {
>> if (a == 1)
>> return 1;
>>
>> return 0;
>> }
>>
>>
>> static
>> int bar(int a)
>> {
>> if (a == 1)
PING^1
On 06/13/2017 10:09 AM, Martin Liška wrote:
> Hi.
>
> For a function that does not handle an expection (and calls
> BUILT_IN_UNWIND_RESUME),
> we need to emit call to BUILT_IN_ASAN_HANDLE_NO_RETURN. That will clean up
> stack
> which can possibly contain poisoned shadow memory that will
On Fri, Jun 16, 2017 at 6:35 PM, Pierre-Marie de Rodat
wrote:
> On 05/31/2017 11:08 AM, Pierre-Marie de Rodat wrote:
>>
>> On 05/31/2017 09:34 AM, Richard Biener wrote:
>>>
>>> Actually for the bigger picture I'd refactor
>>> rest_of_decl_compilation, not calling it from the frontends but
>>> rely
On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>
>> 74,99% a.outa.out [.] test_or
>> 12,50% a.outa.out [.] test_movb
>> 12,50% a.outa.out [.] test_movl
>
> Could you try notl/notb/negl/negb as well
On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote:
> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>
>>> 74,99% a.outa.out [.] test_or
>>> 12,50% a.outa.out [.] test_movb
>>> 12,50% a.outa.out
On Tue, Jun 20, 2017 at 2:20 PM, Uros Bizjak wrote:
> On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote:
>> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
>>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>>
74,99% a.outa.out [.] test_or
12,50% a.outa.out
On 19 June 2017 at 16:47, Thomas Preudhomme
wrote:
>
>
> On 19/06/17 15:31, Christophe Lyon wrote:
>>
>> On 19 June 2017 at 16:11, Thomas Preudhomme
>> wrote:
>>>
>>>
>>>
>>> On 19/06/17 10:16, Thomas Preudhomme wrote:
On 19/06/17 08:41, Christophe Lyon wrote:
>
>
The following fixes PR81097 but not eventually more latent issues
in transforming ~x "back" to -x - 1. I want a testcase before
fiddling more with this. The following follows the pattern
of previous fixes to this function, making sure to do negation
in 'type'.
Bootstrapped and tested on x86_64-
This patch fixes a couple of places where namespace aliases refer to the
same namespace. These are not ambiguous or conflicting.
Firstly, aliases of the same name may exist in namespaces searched via
using directives. Those should be merged in lookup, which is the change
to add_value.
Seco
On Mon, Jun 19, 2017 at 12:40:53PM -0500, Segher Boessenkool wrote:
> On Mon, Jun 19, 2017 at 05:01:10PM +0100, Richard Earnshaw (lists) wrote:
> > Yeah, and I'm not suggesting we change the logic there (sorry if the
> > description was misleading). Instead I'm proposing that we handle more
> > ca
Hi Jonathan,
> On 15/06/17 12:51 +0200, Rainer Orth wrote:
>>I happened to notice that recently a couple of testcases have sneaked in
>>that are restricted to x86_64-*-* targets only. This is always wrong:
>>it should be i?86-*-* and x86_64-*-* alike, eventually restricing the
>>test to ilp32 or
On 06/20/2017 11:32 AM, Jakub Jelinek wrote:
> On Tue, Jun 20, 2017 at 11:23:36AM +0200, Martin Liška wrote:
>>> Then something needs to be done for debugging too. If it is without VTA,
>>> then probably just having DECL_VALUE_EXPR is good enough, otherwise
>>> (VTA) you probably don't want that (
>> Currently, extract_... () does that all that for me, is it really too
>> expensive to call? I guess, using get_range_info first and calling
>> extract when get_range_info returns a VR_RANGE is not really a favorable
>> thing to do either? :)
> Not only the cost, we should avoid introducing more
Hi,
We have decided to apply the following patch to the ARM/embedded-6-branch and
ARM/embedded-7-branch to implement the __ARM_FEATURE_COPROC coprocessor
intrinsic feature macro.
2017-06-20 Thomas Preud'homme
Backport from mainline
2017-06-20 Prakhar Bahuguna
g
Hi,
We have decided to apply the referenced fix (r249352) to the
ARM/embedded-6-branch along with its initial commit (r249224) to fix an ICE with
LTO and aliases.
Fix PR69866
2017-06-20 Thomas Preud'homme
Backport from mainline
2017-06-15 Jan Hubicka
On 06/20/2017 01:01 PM, Rainer Orth wrote:
>
> once I got the syntax right, this worked fine: it needs
>
> { target { ilp32 || lp64 } }
>
> instead ;-)
>
> I've also now managed to complete a Darwin/x86_64 bootstrap by locally
> reverting the two culprit patches for PR bootstrap/81033 and
Mike Stump writes:
> On Jun 10, 2017, at 12:57 AM, Tom de Vries wrote:
>>
>> one thing that has bothered me on a regular basis is the inability to
>> spread long dejagnu directives over multiple lines.
>
> I'm not terribly in favor of this. I'd like to retain the ability to grep
> and sed sing
Hi,
This patch rearranges the cores in aarch64-cores.def first by architecture
revision, then by alphabetical order of implementer ID.
This just neatens up the file a bit, as it is growing to be unwieldy.
Committed as revision 249410.
Thanks,
James
---
2017-06-20 James Greenhalgh
JonY <10wa...@gmail.com> writes:
> On 06/20/2017 01:01 PM, Rainer Orth wrote:
>> Given that there were no other comments, I've installed the patch. It
>> would still be nice if the Cygwin/MingW maintainer could comment on the
>> testcase situation for those targets.
>
> Honestly, I'm not sure how
Hi,
As currently coded, the native detection of the fp16 architecture extension
from the ARMv8.2-A extensions looks for the string "fp16", but the kernel
exposes support of these features through two strings "fphp, for scalar
16-bit floating point support, and "asimdhp" for vector 16-bit floating
Hi,
We have decided to apply the following patch to the embedded-6-branch to fix
naming of an ARM intrinsic.
ChangeLog entry is as follows:
2017-06-20 Thomas Preud'homme
Backport from mainline
2017-05-04 Prakhar Bahuguna
gcc/
* gcc/config/arm/arm-builti
On Tue, Jun 20, 2017 at 3:08 PM, Robin Dapp wrote:
>>> Currently, extract_... () does that all that for me, is it really too
>>> expensive to call? I guess, using get_range_info first and calling
>>> extract when get_range_info returns a VR_RANGE is not really a favorable
>>> thing to do either? :
Hi,
While GCC doesn't need to know anything about the RcPc extension for code
generation, we do need to add the extension flag to the string we pass
to the assembler when we're compiling for a CPU which implements the RcPc
extension.
I've built a toolchain with this patch applied, and checked th
On Fri, Jun 16, 2017 at 10:06:51AM -0700, Steve Ellcey wrote:
>
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00021.html
>
> Ping.
Hi Steve,
These changes all look like they are to the tree pass rather than to the
AArch64 back end. Maybe reposting it without the AArch64 tag will get it
more v
Ping re this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00204.html
(more description can be seen in v1 of the patch here:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01429.html
)
On Mon, 2017-06-05 at 12:41 -0400, David Malcolm wrote:
> Ping re this patch:
>
> https://gcc.gnu.
On Jun 20, 2017, at 6:23 AM, Richard Biener wrote:
>
> On Fri, Jun 16, 2017 at 6:10 PM, Bill Schmidt
> wrote:
>> Hi,
>>
>> PR71815 identifies a situation where SLSR misses opportunities for
>> PHI candidates when code hoisting is enabled (which is now on by
>> default). The basic problem is th
Hi,
For this code:
struct y {
float x[4];
};
float
bar3 (struct y x)
{
return x.x[3];
}
GCC generates:
bar3:
fmovx1, d2
mov x0, 0
bfi x0, x1, 0, 32
fmovx1, d3
bfi x0, x1, 32, 32
sbfxx0, x0, 32, 32
Hi Thomas,
On my machine I get the following timings without the patch
cpu time cshift dim=1 0.490763009
cpu time do loop dim=15.57969809E-02
cpu time cshift dim=2 0.416319966
cpu time do loop dim=2 0.187106013
cpu time cshift dim=31.37362707
cpu time do loop d
On 06/20/2017 01:35 PM, Rainer Orth wrote:
> JonY <10wa...@gmail.com> writes:
>
>> On 06/20/2017 01:01 PM, Rainer Orth wrote:
>>> Given that there were no other comments, I've installed the patch. It
>>> would still be nice if the Cygwin/MingW maintainer could comment on the
>>> testcase situatio
On 06/20/2017 02:16 PM, Richard Biener wrote:
Nice. This looks ok.
Great, thank you!
I'm mildy curious about the deecrease of debuginfo size for cc1 -- did
you spot anything obvious there?
Well, the benchmark I exposed was for the whole file size, not just
.debug_info section size. Just t
On 20/06/17 14:50, James Greenhalgh wrote:
>
> Hi,
>
> While GCC doesn't need to know anything about the RcPc extension for code
> generation, we do need to add the extension flag to the string we pass
> to the assembler when we're compiling for a CPU which implements the RcPc
> extension.
>
> I
Richard Earnshaw wrote:
> What testing has this had with -fpic? I'm not convinced that this
> assertion is true in that case?
I ran the GLIBC tests which pass. -fpic works since it does also form a
constant address, ie. instead of:
adrp x1, global
add x1, x1, :lo12:global
we do:
adrp x1, :g
On 06/20/2017 02:41 AM, Aldy Hernandez wrote:
On 05/23/2017 03:26 PM, Martin Sebor wrote:
On 05/23/2017 04:48 AM, Aldy Hernandez wrote:
+ void Union (wide_int x, wide_int y);
+ bool Union (const irange &r);
+ bool Union (const irange &r1, const irange &r2);
+
+ // THIS = THIS ^ [X,Y].
Hi,
Function cmse_nonsecure_entry_clear_before_return has code to deal with
high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do
not support more than 16 double VFP registers (D0-D15). This makes this
security-sensitive code harder to read for not much benefit since
libcall for
James Greenhalgh wrote:
>
> Have you tested this in cases where an integer dup is definitely the right
> thing to do?
Yes, this still generates:
#include
void f(unsigned a, unsigned b, uint32x4_t *c)
{
c[0] = vdupq_n_u32(a);
c[1] = vdupq_n_u32(b);
}
dup v1.4s, w0
On Tue, 2017-06-20 at 14:58 +0100, James Greenhalgh wrote:
> On Fri, Jun 16, 2017 at 10:06:51AM -0700, Steve Ellcey wrote:
> >
> >
> > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00021.html
> >
> > Ping.
> Hi Steve,
>
> These changes all look like they are to the tree pass rather than to the
Hi Mike,
Sorry, there was a mistake in the patch I sent. Please find an updated patch
below.
ChangeLog entry unchanged:
*** contrib/ChangeLog ***
2017-06-14 Thomas Preud'homme
* dg-cmp-results.sh: Keep test result lines rather than throwing
header and summary to support s
Hi,
This patch adds support for the ARM Cortex-A75 and
Cortex-A55 processors through the -mcpu/-mtune values cortex-a55 and
cortex-a75, and an ARM DynamIQ big.LITTLE configuration of these two
processors through the -mcpu/-mtune value cortex-a75.cortex-a55
The ARM Cortex-A75 is ARM's latest and
On Fri, Jun 16, 2017 at 11:41:57AM +0200, Richard Biener wrote:
> On Fri, 16 Jun 2017, James Greenhalgh wrote:
> > On Mon, Jun 12, 2017 at 03:56:25PM +0200, Richard Biener wrote:
> > > + We can't do the same for signed A, as it might be negative, which
> > > would
> > > + introduce undefined b
From: Sebastian Huber
Date: Tue, 20 Jun 2017 07:55:33 +0200
> would someone mind reviewing this patch please. It was already sent
> for review on January this year and got no attention. Now we are in a
> different development stage.
>
> https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01354.html
I
On Jun 20, 2017, at 8:31 AM, Thomas Preudhomme
wrote:
>
> 2017-06-14 Thomas Preud'homme
>
> * dg-cmp-results.sh: Keep test result lines rather than throwing
> header and summary to support sum files with multiple tools.
>
>
> Is this still ok?
Ok.
On 06/20/2017 02:21 AM, Eric Botcazou wrote:
>> Out of curiousity, does the old Alpha/VMS stack-checking API meet the
>> requirements? From what I recall, I think it does.
>
> No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it
> because of valgrind. I'd personally rat
On 06/20/2017 02:27 AM, Richard Earnshaw (lists) wrote:
> On 19/06/17 20:04, Jeff Law wrote:
>> On 06/19/2017 11:50 AM, Joseph Myers wrote:
>>> On Mon, 19 Jun 2017, Jeff Law wrote:
>>>
A key point to remember is that you can never have an allocation
(potentially using more than one alloca
Ping re the C++ part of this:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00242.html
Marek approved the C parts; are the C++ parts OK for trunk?
Or can I self-approve this? (exactly what the boundaries of
my"diagnostic messages" maintainer remit are aren't clear to me).
Thanks
Dave
On Mon
2017-06-20 Uros Bizjak
* config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update.
Tested on alphaev68-linux-gnu and committed to mainline SVN.
Uros.
Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt
===
--- con
On 06/20/2017 06:17 AM, Uros Bizjak wrote:
> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>
>>> 74,99% a.outa.out [.] test_or
>>> 12,50% a.outa.out [.] test_movb
>>> 12,50% a.outa.out [.] test_
So here's the patch that reverts the special enum handling in
type_to_string and uses %q#T instead of %qT for two casting-related
diagnostics.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK for trunk?
The "E {enum}'" notation is still on trunk so it seems that this
patch has never been
'nelts' was a suspiciously gnu user space identifier to have. Turns out
we don't use it anywhere. so killed ...
nathan
--
Nathan Sidwell
2017-06-20 Nathan Sidwell
* cp-tree.h (CPTI_NELTS_IDENTIFIER): Delete.
(nelts_identifier): Delete.
* decl.c (initialize_predefined_identifiers): Remov
In C++17 mode we check to make sure that we are initializing directly
from class prvalues rather than copying them, which hit an issue
with packed fields: we create a temporary for binding a
reference to a packed field, and then pass that temporary to the copy
constructor. This isn't actually a pr
On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm wrote:
>> + ob->next_free = p + type_start + type_len;
I'm uncomfortable with modifying the obstack directly. Why not use
obstack_free? I guess for that you'd want to change type_start to a
pointer and get it from obstack_next_free.
Jason
On Tue, Jun 20, 2017 at 1:58 PM, Jason Merrill wrote:
> On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm wrote:
>>> + ob->next_free = p + type_start + type_len;
>
> I'm uncomfortable with modifying the obstack directly. Why not use
> obstack_free?
...because you aren't freeing the object,
Here is the updated patch based on the new infrastructure which is now included.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions
and tested again on SPEC CPU 2006 on THunderX T88 with the speed up
mentioned before.
Thanks,
Andrew Pinski
ChangeLog:
* config/aarch64/aarch64-c
On Tue, Jun 20, 2017 at 6:50 AM, James Greenhalgh
wrote:
>
> Hi,
>
> While GCC doesn't need to know anything about the RcPc extension for code
> generation, we do need to add the extension flag to the string we pass
> to the assembler when we're compiling for a CPU which implements the RcPc
> exte
1 - 100 of 140 matches
Mail list logo
