On Mon, Jan 16, 2017 at 09:26:53AM +0100, Eric Botcazou wrote:
> rs6000 (Fix reload failures in 64-bit mode):
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00568.html
The one thing I find questionable about this patch is that it will set
mem_alias_set for the resulting MEMs to the TOC alias se
On Mon, Jan 16, 2017 at 11:30 PM, Andrew Senkevich
wrote:
> Hi,
>
> here is one more part of intrinsics for k-mask registers shifts:
>
> gcc/
> * config/i386/avx512bwintrin.h: Add k-mask registers shift intrinsics.
> * config/i386/avx512dqintrin.h: Ditto.
> * config/i386/avx512fintrin.
> The one thing I find questionable about this patch is that it will set
> mem_alias_set for the resulting MEMs to the TOC alias set. Is that
> correct for memory not in the TOC?
I don't understand why the memory would not be in the TOC (but I discovered
this TOC business while investigating the
Hi,
This patch fixes inconsistencies in the format strings used to emit
error messages when problems are detected in the AdvSIMD tests. They
are not used normally since there is currently no error, but Doko
complained about warnings when he runs the testsuite with -Wformat=1.
The patch consists i
On Mon, Jan 16, 2017 at 11:36 PM, Richard Biener
wrote:
> On January 16, 2017 7:27:53 PM GMT+01:00, Jeff Law wrote:
>>On 01/16/2017 01:51 AM, Richard Biener wrote:
>>> On Sun, Jan 15, 2017 at 10:34 AM, Jeff Law wrote:
At one time I know I had the max_size == size test in
>>valid_ao_ref
On Tue, Jan 17, 2017 at 09:21:38AM +0100, Eric Botcazou wrote:
> > The one thing I find questionable about this patch is that it will set
> > mem_alias_set for the resulting MEMs to the TOC alias set. Is that
> > correct for memory not in the TOC?
>
> I don't understand why the memory would not b
On Mon, Jan 16, 2017 at 10:25 PM, Jeff Law wrote:
> On 01/09/2017 07:38 PM, David Malcolm wrote:
>>
>> The RTL backend code is full of singleton state, so we have to handle
>> functions as soon as we parse them. This requires various special-casing
>> in the callgraph code.
>>
>> gcc/ChangeLog:
>
On Mon, Jan 16, 2017 at 10:42 PM, Jeff Law wrote:
> On 01/09/2017 07:38 PM, David Malcolm wrote:
>>
>> gcc/ChangeLog:
>> * passes.c: Include "insn-addr.h".
>> (should_skip_pass_p): Add logging. Update logic for running
>> "expand" to be compatible with both __GIMPLE and __
On Tue, Jan 17, 2017 at 2:03 AM, Jan Hubicka wrote:
>> Hello.
>>
>> Not being expert in multi_target area, however it consists of 2 passes. The
>> first
>> one (ipa_target_clone) is responsible for creation of multiple targets for
>> functions
>> decorated with __attribute__((target_clones("xxx"
Moore, Catherine writes:
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Matthew Fortune
> > Sent: Monday, January 16, 2017 11:25 AM
> > To: Doug Gilmore ; gcc-
> > patc...@gcc.gnu.org
> > Cc: Moore, Catherine
> > Sub
On 16 January 2017 at 19:50, David Malcolm wrote:
> On Mon, 2017-01-16 at 13:31 +0100, Rainer Orth wrote:
>> Hi Christophe,
>>
>> > > Successfully bootstrapped®rtested on x86_64-pc-linux-gnu;
>> > > adds 34 PASS results to gcc.sum.
>> > >
>> > These 2 tests fail on arm:
>> >
>> > gcc.dg/format/p
On Tue, Jan 10, 2017 at 2:32 PM, Robin Dapp wrote:
> Perhaps I'm still missing how some cases are handled or not handled,
> sorry for the noise.
>
>> I'm not sure there is anything to "interpret" -- the operation is unsigned
>> and overflow is when the operation may wrap around zero. There might
> Um, why are you using use_toc_relative_ref then, if not to access MEMs
> outside the TOC?
OK, I guess I misunderstood what you meant by "memory not in the TOC", you are
probably referring to the MEM generated by the call to force_const_mem, which
indeed points outside the TOC for VxWorks.
--
Hi Jeff,
On 17 January 2017 at 00:44, Jeff Law wrote:
>
>
> ACATS already had a test covering the Ada issue, Eric also added a test to
> the gnat.dg testsuite. So that's well covered.
>
> The test for the bootstrap comparison failure was (as expected) trivial to
> construct (ssa-dse-29.c). The
Hi Jakub:
Thanks for your review, attachment is v2 patch, it's also run
regression with x86-64, mips64, riscv64 and riscv32.
and additional, I've run gcc 6 branch with this patch, fix mips64 and
riscv64 and no
introduce new regression on x86-64 and riscv32 on 6/trunk, it's ok for
trunk and gcc-6-b
On Tue, Jan 17, 2017 at 06:09:29PM +0800, Kito Cheng wrote:
> Hi Jakub:
>
> Thanks for your review, attachment is v2 patch, it's also run
> regression with x86-64, mips64, riscv64 and riscv32.
> and additional, I've run gcc 6 branch with this patch, fix mips64 and
> riscv64 and no
> introduce new
On Tue, Jan 17, 2017 at 11:06:27AM +0100, Christophe Lyon wrote:
> The new ssa-dse-2.C test fails on arm because:
> warning: declaration of 'void* memmove(void*, const void*, size_t)'
> conflicts with built-in declaration 'void* memmove(void*, const void*,
> unsigned int)' [-Wbuiltin-declaration-mi
Hi Jakub:
Got it, thanks, however I don't have commit right yet, can you commit it?
On Tue, Jan 17, 2017 at 6:13 PM, Jakub Jelinek wrote:
> On Tue, Jan 17, 2017 at 06:09:29PM +0800, Kito Cheng wrote:
>> Hi Jakub:
>>
>> Thanks for your review, attachment is v2 patch, it's also run
>> regression w
>
> gcc/testsuite/ChangeLog:
>
> 2017-01-12 Martin Liska
>
> PR ipa/71207
> * g++.dg/ipa/pr71207.C: New test.
>
> gcc/ChangeLog:
>
> 2017-01-12 Martin Liska
>
> PR ipa/71207
> * ipa-polymorphic-call.c (contains_type_p): Fix wrong
> assumption, add comment a
The problem at hand can be seen in this simple testcase:
int array[999];
void foo()
{
_Cilk_for (int i=0; i < 999; ++i)
array[:] = 0;
}
The issue here is that the _Cilk_for degrades into an OMP PARALLEL, and
we fail to expand the array extension in the body of the OMP PARALLEL.
This is
On Tue, Jan 17, 2017 at 05:43:34AM -0500, Aldy Hernandez wrote:
> The problem at hand can be seen in this simple testcase:
>
> int array[999];
> void foo()
> {
> _Cilk_for (int i=0; i < 999; ++i)
> array[:] = 0;
> }
>
> The issue here is that the _Cilk_for degrades into an OMP PARALLEL, and
2017-01-17 1:55 GMT+03:00 Jakub Jelinek :
> On Tue, Jan 17, 2017 at 01:30:11AM +0300, Andrew Senkevich wrote:
>> here is one more part of intrinsics for k-mask registers shifts:
>
> The software developer manuals describe KSHIFT{L,R}* like:
> KSHIFTLW
> COUNT <- imm8[7:0]
> DEST[MAX_KL-1:0] <- 0
>
On Tue, Jan 17, 2017 at 12:04 PM, Andrew Senkevich
wrote:
> 2017-01-17 1:55 GMT+03:00 Jakub Jelinek :
>> On Tue, Jan 17, 2017 at 01:30:11AM +0300, Andrew Senkevich wrote:
>>> here is one more part of intrinsics for k-mask registers shifts:
>>
>> The software developer manuals describe KSHIFT{L,R}*
* Claudiu Zissulescu [2017-01-09 14:41:44
+0100]:
> This patch revamps the arc's header file by means of using separate
> headers for different tool targets. Each target header file holds the
> specific compiler backend macros definitions. Thus, we have:
> - elf.h is used for bare metal type of
Hi Martin,
On 10/01/17 22:16, Martin Sebor wrote:
The -Walloca-larger-than, -Wformat-length, and -Wformat-truncation
options do not mention LTO among the supported languages and so are
disabled when -flto is used, causing false negatives.
The attached patch adds the missing LTO to the three opt
Wilco Dijkstra wrote:
> Ramana Radhakrishnan wrote:
>> On Wed, Dec 14, 2016 at 5:43 PM, Wilco Dijkstra
>> wrote:
>
> > > Yes, the reason to split the pattern was to introduce the '!' to
> > > discourage Neon->int moves on Cortex-A8
> (https://patches.linaro.org/patch/541/). I am not removing the
ping
From: Wilco Dijkstra
Sent: 31 October 2016 18:29
To: GCC Patches
Cc: nd
Subject: [RFC][PATCH][AArch64] Cleanup frame pointer usage
This patch cleans up all code related to the frame pointer. On AArch64 we
emit a frame chain even in cases where the frame pointer is not required.
So ma
ping
From: Wilco Dijkstra
Sent: 03 November 2016 12:20
To: GCC Patches
Cc: nd
Subject: [PATCH][ARM] Fix ldrd offsets
Fix ldrd offsets of Thumb-2 - for TARGET_LDRD the range is +-1020,
without -255..4091. This reduces the number of addressing instructions
when using DI mode operations (such
ping
From: Wilco Dijkstra
Sent: 10 November 2016 17:19
To: GCC Patches
Cc: nd
Subject: [PATCH][ARM] Improve max_insns_skipped logic
Improve the logic when setting max_insns_skipped. Limit the maximum size of IT
to MAX_INSN_PER_IT_BLOCK as otherwise multiple IT instructions are needed,
incr
Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>
> > I haven't seen a follow-up to Andrew's point regarding other
> > read-modify-write operations.
> >
> > Did youi investigate the cost of these?
>
> I looked at whether there are other similar cases, but it appears SHA1
> is unique due to the odd
Hi Eric,
On Mon, Nov 07, 2016 at 10:44:44AM +0100, Eric Botcazou wrote:
> Tested on PowerPC64/Linux, OK for the mainline?
>
>
>* config/rs6000/rs6000.c (rs6000_emit_move): Also use a TOC reference
> after forcing to constant memory when the code model is medium.
Sorry I lost tra
Hi Anrey,
On 17 Jan 14:04, Andrew Senkevich wrote:
> 2017-01-17 1:55 GMT+03:00 Jakub Jelinek :
> > On Tue, Jan 17, 2017 at 01:30:11AM +0300, Andrew Senkevich wrote:
> >> here is one more part of intrinsics for k-mask registers shifts:
> >
> > The software developer manuals describe KSHIFT{L,R}* lik
> On Mon, Jan 16, 2017 at 10:25 PM, Jeff Law wrote:
> > On 01/09/2017 07:38 PM, David Malcolm wrote:
> >>
> >> The RTL backend code is full of singleton state, so we have to handle
> >> functions as soon as we parse them. This requires various special-casing
> >> in the callgraph code.
> >>
> >>
Ping?
On 01/06/2017 04:25 PM, Nathan Sidwell wrote:
This patch refactors the decl localizing that happens in
function_and_variable_visibility. It doesn't fix the bug I'm working on
(that's next).
Both the FOR_EACH_FUNCTION and FOR_EACH_VARIABLE loops contain very
similar, but not quite the sam
Maciej Rozycki writes:
> On Mon, 16 Jan 2017, Toma Tabacu wrote:
>
> > After searching through the archives, I have found an interesting bit
> > of information about DIV.G/MOD.G in the original submission thread:
> >
> > > > Ruan Beihong 23 July 2008:
> > > >
> > > > I've seen the Loongson 2F man
Hi,
I added builtin changes to Jakub's patch from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731 It fixes the issue, when
gather/scatter intrinsics has wrong spec. Ok for trunk?
gcc/
* config/i386/avx512fintrin.h
(_mm512_i32gather_ps): Fixed arg to void const*.
(_mm512_mask_i32gath
Hi Julia,
On 17 Jan 12:57, Koval, Julia wrote:
> Hi,
> I added builtin changes to Jakub's patch from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731 It fixes the issue, when
> gather/scatter intrinsics has wrong spec. Ok for trunk?
Patch is OK for main trunk
--
Thanks, K
>
> gcc/
> * con
2017-01-17 15:30 GMT+03:00 Kirill Yukhin :
> Hi Anrey,
> On 17 Jan 14:04, Andrew Senkevich wrote:
>> 2017-01-17 1:55 GMT+03:00 Jakub Jelinek :
>> > On Tue, Jan 17, 2017 at 01:30:11AM +0300, Andrew Senkevich wrote:
>> >> here is one more part of intrinsics for k-mask registers shifts:
>> >
>> > The
On Tue, Jan 17, 2017 at 1:57 PM, Koval, Julia wrote:
> Hi,
> I added builtin changes to Jakub's patch from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731 It fixes the issue, when
> gather/scatter intrinsics has wrong spec. Ok for trunk?
> * config/i386/i386-builtin-types.def: Remove typ
Hi,
the testcase is about jump threading confusing profile enough so many edges
are considered cold. The first problem occurs in thread1 pass where
first remove_ctrl_stmt_and_useless_edges does not ouptated outgoing edge
probability after removing the other edges (so we end up with a single
succ bb
I fixed the Changelog. Can you commit it for me if it is ok?
Thanks,
Julia
gcc/
* config/i386/avx512fintrin.h
(_mm512_i32gather_ps): Fixed arg to void const*.
(_mm512_mask_i32gather_ps): Ditto.
(_mm512_i32gather_pd): Ditto.
(_mm512_mask_i32gather_pd): Ditto.
(_mm512_i64gathe
On Tue, Jan 17, 2017 at 2:27 PM, Koval, Julia wrote:
> I fixed the Changelog. Can you commit it for me if it is ok?
This is fairly unreviewable patch, so let's trust testsuite that
everything is OK.
I'll commit the patch later today.
Thanks,
Uros.
> Thanks,
> Julia
>
> gcc/
> * config/i386/a
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, January 17, 2017 4:35 AM
> To: Moore, Catherine ; Doug
> Gilmore ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH, MIPS] Target flag and build option to disable
> indexed memory OPs.
>
> Moor
> This patch refactors the decl localizing that happens in
> function_and_variable_visibility. It doesn't fix the bug I'm working on
> (that's next).
>
> Both the FOR_EACH_FUNCTION and FOR_EACH_VARIABLE loops contain very similar,
> but not quite the same code for localizing a definition that it'
On Tue, Jan 17, 2017 at 04:03:08PM +0300, Andrew Senkevich wrote:
> > I've played a bit w/ SDE. And looks like operands are not early clobber:
> > TID0: INS 0x004003ee AVX512VEX kmovd k0, eax
> > TID0: k0 := _
> > ...
> > TID0: INS 0x004003f4
On 16/01/17 14:29, Jiong Wang wrote:
> On 13/01/17 18:02, Jiong Wang wrote:
>> On 13/01/17 16:09, Richard Earnshaw (lists) wrote:
>>> On 06/01/17 11:47, Jiong Wang wrote:
This patch is an update on DWARF generation for return address signing.
According to new proposal, we simply
This is the same as pr70565 but it fails in an entirely different manner
in the C front-end.
The problem here is that the parser builds an ARRAY_NOTATION_REF with a
type of ptrdiff for length and stride. Later in
cilkplus_extract_an_triplets we convert convert length and stride to an
integer
On 1/16/17 3:09 PM, Aaron Sawdey wrote:
Here is an updated version of this patch.
Tulio noted that glibc's strncmp test was failing. This turned out to
be the use of signed HOST_WIDE_INT for handling strncmp length. The
glibc test calls strncmp with length 2^64-1, presumably to provoke
exactly t
On Tue, Jan 17, 2017 at 09:22:52AM -0500, Aldy Hernandez wrote:
> This is the same as pr70565 but it fails in an entirely different manner in
> the C front-end.
>
> The problem here is that the parser builds an ARRAY_NOTATION_REF with a type
> of ptrdiff for length and stride. Later in cilkplus_e
On 01/17/2017 02:15 AM, Richard Biener wrote:
On Mon, Jan 16, 2017 at 11:36 PM, Richard Biener
wrote:
On January 16, 2017 7:27:53 PM GMT+01:00, Jeff Law wrote:
On 01/16/2017 01:51 AM, Richard Biener wrote:
On Sun, Jan 15, 2017 at 10:34 AM, Jeff Law wrote:
At one time I know I had the max_
Hi All,
This patch vectorizes the copysign builtin for AArch64
similar to how it is done for Arm.
AArch64 now generates:
...
.L4:
ldr q1, [x6, x3]
add w4, w4, 1
ldr q0, [x5, x3]
cmp w4, w7
bif v1.16b, v2.16b, v3.16b
fmulv0.2
On 17/01/17 13:57, Richard Earnshaw (lists) wrote:
On 16/01/17 14:29, Jiong Wang wrote:
I can see the reason for doing this is if you want to seperate the
interpretion
of GCC CFA reg-note and the final DWARF CFA operation. My
understanding is all
reg notes defined in gcc/reg-note.def should
On 01/17/2017 11:43 AM, Jan Hubicka wrote:
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2017-01-12 Martin Liska
>>
>> PR ipa/71207
>> * g++.dg/ipa/pr71207.C: New test.
>>
>> gcc/ChangeLog:
>>
>> 2017-01-12 Martin Liska
>>
>> PR ipa/71207
>> * ipa-polymorphic-call.c (contains_type_
On 01/13/2017 02:01 PM, Richard Biener wrote:
> On Fri, Jan 13, 2017 at 2:00 PM, Martin Liška wrote:
>> On 01/13/2017 01:16 PM, Richard Biener wrote:
>>> On Tue, Jan 10, 2017 at 4:28 PM, Martin Liška wrote:
As mentioned in the PR, we currently do not properly reload global
optimization
Someone pointed out a grammar nit in the -Wmisleading-indentation
diagnostic messages, which this patch fixes.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk and for gcc 6?
gcc/c-family/ChangeLog:
PR c++/71497
* c-indentation.c (warn_for_misleading_indenta
Here is v3 of the patch - tree_fits_uhwi_p was necessary to ensure the size of
a
declaration is an integer. So the question is whether we should allow
largish offsets outside of the bounds of symbols (v1), no offsets (this
version), or
small offsets (small negative and positive offsets just outs
On 01/17/2017 08:52 AM, David Malcolm wrote:
Someone pointed out a grammar nit in the -Wmisleading-indentation
diagnostic messages, which this patch fixes.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk and for gcc 6?
gcc/c-family/ChangeLog:
PR c++/71497
On 01/17/2017 09:41 AM, Jakub Jelinek wrote:
On Tue, Jan 17, 2017 at 09:22:52AM -0500, Aldy Hernandez wrote:
This is the same as pr70565 but it fails in an entirely different manner in
the C front-end.
The problem here is that the parser builds an ARRAY_NOTATION_REF with a type
of ptrdiff for l
I added a static assertion to enforce the CopyConstructible
requirement that the standard imposes for std::throw_with_nested.
Unfortunately the standard is defective, so we started rejecting
perfectly good code. This alters the check to what I think the
standard should say (and what I've proposed
On 01/16/2017 05:06 PM, Martin Sebor wrote:
The test case submitted in bug 79095 - [7 regression] spurious
stringop-overflow warning shows that GCC optimizes some loops
into calls to memset with size arguments in excess of the object
size limit. Since such calls will unavoidably lead to a buffer
On Tue, 2017-01-17 at 08:30 -0600, Peter Bergner wrote:
> On 1/16/17 3:09 PM, Aaron Sawdey wrote:
> > Here is an updated version of this patch.
> >
> > Tulio noted that glibc's strncmp test was failing. This turned out
> > to
> > be the use of signed HOST_WIDE_INT for handling strncmp length. The
The closest thing we have to a version macro in libstdc++ is
__GLIBCXX__ which holds the valid of gcc/DATESTAMP from the source
tree. That's useless for version checking or feature testing because
snapshots have arbitrary values and there's no total order across
branches (a later date does not mea
Hi!
This PR has been fixed in r244218 aka the PR78997 fix.
I've tested the testcase on x86_64-linux with -m32/-m64 (without/with
the PR78997 fix) and committed to trunk as obvious.
2017-01-17 Jakub Jelinek
PR tree-optimization/71854
* gcc.dg/vect/pr71854.c: New test.
--- gcc/
Hi,
ISA 3.0 adds the vbpermd instruction, related to the vbpermq instruction
added in ISA 2.7. This patch adds support for that instruction, and
also ensures that vec_bperm provides access to the three supported
interfaces mandated by the ELFv2 ABI:
vector unsigned char vec_bperm (vector unsigne
I think this is missing the update of the libgo version number.
- Lynn
On 01/13/2017 06:05 PM, Ian Lance Taylor wrote:
I committed a patch to libgo to update the library to the first
release candidate of the upcoming Go 1.8 release. This is a big
update, mostly a straight copy of the code in t
On Tue, Jan 17, 2017 at 10:03:25AM -0600, Lynn A. Boger wrote:
> I think this is missing the update of the libgo version number.
Why? GCC 6.x shipped with libgo.so.9, so I don't see anything wrong
on 7.x shipping libgo.so.10.
Jakub
On 01/17/2017 08:26 AM, Jeff Law wrote:
On 01/16/2017 05:06 PM, Martin Sebor wrote:
The test case submitted in bug 79095 - [7 regression] spurious
stringop-overflow warning shows that GCC optimizes some loops
into calls to memset with size arguments in excess of the object
size limit. Since suc
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 244535.
Index: ChangeLog
===
--- ChangeLog (revision 244534)
+++ ChangeL
On 01/16/2017 03:20 PM, Jakub Jelinek wrote:
> On Mon, Jan 09, 2017 at 03:58:04PM +0100, Martin Liška wrote:
Well, having following sample:
int
main (int argc, char **argv)
{
int *ptr = 0;
{
int a;
ptr = &a;
*ptr = 12345;
On 01/16/2017 08:26 PM, Jeff Law wrote:
On 01/13/2017 11:19 AM, Thomas Preudhomme wrote:
Ping? I'm not sure if an ok from Valdimir is enough or if I also need RM
approval.
Vlad's approval is all you need.
Is that a general rule? I'm never too certain on that.
Bernd
On Tue, Jan 17, 2017 at 05:22:34PM +0100, Bernd Schmidt wrote:
> On 01/16/2017 08:26 PM, Jeff Law wrote:
> > On 01/13/2017 11:19 AM, Thomas Preudhomme wrote:
> > > Ping? I'm not sure if an ok from Valdimir is enough or if I also need RM
> > > approval.
> > Vlad's approval is all you need.
>
> Is t
On 01/17/2017 05:04 AM, Kyrill Tkachov wrote:
Hi Martin,
On 10/01/17 22:16, Martin Sebor wrote:
The -Walloca-larger-than, -Wformat-length, and -Wformat-truncation
options do not mention LTO among the supported languages and so are
disabled when -flto is used, causing false negatives.
The attac
In the past, the libgo version number has always matched the Go version,
not the gcc release.
The libgo for Go 1.7 and Go 1.8 are not the same. If someone wanted to
build gccgo for Go 1.7 using an old commit
maybe for testing or comparison purposes, the libgo version would not
identify whic
On Tue, Jan 17, 2017 at 05:16:44PM +0100, Martin Liška wrote:
> > If it did, we would ICE because ASAN_POISON_USE would survive this way until
> > expansion. A quick fix for the ICE (if it can ever happen) would be easy,
> > in sanopt remove ASAN_POISON_USE calls which have argument that is not lh
> Maciej Rozycki writes:
> > This ought to be handled then, likely by adding Loongson-specific RTL
> > insns matching the `divmod4' and `udivmod4' expanders. It
> > may be as simple as say (conceptually, untested):
> >
> > (define_insn "divmod4_loongson"
> > [(set (match_operand:GPR 0 "register
On 01/13/2017 08:33 AM, Nathan Sidwell wrote:
* lambda.c (resolvable_dummy): New, broken out of ...
Maybe resolvable_dummy_lambda, since that's what it returns?
OK with that change.
Jason
OK.
On Thu, Jan 12, 2017 at 3:27 PM, Jakub Jelinek wrote:
> Hi!
>
> While DW_AT_data_bit_offset has been introduced already in DWARF4, GDB only
> gained support for it last November, so I think it is better to enable this
> only for -gdwarf-5 for now and we can reconsider it in a year or two.
>
>
>
> Ok, applied without the renaming as r244530. I guess you added that to cut
> the recursion.
>
> Would it be fine to install the patch to active branches after proper testing?
OK
Honza
> Thanks,
> Martin
>
> >> bool consider_placement_new,
> >> bool consider_bases)
>
On Tue, 2017-01-17 at 13:35 +0100, Jan Hubicka wrote:
> > On Mon, Jan 16, 2017 at 10:25 PM, Jeff Law wrote:
> > > On 01/09/2017 07:38 PM, David Malcolm wrote:
> > > >
> > > > The RTL backend code is full of singleton state, so we have to
> > > > handle
> > > > functions as soon as we parse them.
As I said in https://gcc.gnu.org/ml/libstdc++/2017-01/msg00109.html
the __GLIBCXX__ macro is useless, but is the closest thing we have to
a version macro for libstdc++. This matters when using libstdc++ with
Clang or Intel icc or other compilers, because you can't check the
__GNUC__ macro. I've se
Currently, on PowerPC, code compiled with -fstack-protector will load
the canary from -0x7010(13) (for -m64) or from -0x7008(2) (for -m32)
if GCC was compiled against GNU libc 2.4 or newer or some other libc
that supports -fstack-protector, and from the global variable
__stack_chk_guard otherwise.
Hi Bill,
On Tue, Jan 17, 2017 at 09:58:52AM -0600, Bill Schmidt wrote:
> Bootstrapped and tested on powerpc64-unknown-linux-gnu and on
> powerpc64le-unknown-linux-gnu with no regressions. Is this ok for
> trunk?
Yes this is fine. Just one trivial remark, fix it or not, your choice...
> +; One
On 01/17/2017 09:12 AM, Martin Sebor wrote:
On 01/17/2017 08:26 AM, Jeff Law wrote:
On 01/16/2017 05:06 PM, Martin Sebor wrote:
The test case submitted in bug 79095 - [7 regression] spurious
stringop-overflow warning shows that GCC optimizes some loops
into calls to memset with size arguments i
After Bernd's DImode patch [1] almost all DImode operations are expanded
early (except for -mfpu=neon). This means the Thumb-2 iordi_notdi_di
patterns are no longer used - the split ORR and NOT instructions are merged
into ORN by Combine. With -mfpu=neon the iordi_notdi_di patterns are used
on Thu
On Mon, Jan 16, 2017 at 03:00:48PM +, Wilco Dijkstra wrote:
> Here is the updated version:
>
> This patch simplifies the handling of the EH return value. We force the use
> of the
> frame pointer so the return location is always at FP + 8. This means we can
> emit
> a simple volatile acces
On Tue, Dec 06, 2016 at 03:10:50PM +, Wilco Dijkstra wrote:
>
>
> ping
OK.
This has been on the list since before Stage 1 closed and should be low
risk outside of code using the SHA1H intrinsics.
Though, given where we are in the release cycle, please give
Richard/Marcus 24 hours to ob
Jason,
in r241944:
2016-11-07 Jason Merrill
Implement P0012R1, Make exception specifications part of the type
system.
You increment processing_template_decl around the mangling of a template
function decl. AFAICT, that's so that nothrow_spec_p doesn't explode at:
gcc_asse
On Wed, Jan 11, 2017 at 3:19 PM, Jakub Jelinek wrote:
> + else
> #endif /* PCC_BITFIELD_TYPE_MATTERS */
> -
> - tree_result = byte_position (decl);
> +tree_result = byte_position (decl);
Let's add a blank line after this assignment. OK with that change.
Jason
On Thu, Jan 12, 2017 at 7:31 AM, Nathan Sidwell wrote:
> Thanks, that does address my comments. AFAICT your reading of the ABI doc
> is correct, but I'd like Jason to confirm that.
I agree.
> you're missing the testsuite/ChangeLog entry, don't forget.
I don't believe in modifying testsuite/Cha
On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
wrote:
> On 2017.01.11 at 13:03 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 11, 2017 at 12:48:29PM +0100, Markus Trippelsdorf wrote:
>> > @@ -1965,7 +1966,11 @@ write_discriminator (const int discriminator)
>> >if (discriminator > 0)
>> >
The attached patch adds fuchsia support to libgcc.
OK for trunk?
Thanks -
Josh
2017-01-17 Joshua Conner
* config/arm/unwind-arm.h (_Unwind_decode_typeinfo_ptr): Use
pc-relative indirect handling for fuchsia.
* config/t-slibgcc-fuchsia: New file.
* config.hos
On Jan 17, 2017, at 3:30 AM, Andrew Burgess wrote:
>
>> This patch revamps the arc's header file by means of using separate
>> headers for different tool targets. Each target header file holds the
>> specific compiler backend macros definitions. Thus, we have:
>> - elf.h is used for bare metal ty
A left shift of 1 can always be done using an add, so slightly adjust rtx
cost for DImode left shift by 1 so that adddi3 is preferred in all cases,
and the arm_ashldi3_1bit is redundant.
DImode right shifts of 1 are rarely used (6 in total in the GCC binary),
so there is little benefit of the arm_
Hello!
As said above i386.c, inline_secondary_memory_needed:
--cut here--
The function can't work reliably when one of the CLASSES is a class
containing registers from multiple sets. We avoid this by never combining
different sets in a single alternative in the machine description.
E
Hello,
This patch series addresses a correctness issue in how OpenMP SIMD regions are
transformed for SIMT execution. On NVPTX, OpenMP target code runs with
per-warp stacks outside of SIMD regions, and needs to transition to per-lane
stacks on SIMD region boundaries. Originally the plan was to i
In preparation to handle new SIMT privatization in lower_rec_simd_input_clauses
this patch factors out variables common to this and lower_rec_input_clauses to
a new structure. No functional change intended.
* omp-low.c (omplow_simd_context): New struct. Use it...
(lower_rec_simd_
This patch prevents inlining into SIMT code by introducing a new loop
property 'in_simtreg' and using ANNOTATE_EXPR (_, 'simtreg') to carry this
property between omp-low and the cfg pass (this is needed only for SIMD
reduction helper loops; for main bodies of SIMD loops omp-expand sets
loop->in_sim
This patch adjusts privatization in OpenMP SIMD loops lowered for SIMT targets.
Addressable private variables become fields of new '.omp_simt' structure that
is allocated by a call to GOMP_SIMT_ENTER (). This function is similar to
__builtin_alloca_with_align, except that it obtains per-SIMT-lane
This patch adds handling of new omp_simt_enter/omp_simt_exit named insns
in the NVPTX backend.
* config/nvptx/nvptx-protos.h (nvptx_output_simt_enter): Declare.
(nvptx_output_simt_exit): Declare.
* config/nvptx/nvptx.c (nvptx_init_unisimt_predicate): Use
cfun->machi
This patch implements propagation of PROP_gimple_lomp_dev during inlining to
allow using it to decide whether pass_omp_device_lower needs to run.
We need to clear this property in expand_omp_simd when the _simt_ clause is
present even if we are not doing any SIMT transforms, because we need to
cle
1 - 100 of 132 matches
Mail list logo
