On 09/06/15 00:05, Tom de Vries wrote:
On 08/06/15 17:55, Thomas Schwinge wrote:
Hi Tom!
On Mon, 8 Jun 2015 12:43:01 +0200, Tom de Vries
wrote:
There are two problems in try_transform_to_exit_first_loop_alt:
1. In case the latch is not a singleton bb, the function should return
false rat
On Mon, 8 Jun 2015, DJ Delorie wrote:
Also, I note that some tests check for __SIZE_TYPE__ as I do below,
and others use it unconditionally as a replacement for size_t. Is
there a convention?
As far as I can tell, __SIZE_TYPE__ is always defined. The tests that
check for it probably date fro
All,
I sincerely hope this patch will hit the trunk soon. There are 9 users on the
cc list for this bug so it is clearly of considerable user interest.I was
recently informed that the following three-line program does not compile:
$ cat source-allocation.f90
integer, allocatable :: x(:
On Tue, Jun 2, 2015 at 3:45 AM, James Greenhalgh
wrote:
> On Tue, Jun 02, 2015 at 11:38:29AM +0100, Kyrill Tkachov wrote:
>> Hi James, Jim,
>>
>> On 02/06/15 10:42, James Greenhalgh wrote:
>> > On Sat, May 23, 2015 at 12:24:00AM +0100, Jim Wilson wrote:
>> >> The compiler currently ICEs when compi
The testcase for pr 66345 assumes size_t is "unsigned long" instead of
using the real type, which causes failures on some 16-bit targets.
Ok?
Also, I note that some tests check for __SIZE_TYPE__ as I do below,
and others use it unconditionally as a replacement for size_t. Is
there a convention?
.. in case isn't obvious: this case is already Ok:
struct array {
int data [2];
};
struct X {
X() : a{ 1, 2 } { }
array a;
};
because perform_member_init calls reshape_init.
Paolo.
Hi again,
On 06/08/2015 10:33 PM, Paolo Carlini wrote:
Could you also check that we do the right thing for mem-initializers?
Sure I will.
I think we have a similar issue in expand_default_init: exactly when
reshape_init is in order we fail to call it before digest_init. The
below also passes
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Hi,
> > this is a variant of patch that globs also the rest of integer types.
> > Note that we will still get false warnings out of lto-symtab when the
> > values are not wrapped up in structures. This is because lto-symtab
> > uses types_compatible_
>
> Yeah, I think streaming all locations up to RESERVED_LOCATION_COUNT
> literally is more robust. Thus do
>
> bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
> loc < RESERVED_LOCATION_COUNT ? loc :
> RESERVED_LOCATION_COUNT);
> if (loc < RESERVED_LOCATION_COUNT
On 08/06/15 17:55, Thomas Schwinge wrote:
Hi Tom!
On Mon, 8 Jun 2015 12:43:01 +0200, Tom de Vries wrote:
There are two problems in try_transform_to_exit_first_loop_alt:
1. In case the latch is not a singleton bb, the function should return
false rather than true.
2. The check for singleto
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Thank you. It is interesting that the DR exists. We do have comments about
> > possibly completing the types by equiality established by the symbol table
> > but I tought it is strictly invalid. Not sure how much that buy us though.
> > As for speci
Hi,
On 06/08/2015 06:16 PM, Jason Merrill wrote:
On 05/22/2015 02:46 PM, Paolo Carlini wrote:
take a type, not a decl, as first argument.
Why? This complicates calls.
Yes, but, on the other hand, it's more consistent with the arguments of
the various digest_init_*. Also, we don't really
On 06/08/2015 02:59 PM, Richard Biener wrote:
On June 8, 2015 7:14:19 PM GMT+02:00, Aldy Hernandez wrote:
On 06/08/2015 09:30 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez
wrote:
On 06/08/2015 04:26 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 3:23 AM, Aldy
On 06/08/15 13:47, Jason Merrill wrote:
How about using a DECL_LANG_FLAG instead of creating a garbage DEFAULT_ARG?
good idea, I'll go look for an available one.
nathan
Patrick Palka writes:
> On Mon, Jun 8, 2015 at 2:11 PM, David Malcolm wrote:
>>> void
>>> warn_for_misleading_indentation (const common_token_info &guard_tinfo,
>>>const common_token_info &body_tinfo,
>>>const common_toke
On Mon, Jun 8, 2015 at 2:45 PM, Richard Sandiford
wrote:
> Patrick Palka writes:
>> At the same time this patch extends the coverage of the
>> -Wmisleading-indentation implementation to catch misleading indentation
>> involving the semicolon. (These changes are all contained in
>> c-indentation.
On Mon, Jun 8, 2015 at 2:11 PM, David Malcolm wrote:
> On Sun, 2015-06-07 at 16:06 -0400, Patrick Palka wrote:
>> This patch refactors the entry point of -Wmisleading-indentation
>
> Thanks for working on this. I was hoping to submit a patch to propose
> putting -Wmisleading-indentation into -Wal
On June 8, 2015 7:14:19 PM GMT+02:00, Aldy Hernandez wrote:
>On 06/08/2015 09:30 AM, Richard Biener wrote:
>> On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez
>wrote:
>>> On 06/08/2015 04:26 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez
>wrote:
>
> On 0
Patrick Palka writes:
> At the same time this patch extends the coverage of the
> -Wmisleading-indentation implementation to catch misleading indentation
> involving the semicolon. (These changes are all contained in
> c-indentation.c.) For example, now we warn on the following code
> samples:
>
On Sun, 2015-06-07 at 16:06 -0400, Patrick Palka wrote:
> This patch refactors the entry point of -Wmisleading-indentation
Thanks for working on this. I was hoping to submit a patch to propose
putting -Wmisleading-indentation into -Wall, and have been testing the
warning on the linux kernel to tr
On 06/08/2015 09:32 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod wrote:
During the original flattening process I decided to use gcc-plugin.h as the
kitchen sink for all includes that plugins might need. I think this has
worked well for plugins, drastically reducing
On 08/06/15 17:31, Jakub Jelinek wrote:
On Mon, Jun 08, 2015 at 02:04:12PM +0200, Tom de Vries wrote:
>this patch fixes PR66444, a problem with -fipa-ra in reload_combine.
>
>The problem is that for the test-case, reload_combine combines these two
>insns:
Please work out with Vlad whether reloa
How about using a DECL_LANG_FLAG instead of creating a garbage DEFAULT_ARG?
Jason
On 08/06/15 17:31, Jakub Jelinek wrote:
On Mon, Jun 08, 2015 at 02:04:12PM +0200, Tom de Vries wrote:
this patch fixes PR66444, a problem with -fipa-ra in reload_combine.
The problem is that for the test-case, reload_combine combines these two
insns:
Please work out with Vlad whether reload_c
Ok. Thanks!
On 06/08/2015 09:30 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez wrote:
On 06/08/2015 04:26 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez wrote:
On 06/07/2015 02:33 PM, Richard Biener wrote:
On June 7, 2015 6:00:05 PM GMT+02:00, Ald
On Mon, 8 Jun 2015, Marek Polacek wrote:
PR tree-optimization/66299
* match.pd ((CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
((CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)): New
You are braver than I am, I would have abbreviated ctz (CST2) - ctz (CST1)
to CST3 in
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> Thank you. It is interesting that the DR exists. We do have comments about
> possibly completing the types by equiality established by the symbol table
> but I tought it is strictly invalid. Not sure how much that buy us though.
> As for specific examples
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Joseph, I may be wrong, but I believe that the cross-compilation-unit
> > representation compatibility (in C standard sense) is however not an
> > equivalence class, so it can't be fully represented by TYPE_CANOINICAL
>
> Indeed, type compatibility i
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> Joseph, I may be wrong, but I believe that the cross-compilation-unit
> representation compatibility (in C standard sense) is however not an
> equivalence class, so it can't be fully represented by TYPE_CANOINICAL
Indeed, type compatibility is not transiti
On 05/22/2015 02:46 PM, Paolo Carlini wrote:
take a type, not a decl, as first argument.
Why? This complicates calls.
Could you also check that we do the right thing for mem-initializers?
Jason
On 8 June 2015 at 18:53, Ville Voutilainen wrote:
> On 8 June 2015 at 18:37, Martin Sebor wrote:
>> In the hunk below, should the sizes_match template parameter
>> be privatized (since it isn't part of the public interface)?
>> Or perhaps even removed if it's not used?
>
> Yes, it should be uglif
On 06/08/2015 09:12 AM, Jonathan Wakely wrote:
The linker script assumes that std::mbstate_t has the name __mbstate_t
for linkage purposes, but that's not necessarily true. For mingw32
it's just a typedef for int, so the patterns don't match.
This adds a new mingw32-specific pattern for codecvt_
Hi Tom!
On Mon, 8 Jun 2015 12:43:01 +0200, Tom de Vries wrote:
> There are two problems in try_transform_to_exit_first_loop_alt:
> 1. In case the latch is not a singleton bb, the function should return
> false rather than true.
> 2. The check for singleton bb should ignore debug-insns.
>
> A
On 8 June 2015 at 18:37, Martin Sebor wrote:
> In the hunk below, should the sizes_match template parameter
> be privatized (since it isn't part of the public interface)?
> Or perhaps even removed if it's not used?
Yes, it should be uglified, thanks.
Hi,
gently pinging this...
On 05/22/2015 08:46 PM, Paolo Carlini wrote:
Hi,
surprisingly, for NSDMIs we don't use reshape_init and we end-up
rejecting simple testcases like the below. It seems clear to me that
we should - consistently with the comment preceding digest_init too -
but I'm not
* include/std/tuple
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's not used?
Martin
@ -457,6 +457,73 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
};
+
+ // Concept utility fun
On Mon, Jun 08, 2015 at 02:04:12PM +0200, Tom de Vries wrote:
> this patch fixes PR66444, a problem with -fipa-ra in reload_combine.
>
> The problem is that for the test-case, reload_combine combines these two
> insns:
Please work out with Vlad whether reload_cse_move2add doesn't need similar
fix
Hi,
to furhter add to the topics to discuss, I noticed that Fortran FE seems to be
quite
ambivalent about C_CHAR type:
[jh@gcc2-power8 gcc]$ cat ../b.f90
! This testcase will abort if C_CHAR types are not interoperable
module lto_type_merge_test
use, intrinsic :: iso_c_binding
implicit none
c
The linker script assumes that std::mbstate_t has the name __mbstate_t
for linkage purposes, but that's not necessarily true. For mingw32
it's just a typedef for int, so the patterns don't match.
This adds a new mingw32-specific pattern for codecvt_byname's
constructors and destructors, and relax
On Thu, May 28, 2015 at 09:48:10PM +0200, Marc Glisse wrote:
> Side note: if we are looking for extra patterns to simplify, llvm has an
> almost unlimited supply. Here are a few we don't seem to have (there are
> more where those came from), of course several need constraining /
> generalizing, it
On 06/01/2015 06:16 PM, mliska wrote:
> Hi.
>
> Following 2 patches improve memory statistics infrastructure. First one
> ports pool allocator to the new infrastructure. And the second one makes
> column alignment properly.
>
> Both can bootstrap on x86_64-linux-pc and survive regression tests.
>
>
> I think we should instead work towards eliminating the get_alias_set
> langhook first. The LTO langhook variant contains the same handling, btw,
> so just inline that into get_alias_set and see what remains?
I see, i completely missed existence of gimple_get_alias_set. It makes more
sense no
diff --git a/libgomp/libgomp.map b/libgomp/libgomp.map
index fe38dc6..663c27c 100644
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -318,6 +318,7 @@ GOACC_2.0 {
global:
GOACC_data_end;
GOACC_data_start;
+ GOACC_declare;
GOACC_enter_exit_data;
GOACC_parallel;
GOACC_update;
@@
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index 7c3273f..0774da5 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -451,6 +451,7 @@ DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_ULONG_ULONG_ULONGPTR, BT_BOOL, BT_ULONG,
DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_ULONGLONG_ULONGLONG_ULONGL
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Hi,
> > this is a variant of patch that globs also the rest of integer types.
> > Note that we will still get false warnings out of lto-symtab when the
> > values are not wrapped up in structures. This is because lto-symtab
> > uses types_compatible_
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 5003581..a889342 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -119,6 +119,8 @@ static const struct attribute_spec gfc_attribute_table[] =
affects_type_identity } */
{ "omp declare target", 0, 0, t
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 261a12d..15da51e 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -78,6 +78,7 @@ along with GCC; see the file COPYING3. If not see
#include "cilk.h"
#include "wide-int.h"
#include "builtins.h"
+#include "gomp-constants.h"
/* Possible cases
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index f508b91..83c1432 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -82,6 +82,7 @@ along with GCC; see the file COPYING3. If not see
#include "omp-low.h"
#include "builtins.h"
#include "gomp-constants.h"
+#include "tree-iterator.h"
On 06/07/2015 02:05 PM, Ilmir Usmanov wrote:
> Fixed fortran mail-list address. Sorry for inconvenience.
>
> 08.06.2015, 00:01, "Ilmir Usmanov" :
>>> Hi Cesar!
>>>
>>> This patch fixes checks of OpenMP and OpenACC continuations in
>>> case if someone mixes them (i.e. continues OpenMP directive wi
Hi!
This patch series completes the implementation of the OpenACC
declare directive.
Patches applied to gomp-4_0-branch
Thanks!
Jim
= gcc/ChangeLog.gomp
* builtin-types.def (BT_FN_VOID_PTR_INT_UINT): New type.
* gimple-pretty-print.c (dump_gimple_omp_target): Handl
This fixes PR66419.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2015-06-08 Richard Biener
PR tree-optimization/66419
* tree-vect-slp.c (vect_supported_load_permutation_p): Properly
consider GROUP_GAP when detecting a perfect subchain.
*
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > On Mon, 8 Jun 2015, Richard Biener wrote:
> >
> > > On Mon, 8 Jun 2015, Joseph Myers wrote:
> > >
> > > > On Mon, 8 Jun 2015, Richard Biener wrote:
> > > >
> > > > > I'm not sure the C standard mandates compatibility between
> > > > >
> > > > > struct
> On Mon, 8 Jun 2015, Richard Biener wrote:
>
> > On Mon, 8 Jun 2015, Joseph Myers wrote:
> >
> > > On Mon, 8 Jun 2015, Richard Biener wrote:
> > >
> > > > I'm not sure the C standard mandates compatibility between
> > > >
> > > > struct { int i; } and struct { unsigned i; } for purposes of TBA
On Mon, 8 Jun 2015, Richard Biener wrote:
> On Mon, 8 Jun 2015, Joseph Myers wrote:
>
> > On Mon, 8 Jun 2015, Richard Biener wrote:
> >
> > > I'm not sure the C standard mandates compatibility between
> > >
> > > struct { int i; } and struct { unsigned i; } for purposes of TBAA.
> > > Joseph?
>
On Mon, 8 Jun 2015, Joseph Myers wrote:
> On Mon, 8 Jun 2015, Richard Biener wrote:
>
> > I'm not sure the C standard mandates compatibility between
> >
> > struct { int i; } and struct { unsigned i; } for purposes of TBAA.
> > Joseph?
>
> I don't think they are necessarily compatible for TBAA.
We fail to unshare exprs put into debug stmts during inlinign which
creates bogus tree sharing.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2015-06-08 Richard Biener
PR middle-end/66413
* tree-inline.c (insert_init_debug_bind): Unshare value.
On Mon, 8 Jun 2015, Richard Biener wrote:
> I'm not sure the C standard mandates compatibility between
>
> struct { int i; } and struct { unsigned i; } for purposes of TBAA.
> Joseph?
I don't think they are necessarily compatible for TBAA.
--
Joseph S. Myers
jos...@codesourcery.com
Hi Guys,
I am applying the patch below to the RX's handling of vector
functions. The RX ABI specifies that small integer return values
should always be promoted to 32-bit values, but the code that performs
this promotion was also affecting vector types. This results in
internal compile
On Fri, Jun 5, 2015 at 5:24 PM, Andrew MacLeod wrote:
> There is a horrible morass of include dependencies between hash-map.h,
> mem-stats.h and hash-table.h. There are even includes in both directions
> (mem-stats.h and hash-map.h include each other, as do hash-map.h and
> hash-table.h.. blech).
On Mon, Jun 8, 2015 at 3:37 PM, Jan Kratochvil
wrote:
> On Mon, 08 Jun 2015 09:46:59 +0200, Richard Biener wrote:
>> adding a
>>
>> import sys
>>
>> makes it work fine though.
>
> I do not see the sys error with either FSF GDB HEAD or Fedora 22 GDB.
> I agree it probably should be there.
Yeah, I
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> Hi,
> this is a variant of patch that globs also the rest of integer types.
> Note that we will still get false warnings out of lto-symtab when the
> values are not wrapped up in structures. This is because lto-symtab
> uses types_compatible_p that in turn
On Mon, Jun 08, 2015 at 03:32:50PM +0200, Andreas Krebbel wrote:
> On 06/01/2015 10:22 AM, Jakub Jelinek wrote:
> > On Fri, May 22, 2015 at 09:54:00AM +0200, Andreas Krebbel wrote:
> >> On Tue, May 19, 2015 at 10:40:26AM +0200, Andreas Krebbel wrote:
> >>> On 05/18/2015 04:19 PM, Richard Biener wro
On Mon, 08 Jun 2015 09:46:59 +0200, Richard Biener wrote:
> adding a
>
> import sys
>
> makes it work fine though.
I do not see the sys error with either FSF GDB HEAD or Fedora 22 GDB.
I agree it probably should be there.
> Thus, ok with also adding a imoprt sys.
Done and checked in: r224223
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > Hi,
> > this patchs makes fortran's C_SIGNED_CHAR and C_SIZE_T interoperable with
> > signed char and size_t as standard require. There are two issues here.
> >
> > First Fortran integers are always signed, but the standard insist on the
> > signed int
On 06/05/2015 01:04 AM, Jan-Benedict Glaw wrote:
> Hi Andreas,
>
> On Mon, 2015-05-11 15:23:33 +0200, Andreas Krebbel
> wrote:
>> gcc/
>> * config/s390/constraints.md (j00, jm1, jxx, jyy, v): New
>> constraints.
>> * config/s390/predicates.md (const0_operand, constm1_operand)
>>
On 06/01/2015 10:22 AM, Jakub Jelinek wrote:
> On Fri, May 22, 2015 at 09:54:00AM +0200, Andreas Krebbel wrote:
>> On Tue, May 19, 2015 at 10:40:26AM +0200, Andreas Krebbel wrote:
>>> On 05/18/2015 04:19 PM, Richard Biener wrote:
Please use uint64_t instead.
>>>
>>> Done. Ok with that change?
On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod wrote:
> During the original flattening process I decided to use gcc-plugin.h as the
> kitchen sink for all includes that plugins might need. I think this has
> worked well for plugins, drastically reducing their dependency on gcc
> internal header f
On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez wrote:
> On 06/08/2015 04:26 AM, Richard Biener wrote:
>>
>> On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez wrote:
>>>
>>> On 06/07/2015 02:33 PM, Richard Biener wrote:
On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez
wrote:
If the codecvt facet generates a BOM on every call to out() then we
need to ensure there is enough capacity in the output string for the
entire result, otherwise we loop and insert more than one BOM into the
result.
Tested powerpc64-linux and powerpc64-linux.
Committing to trunk and gcc-5-branch
On Wed, 3 Jun 2015, Richard Biener wrote:
>
> This allows all permutations we can generate (according to the target).
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
So this turned up other issues thus the following is what I have
committed after bootstrapping and testing on x86_
On 18/05/15 14:53, Tom de Vries wrote:
On 15-04-15 15:10, Tom de Vries wrote:
Hi,
This patch series fixes PR65637.
Currently, ssa-handling code in expand_omp_for_static_chunk is dead
and not
exercised by testing.
Ssa-handling code in omp-low.c is only triggered by
pass_parallelize_loops, and
On 17/04/15 12:08, Tom de Vries wrote:
On 20-03-15 12:38, Tom de Vries wrote:
On 19-03-15 12:05, Tom de Vries wrote:
On 18-03-15 18:22, Tom de Vries wrote:
Hi,
this patch fixes PR65460.
The patch marks offloaded functions as parallelized, which means the
parloops
pass no longer attempts to m
During the original flattening process I decided to use gcc-plugin.h as
the kitchen sink for all includes that plugins might need. I think this
has worked well for plugins, drastically reducing their dependency on
gcc internal header file structure.
What I didn't realize was that gcc's intern
Hi DJ,
The -mes0 option for the RL78 backend should put read only data into a
special .frodata section, but unfortunately my recent update to the
rl78_select_section function broke this behaviour. Below is a patch
to fix this. Tested with no regressions on an rl78-elf toolchain.
OK to
On 06/08/2015 04:26 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez wrote:
On 06/07/2015 02:33 PM, Richard Biener wrote:
On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez
wrote:
On 06/07/2015 11:25 AM, Richard Biener wrote:
On June 7, 2015 5:03:30 PM GMT+02:00
Hi,
this patch fixes PR66444, a problem with -fipa-ra in reload_combine.
The problem is that for the test-case, reload_combine combines these two
insns:
...
(insn 13 12 14 2 (parallel [
(set (reg/v/f:DI 37 r8 [orig:92 xD.1858 ] [92])
(plus:DI (reg:DI 37 r8 [96])
Hi,
This patch adds a thread barrier after worker loops for OpenACC, in
accordance with OpenACC 2.0a section 2.7.3 (worker loops): "All workers
will complete execution of their assigned iterations before any worker
proceeds beyond the end of the loop.". (This is quite target-specific:
work to alle
I forgot to swap the byte-order for codepoints that fit in a single
UTF-16 character, fixed like so.
Tested powerpc64-linux and powerpc64le-linux.
Committing to trunk and gcc-5-branch.
commit cc2dca496553bba0d09db49b98ccef0d728d9a36
Author: Jonathan Wakely
Date: Mon Jun 8 11:38:04 2015 +0100
On Mon, 8 Jun 2015, Tom de Vries wrote:
> On 04/06/15 10:28, Tom de Vries wrote:
> > > I'm ok with the patch and count on you to fix eventual fallout ;)
> > >
> >
> > Great, will do.
>
> And here is the fallout:
> * PR66442 - [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for
> excess er
The following patch should fix the bogus array-bound warning caused
by loop peeling which fails to split blocks after inserted unreachable
calls (which is now "fatal" to optimization after removing the
quadraticness in CFG cleanup to scan for noreturn calls).
Bootstrap and regtest in progress on
On 04/06/15 10:28, Tom de Vries wrote:
I'm ok with the patch and count on you to fix eventual fallout ;)
Great, will do.
And here is the fallout:
* PR66442 - [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for
excess errors)
There are two problems in try_transform_to_exit_first_loop_a
Hi Uros,
Checked the patch in the following branches and trunk after bootstrapping and
regression testing them individually.
GCC 5 branch
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=224215
GCC 4.9 branch
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=224214
GCC 4.8 branch
Hi All,
Here is a simple fix which allows duplication of outer loops to
perform peeling for number of iterations if outer loop is marked with
pragma omp simd.
Bootstrap and regression testing did not show any new failures.
Is it OK for trunk?
ChangeLog:
2015-06-08 Yuri Rumyantsev
* tree-vec
On 06/08/2015 04:03 AM, Iain Sandoe wrote:
Hi Aldy,
On 7 Jun 2015, at 12:37, Aldy Hernandez wrote:
On 06/07/2015 06:19 AM, Andreas Schwab wrote:
Another fallout:
FAIL: obj-c++.dg/try-catch-5.mm -fgnu-runtime (test for excess errors)
Excess errors:
: warning: '_OBJC_Module' defined but not us
On Mon, 8 Jun 2015, Marek Polacek wrote:
> This PR is about a bogus -Wunused-variable warning about an internal
> structure (*.Lubsan_data*), exposed by the debug-early merge.
>
> I think the "defined but not used" warning should not be allowed for
> the compiler-generated entities.
>
> Bootstra
This PR is about a bogus -Wunused-variable warning about an internal
structure (*.Lubsan_data*), exposed by the debug-early merge.
I think the "defined but not used" warning should not be allowed for
the compiler-generated entities.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-06-0
Oh, have you tested bigendian?
--Alan
Charles Baylis wrote:
This is another attempt at fixing this PR63870 for AArch64 (ARM is
still to come).
As before, the Q register variants are handled by moving the check for
the lane bounds into builtin expansion. The handling of lane numbers
is made con
Thanks for working on this!
I'd been fiddling around with a patch with some similar elements to this, but
many trials with union types, subregs, etc., all worsened the register
allocation and led to more unnecessary shuffling / moves. The only real thing I
tried which you don't do here, was to
On 08/06/15 09:45, Christian Bruel wrote:
Hi Ramana,
Ok, I see.
The patch looks ok to me modulo the typo nits I pointed out, but I
think Ramana
should have the final say here as he's already started reviewing it
and it adds quite
a lot of functionality.
Thanks,
Kyrill
do you have other f
On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez wrote:
> On 06/07/2015 02:33 PM, Richard Biener wrote:
>>
>> On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez
>> wrote:
>>>
>>> On 06/07/2015 11:25 AM, Richard Biener wrote:
On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez
>>>
>>>
On Sat, Jun 6, 2015 at 1:34 PM, Marc Glisse wrote:
> Hello,
>
> as discussed around
> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00041.html
> we are currently guessing the type of a?b:c incorrectly. This does not
> affect current simplifications, because the only 'cond' in output patterns
> are
On Sat, Jun 6, 2015 at 3:14 AM, Alexandre Oliva wrote:
> On Apr 27, 2015, Richard Biener wrote:
>
>> This should also mention that is_gimple_reg vars do not have their
>> address taken.
>
> check
>
>>> +static tree
>>> +leader_merge (tree cur, tree next)
>
>> Ick - presumably you can't use sth be
On Thu, Jun 4, 2015 at 5:02 PM, Tom de Vries wrote:
> On 22/05/15 11:27, Richard Biener wrote:
>>
>> On Thu, May 21, 2015 at 5:36 PM, Thomas Schwinge
>> wrote:
>>>
>>> Hi!
>>>
>>> It's just been a year. ;-P
>>>
>>> In early March, I (hopefully correctly) adapted Tom's patch to apply to
>>> then-
On Thu, Jun 4, 2015 at 4:42 PM, Tom de Vries wrote:
> On 04/06/15 15:20, Tom de Vries wrote:
>>
>> Hi,
>>
>> [ posted earlier as part of "Don't dump low gimple functions in gimple
>> dump", https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01586.html,
>> currently discussed at:
>> https://gcc.gnu.org/
Hi Aldy,
On 7 Jun 2015, at 12:37, Aldy Hernandez wrote:
> On 06/07/2015 06:19 AM, Andreas Schwab wrote:
>> Another fallout:
>>
>> FAIL: obj-c++.dg/try-catch-5.mm -fgnu-runtime (test for excess errors)
>> Excess errors:
>> : warning: '_OBJC_Module' defined but not used [-Wunused-variable]
>
> ch
On Wed, Jun 3, 2015 at 11:55 PM, Alexandre Oliva wrote:
> On Feb 25, 2015, Alexandre Oliva wrote:
>
>> This patch fixes a problem that has been with us for several years.
>> Variable tracking has no idea about the end of the lifetime of inlined
>> variables, so it keeps on computing locations for
On Wed, Jun 3, 2015 at 3:26 PM, Jan Kratochvil
wrote:
> On Wed, 03 Jun 2015 10:25:20 +0200, Richard Biener wrote:
>> gdb 7.9, python 2.7.6
>
> attaching a fix; I do not know much Python so check it, please.
>
> OK for check-in?
Python Exception global name 'sys' is not defined:
Python Exception
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > > + bp_pack_value (bp, loc == BUILTINS_LOCATION, 1);
> > > + if (loc == BUILTINS_LOCATION)
> > > +return;
> >
> > Hmm, with this and
> >
> > #define DECL_IS_BUILTIN(DECL) \
> > (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION)
> > + bp_pack_value (bp, loc == BUILTINS_LOCATION, 1);
> > + if (loc == BUILTINS_LOCATION)
> > +return;
>
> Hmm, with this and
>
> #define DECL_IS_BUILTIN(DECL) \
> (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION)
>
> shouldn't we rather stream all locations <= BUILTIN
1 - 100 of 103 matches
Mail list logo
