Tom suggested that it would be more efficient to use static_nochunk for
loop scheduling for acc gang loops when the static argument isn't
present. We also decided that gang(static:*) should be scheduled using
static_nochunk too. A chunk_size of 1 is probably too conservative for
gangs running on gp
Hi again,
I'm finishing testing this different idea, a much bigger patch but
arguably more neat: add a bool parameter to cp_parser_id_expression and
then to cp_parser_unqualified_id and pass down 'true' from
cp_parser_decltype_expr (this is also nicely consistent with the 'true'
we are passin
ok.
David
On Wed, Jun 17, 2015 at 3:06 PM, Carrot Wei wrote:
> Hi
>
> In aarch64 backend of google/4.9 branch, the split pattern for insn
> aarch64_lshr_sisd_or_int_3 destroys one of the source operands,
> causes the later usage of the operand get a wrong value (google bug
> 17907351).
>
> The b
Hi
In aarch64 backend of google/4.9 branch, the split pattern for insn
aarch64_lshr_sisd_or_int_3 destroys one of the source operands,
causes the later usage of the operand get a wrong value (google bug
17907351).
The bug has been fixed in trunk by r220860. This patch backports it to
google/4.9 b
Steve Ellcey writes:
> On Wed, 2015-06-17 at 19:44 +0100, Richard Sandiford wrote:
>
> >
> > FWIW, to be specific, I think we're talking about every check except
> > the last two in mips.md:
> >
> > and the one mips-ps-3d.md:
> >
> > In particular, the two checks in mips.c should go.
>
> OK, her
On Wed, 2015-06-17 at 19:44 +0100, Richard Sandiford wrote:
>
> FWIW, to be specific, I think we're talking about every check except
> the last two in mips.md:
>
> and the one mips-ps-3d.md:
>
> In particular, the two checks in mips.c should go.
OK, here is a patch that does that.
> But like
Now that reshape_init can return a non-CONSTRUCTOR, we need to call it
earlier in implicit_conversion.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3732672177a2f4893d79279d44b5caed24d6177b
Author: Jason Merrill
Date: Wed Jun 17 07:45:03 2015 -0400
PR c++/66515
* call.c (im
To avoid
FAIL: gcc.target/i386/noplt-1.c scan-assembler call[
\\t]*.*foo.*@GOTPCREL(%rip)
FAIL: gcc.target/i386/noplt-2.c scan-assembler jmp[
\\t]*.*foo.*@GOTPCREL(%rip)
FAIL: gcc.target/i386/noplt-3.c scan-assembler call[
\\t]*.*foo.*@GOTPCREL(%rip)
FAIL: gcc.t
I didn't get time to finish this for 5.1, but this adds missing C++11
allocator support to std::list.
Tested powerpc64le-linux with old and new ABIs, committed to trunk.
commit a2f754fff86496f45b1159f5cdd2420578f96817
Author: Jonathan Wakely
Date: Fri Jun 27 18:36:05 2014 +0100
C++11 allo
On Thu, 2015-06-11 at 00:18 +0200, Jakub Jelinek wrote:
> On Wed, Jun 10, 2015 at 01:16:20PM -0400, David Malcolm wrote:
> > On Wed, 2015-06-10 at 17:34 +0200, Jakub Jelinek wrote:
> > > On Wed, Jun 10, 2015 at 11:24:41AM -0400, David Malcolm wrote:
> > > > I picked the Google Test framework:
> > >
No functional changes.
2015-06-17 Uros Bizjak
* config/i386/i386.c (ix86_function_arg): Nest TARGET_64BIT code.
(ix86_function_arg_advance): Ditto.
(ix86_pass_by_reference): Ditto. Rewrite MS_ABI part.
Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index
On Wed, 2015-06-17 at 19:17 +0100, Maciej W. Rozycki wrote:
> On Wed, 17 Jun 2015, Steve Ellcey wrote:
>
> FAOD I meant to remove the checks globally throughout MIPS target code
> only.
>
> > Is there any reason why my patch (minus the HONOR_NAN checks) would have
> > to wait for the other chan
On 06/17/2015 01:53 PM, Ed Smith-Rowland wrote:
I tried the obvious: an error message with %qE and got 'false'.
constexpr values are evaluated early on.
Is there a possibility that late folding could help or is that
completely different?
Late folding could help, but I think handling it in libc
Sandra Loosemore writes:
> Index: gcc/regrename.c
> ===
> --- gcc/regrename.c (revision 224532)
> +++ gcc/regrename.c (working copy)
> @@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he
>int reg_ptr = REG_POINT
"Maciej W. Rozycki" writes:
> On Wed, 17 Jun 2015, Steve Ellcey wrote:
>> Well, I don't mind removing the HONOR_NAN checks from the MIPS code in
>> my patch but I am not sure I can do a patch to remove it from the shared
>> code. I see about 80 HONOR_NAN checks in the shared code and I am not
>>
On Wed, 17 Jun 2015, Steve Ellcey wrote:
> Well, I don't mind removing the HONOR_NAN checks from the MIPS code in
> my patch but I am not sure I can do a patch to remove it from the shared
> code. I see about 80 HONOR_NAN checks in the shared code and I am not
> sure which ones can and cannot be
On 06/17/2015 10:23 AM, Jason Merrill wrote:
On 06/15/2015 07:14 PM, Ed Smith-Rowland wrote:
I wanted to fix it up as per your suggestion. If someone wants it now I
can retest and commit. Otherwise give me a bit more time.
Someone in LWG was asking about it, and I figured it wouldn't hurt to
There's a potential memory leak in the allocator-extended move
constructor of forward_list, if the allocator parameter is not equal
to the rvalue list's allocator then new list nodes must be allocated,
but if doing so throws then the already-allocated nodes are not freed.
Rather than adding a try
On Wed, 2015-06-17 at 11:41 +0100, Richard Sandiford wrote:
> "Maciej W. Rozycki" writes:
> > In that case I think the HONOR_NANS checks will best be globally removed
> > first (where applicable of course), with a separate preparatory change.
>
> With a comment though :-) I.e. say that althoug
We ran across problems with the regrename pass introducing invalid insns
while working on support for new load/store multiple instructions on
nios2. We're using an implementation similar to what ARM already does,
with a match_parallel predicate testing for restrictions on the
underlying machin
Richard,
I attached updated patch.
You asked me to explain why I did changes for renaming.
If we do not change PHI arguments for inner loop header we can get the
following IR:
source outer loop:
: outer-loop header
# i_45 = PHI <0(4), i_18(9)>
# .MEM_17 = PHI <.MEM_4(D)(4), .MEM_44(9)>
:i
On Thu, May 22, 2014 at 03:24:23PM +0100, Marcus Shawcroft wrote:
> On 2 May 2014 13:27, Kugan wrote:
>
> > +2014-05-02 Kugan Vivekanandarajah
> > +
> > + * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> > + define.
> > + * config/aarch64/aarch64-protos.h
gcc_jit_rvalue_dereference_field has error-checking to ensure that the
field is of the correct struct, but it turned out that
gcc_jit_lvalue_access_field and gcc_jit_rvalue_access_field were missing
this check, and this just bit a user.
Add the missing validation, along with testcases.
Takes "mak
Looks good to me, but I can't approve.
Thanks,
Alan
Charles Baylis wrote:
Ping?
On 11 June 2015 at 00:42, Charles Baylis wrote:
[resending, as previous version was rejected from the list for html]
On 11 June 2015 at 00:38, Charles Baylis wrote:
On 8 June 2015 at 10:44, Alan Lawrence wro
On 06/17/15 04:57, James Greenhalgh wrote:
I'm seeing the same issues on aarch64-none-elf and aarch64_be-none-elf
in one of my testing environments, but, interestingly, not on
aarch64-none-linux-gnu or in my other aarch64-none-elf testing
environment (!!).
ugh. What is the behavior on the tes
Hi,
this implements support for strided grouped stores in the non-SLP case
(the SLP case existed already). Before we were ignoring all but the last
store in a group. That led to a miscompile of GemsFDTD, the testcase
reflects that situation.
Also since r224511 yesterday grouped strided non-S
On 06/17/2015 01:29 PM, Richard Biener wrote:
> On Wed, Jun 17, 2015 at 1:22 PM, Jakub Jelinek wrote:
>> On Wed, Jun 17, 2015 at 11:13:58AM +0200, Martin Jambor wrote:
>> Do you mean Richard following changes:
>>
>> alloc-pool.h (allocate):
>> ...
>> + /* Placement new contruc
On 06/15/2015 07:14 PM, Ed Smith-Rowland wrote:
I wanted to fix it up as per your suggestion. If someone wants it now I
can retest and commit. Otherwise give me a bit more time.
Someone in LWG was asking about it, and I figured it wouldn't hurt to
have this version in now. Glad to hear you'
Hi,
This is a set of tests for OpenACC private variable/state propagation
support in GCC. The associated functionality is a work-in-progress: as
such, many of these tests do not pass yet (causing incorrect results,
ICEs or even bogus assembly output). I believe the tests to be valid
OpenACC, thoug
Ping?
On 11 June 2015 at 00:42, Charles Baylis wrote:
> [resending, as previous version was rejected from the list for html]
>
> On 11 June 2015 at 00:38, Charles Baylis wrote:
>>
>>
>> On 8 June 2015 at 10:44, Alan Lawrence wrote:
>>> Oh, have you tested bigendian?
>>
>> No regressions on aarc
On 06/10/2015 01:50 PM, Martin Liška wrote:
> On 05/15/2015 08:52 PM, Jan Hubicka wrote:
>>> +/* Return true if DECL_ARGUMENT types are valid to be merged. */
>> Perhaps bettter as
>>
>> Perform additional check needed to match types function parameters that are
>> used. Unlike for normal paramet
On Wed, Jun 17, 2015 at 3:06 PM, Andrew MacLeod wrote:
> On 06/17/2015 08:28 AM, Richard Biener wrote:
>>
>> On Tue, Jun 16, 2015 at 7:16 PM, Andrew MacLeod
>> wrote:
>>>
>>> Pretty much everything in the compiler has a need for both is-a.h and
>>> input.h, so this patch moves those into coretype
On 06/17/2015 08:28 AM, Richard Biener wrote:
On Tue, Jun 16, 2015 at 7:16 PM, Andrew MacLeod wrote:
Pretty much everything in the compiler has a need for both is-a.h and
input.h, so this patch moves those into coretypes.h (and rtl.h for
generators.. :-P still working on a good way around that
Hi,
the patch below adds support for HSA vector immediates and
instructions storing them directly to memory, which was hitherto
missing on the branch.
Committed as r224554.
Thanks,
Martin
2015-06-16 Martin Jambor
* hsa-brig.c (hsa_get_imm_brig_type_len): New function.
(emi
On Tue, Jun 16, 2015 at 7:21 PM, Andrew MacLeod wrote:
> function.h defines struct rtl_data which is used for generating rtl. In
> particular, it defines an instance 'crtl' which for generating rtl appears
> analagous to cfun for gimple and trees.
>
> That is the only reason function.h requires ha
On Tue, Jun 16, 2015 at 7:20 PM, Andrew MacLeod wrote:
> tree-core.h won't compile without seeing options.h (which is usually brought
> in by tm.h) because a TARGET_OPTION node contains an instance of struct
> cl_target_option, defined thru options.h.
>
> Its fairly straightforward to change it s
On Tue, Jun 16, 2015 at 7:17 PM, Andrew MacLeod wrote:
>
> There are 2 macros defined in tree.h the depend on the definition of
> NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL. These are ANON_AGGRNAME_FORMAT and
> ANON_AGGRNAME_P. This means that in order to get the correct values for
> those macros,
On Tue, Jun 16, 2015 at 7:16 PM, Andrew MacLeod wrote:
> Pretty much everything in the compiler has a need for both is-a.h and
> input.h, so this patch moves those into coretypes.h (and rtl.h for
> generators.. :-P still working on a good way around that)
>
> is-a.h is required by anything which
On Tue, Jun 16, 2015 at 4:12 PM, Yuri Rumyantsev wrote:
> Thanks a lot Richard for your review.
>
> I presented updated patch which is not gated by force_vectorize.
> I added test on outer-loop in vect_enhance_data_refs_alignment
> and it returns false for it because we can not improve dr alighmen
Similar to yesterday's patch for std::list.
Also removes some invalid downcasts of the _Node_base sentinel's
address to _Node*. The casts aren't needed anyway, as we only access
members of the base class through those pointers.
Also removes some redundant upcasts using *static_cast(&x)
which wil
On Wed, Jun 17, 2015 at 1:22 PM, Jakub Jelinek wrote:
> On Wed, Jun 17, 2015 at 11:13:58AM +0200, Martin Jambor wrote:
>> > >> Do you mean Richard following changes:
>> > >>
>> > >> alloc-pool.h (allocate):
>> > >> ...
>> > >> + /* Placement new contructor. */
>> > >> + inline void *operator ne
On Wed, Jun 17, 2015 at 11:13:58AM +0200, Martin Jambor wrote:
> > >> Do you mean Richard following changes:
> > >>
> > >> alloc-pool.h (allocate):
> > >> ...
> > >> + /* Placement new contructor. */
> > >> + inline void *operator new (size_t, elt_loc_list *&ptr)
> > >> + {
> > >> +return p
On Wed, Jun 17, 2015 at 11:13 AM, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 16, 2015 at 05:31:57PM +0200, Martin Liska wrote:
>> On 06/16/2015 04:02 PM, Richard Biener wrote:
>> > On Tue, Jun 16, 2015 at 3:38 PM, Martin Liška wrote:
>
> ...
>
>> >> Do you mean Richard following changes:
>> >>
>>
Hi!
On Mon, 1 Jun 2015 17:04:03 +0300, Ilya Verbin wrote:
> Is this change ok for OpenACC/PTX?
Well, it doesn't cause any visible regressions in libgomp testing for
OpenACC, so OK from that point of view.
The code that you're changing is not actually used for OpenACC; I first
though it was, unt
This fixes a bug in _S_nothrow_swap(), where I assumed that allocator
types are always swappable, but they don't need to be if
propagate_on_container_swap is false. Thanks to Ville's new trait it's
easy to fix.
For the branches we don't have __is_nothrow_swappable, but could
dispatch on the propa
On Wed, Jun 17, 2015 at 12:10 AM, Jan Hubicka wrote:
>> >> PR middle-end/66325
>> >> * c-decl.c (start_enum): Set TYPE_PACKED consistently among type
>> >> variants.
>> >> Index: c-decl.c
>> >> ===
>> >> --- c-decl.c (re
"Maciej W. Rozycki" writes:
> In that case I think the HONOR_NANS checks will best be globally removed
> first (where applicable of course), with a separate preparatory change.
With a comment though :-) I.e. say that although NEG is the IEEE negate
operation, we don't need to honour NaNs in th
I am not very familiar with this feature entirely so please bear with me
during review and will find some time to do some experiments with the
feature during this week, but a couple of things with respect to the
patch immediately spring to mind.
+(define_insn "probe_stack_range"
+ [(set (ma
Ping^5.
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01130.html
Thanks,
Kyrill
On 02/06/15 09:16, Kyrill Tkachov wrote:
Ping^4.
Thanks,
Kyrill
On 21/05/15 18:00, Kyrill Tkachov wrote:
Ping^3.
Thanks,
Kyrill
On 12/05/15 10:09, Kyrill Tkachov wrote:
Ping^2.
Thanks,
Kyrill
On 30/04/15 13
On Tue, Jun 16, 2015 at 5:13 PM, Uros Bizjak wrote:
> Hello!
>
> Following patch fixes:
>
> cp_lto_pr65276_1.o: In function `std2::runtime_error::~runtime_error()':^M
> pr65276_1.C:(.text._ZN4std213runtime_errorD2Ev[_ZN4std213runtime_errorD5Ev]+0x8):
> undefined reference to `std2::exception::~exc
Hi Jim!
I had mentioned that the Fortran front end changes cause regressions in a
few libgomp execution tests, if configured for Intel MIC (emulation)
offloading. I have now located *where* this is coming from, but would
you please work on figuring out *why*?
Fortunately, you'll be able to work
Hi,
>
> Trim the extra trailing newline.
>
> OK to commit if you are happy with the comment.
Committed as r224549.
Regards,
Robert
On 06/17/2015 10:44 AM, Jakub Jelinek wrote:
> The GCC 4.9 branch is now frozen for preparing of a release candidate for
> GCC 4.9.3. All changes to the branch require release manager approval
> from now on until 4.9.3 is released.
>
> I'll announce the GCC 4.9.3 release candidate once it is read
The patch removes unneeded dg-require-effective-target directives for
compile-only testcases, adds missing dg-do compile and dg-do run in a
couple of cases.
2015-06-17 Uros Bizjak
* gcc.target/i386/pr54592.c: Remove dg-require-effective-target.
* gcc.target/i386/pr52252-atom.c: D
Hi Yury [cc'ing the ARM maintainers]
On 16/06/15 15:04, Yury Usishchev wrote:
Hello!
Following patch fixes PR target/66433.
As described in PR, cost of memory operation with autoincrement is
considered to be greater than same operation without autoincrement. This
causes auto-inc-dec pass not t
Hi,
On Tue, Jun 16, 2015 at 05:31:57PM +0200, Martin Liska wrote:
> On 06/16/2015 04:02 PM, Richard Biener wrote:
> > On Tue, Jun 16, 2015 at 3:38 PM, Martin Liška wrote:
...
> >> Do you mean Richard following changes:
> >>
> >> alloc-pool.h (allocate):
> >> ...
> >> + /* Placement new contruc
On Tue, Jun 16, 2015 at 05:44:49PM +0100, Nathan Sidwell wrote:
> On 06/16/15 03:47, Andreas Schwab wrote:
> > Nathan Sidwell writes:
> >
> >>PR c++/58583
> >>* g++.dg/cpp0x/nsdmi-template14.C: New test.
> >
> > spawn -ignore SIGHUP
> > /usr/local/gcc/gcc-20150616/Build/gcc/testsuite/g++2
The GCC 4.9 branch is now frozen for preparing of a release candidate for
GCC 4.9.3. All changes to the branch require release manager approval
from now on until 4.9.3 is released.
I'll announce the GCC 4.9.3 release candidate once it is ready.
58 matches
Mail list logo