The test case exposes a bug that occurs only when a diamond control flow
pattern has the arguments of the joining phi in a different order from
the successor arcs of the entry block. My logic for setting
bb_for_def[12] was just brain-dead. This cleans that up and also
prevents wasting time examin
On 06/17/2012 09:28 AM, Markus Trippelsdorf wrote:
> On 2012.05.29 at 19:07 +, Joseph S. Myers wrote:
>> On Tue, 29 May 2012, Meador Inge wrote:
>>
>>> 2012-05-29 Meador Inge
>>>
>>> * c-decl.c (c_push_function_context): Always create a new language
>>> function.
>>> (c_pop_func
OK for 4.6?
2012-06-18 Joey Ye
Backport from mainline
2011-10-14 David Alan Gilbert
PR target/48126
* config/arm/arm.c (arm_output_sync_loop): Move label before
barrier.
Index: gcc/config/arm/arm.c
==
Hello Everyone,
I missed one case where bug comes up again. This patch should fix that.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Iyer, Balaji V [mailto:balaji.v.i...@intel.com]
Sent: Friday, June 15, 2012 3:37 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH][Cilkplus]PR 5
Hello!
gcc.target/i386/pr33329.c is fully optimized with tree optimizers to a
constant. Attached patch increases array size to avoid
over-optimization and to perform intended RTL optimization check.
2012-06-17 Uros Bizjak
* gcc.target/i386/pr33329.c (f): Increase tabs array to 1024.
On Thu, 14 Jun 2012, Richard Earnshaw wrote:
> This patch removes the command line options that enabled generation of
> FPA and maverick instructions, along with their associated documentation.
>
> * arm.opt (mfp=2, mfp=3, mfpe, mfpe=2, mfpe=3): Delete options.
> * arm-fpus.def (fpa, f
Updated patch: After fixing two small errors, the patch also fixes PR
47710 (test case added).
Still regtesting cleanly ...
Cheers,
Janus
2012-06-17 Janus Weil
PR fortran/47710
PR fortran/53328
* interface.c (count_types_test,generic_correspondence,
gfc_compa
Richard Henderson writes:
> On 2012-06-16 00:45, Richard Sandiford wrote:
>> [(mem:GPR (match_operand:P 1 "register_operand" "d"))]
>>
>>Instead, we should define a new memory predicate/constraint pair
>>for memories that only accept register addresses. I.e. there
>>should be a
On Tue, Jun 12, 2012 at 8:45 AM, H.J. Lu wrote:
> On Mon, Jun 11, 2012 at 1:37 PM, William J. Schmidt
> wrote:
>> OK, once more with feeling... :)
>>
>> This patch differs from the previous one in two respects: It disables
>> the optimization when either the then or else edge is well-predicted;
On Sun, Jun 17, 2012 at 8:37 PM, Uros Bizjak wrote:
> Hello!
>
> Please note that you will probably hit PR33329, this is the reason
> that we expand multiplications after reload. Please see [1] for
> further explanation. There is gcc.target/i386/pr33329.c test to cover
> this issue, but it is not
Hello!
Please note that you will probably hit PR33329, this is the reason
that we expand multiplications after reload. Please see [1] for
further explanation. There is gcc.target/i386/pr33329.c test to cover
this issue, but it is not effective anymore since the simplification
happens at tree level
On Thu, Jun 14, 2012 at 6:38 PM, Easwaran Raman wrote:
> The conditional dead call elimination pass shrink wraps certain dead
> calls to math functions. It doesn't handle case like this:
>
> D.142420_139 = powD.549 (D.142421_138, D.142419_132);
> fooD.120935.barD.113815 = D.142420_139;
> # foo.ba
On 2012-06-16 00:45, Richard Sandiford wrote:
>[(mem:GPR (match_operand:P 1 "register_operand" "d"))]
>
>Instead, we should define a new memory predicate/constraint pair
>for memories that only accept register addresses. I.e. there
>should be a new predicate to go alongside th
Hi Tobias,
> Two rather simple patches.
>
> Build and regtested on x86-64-linux.
> As one of the issues is a 4.7/4.8 regression:
> OK for the trunk and 4.7?
l'd say ok for both trunk and 4.7.
Thanks for the patches,
Janus
On 2012.05.29 at 19:07 +, Joseph S. Myers wrote:
> On Tue, 29 May 2012, Meador Inge wrote:
>
> > 2012-05-29 Meador Inge
> >
> > * c-decl.c (c_push_function_context): Always create a new language
> > function.
> > (c_pop_function_context): Clear the language function created in
Hello!
2012-06-17 Uros Bizjak
* config/i386/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Use
__builtin_expect when checking for exceptions.
* config/ia64/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32} and ia64-unknown-linux-gnu,
committed t
Hello!
2012-06-17 Uros Bizjak
* config/i386/sse.md (vcvtph2ps): Fix vec_select selector.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN, will
be backported to release branches.
Uros.
Index: config/i386/sse.md
=
On Sun, Jun 17, 2012 at 6:58 AM, Richard Guenther
wrote:
> On Sat, Jun 16, 2012 at 8:47 PM, Gabriel Dos Reis
> wrote:
>> On Sat, Jun 16, 2012 at 3:54 AM, Duncan Sands wrote:
>>> Hi,
>>>
>>>
> If ENABLE_BUILD_WITH_CXX is defined, then GCC itself is built with C++,
> and we want a C++ sign
On Sun, Jun 17, 2012 at 6:55 AM, Richard Guenther
wrote:
> On Fri, Jun 15, 2012 at 5:18 PM, Gabriel Dos Reis
> wrote:
>> On Fri, Jun 15, 2012 at 10:13 AM, Duncan Sands wrote:
>>> Hi Gabriel,
>>>
>> Richard just reminded me that we have two fancy_aborts.
>> Could you tell which one your c
On Sun, Jun 17, 2012 at 10:41 AM, Uros Bizjak wrote:
> Hello!
>
> The testcase still fails on x86_64-pc-linux-gnu with:
>
> FAIL: gcc.dg/tree-ssa/vrp68.c scan-tree-dump-times vrp1 "link_error" 1
>
> since there are two calls to link_error.
Oops. I wonder how I did not see those failures myself .
On Sat, Jun 16, 2012 at 8:47 PM, Gabriel Dos Reis
wrote:
> On Sat, Jun 16, 2012 at 3:54 AM, Duncan Sands wrote:
>> Hi,
>>
>>
If ENABLE_BUILD_WITH_CXX is defined, then GCC itself is built with C++,
and we want a C++ signature for functions. If it is not defined, then
GCC itself is
On Fri, Jun 15, 2012 at 5:18 PM, Gabriel Dos Reis
wrote:
> On Fri, Jun 15, 2012 at 10:13 AM, Duncan Sands wrote:
>> Hi Gabriel,
>>
> Richard just reminded me that we have two fancy_aborts.
> Could you tell which one your code is indirectly using?
the one installed as p
On Fri, 15 Jun 2012, Richard Henderson wrote:
> ... but not actually fixing it.
>
> I was hoping that the first patch might give the vectorizer enough
> info to solve the costing problem, but no such luck. Nevertheless
> it would seem that not having the info present at all would be a
> bit of a
Hi all,
here is a patch which concerns the ambiguity checking of generic TBPs,
where F03 has similar rules as F95, with the difference that PASS
arguments basically should be skipped in these tests. That is what the
patch implements by passing the PASS arguments to
'gfc_compare_interfaces' and mod
On Fri, Jun 15, 2012 at 6:48 PM, Eric Botcazou wrote:
>> Btw, I think we should enable this flag by default for all languages but
>> Java so that if you enable -fnon-call-exceptions for C or C++ you don't get
>> too many spurious exceptions from dead code.
>
> The attached patch enables it for the
On Fri, Jun 15, 2012 at 5:00 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Fri, Jun 15, 2012 at 3:13 PM, Ulrich Weigand wrote:
>> > However, there is a second case where we need to check every pass: if
>> > we're not actually vectorizing any loop, but are performing basic-block
>> > S
Hello!
The testcase still fails on x86_64-pc-linux-gnu with:
FAIL: gcc.dg/tree-ssa/vrp68.c scan-tree-dump-times vrp1 "link_error" 1
since there are two calls to link_error.
2012-06-17 Uros Bizjak
* gcc.dg/tree-ssa/vrp68.c: Fix scan-tree-dump-times argument order.
Committed to mainl
27 matches
Mail list logo
