Hi!
If collapse_bb != NULL, then cont_bb isn't a latch of schedule(static,C)
collapse(N) omp for loops, and the latch for simd loops was only correct
if the loop contained just two basic blocks and not more.
Fixed thusly, bootstrapped/regtested on x86_64-linux, committed to trunk.
2013-11-26 Ja
Hi!
The problem here is that lower_rec_input_clauses for privatized reference
vars in clauses adds u = &u.1; statements, which is usually the right thing,
but if this is a reduction in simd loop for which we are going to handle
using simd arrays, then we want to set DECL_VALUE_EXPR of the var to
s
Hi!
The problem on this testcase was that
start_preparsed_function called maybe_begin_member_template_processing
but finish_function wasn't called with matching flag and thus
didn't call maybe_end_member_template_processing and we ended up with
processing_template_decl even when it shouldn't be se
On 11/26/13 13:34, Steven Bosscher wrote:
On Tue, Nov 26, 2013 at 9:25 PM, Jakub Jelinek wrote:
\> PR rtl-optimization/59166
* ira.c (find_moveable_pseudos): Use DF_REF_REAL_LOC instead of
DF_REF_LOC in validate_change call.
(split_live_ranges_for_shrink_wrap):
On Nov 25, 2013, at 9:17 PM, Alan Modra wrote:
> Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR
> On Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote:
>> This patch is obvious and it fixes breakage. Please go ahead and commit it.
>
> Sorry to pick on you here Steven,
On Nov 26, 2013, at 11:39 AM, Uros Bizjak wrote:
>* gcc.dg/gomp/openmp-simd-1.c: Cleanup original tree dump.
Thanks.
On 26-11-13 11:12, Richard Biener wrote:
On Tue, Nov 26, 2013 at 8:57 AM, Tom de Vries wrote:
Jason,
This patch prevents creating out-of-bounds BIT_FIELD_REFs in 3 locations.
It fixes a SIGSEGV (triggered by gimple_fold_indirect_ref_1) in
simplify_bitfield_ref. I've added an assert to detect
On 11/26/13 13:33, Jakub Jelinek wrote:
Hi!
Given:
_6 = (_Bool) a.1_5;
_7 = _4 | _6;
if (_7 != 0)
goto ;
else
goto ;
where a.1_5 has int type and _6/_4/_7 are _Bool, register_edge_assert_for_1
happily inserts:
:
a.1_14 = ASSERT_EXPR ;
assertion, which is wrong, the fa
On 11/26/13 13:20, Jakub Jelinek wrote:
Hi!
As the testcase in the patch shows, if exact memcpy or memset count
is unknown, but max_size is smaller than epilogue_size_needed,
ix86_expand_set_or_movmem can ICE.
The following patch fixes that, bootstrapped/regtested on x86_64-linux
and i686-linux
On 11/26/13 13:25, Jakub Jelinek wrote:
Hi!
The problem on this testcase is that we have
(debug_insn 30 29 31 7 (var_location:HI D#1 (subreg:HI (reg/v:SI 93 [ p ]) 0))
pr59166.c:20 -1
(nil))
and split_live_ranges_for_shrink_wrap decides to replace
SImode pseudo 93 with some other SImode p
On 11/26/13 13:14, Jakub Jelinek wrote:
Hi!
The problem here is that ubsan_create_data was called
with location_t that includes both location and BLOCK, and that
location was sticked into an ADDR_EXPR in a static var's constructor.
As the BLOCk wasn't live in any of the functions, it was removed
Hi Jakub,
Did you get a chance to look at this patch? Is it Ok to install?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Tuesday, November 19, 2013 5:09 PM
> To: Jakub Jelinek
> Cc: Joseph S. Myers; gcc-patches@gcc.gnu.org; Aldy Hernandez
> (al...@re
>> Sorry to pick on you here Steven, but this doesn't meet gcc's
>> definition of an obvious patch. Don't believe me?
> No. I don't, let me quote from the policy:
I find this whole thread a rather sad and pathetic bikeshed
discussion. Regardless of the formal policy, the basic concept is to
use
On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
> 5) rs6000_aggregate_candidate, is this change correct for Ada and
> non-constant type size?
No. It was merely an oversight in converting the code.
I've analyzed it, and think that we can speed up Ada and VLAs by keeping all
the checks for t
On 11/26/13 02:58, Richard Biener wrote:
What is the rationale behind one for over the other? Or is it arbitrary? I
can easily make a case for either form based on what we're trying to
optimize. In general, it seems to me that
When (Type) is a widening cast then you have to worry to not
On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
> 2) non_logical_cint_operand changed const_double to const_wide_int, it
> did not add the additional CODE. Mike explained why in a private
> conversation, but the ChangeLog should be corrected.
Index: gcc/ChangeLog.wide-int
To me the issue is not what is written down about
the policy, but whether the policy works in practice,
and it seems like it does, so what's the problem?
This just seems to be making a problem where
none exists.
> On 11/26/13 13:20, Jakub Jelinek wrote:
> >Hi!
> >
> >As the testcase in the patch shows, if exact memcpy or memset count
> >is unknown, but max_size is smaller than epilogue_size_needed,
> >ix86_expand_set_or_movmem can ICE.
> >
> >The following patch fixes that, bootstrapped/regtested on x86_64
On Nov 26, 2013, at 3:58 AM, Richard Sandiford
wrote:
> Mike Stump writes:
>> On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
>>> 3) altivec_resolve_overloaded_builtin, both hunks should be converted
>>> the same way, using tree_fits_uhwi_p
>>>
>>> - && TREE_CODE (arg2) == INTEGER_CST
>>
On 11/26/13 02:26, Richard Biener wrote:
But only necessary if this threading returned true, no?
Correct. Fix for that spinning overnight.
Also
how "likely" did it scramble the loop? I see that thread_block_1
already cancels loops in some cases so I wonder what case
it misses so that you n
On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
> Thanks for doing this conversion work. A few questions and comments:
>
> 1) Because rs6000 is one of the few ports that was completely
> converted to wide-int instead of simply accommodating wide-int, what
> is the compile-time performance im
This patch does two things:
1) The hash table should consume VAR_DECLs rather than ADDR_EXPRs; the
latter allegedly cannot be shared between different locations.
2) Sometimes it can happen that some earlier instrumentation (e.g.
-fsanitize=shift) creates an .Lubsan_type, but later on
varp
This patch to libgo fixes the handling of surrogate pairs when
converting a []rune value to string. Invalid surrogate pair values
should become the replacement character in the string, as otherwise the
string will not be valid UTF-8. I have a patch ready for the master Go
testsuite after the 1.2
On Wed, Nov 27, 2013 at 12:26:08AM +0100, Marek Polacek wrote:
> Ran the testsuite on x86_64-linux. Ok for trunk?
Ok, with a minor nit.
> --- gcc/testsuite/c-c++-common/ubsan/undefined-1.c.mp32013-11-26
> 23:56:42.151624262 +0100
> +++ gcc/testsuite/c-c++-common/ubsan/undefined-1.c2
On Wed, Nov 27, 2013 at 12:31:18AM +0100, Jakub Jelinek wrote:
> Please use here:
> int z = 2;
> if (z & 1)
> or similar instead, to make sure it is only early
> GIMPLE optimization passes that optimize it away, if already the
> front end knows it isn't needed, perhaps in the future it could
>
On Tue, Nov 26, 2013 at 5:46 PM, Mike Stump wrote:
> Ok?
The revised version of the patch looks okay from a technical
perspective, but I still am concerned about the compile-time impact. I
thought that I saw a comment on IRC that wide-int seems to have a 3-5%
compile time impact, which is a conc
On 11/26/2013 03:47 AM, Marc Glisse wrote:
On Tue, 26 Nov 2013, Tom de Vries wrote:
* g++.dg/pr59032.C: New testcase.
* gcc.dg/pr59032.c: Same.
I didn't check very carefully, but they look similar. If they are indeed
the same, could it move to c-c++-common?
OK with that change.
Jas
This patch updates libgo to the current Go library sources, which will
almost certainly be the Go library included in the Go 1.2 release.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 827fb5004620 libgo/MERGE
--- a/libgo/MERGE Tue Nov 26 15:22:1
We will of course measure it but the only thing that is different because of
the conversion is that timode integers are packaged differently
> On Nov 26, 2013, at 6:17 PM, David Edelsohn wrote:
>
>> On Tue, Nov 26, 2013 at 5:46 PM, Mike Stump wrote:
>>
>> Ok?
>
> The revised version of the
On Tue, Nov 26, 2013 at 04:30:50PM -0500, David Edelsohn wrote:
> >> Sorry to pick on you here Steven, but this doesn't meet gcc's
> >> definition of an obvious patch. Don't believe me?
>
> > No. I don't, let me quote from the policy:
>
> I find this whole thread a rather sad and pathetic bikes
On Sun, 2013-11-24 20:02:43 +0100, Jan-Benedict Glaw wrote:
> 2013-11-24 Jan-Benedict Glaw
>
> * config-list.mk (host_options): Allow to override it.
> (LIST): Change "=" to "EQUAL".
> (list): New target listing all configurations.
> ($(LIST)): Substitute "EQUAL" back t
On Tue, Nov 26, 2013 at 04:56:26PM -0500, Robert Dewar wrote:
> To me the issue is not what is written down about
> the policy, but whether the policy works in practice,
> and it seems like it does, so what's the problem?
>
> This just seems to be making a problem where
> none exists.
I gave some
> The thing about written policy is that it sets the tone for a project.
> A restrictive policy tends to authoritarian rule by maintainers, it
> seems to me.
And a too little restrictive policy runs the risk of creating a
feeling that the rules aren't necessarily to be taken too seriously.
Neithe
I've merged revision 205426 from GCC mainline to the gccgo branch.
Ian
On Mon, 2013-11-25 at 12:34 -0700, Jeff Law wrote:
> On 11/25/13 08:35, David Malcolm wrote:
> >
> > I'm not a fan of these "_layout" names, but I'm not sure what better to
> > call them. Perhaps:
> > GSS_OMP_PARALLEL_LAYOUT -> GSS_OMP_WITH_CLAUSES_CHILD_FN_DATA_ARG
> > GSS_OMP_SINGLE_L
On Tue, Nov 26, 2013 at 8:37 PM, Alan Modra wrote:
>> I find this whole thread a rather sad and pathetic bikeshed
>> discussion. Regardless of the formal policy, the basic concept is to
>> use common sense. Common sense about the context of the code being
>> changed, common sense about the patch
Google ref b/11631232
With AutoFDO, the .gnu.callgraph sections are not emitted with option
-freorder-functions=callgraph. This simple patch fixes it.
Index: final.c
===
--- final.c (revision 205418)
+++ final.c (working copy)
@@ -44
Ok.
David
On Tue, Nov 26, 2013 at 6:44 PM, Sriraman Tallam wrote:
> Google ref b/11631232
>
> With AutoFDO, the .gnu.callgraph sections are not emitted with option
> -freorder-functions=callgraph. This simple patch fixes it.
>
> Index: final.c
> ==
Hi,
This patch back ported trunk fix at r205391 to arm/embedded-4_8-branch.
BR,
Terry
gcc/ChangeLog.arm
2013-11-27 Terry Guo
Backport mainline r205391
2013-11-26 Terry Guo
* config/arm/arm.c (require_pic_register): Handle high pic base
register for thumb-1
On 27/11/13 02:07, Richard Earnshaw wrote:
> On 23/11/13 01:54, Kugan wrote:
[snip]
>> +2013-11-22 Kugan Vivekanandarajah
>> +
>> +* libgcc/config/arm/pbapi-lib.h (HAVE_NO_HW_DIVIDE): Define for
>
> It's bpabi-lib.h
Thanks for the review.
>> +__ARM_ARCH_7_A__.
>> +
>>
>>
>
> No, th
On 11/26/13 12:33, Wei Mi wrote:
On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
Doing the cleanup at the end of BB could ensure all the groups
inserted for macrofusion will be cleaned. For groups not at the end of
a block, no matter whether they are cleaned up or not, nothing will
happen b
On 11/25/13 17:29, Kugan wrote:
On 24/11/13 02:14, Ian Lance Taylor wrote:
Kugan writes:
This RFC patch series implements a simple align divisor shift dividend
method.
Regression tested on arm-none-linux-gnueabi with no issues.
OK?
Thanks,
Kugan
+2013-11-22 Kugan Vivekanandarajah
+
+
On 11/22/13 15:24, Eric Botcazou wrote:
Well, the baseline is:
eric@polaris:~/build/gcc/native> gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc/configure --build=x86_64-suse-linux --
prefix=/home/eric/install/gcc --enable-langu
On 11/26/13 14:10, Tom de Vries wrote:
On 26-11-13 11:12, Richard Biener wrote:
On Tue, Nov 26, 2013 at 8:57 AM, Tom de Vries
wrote:
Jason,
This patch prevents creating out-of-bounds BIT_FIELD_REFs in 3
locations.
It fixes a SIGSEGV (triggered by gimple_fold_indirect_ref_1) in
simplify_bitfi
> This patch is supposed to fix PR59063
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
>
> The original bug results from libasan providing clock_gettime wrapper
and then trying to call the "real" clock_gettime.
> The "real" symbol is supposed to come from librt.so which was not
necessaril
> Hopefully someone from AMD will provide tests that are mysteriously missing
> from XOP testsuite.
As pointed out by Marc, I added myself to the bug later.
I was bit confused about the "internal insn representation" with "user-visible
function".
So, couldn't add test then and there. I could ha
On Tue, Nov 26, 2013 at 9:34 PM, Jeff Law wrote:
> On 11/26/13 12:33, Wei Mi wrote:
>>
>> On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
>>>
>>>
Doing the cleanup at the end of BB could ensure all the groups
inserted for macrofusion will be cleaned. For groups not at the end of
>
On Wed, Nov 27, 2013 at 10:36:41AM +0400, Yury Gribov wrote:
> > This patch is supposed to fix PR59063
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
> >
> > The original bug results from libasan providing clock_gettime
> wrapper and then trying to call the "real" clock_gettime.
> > The "re
Done.
Sergos
On Tue, Nov 26, 2013 at 1:46 PM, Jakub Jelinek wrote:
> On Tue, Nov 26, 2013 at 10:43:32AM +0100, Richard Biener wrote:
>> 2013-11-25 sergey.y.ostanevich
>
> Please use your name with capital letters and spaces rather than
> all lowercase plus dots.
>
> Jakub
2013-11-25
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
> In fact, I would suggest that anyone with a pending patch from prior
> to stage1 close that hasn't gotten feedback by midnight Tuesday ping
> their patch. I'd like to have a sense of everything that is
> outstanding sooner rather than lat
Jason,
This patch handles vector increment/decrement in build_unary_op and
cp_build_binary_op.
In other words, we allow v++ and --v on a vector v.
v + 1 and v - 1 are already allowed.
This fixes an ICE when compiling a vector increment/decrement.
Bootstrapped and reg-tested on x86_64.
OK fo
On Sat, Nov 23, 2013 at 06:38:31PM -0800, Ian Lance Taylor wrote:
> Reportedly in the new PPC ELF v2 ABI calls to varargs functions act
> differently from calls to normal functions.
Thanks for taking an interest in ELFv2 Ian! If you mean by "act
differently" that arguments are passed differently,
Mike Stump writes:
> On Nov 2, 2013, at 3:13 AM, Richard Sandiford
> wrote:
>> I decided to lump these together since the problems were the same.
>> There were some typos in the real_to_integer invocation, while changing:
>>
>> /* There must be no padding. */
>> if (!host_integerp (TY
> My (our) question is, doesn't Ada have non-INTEGER_CST TYPE_SIZE (type), and
> the old code had this type of check:
>
> bool
> tree_fits_uhwi_p (const_tree t)
> {
> return (t != NULL_TREE
> && TREE_CODE (t) == INTEGER_CST
> && TREE_INT_CST_HIGH (t) == 0);
> }
>
> to ensure
On Mon, Nov 25, 2013 at 09:52:47PM +, Richard Sandiford wrote:
> But my point is that at the moment we always have trees for the ranges
> we want to record, so it seems simplest just to store those in the
> structure. I was thinking of something like the attached (only just
> started testing,
On Tue, 26 Nov 2013, Tom de Vries wrote:
* g++.dg/pr59032.C: New testcase.
* gcc.dg/pr59032.c: Same.
I didn't check very carefully, but they look similar. If they are indeed
the same, could it move to c-c++-common?
--
Marc Glisse
On Tue, Nov 26, 2013 at 6:17 AM, Alan Modra wrote:
> Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR
> On Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote:
>> This patch is obvious and it fixes breakage. Please go ahead and commit it.
>
> Sorry to pick on you here Steve
When looking at the code generated for wide-int idioms on the branch
again I noticed that we fail to eliminate quite some dead stores
(on GIMPLE, eventually we recover from that at RTL level - I didn't
check). This is caused by some old special-casing of union
accesses during points-to analysis w
On Mon, Nov 25, 2013 at 12:02 PM, Marek Polacek wrote:
> On Mon, Nov 25, 2013 at 11:47:29AM +0100, Jakub Jelinek wrote:
>> That looks much better, I wonder if it would reproduce even if the result
>> is saved somewhere (either E *e; field in S with swapping of the two class
>> definitions, or glob
On Mon, Nov 25, 2013 at 4:49 PM, Kenneth Zadeck
wrote:
>
> On 11/25/2013 06:04 AM, Richard Biener wrote:
>>
>> On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump wrote:
>>>
>>> Richi has asked the we break the wide-int patch so that the individual
>>> port and front end maintainers can review their part
> you are correct - this was an incorrect change. I believe that the
> patch below would be correct, but it is impossible to test it because (i
> believe) that gcc no longer works if the host_bits_per_wide_int is 32.
> I could be wrong about this but if i am correct, what do you want me to do?
W
On Mon, Nov 25, 2013 at 6:12 PM, Jan Hubicka wrote:
> Hi,
> I am looking into testcases for individual code paths of ipa-devirt and my
> life
> would be much easier if gimple-fold did not take some of them by old code.
> This patch also improves code by doing devirtualization earlier in the game
On Tue, Nov 26, 2013 at 10:13:35AM +0100, Richard Biener wrote:
> On Mon, Nov 25, 2013 at 12:02 PM, Marek Polacek wrote:
> > On Mon, Nov 25, 2013 at 11:47:29AM +0100, Jakub Jelinek wrote:
> >> That looks much better, I wonder if it would reproduce even if the result
> >> is saved somewhere (either
On Mon, Nov 25, 2013 at 7:25 PM, Jeff Law wrote:
> On 11/22/13 08:56, Richard Biener wrote:
>>
>>
>>> So the issue here is we can create irreducible regions & new nested
>>> loops. Does just setting the header,latch fields for the current loop
>>> handle those cases?
>>
>>
>> Yes.
>
> Fixed via t
[ Fix email address Marc ]
On 26-11-13 08:57, Tom de Vries wrote:
Jason,
This patch prevents creating out-of-bounds BIT_FIELD_REFs in 3 locations.
It fixes a SIGSEGV (triggered by gimple_fold_indirect_ref_1) in
simplify_bitfield_ref. I've added an assert to detect the problematic
BIT_FIELD_REF
On Mon, Nov 25, 2013 at 9:05 PM, Richard Sandiford
wrote:
> Jason Merrill writes:
>> On 11/23/2013 02:20 PM, Mike Stump wrote:
>>> @@ -2605,8 +2606,7 @@ cp_tree_equal (tree t1, tree t2)
>>> switch (code1)
>>> {
>>> case INTEGER_CST:
>>> - return TREE_INT_CST_LOW (t1) == TREE_
Hi,
This backport intends to enable new arm rtx cost model in trunk for
embedded-4_8-branch. The backport incorporates all relevant trunk commits
and some minor tweaks for embedded-4_8-branch. Tested with gcc regression
test and found one regression related to case pr42575.c. The upstream gcc
has
On 26/11/13 04:18, Terry Guo wrote:
> Hi,
>
> This patch intends to fix ICE when high register is used for pic base
> register for thumb1 target. Tested with gcc regression test, no new
> regressions. Is it OK to trunk?
>
> BR,
> Terry
>
> gcc/ChangeLog:
>
> 2013-11-26 Terry Guo
>
>
On Mon, 25 Nov 2013, Sergey Ostanevich wrote:
> Updated patch with spaces, etc according to check_GNU_style.sh
>
> Put guard as per Tobias' request.
>
> Is it Ok?
See inline comments below (and Tobias mail).
>
>
> On Thu, Nov 21, 2013 at 6:18 PM, Sergey Ostanevich
> wrote:
> > Tobias,
> >
Ping?
Thanks,
Kyrill
On 19/11/13 17:04, Kyrill Tkachov wrote:
On 19/11/13 16:26, Joseph S. Myers wrote:
In any target header installed for user use, such as arm_acle.h, you need
to be namespace-clean. In this case, that means you need to use
implementation-namespace identifiers such as __a, _
On Tue, Nov 26, 2013 at 10:43:32AM +0100, Richard Biener wrote:
> 2013-11-25 sergey.y.ostanevich
Please use your name with capital letters and spaces rather than
all lowercase plus dots.
Jakub
On 22 November 2013 15:11, James Greenhalgh wrote:
> gcc/
>
> 2013-11-22 James Greenhalgh
>
> * config/aarch64/aarch64-builtins.c
> (VAR1): Use new naming scheme for aarch64_builtins.
> (aarch64_builtin_vectorized_function): Use new
> aarch64_builtins names.
O
On 22 November 2013 15:11, James Greenhalgh wrote:
> 2013-11-22 James Greenhalgh
>
> * config/aarch64/aarch64-builtins.c
> (aarch64_type_qualifiers): Add qualifier_poly.
> (aarch64_build_scalar_type): Also build Poly types.
> (aarch64_build_vector_type): Likewis
On 22 November 2013 15:11, James Greenhalgh wrote:
> gcc/
>
> 2013-11-22 James Greenhalgh
>
> * config/aarch64/aarch64-builtins.c
> (aarch64_types_bsl_p_qualifiers): New.
> (aarch64_types_bsl_s_qualifiers): Likewise.
> (aarch64_types_bsl_u_qualifiers): Likewise.
On 22 November 2013 15:11, James Greenhalgh wrote:
> 2013-11-22 James Greenhalgh
>
> * config/aarch64/arm_neon.h (vtbx1_8): Emulate behaviour
> using other intrinsics.
> (vtbx3_8): Likewise.
OK /Marcus
Hi,
On 11/25/2013 10:47 PM, Jason Merrill wrote:
On 11/25/2013 05:02 AM, Paolo Carlini wrote:
because then we don't warn *at all*. The reason being that with the
*first* cp_convert we end up calling c_common_truthvalue_conversion with
c_inhibit_evaluation_warnings bumped. The bumping happens in
On Tue, Nov 26, 2013 at 8:00 AM, Jeff Law wrote:
> On 11/22/13 18:43, Kai Tietz wrote:
>>
>> - Original Message -
>>
>> That is actual wished. We shouldn't come to patterns, which have more
>> type-casts by this patch.
>> What we see here is the normalization of shift-left/right operation
On Tue, Nov 26, 2013 at 9:43 AM, Jakub Jelinek wrote:
> On Mon, Nov 25, 2013 at 09:52:47PM +, Richard Sandiford wrote:
>> But my point is that at the moment we always have trees for the ranges
>> we want to record, so it seems simplest just to store those in the
>> structure. I was thinking o
On Tue, Nov 26, 2013 at 10:18 AM, Eric Botcazou wrote:
>> you are correct - this was an incorrect change. I believe that the
>> patch below would be correct, but it is impossible to test it because (i
>> believe) that gcc no longer works if the host_bits_per_wide_int is 32.
>> I could be wrong a
On Tue, Nov 26, 2013 at 8:57 AM, Tom de Vries wrote:
> Jason,
>
> This patch prevents creating out-of-bounds BIT_FIELD_REFs in 3 locations.
>
> It fixes a SIGSEGV (triggered by gimple_fold_indirect_ref_1) in
> simplify_bitfield_ref. I've added an assert to detect the problematic
> BIT_FIELD_REF th
On 26/11/13 10:07, Charles Baylis wrote:
> Updated version. Only build tested.
>
> PR target/59142
> gcc/
> * arm/predicates.md (arm_hard_general_register_operand): New
> predicate.
> (vfp_hard_register_operand): Likewise.
> * config/arm/arm-ldmstm.ml: Use
On Sun, Oct 27, 2013 at 5:01 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
>> Finally I think the recursion into the VIEW_CONVERT_EXPR case
>> is only there because of the keep_aligning flag of get_inner_reference
>> which should be obsolete now that we pr
On Fri, Nov 22, 2013 at 2:50 PM, H.J. Lu wrote:
> Toplevel configure supports:
>
> # Handle --enable-gold, --enable-ld.
> # --disable-gold [--enable-ld]
> # Build only ld. Default option.
> # --enable-gold [--enable-ld]
> # Build both gold and ld. Install gold as "ld.gold", install ld
>
Hi,
On 11/23/2013 11:35 PM, Jason Merrill wrote:
On 10/20/2013 12:07 PM, Paolo Carlini wrote:
case COMPONENT_REF:
+ if (is_overloaded_fn (TREE_OPERAND (t, 1)))
+return t;
Hmm, I'd be inclined to strip the COMPONENT_REF in this case to
produce something that's actually usable as
[plain text version]
Tool-specific actions in the interceptors are disabled when we enter
the symbolizer.
What happens if user app links libbacktrace? An instrumented
libbacktrace? Memory that is allocated internally in sanitizer runtime
is not unpoisoned; for example, asan may consider it unaddr
2013-11-26 Joern Rennecke
* config/epiphany/epiphany.c (epiphany_expand_prologue):
Remove unused variable save_config.
(epiphany_compute_frame_size): Avoid signed/unsigned comparison in
assert.
Index: config/epiphany/epiphany.c
2013/11/25 Jeff Law :
> On 11/25/13 04:12, Ilya Enkovich wrote:
>>
>>
>> I'll prepare a patch to remove committed patches. But the first part
>> of series added new ISA extension support. It is independent from the
>> checker. Should it be OK to keep ISA in trunk?
>
> I think this can/should rea
On 23/11/13 19:19, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the arm port.
>
> Ok?
>
>
> wide-int-arm.diffs.txt
>
>
>
2013/11/26 Ilya Enkovich :
> 2013/11/25 Jeff Law :
>> On 11/25/13 04:12, Ilya Enkovich wrote:
>>>
>>>
>>> I'll prepare a patch to remove committed patches. But the first part
>>> of series added new ISA extension support. It is independent from the
>>> checker. Should it be OK to keep ISA in tru
Hello,
The attached patch is the same as posted in the PR as attachment 31283.
In addition to the testing done by Kaz and Christian, I've also tested
it with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
on rev 205313 with no new
On 23/11/13 19:19, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the aarch64 port.
>
> Ok?
>
>
> wide-int-aarch64.diffs.txt
>
On Tue, Nov 26, 2013 at 03:00:27PM +0400, Evgeniy Stepanov wrote:
> [plain text version]
>
> Tool-specific actions in the interceptors are disabled when we enter
> the symbolizer.
>
> What happens if user app links libbacktrace? An instrumented
> libbacktrace? Memory that is allocated internally
2013/11/21 Uros Bizjak :
> On Wed, Nov 20, 2013 at 5:33 PM, Ilya Enkovich wrote:
CM_MEDIUM has unlimited data size.
i386-opts.h: CM_MEDIUM,/* Assumes code fits in the low 31
bits; data unlimited. */
The x86_64_zext_immediate_operand allows _address_ to be lo
Oleg Endo wrote:
> The attached patch is the same as posted in the PR as attachment 31283.
> In addition to the testing done by Kaz and Christian, I've also tested
> it with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> on
On Tue, Nov 26, 2013 at 12:18 PM, Ilya Enkovich wrote:
> 2013/11/26 Ilya Enkovich :
>> 2013/11/25 Jeff Law :
>>> On 11/25/13 04:12, Ilya Enkovich wrote:
I'll prepare a patch to remove committed patches. But the first part
of series added new ISA extension support. It is indep
Mike Stump writes:
> On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
>> 3) altivec_resolve_overloaded_builtin, both hunks should be converted
>> the same way, using tree_fits_uhwi_p
>>
>> - && TREE_CODE (arg2) == INTEGER_CST
>> - && TREE_INT_CST_HIGH (arg2) == 0
>> - && (TREE_INT_CST_L
Ping^2
The patch was posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01523.html
Thanks,
Yufeng
On 11/19/13 11:45, Yufeng Zhang wrote:
Hi Richard,
Can I get an approval or some feedback from you about the patch?
Regards,
Yufeng
On 11/13/13 23:25, Yufeng Zhang wrote:
On 11/13/13 2
On Tue, Nov 26, 2013 at 12:30 PM, Ilya Enkovich wrote:
CM_MEDIUM has unlimited data size.
>
> i386-opts.h: CM_MEDIUM,/* Assumes code fits in the low 31
> bits; data unlimited. */
>
> The x86_64_zext_immediate_operand allows _address_ to be loaded by
> movl. T
Hi,
arm_legitimize_address forces immediates in PLUS to be in REG for no
good reason. This patch changes it not to do this.
With the immediate constants directly available in the RTL, it helps the
expand more effectively to fold and re-associate the immediates.
The change also helps the fo
2013/11/26 Richard Biener :
> On Tue, Nov 26, 2013 at 12:18 PM, Ilya Enkovich
> wrote:
>> 2013/11/26 Ilya Enkovich :
>>> 2013/11/25 Jeff Law :
On 11/25/13 04:12, Ilya Enkovich wrote:
>
>
> I'll prepare a patch to remove committed patches. But the first part
> of series added
1 - 100 of 154 matches
Mail list logo
