The problem with 69320 (and its various duplicates) is via various paths
we can end up with tests of a boolean ranged object against a constant
outside a boolean range. ie
if (x != 23)
Where x is a boolean ranged object.
That in turn ran afoul of code in record_edge_info which assumed that
Ping.
On 2016/1/5 10:15 PM, Chung-Lin Tang wrote:
> Hi,
> we've been encountering an ICE for OpenACC host_data sections, which
> has a use_device() clause similar to OpenMP use_device_ptr.
>
> The ICE happens in make_decl_rtl() for scan-created variables, which IIUC,
> should not be entered at al
Ping x 2.
On 2016/1/5 11:22 PM, Chung-Lin Tang wrote:
> Patch has been updated to accommodate the gomp_fini_device() removal changes.
> And ping.
>
> On 2015/12/14 11:47 PM, Chung-Lin Tang wrote:
>> [sorry, forgot to C gcc-patches in last send]
>>
>> Hi Jakub,
>> these patches are a revision of
Hi,
aarch64-builtins.c defines several SIMD builtin types. Among these
SIMD types there are the polynomials __Poly{8,16,64,128}_t. These are
built by a call to build_distinct_type_copy
(unsigned_int{Q,H,D,T}I_type_node), respectively, i.e. they are not
VECTOR_TYPEs. A later loop, traverses an arra
mark_used is wrongly diagnosing a use of a TEMPLATE_DECL (e.g. the call
to f1 in function f3 of auto-fn29.C below) for having an undeduced
'auto' return type. This doesn't make sense, because an 'auto' used
inside a template doesn't get deduced until after the template is
instantiated. So for a T
Hi,
This is an updated version of
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02196.html.
Patch to fix PR66726 missed optimization, factor conversion out of
COND_EXPR caused a regression for targets with branch cost greater than
i.e., testcase gcc.dg/pr46309.c failed for these targets. I posted
On Thu, Dec 24, 2015 at 3:55 AM, Alan Lawrence wrote:
> This version changes the test cases to fix failures on some platforms, by
> rewriting the initializers so that they aren't pushed out to the constant
> pool.
>
> gcc/ChangeLog:
>
> * tree-ssa-scopedtables.c (avail_expr_hash): Hash ME
The attached is a minimal patch to avoid the ICE. The patch doesn't
fix the type substitution of flexible array members as that seems
more involved and is, strictly speaking, outside the scope of this
bug.
Type substitution of flexible array is wrong in 5.3.0 (which treats
flexible array members
I think the documentation relating to '-z bndplt' in the GCC manual
description of -fcheck-pointer-bounds is incorrect. It looks like, as
of r225862, the GCC driver is supposed to emit an error message if GCC
was configured with a linker that doesn't support this option and you
pass -mmpx with
On Sat, 16 Jan 2016, Prathamesh Kulkarni wrote:
> > There's a GNU C extension allowing forward declarations of enums, and it
> > seems that
> >
> > static enum e x;
> >
> > doesn't get diagnosed either with -fsyntax-only. Thus I think you should
> > cover that case as well.
> Done in the attached
On Fri, Jan 15, 2016 at 03:04:33PM -0500, David Malcolm wrote:
> OK for trunk? (assuming it bootstraps®rtests by itself)
>
> gcc/ChangeLog:
> PR jit/68446
> * gcc.c (driver::decode_argv): Add call to
> init_opts_obstack before init_options_struct.
> * opts.c (init_opts_obs
On Mon, Jan 18, 2016 at 11:40:23AM +0100, Eric Botcazou wrote:
> > So, do you suggest to tweak get_addr like the patch below, and remove the
> > mem_addr = get_addr (mem_addr);
> > line above and the comment?
>
> Yes, exactly. And if that doesn't easily work, then go for your solution and
> ad
Hi!
On the following testcase with -mrelocatable on ppc32 we get assembly that
contains undefined reference to a local .LC* symbol.
The problem is that prepare_shrink_wrap attempts to schedule some
instructions from the entry block to later basic blocks, if they set a
register that is only used in
Hi!
Here is an attempt to fix ICE on statement expression in "m" asm input
operand. The problem is that gimplify_asm_expr attempts to mark it
addressable, but that can be just too late, a temporary the stmt-expression
gimplifies to might not be addressable and may be used already in the
gimplifie
Hello!
As explained by Honza in the PR, these two tests are not suitable for
LTO tests. Also, the dg-options directives are not effective in this
directory.
2016-01-19 Uros Bizjak
PR testsuite/68820
* gcc.c-torture/execute/builtins/memops-asm.x: New file.
* gcc.c-torture/execute/b
On 01/15/2016 10:48 AM, Mike Stump wrote:
> On Jan 15, 2016, at 10:40 AM, Zachary T Welch wrote:
>> Does this version look better?
>
> Ok.
>
>> I am not sure if this the right place to put the new helper, so let me know
>> if there is a better spot for it.
>
> So, someone that wants to rehome
On 18/01/16 18:39, Manuel López-Ibáñez wrote:
On 18/01/16 14:39, Jesper Broge Jørgensen wrote:
No i have not gone through copyright assignment.
This is my first time trying to contribute to a GNU project so i have
tried
following the "Contributing to GCC"@
https://gcc.gnu.org/contribute.html
On 01/18/2016 11:14 PM, Thomas Koenig wrote:
Hi Toon,
It will also perform the following tests (minus the
"inline_matmul_13.f90" one, which wasn't included in the attachements :-)
Well, here it is.
Included, thanks,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnusho
Hi Toon,
It will also perform the following tests (minus the
"inline_matmul_13.f90" one, which wasn't included in the attachements :-)
Well, here it is.
Regards
Thomas
! { dg-do run }
! { dg-options "-ffrontend-optimize -fdump-tree-original -Wrealloc-lhs" }
! PR 66094: Check functio
Hello,
4 years ago when I create some SMS patches nobody cares about SMS
failures on ia64. Now ia64 is even more dead but at least one of bugs
appears on powerpc - PR69252.
Proposed patch is here:
https://gcc.gnu.org/ml/gcc-patches/2011-12/txt00266.txt and it even
suits current trunk without modi
On Mon, Jan 18, 2016 at 01:06:46PM -0500, Jason Merrill wrote:
> Yes, and let's also clear the fold_cache at the same time.
Ah, that one as well. Thus:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-01-18 Marek Polacek
PR c++/68586
* constexpr.c (clear_cv_cache):
On 01/18/2016 02:12 PM, Patrick Palka wrote:
On Mon, Jan 18, 2016 at 10:34 AM, Jason Merrill wrote:
On 12/25/2015 12:37 PM, Patrick Palka wrote:
That alone would not be sufficient because more_specialized_fn()
doesn't call maybe_adjust_types_for_deduction() beforehand, yet we
have to do the d
On 18/01/16 21:24 +0100, Marc Glisse wrote:
On Mon, 18 Jan 2016, Jonathan Wakely wrote:
This fixes PR60637 by using the appropriate built-in for the size of
the argument type. In Bugzilla Marc asked why we don't just use the
same code as for C++11, but I want to make this less intrusive change
> -Original Message-
> From: Moore, Catherine
> Sent: Tuesday, January 05, 2016 8:53 AM
> To: Richard Henderson; ja...@redhat.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: FW: [RFA] Compact EH Patch [Ping * 2]
>
> Ping, Ping.
>
> -Original Message-
> From: gcc-patches-ow...@gcc.g
On 01/18/2016 02:04 AM, Richard Earnshaw (lists) wrote:
+(define_constraint "Upl"
+ "A constraint that matches two uses of add instructions."
That's not a particularly helpful description for external users of the
compiler. I think that either needs to be sufficiently precise that
people who
On Fri, Jan 15, 2016 at 09:15:01 +0100, Richard Biener wrote:
> On Fri, 15 Jan 2016, Ilya Verbin wrote:
> > II) The __offload_func_table, __offload_funcs_end, __offload_var_table,
> > __offload_vars_end are now provided by the linker script, instead of
> > crtoffload{begin,end}.o, this allows to su
Sandra Loosemore writes:
> On 01/18/2016 10:26 AM, Tom de Vries wrote:
>> Hi,
>>
>> This patch introduces an option fopt-info-oacc.
>>
>> When using the option like this with a kernels region in kernels-loop.c
>> that parloops does not manage to parallelize:
>> ...
>> $ gcc kernels-loop.c -S -O2 -
On Mon, 18 Jan 2016, Jonathan Wakely wrote:
This fixes PR60637 by using the appropriate built-in for the size of
the argument type. In Bugzilla Marc asked why we don't just use the
same code as for C++11, but I want to make this less intrusive change
on the branches (trunk is already OK anyway).
On 18/01/16 17:30 +0100, Torvald Riegel wrote:
On Mon, 2016-01-18 at 14:54 +0100, Torvald Riegel wrote:
On Sun, 2016-01-17 at 18:30 -0500, David Edelsohn wrote:
> On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel wrote:
> > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> >> On Sat, Jan
On 01/17/2016 01:44 PM, Thomas Koenig wrote:
So... comments? Toon, would this help you? Could yo maybe give this
a spin?
Thanks, the nightly test at my home computer will build with your patch.
2016-01-17 Thomas Koenig
PR fortran/66094
* frontend-passes.c (enum matrix
The attached patch fixes the ICE reported for the test case below:
struct str {
int a;
char s[];
};
void fn1() { (struct str){1, ""}; }
While I don't think the patch is incorrect as far as it goes, it's
not the last word on the subject of initializing flexible array
members. I unc
AIX7 has added support for DWARF to XCOFF, but complete and correct
support did not occur with a single update and the initial release of
AIX7. The initial support defined a subset of common DWARF debug
sections. A later update added most of the remaining sections for
location lists and frames, b
On Mon, Jan 18, 2016 at 10:34 AM, Jason Merrill wrote:
> On 12/25/2015 12:37 PM, Patrick Palka wrote:
>>
>> That alone would not be sufficient because more_specialized_fn()
>> doesn't call maybe_adjust_types_for_deduction() beforehand, yet we
>> have to do the decaying there too (and on both types
Thanks for working on this, Christophe, and sorry I missed the PR. You got
further in fixing more things than I did though :). A couple of comments:
> For the vec_set_internal and neon_vld1_dup patterns, I
> switched to an existing iterator which already had the needed
> V4HF/V8HF (so I switched t
This patch follows the suggestion Jakub made in the PR and is very
straightforward.
With the patch, an abort is given on actual errors, in agreement with the
documentation for -dH.
(Yes, not very useful, but we can clear this PR)
Buffered errors bypass this abort by saving and restoring the stat
On Jan 18, 2016, at 8:14 AM, David Malcolm wrote:
> I assumed that these differences were unintentional, so the patch
> consolidates things to make the cleanup identical between (A) and (B).
I also think this is the right path forward.
On 01/18/2016 07:09 AM, Jesper Broge Jørgensen wrote:
Ping patch:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
I'd put it in my gcc-7 queue. But if Richard, Bernd, Richi or someone
else wants to work though the changes as a bugfix for bootstrapping on
platforms with crippled compi
On 01/18/2016 10:26 AM, Tom de Vries wrote:
Hi,
This patch introduces an option fopt-info-oacc.
When using the option like this with a kernels region in kernels-loop.c
that parloops does not manage to parallelize:
...
$ gcc kernels-loop.c -S -O2 -fopenacc -fopt-info-oacc-all
...
we get a messa
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Saturday, January 16, 2016 4:33 AM
To: Ajit Kumar Agarwal; Richard Biener
Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida;
Nagaraju Mekala
Subject: Re: [Patch,tree-optimization]: Add new path Split
On 01/18/2016 11:57 AM, Marek Polacek wrote:
On Mon, Jan 18, 2016 at 10:04:12AM -0500, Jason Merrill wrote:
This wouldn't cover cases where this change affects the type or value of
more complicated expressions, so my preference would be to clear the caches
when we finish_enum_value_list.
So li
On 18/01/16 14:39, Jesper Broge Jørgensen wrote:
No i have not gone through copyright assignment.
This is my first time trying to contribute to a GNU project so i have tried
following the "Contributing to GCC"@
https://gcc.gnu.org/contribute.html
There i followed the advice to run the patch throu
Hi,
This patch introduces an option fopt-info-oacc.
When using the option like this with a kernels region in kernels-loop.c
that parloops does not manage to parallelize:
...
$ gcc kernels-loop.c -S -O2 -fopenacc -fopt-info-oacc-all
...
we get a message:
...
kernels-loop.c:23:9: note: kernels
> Similarly to ARM, I note that Ada is affected. Indeed, with a gcc 4.9 host
> compiler, I saw a bootstrap miscompare iff including Ada; however, I was
> able to bootstrap Ada successfully, if I first built a GCC including this
> patch with --disable-bootstrap, and then used that as host compiler.
* configure.ac (CONFIG_STATUS_DEPENDENCIES): Substitute.
* configure: Regenerate.
* Makefile.in: Regenerate.
diff --git a/libcc1/configure.ac b/libcc1/configure.ac
index 6c97afd..e2e3fda 100644
--- a/libcc1/configure.ac
+++ b/libcc1/configure.ac
@@ -50,6 +50,7 @@ AC_CHECK_D
On Mon, Jan 18, 2016 at 10:04:12AM -0500, Jason Merrill wrote:
> This wouldn't cover cases where this change affects the type or value of
> more complicated expressions, so my preference would be to clear the caches
> when we finish_enum_value_list.
So like this?
Bootstrapped/regtested on x86_64-
On January 18, 2016 4:59:30 PM GMT+01:00, Jan Hubicka wrote:
>Hi,
>this patch fixes pasto that leads to undefined symbol in the testcase
>in PR69003.
>Unfortunately i am not sure how to do incremental linking tests in the
>testsuite.
Only with custom .exp files I guess.
>The patch should work f
On Mon, 2016-01-18 at 14:54 +0100, Torvald Riegel wrote:
> On Sun, 2016-01-17 at 18:30 -0500, David Edelsohn wrote:
> > On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel wrote:
> > > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> > >> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek wrote
This fixes PR60637 by using the appropriate built-in for the size of
the argument type. In Bugzilla Marc asked why we don't just use the
same code as for C++11, but I want to make this less intrusive change
on the branches (trunk is already OK anyway).
The new test is only run on x86 because it f
On 01/18/2016 11:06 AM, Jakub Jelinek wrote:
On Mon, Jan 18, 2016 at 10:53:41AM -0500, Jason Merrill wrote:
In this testcase, we weren't getting the benefits of fold's cleverness in
handling COND_EXPR because we were only calling fold_for_warn on the
condition itself. This patch changes check_f
On 01/13/2016 05:52 PM, Marek Polacek wrote:
On Wed, Jan 13, 2016 at 03:33:27PM -0500, Jason Merrill wrote:
On 01/13/2016 11:50 AM, Marek Polacek wrote:
So to quash that -Wunused-parameter warning, I decided to set TREE_USED at the
place where we create those #xs parameters.
Won't that cause
So we do need error cleanup for both blocks (A) and (B).
gcc/testsuite/ChangeLog:
PR testsuite/69181
* gcc.dg/pr69181-1.c: New test file.
* gcc.dg/pr69181-2.c: New test file.
* lib/gcc-dg.exp (dg-test): Consolidate post-test cleanup of
globals by moving i
On 01/12/2016 01:11 PM, Martin Sebor wrote:
On 01/11/2016 10:20 PM, Jason Merrill wrote:
On 12/22/2015 09:32 PM, Martin Sebor wrote:
+ if (is_attribute_p ("aligned", name)
+ || is_attribute_p ("vector_size", name))
+{
+ /* Attribute argument may be a dependent indentifier. */
+
On Mon, Jan 18, 2016 at 10:53:41AM -0500, Jason Merrill wrote:
> In this testcase, we weren't getting the benefits of fold's cleverness in
> handling COND_EXPR because we were only calling fold_for_warn on the
> condition itself. This patch changes check_function_arguments_recurse to
> fold the en
Hi,
this patch fixes pasto that leads to undefined symbol in the testcase in
PR69003.
Unfortunately i am not sure how to do incremental linking tests in the
testsuite.
The patch should work for the release branches, too,
Honza
Index: ChangeLog
==
In this testcase, we weren't getting the benefits of fold's cleverness
in handling COND_EXPR because we were only calling fold_for_warn on the
condition itself. This patch changes check_function_arguments_recurse
to fold the entire COND_EXPR, and also fixes cp_fold to actually fold
COND_EXPR.
On Tue, 2016-01-12 at 23:21 -0700, Jeff Law wrote:
On 01/12/2016 12:34 PM, David Malcolm wrote:
> >> I looked at this code, and there are two near-identical blocks which
> >> reset all these variables. You are modifying only one of them, leaving
> >> the one inside the if { catch } thing unchanged
Hi!
PDP endian is
gcc_assert (!BYTES_BIG_ENDIAN);
gcc_assert (WORDS_BIG_ENDIAN);
and 16-bit words, thus within uint16_t it is little endian, and the
16-bit words are ordered in larger units in big endian order.
> +#else
> + val = ((val & 0xff00ff00) >> 8) | ((val & 0xff00ff) << 8);
On 12/25/2015 12:37 PM, Patrick Palka wrote:
That alone would not be sufficient because more_specialized_fn()
doesn't call maybe_adjust_types_for_deduction() beforehand, yet we
have to do the decaying there too (and on both types, not just one of
them).
And maybe_adjust_types_for_deduction() see
Hi,
On Sat, Jan 16, 2016 at 09:58:51AM +0100, Jakub Jelinek wrote:
> On Sat, Jan 16, 2016 at 12:49:12AM +0100, Martin Jambor wrote:
> > bootstrapping on i686-linux revealed the need for the following simple
> > patch. I've run into two types of compilation errors on
> > powerpc-ibm-aix (no htolen
Hi,
On Sat, Jan 16, 2016 at 12:43:07PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 15, 2016 at 06:23:05PM +0100, Martin Jambor wrote:
> > BRIG_KIND_OPERAND_REGISTER = 0x300a,
> > BRIG_KIND_OPERAND_STRING = 0x300b,
> > BRIG_KIND_OPERAND_WAVESIZE = 0x3009c,
> > BRIG_KIND_OPERAND_END = 0x300d
>
This wouldn't cover cases where this change affects the type or value of
more complicated expressions, so my preference would be to clear the
caches when we finish_enum_value_list.
Jason
In this PR, we find ourselves in a curious situation. When parsing this enum:
enum E { x = 1, y = x << 1 };
we process the LSHIFT_EXPR in cp_build_binary_op and call
fold_non_dependent_expr
on each of the operands. Then fold_non_dependent_expr calls
maybe_constant_value
which, for CONST_DEC
On 18 January 2016 at 14:12, Kyrill Tkachov wrote:
> Hi Alan,
>
>
> On 18/01/16 12:14, Alan Lawrence wrote:
>>
>> This fixes ICEs on armeb for float16x[48]_t vectors, e.g. in
>> check_effective_target_arm_neon_fp_16_ok.
>>
>> At present, without the expander, moving v4hf/v8hf values around is done
Richard,
Here is the second part of patch which really preforms mask stores and
all statements related to it to new basic block guarded by test on
zero mask. Hew test is also added.
Is it OK for trunk?
Thanks.
Yuri.
2016-01-18 Yuri Rumyantsev
PR middle-end/68542
* config/i386/i386.c (ix86_e
On 01/14/2016 05:33 PM, Andreas Krebbel wrote:
When processing substitutions the operands are renumbered. To find a
free operand number the array used_operands_numbers is used to record
the operand numbers already in use. Currently this array is used to
assign new numbers *before* all the RTXes
On 18/01/16 15:15, Bernd Schmidt wrote:
On 01/13/2016 01:53 AM, Jesper Broge Jørgensen wrote:
genattrab.c can generate if statements that have very deep bracket
nesting causing clang to produce errors (when target=arm-none-eabi) as
explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
A
On 24/11/15 13:26, Tom de Vries wrote:
On 09/11/15 21:06, Tom de Vries wrote:
On 09/11/15 16:35, Tom de Vries wrote:
Hi,
this patch series for stage1 trunk adds support to:
- parallelize oacc kernels regions using parloops, and
- map the loops onto the oacc gang dimension.
The patch series co
On Mon, Jan 18, 2016 at 03:24:21PM +0100, Tom de Vries wrote:
> >>As discussed here (
> >>https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00785.html ), the kernels
> >>directive does not allow the reduction clause. This patch fixes that.
> >>
> >
>
> Ping^2.
Ok.
Jakub
The following patch fixes us miscounting the number of scalar
instructions for BB vectorization leading to vectorizations that
are not profitable.
A simple fix is to count each scalar stmt at most once.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-01-18 Richard
On 24/11/15 13:21, Tom de Vries wrote:
On 09/11/15 16:50, Tom de Vries wrote:
On 09/11/15 16:35, Tom de Vries wrote:
Hi,
this patch series for stage1 trunk adds support to:
- parallelize oacc kernels regions using parloops, and
- map the loops onto the oacc gang dimension.
The patch series co
On Mon, Jan 18, 2016 at 03:15:08PM +0100, Bernd Schmidt wrote:
> Secondly, we're currently in a development phase where we only accept bug
> fixes for gcc-6. You should resubmit/ping the patch once stage1 opens again.
I think this is a bug fix, it is a workaround for a broken compiler that
some pe
On 01/13/2016 01:53 AM, Jesper Broge Jørgensen wrote:
genattrab.c can generate if statements that have very deep bracket
nesting causing clang to produce errors (when target=arm-none-eabi) as
explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
At the above link it was suggested that gen
Ping patch:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
thanks
On Mon, Jan 18, 2016 at 3:02 PM, Yuri Rumyantsev wrote:
> Thanks Richard.
>
> I changed the check on type as you proposed.
>
> What about the second back-end part of patch (it has been sent 08.12.15).
Can't see it in my inbox - can you reply to the mail with a ping?
Thanks,
Richard.
> Thanks.
>
Thanks Richard.
I changed the check on type as you proposed.
What about the second back-end part of patch (it has been sent 08.12.15).
Thanks.
Yuri.
2016-01-18 15:44 GMT+03:00 Richard Biener :
> On Mon, Jan 11, 2016 at 11:06 AM, Yuri Rumyantsev wrote:
>> Hi Richard,
>>
>> Did you have anu chan
On Sun, 2016-01-17 at 18:30 -0500, David Edelsohn wrote:
> On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel wrote:
> > On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> >> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek wrote:
> >> > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn
[ was: Re: [PATCH, 15/16] Add libgomp.oacc-c-c++-common/kernels-*.c ]
On 09/11/15 21:10, Tom de Vries wrote:
On 09/11/15 16:35, Tom de Vries wrote:
Hi,
this patch series for stage1 trunk adds support to:
- parallelize oacc kernels regions using parloops, and
- map the loops onto the oacc gang
[ was: Re: [PATCH, 13/16] Add c-c++-common/goacc/kernels-*.c ]
On 09/11/15 21:07, Tom de Vries wrote:
On 09/11/15 16:35, Tom de Vries wrote:
Hi,
this patch series for stage1 trunk adds support to:
- parallelize oacc kernels regions using parloops, and
- map the loops onto the oacc gang dimensi
[ was: Re: [committed] Add oacc_kernels_p argument to
pass_parallelize_loops ]
On 18/01/16 14:07, Tom de Vries wrote:
[was: Re: [PIING][PATCH, 9/16] Add pass_parallelize_loops_oacc_kernels ]
On 14/12/15 16:22, Richard Biener wrote:
On Sun, Dec 13, 2015 at 5:58 PM, Tom de Vries
wrote:
On 24/
Hi Alan,
On 18/01/16 12:14, Alan Lawrence wrote:
This fixes ICEs on armeb for float16x[48]_t vectors, e.g. in
check_effective_target_arm_neon_fp_16_ok.
At present, without the expander, moving v4hf/v8hf values around is done
via subregs. On armeb, this ICEs because REG_CANNOT_CHANGE_MODE_P. (On
The failures with -m32 are
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Without the closing brace, I get
UNRESOLVED: gfortran.dg/derived_constructor_comps_6.f90 -O0
scan-tree-dump-times original "__builtin_free » 33
Dominique
> Le 18 janv. 2016 à 13:48,
[was: Re: [PIING][PATCH, 9/16] Add pass_parallelize_loops_oacc_kernels ]
On 14/12/15 16:22, Richard Biener wrote:
On Sun, Dec 13, 2015 at 5:58 PM, Tom de Vries wrote:
On 24/11/15 13:24, Tom de Vries wrote:
On 16/11/15 12:59, Tom de Vries wrote:
On 09/11/15 20:52, Tom de Vries wrote:
On 0
This fixes missing handling of GIMPLE_COND in gimple_could_trap_p[_1].
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-01-18 Richard Biener
PR middle-end/69308
* gimple.c (gimple_could_trap_p_1): Handle GIMPLE_COND.
Index: gcc/gimple.c
==
Hello,
On 15 Jan 15:39, Alexander Fomin wrote:
> I've bootstrapped and regtested it against GCC v5 on x86_64-gnu-linux.
> OK for 5-branch?
Yes, it is ok for gcc-5-branch
--
Thanks, K
>
> --
> Thanks,
> Alexander
>
> On Fri, Oct 09, 2015 at 05:24:56PM +0300, Kirill Yukhin wrote:
> > Hello,
> > On
[ was: Re: [PIING][PATCH, 9/16] Add pass_parallelize_loops_oacc_kernels ]
On 14/12/15 16:22, Richard Biener wrote:
Can the pass not just use a pass parameter to switch between oacc/non-oacc?
It can, and that means that parloops is run outside the loops pipeline.
This patch enables that.
Boo
Hi Dominique,
Late or not, thanks for the feedback. I'll fix the right brace. More
worrying is the failure with -m32. I presume that the failure with
-O0/O1 is at runtime? If not, the correction of the missing right
brace is a mysterious trigger for a fault that is optimization
dependent.
Cheers
On Mon, Jan 11, 2016 at 11:06 AM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> Did you have anu chance to look at updated patch?
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index acbb70b..208a752 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5771,6 +5771,10 @@ register_edge_assert_for (tree n
On 18/01/16 11:43 +, Jonathan Wakely wrote:
Fix construction of std::function from null pointer-to-member
PR libstdc++/69293
I've done it again, that was for 69243 not 69293. I have too many
similar PR numbers flying around :-(
Hi Bernd,
+ rtx op0 = force_reg (direct_mode, arg1_rtx);
+ rtx op1 = force_reg (direct_mode, arg2_rtx);
+ rtx tem = emit_store_flag (target, NE, op0, op1,
+direct_mode, true, false);
This is me being ignorant here... wouldn't it be easier to have a
This fixes ICEs when trying to merge functions and variables. As this is
a fatal error in the end no need to try doing sth fancy.
Applied as obvious.
Richard.
2016-01-18 Richard Biener
PR lto/69337
* lto-symtab.c (lto_symtab_merge): Return early for mismatched
funct
This cleans up the neon_reinterpret code on ARM in a similar way to AArch64.
Rather than a builtin backing onto an expander that emits a mov insn, we can
just use a cast, because GCC defines casts of vector types as keeping the same
bit pattern.
On armeb, this fixes previously-failing test:
gcc.ta
This fixes ICEs on armeb for float16x[48]_t vectors, e.g. in
check_effective_target_arm_neon_fp_16_ok.
At present, without the expander, moving v4hf/v8hf values around is done
via subregs. On armeb, this ICEs because REG_CANNOT_CHANGE_MODE_P. (On arm-*,
moving via two subregs is less efficient tha
On 18/01/16 11:49, Jakub Jelinek wrote:
On Mon, Jan 18, 2016 at 11:38:37AM +, Kyrill Tkachov wrote:
On 18/01/16 11:31, Andreas Schwab wrote:
Jeff Law writes:
commit 1384b36abcd52a7ac72ca6538afa2aed2e04f8e0
Author: Jeff Law
Date: Fri Jan 15 17:15:24 2016 -0500
PR tree-optimiz
On Mon, Jan 18, 2016 at 11:38:37AM +, Kyrill Tkachov wrote:
> On 18/01/16 11:31, Andreas Schwab wrote:
> >Jeff Law writes:
> >
> >>commit 1384b36abcd52a7ac72ca6538afa2aed2e04f8e0
> >>Author: Jeff Law
> >>Date: Fri Jan 15 17:15:24 2016 -0500
> >>
> >>PR tree-optimization/69270
>
The wrong overload of _M_not_empty_function gets chosen and we treat a
null pointer-to-member as a valid target.
Tested powerpc64le-linux, comitted to trunk.
commit c0f055172fb4ceda0257a1a4ccd5f244609a0f37
Author: Jonathan Wakely
Date: Mon Jan 18 11:25:43 2016 +
Fix construction of
On 18/01/16 11:31, Andreas Schwab wrote:
Jeff Law writes:
commit 1384b36abcd52a7ac72ca6538afa2aed2e04f8e0
Author: Jeff Law
Date: Fri Jan 15 17:15:24 2016 -0500
PR tree-optimization/69270
* tree-ssanames.c (ssa_name_has_boolean_range): Moved here from
tree-ssa-dom.c
On Fri, Jan 8, 2016 at 2:29 PM, Christian Bruel wrote:
> When compiling code with attribute targets on arm or aarch64,
> vector_type_mode returns different results (eg Vmode or BLKmode) depending
> on the current simd flags that are not set between functions.
>
> for example the following code:
>
Jeff Law writes:
> commit 1384b36abcd52a7ac72ca6538afa2aed2e04f8e0
> Author: Jeff Law
> Date: Fri Jan 15 17:15:24 2016 -0500
>
> PR tree-optimization/69270
> * tree-ssanames.c (ssa_name_has_boolean_range): Moved here from
> tree-ssa-dom.c. Improve test for [0..1] ranve from
In preparation for the implementation of the 'char' compatibility fix.
Tested on x86_64-suse-linux, applied on the mainline.
2016-01-18 Eric Botcazou
* gcc-interface/gigi.h (build_call_raise_column): Adjust prototype.
(build_call_raise_range): Likewise.
(gnat_unsigned
On Tue, Jan 5, 2016 at 3:32 PM, Pierre-Marie de Rodat
wrote:
> Hello,
>
> In Ada, it is possible to have nested subprograms in the following
> configuration:
>
> procedure Parent is
>type T;
>[...]
>procedure Child (Value : T) is
>begin
> [...]
>
1 - 100 of 121 matches
Mail list logo
