> Ok, I was not aware of that policy.
The reason is that experience showed that you may have several issues for the
same class of processors (e.g. for the original UT699) and you don't want to
have to pass a list of -mfix- switches to fix them all. Moreover, the
workarounds may interact wi
On 06/20/2017 10:59 AM, Martin Sebor wrote:
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, co
Hi Ramana,
Thanks for the review and approval.
>> Please update the ARM backend with the new attribute too
>> (define_insn "crypto_vmullp64"
Its already been updated in the patch posted at:-
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00504.html
>> Ok with that change and checking that you ca
GCC maintainers:
This patch adds support for the various vec_reve builtins.
The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE)
and on powerpc64-unknown-linux-gnu (Power 8 BE) with no regressions.
Is the patch OK for gcc mainline?
Carl Love
---
On Tue, 2017-06-20 at 17:15 -0600, Martin Sebor wrote:
> On 06/20/2017 03:25 PM, David Malcolm wrote:
> > This patch fixes a couple of failures of the form:
> >
> > error: 'void* memset(void*, int, size_t)' clearing an object of
> > non-trivial
> > type 'struct quadratic_test'; use assignmen
Jeff Law wrote:
> But the stack pointer might have already been advanced into the guard
> page by the caller. For the sake of argument assume the guard page is
> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that
> the caller hasn't touched the 0xf1000 page.
>
> If FrameSize >
On 06/20/2017 03:25 PM, David Malcolm wrote:
This patch fixes a couple of failures of the form:
error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial
type 'struct quadratic_test'; use assignment or value-initialization
instead [-Werror=class-memaccess]
note: 'st
On Wed, Jun 14, 2017 at 1:01 AM, 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
On Wed, Jun 14, 2017 at 3:40 AM, 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 bran
> But what you end up depending on is undocumented behavior of a
> particular kernel implementation. That seems rather unwise.
And it's the single example of such a thing in the entire codebase?
I don't know the code of the sanitizer much, but from the outside it looks
full of similar tricks...
On Tue, Jun 20, 2017 at 09:34:25PM +, Joseph Myers wrote:
> On Tue, 20 Jun 2017, Segher Boessenkool wrote:
>
> > > And as you see see below the gcc.target tests have to be duplicated
> > > anyway. Even if the C code is common there will many differences in
> > > dg-options and dg-require-effec
On 06/20/2017 06:27 AM, Richard Biener wrote:
> 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.ou
On 06/20/2017 02:16 AM, Eric Botcazou wrote:
>
> Right, because the Linux kernel for x86/x86-64 is the only OS flavor that
> doesn't let you probe the stack ahead of the stack pointer. All other
> combinations of OS and architecture we tried (and it's quite a lot) do.
But what you end up depend
On 06/20/2017 03:27 AM, Richard Earnshaw (lists) wrote:
> 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
Ping.
On Sat, 3 Jun 2017, Marc Glisse wrote:
Hello,
I don't think Richard's "sounds good" was meant as "ok to commit". Does an
x86 maintainer want to approve or criticize the patch?
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02009.html
On Fri, 26 May 2017, Richard Biener wrote:
On Fri
On Tue, 20 Jun 2017, Segher Boessenkool wrote:
> > And as you see see below the gcc.target tests have to be duplicated
> > anyway. Even if the C code is common there will many differences in
> > dg-options and dg-require-effective-target. Trying to common these
> > implementations only creates mor
This patch is completely missing documentation (in *.texi files) of the
new options, attribute, built-in functions etc.
You appear to be adding quite target-specific things to the
architecture-independent compiler. If the attribute, for example, is to
be architecture-independent, the documenta
Hi All,
I committed the chunk below to fix bootstrap on armv6*-*-freebsd.
Andreas
2017-06-20 Andreas Tobler
* config.gcc (armv6*-*-freebsd*): Change the target_cpu_cname to
arm1176jzf-s.
Index: config.gcc
===
-
On Tue, Jun 20, 2017 at 01:51:24PM -0500, Steven Munroe wrote:
> I am not sure this works or is even a good idea.
>
> As an accident bmiintrin.h can be implemented as C code or common
> builtins. But bmi2intrin.h depends on __builtin_bpermd which to my
> knowledge is PowerISA only.
Right. And th
On Mon, Jun 19, 2017 at 2:00 PM, Andrew Pinski wrote:
> On Wed, Jun 7, 2017 at 10:16 AM, James Greenhalgh
> wrote:
>> On Fri, Dec 30, 2016 at 10:05:26PM -0800, Andrew Pinski wrote:
>>> Hi,
>>> Currently for the following function:
>>> int f(int a, int b)
>>> {
>>> return a + (b <<7);
>>> }
>>
Hello,
now that FRE was fixed to avoid infinite recursion, this patch passes
bootstrap+testsuite on x86_64-pc-linux-gnu multilib with all languages
(including ada).
This isn't exactly the patch that was reverted, because the previous patch
did not actually handle vectors properly.
It still
Control-flow Enforcement Technology (CET) provides the following
capabilities to defend against ROP/JOP style control-flow subversion
attacks:
- Shadow Stack - return address protection to defend against Return
Oriented Programming,
- Indirect branch tracking - free branch protection to defend
This patch fixes a couple of failures of the form:
error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial
type 'struct quadratic_test'; use assignment or value-initialization
instead [-Werror=class-memaccess]
note: 'struct quadratic_test' declared here
cc1plus: a
On 06/20/2017 02:37 PM, Eric Botcazou wrote:
>> But then valgrind won't be able to find bugs in the code (storing and later
>> reading stuff into the volatile parts of the stack that could be overwritten
>> by any asynchronous signal). GCC had various bugs in this area and
>> valgrind has been abl
> But then valgrind won't be able to find bugs in the code (storing and later
> reading stuff into the volatile parts of the stack that could be overwritten
> by any asynchronous signal). GCC had various bugs in this area and
> valgrind has been able to report those. Unless the probe instruction
VAX' FFS as variable-length bit field instruction uses a "base"
operand of type "vb" meaning "byte address".
"base" can be 32 bits (SI) and due to the definition of
ffssi2/__builtin_ffs() with the operand constraint "m", code can be
emitted which incorrectly implies a mode-dependent (= longword, fo
From: Eric Botcazou
Date: Tue, 20 Jun 2017 21:19:37 +0200
>> I'm fine with this change.
>
> I disagree, the existing policy is to avoid switches like -mfix-b2bst and use
> -mfix- where is a CPU (here could be ut699e or ut700).
Ok, I was not aware of that policy. But this should
On Tue, Jun 20, 2017 at 10:21:14AM +0200, 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.
This patch inroduces applyRelocationsALPHA to solve:
FAIL: TestCgoConsistentResults
FAIL: TestCgoPkgConfig
FAIL: TestCgoHandlesWlORIGIN
gotools errors.
Bootstrapped and regression tested on alphaev68-linux-gnu.
Uros.
Index: go/debug/elf/file.go
==
On Jun 20 2017, Jason Merrill wrote:
> On Tue, Jun 20, 2017 at 5:40 AM, Andreas Schwab wrote:
>> 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+
Ping re:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00321.html
On Fri, 2017-05-26 at 15:54 -0400, David Malcolm wrote:
> Ping:
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00321.html
>
> On Thu, 2017-05-04 at 12:36 -0400, David Malcolm wrote:
> > As of r247522, fix-it-hints can sugges
> I'm fine with this change.
I disagree, the existing policy is to avoid switches like -mfix-b2bst and use
-mfix- where is a CPU (here could be ut699e or ut700).
--
Eric Botcazou
On Tue, Jun 20, 2017 at 3:06 PM, David Malcolm wrote:
> It's not clear to me what the issue alluded to with negative
> obstack_blank is, but I chose to follow the above docs and use
> obstack_blank_fast; am testing an updated patch in which the above line
> now looks like:
>
> obstack_bl
On Tue, 2017-06-20 at 14:01 -0400, Jason Merrill wrote:
> On Tue, Jun 20, 2017 at 1:58 PM, Jason Merrill
> wrote:
> > On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm <
> > dmalc...@redhat.com> wrote:
> > > > + ob->next_free = p + type_start + type_len;
> >
> > I'm uncomfortable with modifyi
2017-06-20 Uros Bizjak
* gcc.target/i386/pr80732.c: Include fma4-check.h.
(main): Renamed to ...
(fma4_test): ... this.
Tested on x86_64-linux-gnu and committed to mainline SVN.
Uros.
Index: gcc.target/i386/pr80732.c
On Tue, 2017-06-20 at 09:04 +, Hurugalawadi, Naveen wrote:
> 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
On 06/20/2017 03:27 AM, Jakub Jelinek wrote:
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:
On Tue, Jun 20, 2017 at 5:40 AM, Andreas Schwab wrote:
> 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++.
On Wed, May 3, 2017 at 9:51 AM, David Malcolm wrote:
> On Thu, 2017-04-27 at 23:03 +0200, Marek Polacek wrote:
>> On Thu, Apr 27, 2017 at 05:10:24PM -0400, David Malcolm wrote:
>> > + /* First try const_cast. */
>> > + trial = build_const_cast (dst_type, orig_expr, 0 /* complain
>> > */);
>> >
Hello Julia, Uroš,
On 16 Jun 09:05, Uros Bizjak wrote:
> On Fri, Jun 16, 2017 at 8:46 AM, Koval, Julia wrote:
> > Hi,
> >
> > This test hangs on avx512er, maybe that's why:
> >> According to POSIX, the behavior of a process is undefined after it
> >> ignores a SIGFPE, SIGILL, or SIGSEGV signal th
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
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 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,
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
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
'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
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
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_
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
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
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
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 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 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
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
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
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
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
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
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].
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 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
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 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
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
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
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
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 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
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 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,
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
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
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,
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
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
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
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
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
>> 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
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 (
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 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
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
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-
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:
>
>
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 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: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 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
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 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)
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
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 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
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 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: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 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
1 - 100 of 140 matches
Mail list logo
