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
On Sat, Nov 23, 2013 at 8:23 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 parts without have to go through
> the entire patch.This patch covers the tree-saa code.
>
> Ok?
Same comments as to
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng Zhang wrote:
> Hi Bill,
>
>
> On 11/13/13 20:54, Bill Schmidt wrote:
>>
>> Hi Yufeng,
>>
>> The second version of your original patch is ok with me with the
>> following changes. Sorry for the little side adventure into the
>> next-interp logic; in the end
Hi,
The patch addresses the issue Jan-Benedict's buildrobot found:
http://gcc.gnu.org/ml/gcc/2013-11/msg00507.html
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7704433..da9a3e2 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2013-11-26 Alexander Ivchenko
+
+ * confi
On 26/11/13 09:18, 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 about this but if
This fixes PR59245 by more carefully dropping TREE_OVERFLOW
inside VRP (where formerly we only dropped TREE_OVERFLOW from
infinities). It also adds checking ...
Bootstrapped on x86_64-unknown-linux-gnu, 2nd version in
testing (if that doesn't succeed I'm going to remove the new
checking again).
On 26/11/13 12:29, Yufeng Zhang wrote:
> 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-assoc
This fixes PR59288 - re-analyzing via SCEV after performing some
loop transform is fragile - we have STMT_VINFO_LOOP_PHI_EVOLUTION_PART
to avoid doing this. The following applies this also to induction.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-11-26 Richard
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
> On 26/11/13 09:18, 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
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, 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 i
On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
wrote:
> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
>> On 26/11/13 09:18, 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
> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>
> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
> wrote:
>> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
>>> On 26/11/13 09:18, Eric Botcazou wrote:
> you are correct - this was an incorrect change. I believe that the
>
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
wrote:
>
> On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
>>
>> On 26/11/13 09:18, 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
On Tue, Nov 26, 2013 at 6:03 AM, wrote:
>
>
>> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>>
>> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
>> wrote:
>>> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
>> you are correct - this w
On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu wrote:
> On Tue, Nov 26, 2013 at 6:03 AM, wrote:
>>
>>
>>> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>>>
>>> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
>>> wrote:
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
> On 26/11/13
Hi Joseph/Jakub,
Attached is Version 2 patch that adds machine descriptions for stack
protection in Aarch64. I have removed the incorrect test case changes
from the previous patch.
To make GCC compatible with glibc, I have added a test for aarch64 in
"GCC/configure".
This tests for the glibc vers
Hi all,
In the spirit of stage3, this patch fixes a regression in
gcc.target/arm/negdi-2.c when compiling for big-endian with the new rtx costs
for the Cortex-A9. We ended up generating an extra mov because combine generates
a zero-extend operation that would later get split into two moves (ve
On Mon, Nov 25, 2013 at 4:29 PM, Kugan
wrote:
>
> +2013-11-26 Kugan Vivekanandarajah
> +
> + * libgcc/libgcc2.c (__udivmoddi4): Define new implementation when
> + TARGET_HAS_NO_HW_DIVIDE is defined, for processors without any divide
> + instructions.
> +
>
>
> +2013-11-26 Kug
On 26/11/13 14:16, Venkataramanan Kumar wrote:
> Index: gcc/testsuite/gcc.dg/fstack-protector-strong.c
> ===
> --- gcc/testsuite/gcc.dg/fstack-protector-strong.c(revision 205378)
> +++ gcc/testsuite/gcc.dg/fstack-protector-strong.c
On 26/11/13 14:49, Kyrill Tkachov wrote:
> Hi all,
>
> In the spirit of stage3, this patch fixes a regression in
> gcc.target/arm/negdi-2.c when compiling for big-endian with the new rtx costs
> for the Cortex-A9. We ended up generating an extra mov because combine
> generates
> a zero-extend
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng Zhang wrote:
Hi Bill,
On 11/13/13 20:54, Bill Schmidt wrote:
Hi Yufeng,
The second version of your original patch is ok with me with the
following changes. Sorry for the little side adventure into the
next-i
On 23/11/13 01:54, Kugan wrote:
> Hi All,
>
> This RFC patch enables new divide algorithm for ARMV7-A
>
> Regression tested on arm-none-linux-gnueabi with no issues.
>
> OK?
>
> Thanks,
> Kugan
>
> +2013-11-22 Kugan Vivekanandarajah
> +
> + * libgcc/config/arm/pbapi-lib.h (HAVE_NO_HW_DI
On Tue, Nov 26, 2013 at 12: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 Ste
On 11/26/2013 09:12 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
wrote:
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but
Hi,
On Wed, 20 Nov 2013, Jeff Law wrote:
> > There are three places the patch doesn't touch:
> >
> > (A) cfgbuild.c (make_edges) has this comment:
> >/* By nature of the way these get numbered, ENTRY_BLOCK_PTR->next_bb
> > block
> > is always the entry. */
> > where the meaning wasn't
On 11/26/2013 09:16 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu wrote:
On Tue, Nov 26, 2013 at 6:03 AM, wrote:
On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
wrote:
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw
Hi,
this patch fixes a reported issue for windows targets in winnt.c.
This is a classical C++ related warning issue.
ChangeLog
2013-11-26 Kai Tietz
* config/i386/winnt.c (i386_pe_section_type_flags): Use const
pointer cast.
I will apply soon, if there are no objections.
Reg
On 11/26/2013 05:40 AM, Paolo Carlini wrote:
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 t
On 11/26/13 08:21, Diego Novillo wrote:
On Tue, Nov 26, 2013 at 12: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
Richi,
patch ping
also two more pieces of information.With further testing, this seems
to fix
Tests that now work, but didn't before:
===
ext/random/hypergeometric_distribution/operators/values.cc (test for
excess errors)
New tests that PASS:
ext/random/hypergeometric_dist
Hi,
On 11/26/2013 04:30 PM, Jason Merrill wrote:
A BASELINK isn't useful as a constant, either; I was thinking of the
FUNCTION_DECL itself. Perhaps
gcc_checking_assert (!really_overloaded_fn
return get_first_fn
We have got a bunch of testcases, for example constexpr-ex4.C - attached
for your
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Tuesday, November 26, 2013 11:31 AM
> To: Diego Novillo; Steven Bosscher; gcc-patches
> Subject: Re: gcc's obvious patch policy
>
> On 11/26/13 08:21, Diego
Hi Jeff et al.,
Did you get a chance to look at my _Cilk_for patch for C?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Monday, November 18, 2013 4:51 PM
> To: Aldy Hernandez
> Cc: gcc-patches@gcc.gnu.org; Jeff Law; Jason Merrill (ja...@redhat.com);
On Tue, Nov 26, 2013 at 05:14:22PM +, Iyer, Balaji V wrote:
>
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Jeff Law
> > Sent: Tuesday, November 26, 2013 11:31 AM
> > To: Diego Novillo; Steven Bosscher; gcc-pa
> Can I make a suggestion that if someone is making an "obvious" change (with
> the exception of changing non-working code (comments, things inside #if 0,
> etc)), have a patch on the mailing list for 12-24 hrs. before putting it
> in? Maybe they could say something like, I will check this in by X
On 26/11/13 17:14, Iyer, Balaji V wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Jeff Law
>> Sent: Tuesday, November 26, 2013 11:31 AM
>> To: Diego Novillo; Steven Bosscher; gcc-patches
>> Subject: Re: gcc's
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Tuesday, November 26, 2013 12:33 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Diego Novillo; Jeff Law; Steven Bosscher
> Subject: Re: gcc's obvious patch policy
>
> > Can I make a suggestion that
On Tue, Nov 26, 2013 at 12:40 PM, Iyer, Balaji V
wrote:
>
>
>> -Original Message-
>> From: Eric Botcazou [mailto:ebotca...@adacore.com]
>> Sent: Tuesday, November 26, 2013 12:33 PM
>> To: Iyer, Balaji V
>> Cc: gcc-patches@gcc.gnu.org; Diego Novillo; Jeff Law; Steven Bosscher
>> Subject: Re
Hi,
When unwinding the stack, the unwind code checks for two opcodes that
denote a registrations of a signal handler. This is broken on BE as
the opcodes will be in the wrong byte-order as insns are always LE.
Add the correct checks when compiling for AArch64 big endian.
This has been tested wit
> I had not realized that you were into self abuse like that. you are
> going to have a bad time. I tried this as a way to test the wide-int
> branch because if we made hwi be 32bits, then it would trigger the long
> version of the implementation wide-int routines. What a disaster
> richar
This patch from Michael Hudson-Doyle fixes the value of
SizeofSockaddrAny in the syscall package. I'm not sure where the
incorrect value came from. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.8 branch.
Ian
diff -r 8f2a489c6452 -r bcd0cf1ac784 libg
This patch changes the Go frontend so that if a type is defined in terms
of another named type, the hash and equality functions are simply
forwarded to that other type. Without this, programs could fail to link
if the other named type is defined in some other package and uses
unexported types defi
On 11/26/13 05:59, Alexander Ivchenko wrote:
Hi,
The patch addresses the issue Jan-Benedict's buildrobot found:
http://gcc.gnu.org/ml/gcc/2013-11/msg00507.html
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7704433..da9a3e2 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+201
On 11/26/2013 11:43 AM, Paolo Carlini wrote:
We have got a bunch of testcases, for example constexpr-ex4.C - attached
for your convenience - which trigger the assert !really_overloaded_fn
(t) ... What do you suggest?
Aha. Well, in that case we really can't get a constant value, so I'd
assert
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 because other passes wi
On Tue, Nov 26, 2013 at 9:52 AM, Matthew Leach wrote:
> Hi,
>
> When unwinding the stack, the unwind code checks for two opcodes that
> denote a registrations of a signal handler. This is broken on BE as
> the opcodes will be in the wrong byte-order as insns are always LE.
>
> Add the correct chec
Hello!
2013-11-26 Uros Bizjak
* gcc.dg/gomp/openmp-simd-1.c: Cleanup original tree dump.
* gcc.dg/gomp/openmp-simd-2.c: Ditto.
* g++.dg/gomp/openmp-simd-1.C: Ditto.
* g++.dg/gomp/openmp-simd-2.C: Ditto.
* gfortran.dg/c_loc_test_22.f90: Ditto.
* gcc.dg/tree-ssa/attr-alia
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 as unused
and the GCmemory was reused for
Hi!
Uros has reported my optimize_vector_constructor optimization causes
problems on Alpha which for some vector modes supports only moves, but not
arithmetics. The following patch fixed that in a cross compiler,
and has been bootstrapped/regtested on x86_64-linux and i686-linux.
Ok for trunk?
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, ok for trunk?
Though, the resulting cod
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 pseudo. But it
uses DF_REF_LOC, which is ad
1 - 100 of 154 matches
Mail list logo
