Hi!
I observed that for a (slowly increasing?) number of C++ testcases
(gcc/testsuite/g++.*/), their nvptx compilation fails as follows:
spawn [...]/build-gcc/gcc/testsuite/g++/../../xg++
-B[...]/build-gcc/gcc/testsuite/g++/../../
[...]/source-gcc/gcc/testsuite/g++.dg/cpp0x/nsdmi4.C
-fno-d
On 14 August 2015 at 20:57, Alexandre Oliva wrote:
> On Aug 11, 2015, Patrick Marlier wrote:
>
>> On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law wrote:
>>> On 08/10/2015 02:23 AM, James Greenhalgh wrote:
>
For what it is worth, I bootstrapped and tested the consolidated patch
on arm-none-li
Alexandre Oliva writes:
> Would you be so kind as to give it a spin on a m68k native? TIA,
I tried it on ia64, and it falls flat on the floor.
../../../libgcc/config/ia64/unwind-ia64.c: In function ‘_Unwind_SetGR’:
../../../libgcc/config/ia64/unwind-ia64.c:1683:1: internal compiler error:
Seg
Andreas Schwab writes:
> Alexandre Oliva writes:
>
>> Would you be so kind as to give it a spin on a m68k native? TIA,
>
> I tried it on ia64, and it falls flat on the floor.
It fixes the m68k failures, though.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196
Hi Alexandre,
On 17/08/15 03:56, Alexandre Oliva wrote:
On Aug 16, 2015, Andreas Schwab wrote:
Alexandre Oliva writes:
On Aug 15, 2015, Andreas Schwab wrote:
FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error)
In file included from
/opt/gcc/gcc-20150815/gcc/test
Hi Richard,
Thanks for the reply. I'd chosen to add new expressions as this seemed more
consistent with the existing MAX_EXPR and MIN_EXPR tree codes. In addition it
would seem to provide more opportunities for optimisation than a target-specific
builtin implementation would. I accept that optimis
On 16/08/15 20:01, Mike Stump wrote:
On Jun 15, 2015, at 7:30 AM, Kyrill Tkachov wrote:
On 29/05/15 11:15, Kyrill Tkachov wrote:
On 29/05/15 10:08, Kyrill Tkachov wrote:
Hi Mike,
On 28/05/15 22:15, Mike Stump wrote:
So, the arm memcpy code of aligned data isn’t as good as it can be.
void
Thanks for all your reviews.
On Fri, Aug 14, 2015 at 4:17 PM, Richard Biener
wrote:
> On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng wrote:
>> Hi,
>> Loop niter computes inaccurate bound information for different loops. This
>> patch is to improve it by using loop initial condition in
>> determine
On Sun, Aug 16, 2015 at 06:14:18PM -0700, Gary Funck wrote:
>
> While reviewing some code, I noticed that the logic for
> pretty-printing 'restrict' qualifiers is likely missing a
> statement that sets 'previous'.
>
> OK to commit?
>
> 2015-08-l6 Gary Funck
>
> * c-pretty-print.c (pp
All:
Does the Logic to calculate the Loop bound information through Value Range
Analyis uses the post dominator and
Dominator info. The iteration branches instead of Loop exit condition can be
calculated through post dominator info.
If the node in the Loop has two successors and post dominates t
On Sun, Aug 16, 2015 at 07:35:17PM +0200, Torvald Riegel wrote:
> On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote:
> > On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote:
> > > On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote:
> > > > 2015-05-06
> Due to PR67205, the deeply nested instantiations require trampolines,
> which in turn requires an executable stack for the GNAT tools on
> architectures such as x86_64.
>
> Bootstrapped on x86_64-redhat-linux-gnu, and make check-ada
> reports no unexpected failures.
>
> Okay for trunk?
Yes.
A
Oops, there is a typo error instead of L it was typed as L1.
Here is the corrected one.
For All the nodes L in the Loop B
If (L1, L2 belongs to successors of (L) && L1,L2 belongs to PosDom(Header of
Loop)) {
I = I union L;
}
Thanks & Regards
Ajit
-Original Message-
From: gcc-patches-o
Hi,
This is the last patch in the series. It follows on from:
[PATCH][3/N] Replace the pattern GET_MODE_BITSIZE (GET_MODE_INNER (m))
with GET_MODE_UNIT_BITSIZE (m)
As a simple optimisation, introduce new inline functions for GET_MODE_UNIT_SIZE
and GET_MODE_UNIT_PRECISION in machmode.h so that we
On Aug 17, 2015, Andreas Schwab wrote:
> Alexandre Oliva writes:
>> Would you be so kind as to give it a spin on a m68k native? TIA,
> I tried it on ia64, and it falls flat on the floor.
Doh, I see a logic flaw in the patch I posted. The hunk in
assign_parm_setup_stack that looked like this:
On Aug 17, 2015, Christophe Lyon wrote:
> Since this was committed (r226901), I can see that the compiler build
> fails for armeb targets, when building libgcc:
Any chance you could get me a preprocessed testcase for this failure, please?
Thanks in advance,
--
Alexandre Oliva, freedom fighter
On 08/17/15 12:06:08, Marek Polacek wrote:
> No, I don't think this assignment is missing here. The restrict qualifier
> is printed last so we don't need to mark that we've printed something.
>
> Actually, the whole "previous" flag seems to be redundant; pp_c_ws_string
> calls pp_c_maybe_whitespa
On Mon, Aug 17, 2015 at 12:06:08PM +0200, Marek Polacek wrote:
> On Sun, Aug 16, 2015 at 06:14:18PM -0700, Gary Funck wrote:
> >
> > While reviewing some code, I noticed that the logic for
> > pretty-printing 'restrict' qualifiers is likely missing a
> > statement that sets 'previous'.
> >
> > OK
On Tue, Aug 04, 2015 at 12:13:15PM +0100, Alan Lawrence wrote:
> > Bootstrapped + check-gcc on aarch64-none-linux-gnu.
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64.c (aarch64_vector_mode_supported_p): Support
> > V4HFmode and V8HFmode.
> > (aarch64_split_simd_move): Add cas
On Thu, Aug 06, 2015 at 05:28:34PM +0100, Alan Lawrence wrote:
> Alan Lawrence wrote:
> > James Greenhalgh wrote:
> >> Hi Alan,
> >>
> >> The arm_neon.h portion of this patch does not apply after Charles' recent
> >> changes. Could you please rebase and resubmit the patch for review?
> >>
>
On Tue, Aug 04, 2015 at 12:07:21PM +0100, Alan Lawrence wrote:
> James Greenhalgh wrote:
> > Hi Alan,
> >
> > The arm_neon.h portion of this patch does not apply after Charles' recent
> > changes. Could you please rebase and resubmit the patch for review?
> >
> > Thanks,
> > James
>
> These are
On 17 August 2015 at 13:58, Alexandre Oliva wrote:
> On Aug 17, 2015, Christophe Lyon wrote:
>
>> Since this was committed (r226901), I can see that the compiler build
>> fails for armeb targets, when building libgcc:
>
> Any chance you could get me a preprocessed testcase for this failure, pleas
Hi,
even though PR 67133 has been avoided by a different patch, I believe
the patch below is the correct fix. It modifies the function that
changes call statements according to call graph edges so that it
changes the fntype of the call statements also when
combined_args_to_skip is NULL. This cod
I'm working on a patch set for GUPC, and as part of that work,
I may have a couple changes to trunk that will improve the fit
with the GUPC changes. Here's one in configure.ac.
At the moment, there is a check to see if $enable_libgom
is not set, followed by a case statement which adds
libgomp to
> Hi,
>
> even though PR 67133 has been avoided by a different patch, I believe
> the patch below is the correct fix. It modifies the function that
> changes call statements according to call graph edges so that it
> changes the fntype of the call statements also when
> combined_args_to_skip is N
Hi,
On Fri, Aug 14, 2015 at 03:19:26PM +0200, Ilya Verbin wrote:
> 2015-08-14 11:47 GMT+02:00 Thomas Schwinge :
> > On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin wrote:
> >> > > @@ -1095,6 +1092,8 @@ GOMP_target (int device, void (*fn) (void *),
> >> > > const void *unused,
> >> > > return
On Mon, Aug 17, 2015 at 11:29 AM, David Sherwood wrote:
> Hi Richard,
>
> Thanks for the reply. I'd chosen to add new expressions as this seemed more
> consistent with the existing MAX_EXPR and MIN_EXPR tree codes. In addition it
> would seem to provide more opportunities for optimisation than a
On Mon, Aug 17, 2015 at 3:47 PM, Jan Hubicka wrote:
>> Hi,
>>
>> even though PR 67133 has been avoided by a different patch, I believe
>> the patch below is the correct fix. It modifies the function that
>> changes call statements according to call graph edges so that it
>> changes the fntype of
This fixes PR67221.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-08-17 Richard Biener
PR tree-optimization/67221
* tree-ssa-sccvn.c (visit_phi): Keep all-TOP args TOP.
(sccvn_dom_walker::before_dom_children): Mark backedges of
n
OK.
Jason
On Mon, Aug 17, 2015 at 5:20 PM, Kyrill Tkachov
wrote:
> Hi Alexandre,
>
> On 17/08/15 03:56, Alexandre Oliva wrote:
>>
>> On Aug 16, 2015, Andreas Schwab wrote:
>>
>>> Alexandre Oliva writes:
On Aug 15, 2015, Andreas Schwab wrote:
> FAIL: gcc.target/aarch64/target_attr_crypt
Hi,
This patch starts a series introducing scalar masks support in the vectorizer.
It was discussed on the recent Cauldron and changes overiew is available here:
https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=view&target=Vectorization+for+Intel+AVX-512.pdf.
Here is shortly a list
Hi,
This patch intoriduces a new vectorizer hook use_scalar_mask_p which affects
code generated by if-conversion pass (and affects patterns in later patches).
Thanks,
Ilya
--
2015-08-17 Ilya Enkovich
* doc/tm.texi (TARGET_VECTORIZE_USE_SCALAR_MASK_P): New.
* doc/tm.texi.in: R
There are no uses of this include file in the x86 backend.
For that matter, apparently there are no uses of libiberty's fibheap
implementation anywhere (well, at least in GCC, binutils, and gdb. I
don't know if there are other users in the wild). FWIW, GCC has its own
in C++.
Approved by
Hi,
This patch adds scalar masks support for MASK_LOAD, MASK_STORE and
VEC_COND_EXPR. Each one gets new optab for scalar mask case and optab is
chosen depending on operands type. For VEC_COND_EXPR it's actually unclear
which mask to check in case comparison is used as the first operand. Thus
> >> Perhaps add a comment that GOT slots are 64-bit on x32?
> >>
> >
> > Good idea. I will update my patch.
> >
>
> How about this?
>
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index bf8a21d..216dee6 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
>
On Mon, Aug 17, 2015 at 10:08 AM, Alexander Monakov wrote:
>> >> Perhaps add a comment that GOT slots are 64-bit on x32?
>> >>
>> >
>> > Good idea. I will update my patch.
>> >
>>
>> How about this?
>>
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index bf8a21d..216dee6 10
On 08/14/2015 02:46 PM, Marek Polacek wrote:
Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the
stmts in bb 2 and we find a null dereference, so
insert_trap_and_remove_trailing_statements
comes in play and turns bb 2 into:
:
...
SR.5_10 = MEM[(const struct A &
I've applied this patch to fix the C++ parsing of the routine directive. As
with the C parser, this was constructing a list of names to apply the directive
to, rather than simply resolving the name in the scope of the directive. With
C++ this is even more interesting than with C, because names
On Mon, Aug 17, 2015 at 11:31:57AM -0600, Jeff Law wrote:
> The funny thing here is we remove the statements after the trap to avoid
> this exact situation!
>
> I think the problem with schemes that either change the order of block
> processing, or which ignore some blocks are going to run into is
Here we were crashing on an invalid call to posix_memalign. The code in
lower_builtin_posix_memalign assumed that the call had valid arguments.
The reason the C FE doesn't reject this code is, in short, that
int () is compatible with int (void **, size_t, size_t) and we
use the former -- so conv
On 08/12/2015 01:32 PM, Jason Merrill wrote:
cxx_eval_array_reference was assuming that the CONSTRUCTOR for an array
has one entry per array element, in order. But
cxx_eval_store_expression doesn't try to create such a CONSTRUCTOR, and
other places use RANGE_EXPRs, so we need to be prepared to h
We were forgetting to register capture proxies for new captures during
template instantiation.
Tested x86_64-pc-linux-gnu, applying to trunk and 5.
commit 6dbfe4dd24e6f001f17e8ea4cf1aa58f4b22ebc8
Author: Jason Merrill
Date: Mon Aug 17 13:59:52 2015 -0400
PR c++/67244
* pt.c (tsubst
For a while, on the concepts branch check_noexcept_r was seeing a
CALL_EXPR where the fn operand was not a pointer or reference to
function, which caused trouble. Let's add an assert for that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4fbc043d90cbc3820e1eeb381d709c2631b7daeb
Author
Hi,
the bug is very clear: in C++11 we reject the testcase because
null_ptr_cst_p returns 'true' for 'false', whereas [conv.ptr] is
carefully worded in terms of integer literals not boolean literals. The
obvious fix, using == INTEGER_TYPE instead of CP_INTEGRAL_TYPE_P,
appears to work well.
On 08/17/2015 02:40 PM, Paolo Carlini wrote:
the bug is very clear: in C++11 we reject the testcase because
null_ptr_cst_p returns 'true' for 'false', whereas [conv.ptr] is
carefully worded in terms of integer literals not boolean literals. The
obvious fix, using == INTEGER_TYPE instead of CP_INT
Hi,
On 08/17/2015 08:50 PM, Jason Merrill wrote:
On 08/17/2015 02:40 PM, Paolo Carlini wrote:
the bug is very clear: in C++11 we reject the testcase because
null_ptr_cst_p returns 'true' for 'false', whereas [conv.ptr] is
carefully worded in terms of integer literals not boolean literals. The
o
On 08/17/2015 02:52 PM, Paolo Carlini wrote:
On 08/17/2015 08:50 PM, Jason Merrill wrote:
OK. I wonder if we can also drop the STRIP_NOPs on the C++11 path.
You are not alone ;) No, not trivially, without we ICE on pr51313.C.
Hmm, that testcase is ill-formed. We ought to reject it, though no
Hi,
On 08/17/2015 08:59 PM, Jason Merrill wrote:
On 08/17/2015 02:52 PM, Paolo Carlini wrote:
On 08/17/2015 08:50 PM, Jason Merrill wrote:
OK. I wonder if we can also drop the STRIP_NOPs on the C++11 path.
You are not alone ;) No, not trivially, without we ICE on pr51313.C.
Hmm, that testca
On 08/17/2015 03:20 PM, Paolo Carlini wrote:
On 08/17/2015 08:59 PM, Jason Merrill wrote:
On 08/17/2015 02:52 PM, Paolo Carlini wrote:
On 08/17/2015 08:50 PM, Jason Merrill wrote:
OK. I wonder if we can also drop the STRIP_NOPs on the C++11 path.
You are not alone ;) No, not trivially, withou
I've committed this patch to add a new pair of internal functions. These will
be used in implementing reductions.
They'll be emitted around reduction finalization, and implement the locking
required for the general case of combining reduction values. They may be
transformed in the oacc_xform
Hi,
On 08/17/2015 09:26 PM, Jason Merrill wrote:
On 08/17/2015 03:20 PM, Paolo Carlini wrote:
On 08/17/2015 08:59 PM, Jason Merrill wrote:
On 08/17/2015 02:52 PM, Paolo Carlini wrote:
On 08/17/2015 08:50 PM, Jason Merrill wrote:
OK. I wonder if we can also drop the STRIP_NOPs on the C++11 pa
Attached patch makes __builtin_signbit type-generic in the middle-end (PR
36757).
Error message will be issued (from gcc/c-family/c-common.c) if argument is not
real (or too few, or too many).
gcc_assert() is used in expand_builtin_signbit() it cases that should be
unreachable (failure to expand
From: Aditya Kumar
Changing the type of scop::region from void* to sese, as this is
the only type assigned to scop::region for now. No functional changes intended.
Passes regtest and bootstrap.
gcc/ChangeLog:
2015-08-17 Aditya Kumar
* graphite-poly.c: Change type of region from void
On 08/17/2015 10:30 PM, Aditya Kumar wrote:
From: Aditya Kumar
Changing the type of scop::region from void* to sese, as this is
the only type assigned to scop::region for now. No functional changes intended.
Passes regtest and bootstrap.
LGTM.
Tobias
I've committed this new testcase for openacc routines. It showed up some
discreprancies in the diagnostics from the C and C++ FE's, hence the changes
there to unifiy the wording. I also fixed up a couple of the libgomp tests to
avoid an uninteresting warning (which tickles a defect in the off
+ if (TREE_CODE (type) == INTEGER_TYPE)
+ {
+ if (TREE_CODE (t) == INTEGER_CST && integer_zerop (t)
+ && !TREE_OVERFLOW (t))
+ return true;
+ }
Let's fold those conditions together. :)
OK.
Jason
Hi Sterling,
these three patches fix bits of xtensa libgcc related to stack unwinding.
They fix a number of uClibc-ng NPTL thread cancellation and cleanup tests,
particularly uClibc-ng 1.0.5 tests
nptl/tst-cancelx4,
nptl/tst-cancelx16,
nptl/tst-cancelx18,
nptl/tst-cancelx20,
nptl/tst-can
Spilling windowed registers in userspace is much easier, more portable,
less error-prone and equally effective as in kernel. Now that register
spilling syscall is considered obsolete in the xtensa linux kernel
replace it with CALL12 followed by series of ENTRY in libgcc.
2015-08-18 Max Filippov
Returning context->cfa in _Unwind_GetCFA makes CFA point one stack frame
higher than what was actually used by code at context->ra. This results
in invalid CFA value in signal frames and premature unwinding completion
in forced unwinding used by uClibc NPTL thread cancellation.
Returning context->s
This allows having exception cleanup code in binaries that don't
register their unwind tables.
2015-08-18 Max Filippov
libgcc/
* config/xtensa/t-windowed (LIB2ADDEH): Replace unwind-dw2-fde
with unwind-dw2-fde-dip.
---
libgcc/config/xtensa/t-windowed | 2 +-
1 file changed, 1 i
When switching up from an older ISA to MIPSR6 some features need to be
disabled. The support for this added in rev r225813 missed the fact
that both the $isa and $isa_rev variables are referenced in this code
so both must get redefined to their (potentially) new values. Without
this patch a number
As I suspected, once the C & C++ parsers are treating the OpenACC routine
directive properly, we don't need to mention it in the common attribute table.
committed to gomp4 branch
nathan
2015-08-17 Nathan Sidwell
* c-common (c_common_attribute_table) Remove oacc function.
Index: gcc/c-fami
On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov wrote:
> This allows having exception cleanup code in binaries that don't
> register their unwind tables.
>
> 2015-08-18 Max Filippov
> libgcc/
> * config/xtensa/t-windowed (LIB2ADDEH): Replace unwind-dw2-fde
> with unwind-dw2-fde-di
On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov wrote:
> 2015-08-18 Max Filippov
> libgcc/
> * config/xtensa/lib2funcs.S (__xtensa_libgcc_window_spill): Use
> CALL12 followed by series of ENTRY to spill windowed registers.
> (__xtensa_nonlocal_goto): Call __xtensa_libgcc_w
On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov wrote:
> 2015-08-18 Max Filippov
> libgcc/
> * config/xtensa/unwind-dw2-xtensa.c (_Unwind_GetCFA): Return
> context->sp instead of context->cfa.
Approved.
On Tue, Aug 18, 2015 at 3:50 AM, augustine.sterl...@gmail.com
wrote:
> On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov wrote:
>> 2015-08-18 Max Filippov
>> libgcc/
>> * config/xtensa/lib2funcs.S (__xtensa_libgcc_window_spill): Use
>> CALL12 followed by series of ENTRY to spill wi
On Aug 17, 2015, Christophe Lyon wrote:
> On 17 August 2015 at 13:58, Alexandre Oliva wrote:
>> On Aug 17, 2015, Christophe Lyon wrote:
>>
>>> Since this was committed (r226901), I can see that the compiler build
>>> fails for armeb targets, when building libgcc:
>>
>> Any chance you could ge
Hi!
On Mon, 17 Aug 2015 06:46:32 -0700, Gary Funck wrote:
> I'm working on a patch set for GUPC, and as part of that work,
> I may have a couple changes to trunk that will improve the fit
> with the GUPC changes. Here's one in configure.ac.
>
> At the moment, there is a check to see if $enable_
69 matches
Mail list logo
