Hi,
the testcase causes huge inline recursion tree via flatten attribute. In this
case we run into quadratic time issue because we try to update overall
size/time of the function after each inlining decision.
This patch breaks out the part of inline_merge_summary that only recomputes the
overall si
Hello!
> 2012-08-10 Michael Zolotukhin
>
> * config/i386/i386.c (ix86_init_mmx_sse_builtins): Fix description of
> __builtin_ia32_rdseed_di_step.
Maybe better as: Fix builtin target mask of __builtin_ia32_rdseed_di_step.
OK for mainline.
Thanks,
Uros.
On Thu, 9 Aug 2012, Diego Novillo wrote:
> On 12-08-09 09:20 , Richard Guenther wrote:
>
> > if (interm_type)
> >{
> > /* Create a type conversion HALF_TYPE->INTERM_TYPE. */
> > ! tmp = create_tmp_reg (interm_type, NULL);
> > ! new_oprnd = ma
On Fri, 10 Aug 2012, Jan Hubicka wrote:
> >
> > This converts most users of create_tmp_{var,reg} to use anonymous
> > SSA names. To give you one more reason to look at 6/6 ;)
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Very cool. Thanks for the hard work. Did yo
Hi,
I've just merged upstream trunk on the aarch64-branch up to r190154.
Thanks
Sofiane
> OK for mainline.
Thanks!
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00264.html
K
Thanks!
On 10 August 2012 12:40, Kirill Yukhin wrote:
>> OK for mainline.
>
> Thanks!
> http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00264.html
>
> K
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
On Thu, 9 Aug 2012, William J. Schmidt wrote:
> Fix a thinko in strength reduction. I was checking the type of the
> wrong operand to determine whether address arithmetic should be used in
> replacing expressions. This produced a spurious POINTER_PLUS_EXPR when
> an address was converted to an u
On Fri, Aug 10, 2012 at 12:20 AM, Steven Bosscher wrote:
> On Fri, Aug 10, 2012 at 12:15 AM, Richard Henderson wrote:
>> On 08/09/2012 03:06 PM, Steven Bosscher wrote:
>>> + unsigned old_len = name_to_id ? VEC_length (unsigned, name_to_id) :
>>> 0;
>>> + VEC_reserve (unsigned, heap, na
Bootstrap & regtest in progress.
Richard.
2012-08-10 Richard Guenther
* tree-cfg.c (dump_function_to_file): Make sure to dump
anonymous SSA names when there are no local decls.
Index: gcc/tree-cfg.c
===
--- gcc/
Ping.
2012/8/8 Anna Tikhonova :
> Hi,
>
> while running check for Android NDK compiler (I've used
> contrib/test_installed for it) I've noticed that gcov name is
> hardcoded in g++.dg/gcov/gcov.exp.
> All NDK x86 tools have prefix like i686-linux-android-, so testing
> will fail to spawn gcov.
>
>
This fixes an error I introduced when making the VECTOR_CST representation
changes.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-08-10 Richard Guenther
PR middle-end/54219
* fold-const.c (fold_ternary_loc): Do not reverse the mask
when can
This adds a new optimization level, -Og, as previously discussed.
It aims at providing fast compilation, a superior debugging
experience and reasonable runtime performance. Instead of making
-O1 this optimization level this adds a new -Og.
It's a first cut, highlighting that our fixed pass pipel
This fixes another case where re-constructing ARRAY_REFs that were
not in the IL produced by the frontend produces bogus IL. This
time an ICE only, but in other cases this results in wrong-code
because of constraints we impose on ARRAY_REFs in data-dependence
analysis for example.
Bootstrapped a
On 12-08-09 18:04 , Cary Coutant wrote:
This patch is for the google/main and google/gcc-4_7 branches.
New code in GCC 4.7 is calling linemap_lookup with a location_t that
may still represent a location-with-discriminator. Before using a
location_t value to lookup the line number, it needs to b
Hi,
While examining the Power MD file seeking the explanation for a problem I
saw I have noticed a change in the past separated one of the instruction
splitters from its corresponding instruction pattern. Several unrelated
patterns were inserted between the two, presumably by accident where t
Hi!
There were only trivial merge conflicts like
<<<
[(match_operand 0 "memory_operand" "")
(match_operand 1 "memory_operand" "")]
""
---
[(match_operand 0 "memory_operand")
(match_operand 1 "memory_operand")]
"!TARGET_HAS_BIONIC"
>>>
Patch attached.
All necessary testing passed.
Richard Guenther wrote:
> On Tue, Aug 7, 2012 at 4:56 PM, Ulrich Weigand wrote:
> > Would it be OK to backport this to 4.7 and possibly 4.6?
> I'll defer the decision to the target maintainers. But please double-check
> for any changes in the vectorizer parts when backporting to 4.6.
Thanks! F
Richard Guenther wrote:
> On Tue, Aug 7, 2012 at 4:56 PM, Ulrich Weigand wrote:
> > Would it be OK to backport this to 4.7 and possibly 4.6?
> I'll defer the decision to the target maintainers. But please double-check
> for any changes in the vectorizer parts when backporting to 4.6.
And here
Ramana Radhakrishnan wrote:
> In addition I'd like this documented in changes.html for each of the
> release branches.
Richard Earnshaw wrote:
> However, it does need to be release-noted.
Would the following htdocs patch be OK with you? Feel free to suggest
a more appropriate wording ...
B
On 07/31/2012 11:58 AM, Florian Weimer wrote:
The attached patch adds a context parameter to
cxx_eval_constant_expression and its subprograms. This way, we do not
have to thread all context parameters manually. This will simplify the
introduction of additional location information, as suggested
On 10/08/12 14:44, Ulrich Weigand wrote:
> Ramana Radhakrishnan wrote:
>
>> In addition I'd like this documented in changes.html for each of the
>> release branches.
>
> Richard Earnshaw wrote:
>
>> However, it does need to be release-noted.
>
> Would the following htdocs patch be OK with you?
> - ada/gcc-interface/utils.c:rest_of_subprog_body_compilation calls
> dump_function which in turns calls dump_function_to_file which calls
> push_cfun. But Ada front end has its idea of the
> current_function_decl and there is no cfun which is an inconsistency
> which makes push_cfun asse
On 07/18/2012 04:31 PM, Florian Weimer wrote:
On 07/18/2012 03:55 PM, Jason Merrill wrote:
On 06/26/2012 10:29 AM, Florian Weimer wrote:
+ /* Set to (size_t)-1 if the size check fails. */
+ if (size_check != NULL_TREE)
+*size = fold_build3 (COND_EXPR, sizetype, size_check,
+
On 12-08-09 09:05 , Richard Guenther wrote:
What I do not understand is why you need a GTY(()) annotation on
C++ types with user-defined gc routines. gengtype should treat all
types not marked with GTY(()) as having user-defined gc routines, no?
Ideally, yes. But currently gengtype makes it
Richard Earnshaw wrote:
> On 10/08/12 14:44, Ulrich Weigand wrote:
> > Would the following htdocs patch be OK with you? Feel free to suggest
> > a more appropriate wording ...
>
> I think we need to make it clear that this also fixes a bug in the
> compiler that could lead to a run-time error.
On 10/08/12 16:18, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>> On 10/08/12 14:44, Ulrich Weigand wrote:
>>> Would the following htdocs patch be OK with you? Feel free to suggest
>>> a more appropriate wording ...
>>
>> I think we need to make it clear that this also fixes a bug in the
>>
> -Original Message-
> From: Georg-Johann Lay
> Sent: Friday, August 10, 2012 9:52 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric; Sean D'Epagnier; Joerg Wunsch
> Subject: [Patch,AVR] PR54222: Add fixed point support
>
> This patch adds fixed point support to th
On 12-08-09 03:12 , Laurynas Biveinis wrote:
Might be also interesting to try valgrind. Good to hear the zone
collector hasn't bitrotten once again.
Well, it seems it has now. I just tried --with-gc=zone in trunk and it
failed. I have not merged trunk for 2-3 weeks, so something may have
bro
On Fri, Aug 10, 2012 at 01:07:33PM +0200, Richard Guenther wrote:
> This fixes an error I introduced when making the VECTOR_CST representation
> changes.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
The test fails on i686-linux and guess many other targets, passing vector
types
On Fri, Aug 10, 2012 at 10:52:03AM +0400, Michael Zolotukhin wrote:
> Hi,
> Here is an obvious fix for a mistake in description of
> __builtin_ia32_rdseed_di_step.
> Bootstrap and rdseed-* tests are ok.
>
> Ok for commit to trunk?
Yes.
> Changelog entry:
> 2012-08-10 Michael Zolotukhin
>
>
Richard Earnshaw wrote:
> How about:
>
> On ARM, a bug has been fixed in GCC's implementation of the AAPCS
> rules for the layout of vectors that could lead to wrong code being
> generated. Vectors larger than 8 bytes in size are now by default
> aligned to an 8-byte boundary. This is an ABI ch
Weddington, Eric wrote:
>> From: Georg-Johann Lay
>> The patch works out fine. However, because of PR53923 which
>> shreds the AVR port, currently no reasonable testing is possible.
>>
>> Work to be done is better testing after PR53923 is fixed and the
>> AVR port works properly again.
>
> Is the
On Thu, Aug 9, 2012 at 3:06 PM, Jason Merrill wrote:
> On 08/08/2012 12:32 PM, Richard Henderson wrote:
>>
>> On 08/08/2012 09:27 AM, Dehao Chen wrote:
>>>
>>> Then we should probably assign UNKNOWN_LOCATION for these destructor
>>> calls, what do you guys think?
>>
>>
>> I think it's certainly pl
Hello!
Attached patch adds zero-extended variants of PLUS and MULT simple LEA
peephole2s. Patch also disables PLUS peephole2s on TARGET_OPT_AGU
targets (atom), since we already split correct LEAs according to LEA
vs ADD priority.
2012-08-10 Uros Bizjak
* config/i386/i386.md (simple L
On 2012-08-10 10:21, Dehao Chen wrote:
> Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION, but during
> gimplifying, it's reset to input_location:
>
> gimplify.c (gimplify_call_expr)
> 2486 /* For reliable diagnostics during inlining, it is necessary that
> 2487 every call_exp
> -Original Message-
> From: Georg-Johann Lay
> Sent: Friday, August 10, 2012 11:06 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov
> Subject: Re: [Patch,AVR] PR54222: Add fixed point support
>
> The first step would be to bisect and find the patch that lead to
>
On Fri, Aug 10, 2012 at 10:52 AM, Richard Henderson wrote:
> On 2012-08-10 10:21, Dehao Chen wrote:
>> Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION, but during
>> gimplifying, it's reset to input_location:
>>
>> gimplify.c (gimplify_call_expr)
>> 2486 /* For reliable diagnostics d
On 2012-08-10 11:01, Dehao Chen wrote:
> On Fri, Aug 10, 2012 at 10:52 AM, Richard Henderson wrote:
>> On 2012-08-10 10:21, Dehao Chen wrote:
>>> Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION, but during
>>> gimplifying, it's reset to input_location:
>>>
>>> gimplify.c (gimplify_call_ex
Ping
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01440.html
On Sat, 28 Jul 2012, Marc Glisse wrote:
Hello,
here is a patch for PR54112. It does 2 things:
* #undef complex after including the system's complex.h
* in C++11, still include the system's complex.h
The C++11 standard says that inc
A user reported on irc that the std::unique_ptr pretty-printer yields
bad results. For example:
(gdb) p uptr
$1 = std::tuple containing = {
[1] = ,
[2] = {
> = {}, }
}
This omits the actual pointer and prints some useless stuff instead.
This patch fixes the printer and adds a test.
The
On Fri, Aug 10, 2012 at 7:27 AM, Gopalasubramanian, Ganesh
wrote:
>> -mxop implies -mfma4, but reverse is not true.
>
> I think this handling went in for bdver1.
> But, with bdver2, we have both fma and fma4.
> So for bdver2, -mxop should not be enabling one of them.
>
>> if someone set -mfma4 tog
On 2012-08-10 12:59, Uros Bizjak wrote:
> Actually, this is the problem you are trying to solve. The fma4
> patterns are defined before fma3, so gcc prefers these.
The Real Problem is that they should not be separate patterns.
They should be a single pattern that selects alternatives via
the enabl
On 08/10/2012 01:21 PM, Dehao Chen wrote:
gimplify.c (gimplify_call_expr)
2486 /* For reliable diagnostics during inlining, it is necessary that
2487 every call_expr be annotated with file and line. */
2488 if (! EXPR_HAS_LOCATION (*expr_p))
2489SET_EXPR_LOCATION (*expr
On 2012-08-10 08:06, Diego Novillo wrote:
> The end point should be that the only thing we really need to tell
> gengtype about are the variable roots. Everything else would rely on
> user-provided markings. I suppose we could still keep the automatic
> option for really simple stuff, though.
Ye
On 2012-08-10 09:09, Jakub Jelinek wrote:
> * gcc.dg/torture/vector-shuffle1.c (f): Pass vectors indirectly
> to avoid warnings.
Ok.
r~
On Fri, Aug 10, 2012 at 10:02 PM, Richard Henderson wrote:
> On 2012-08-10 12:59, Uros Bizjak wrote:
>> Actually, this is the problem you are trying to solve. The fma4
>> patterns are defined before fma3, so gcc prefers these.
>
> The Real Problem is that they should not be separate patterns.
> Th
On 2012-08-10 13:21, Uros Bizjak wrote:
> Do you think that enabled isa is also appropriate for 4.7?
I think it's more reliable than relying on pattern ordering.
r~
Hello Everyone,
This patch is for the Cilk Plus branch affecting mainly the C++
compiler. This patch will add an implicit sync before a try block in a function
that spawns.
Thanks,
Balaji V. Iyer.
Index: gcc/testsuite/g++.dg/cilk-plus/test-try.cc
===
On Fri, Aug 10, 2012 at 10:22 PM, Richard Henderson wrote:
> On 2012-08-10 13:21, Uros Bizjak wrote:
>> Do you think that enabled isa is also appropriate for 4.7?
>
> I think it's more reliable than relying on pattern ordering.
OK, I will write incremental patch that uses enabled attribute for
ma
On 12-08-10 16:14 , Richard Henderson wrote:
On 2012-08-10 08:06, Diego Novillo wrote:
The end point should be that the only thing we really need to tell
gengtype about are the variable roots. Everything else would rely on
user-provided markings. I suppose we could still keep the automatic
opt
Weddington, Eric schrieb:
From: Georg-Johann Lay
The first step would be to bisect and find the patch that lead to
PR53923. It was not a change in the avr BE, so the question goes
to the authors of the respective patch.
Up to now I didn't even try to bisect; that would take years on the
host
Hello,
this patch detects permutations of permutations and merges them. It also
canonicalizes permutations a bit more.
There are several issues with this patch:
1) I am not sure we always want to combine permutations. Indeed, someone
(user? vectorizer?) may have written 2 permutations to hel
On Fri, 10 Aug 2012, Marc Glisse wrote:
There are several issues with this patch:
Oups:
5) and the testcase needs fixing, just like Jakub just fixed Richard's
testcase, to avoid ABI warnings. But that's easy.
--
Marc Glisse
On Fri, Aug 10, 2012 at 12:04 PM, Richard Henderson wrote:
> On 2012-08-10 11:01, Dehao Chen wrote:
>> On Fri, Aug 10, 2012 at 10:52 AM, Richard Henderson wrote:
>>> On 2012-08-10 10:21, Dehao Chen wrote:
Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION, but during
gimplifying,
On 2012-08-10 14:55, Dehao Chen wrote:
> I see your point. But the problem is that the above code is in
> gimplify_call_expr, in which we have no idea if it is in a
> TRY_FINALLY/TRY_CATCH block.
That's why I suggested saving and restoring input_location
while gimplifying try_finally.
i.e.
On Wed, Aug 1, 2012 at 7:10 AM, H.J. Lu wrote:
> On Sat, Apr 28, 2012 at 8:11 AM, H.J. Lu wrote:
>> Hi,
>>
>> arg_pointer and frame_pointer are handled as special cases in
>> based_loc_descr.
>>
>> (plus:DI (reg/f:DI 16 argp)
>> (const_int -20 [0xffec]))
>>
>> is perfectly valid w
On Fri, Aug 10, 2012 at 3:11 PM, Richard Henderson wrote:
> On 2012-08-10 14:55, Dehao Chen wrote:
>> I see your point. But the problem is that the above code is in
>> gimplify_call_expr, in which we have no idea if it is in a
>> TRY_FINALLY/TRY_CATCH block.
>
> That's why I suggested saving and r
On Fri, Aug 10, 2012 at 10:02 PM, Richard Henderson wrote:
> On 2012-08-10 12:59, Uros Bizjak wrote:
>> Actually, this is the problem you are trying to solve. The fma4
>> patterns are defined before fma3, so gcc prefers these.
>
> The Real Problem is that they should not be separate patterns.
> Th
On 10 August 2012 20:49, Tom Tromey wrote:
> A user reported on irc that the std::unique_ptr pretty-printer yields
> bad results. For example:
>
> (gdb) p uptr
> $1 = std::tuple containing = {
> [1] = ,
> [2] = {
> > = {}, }
> }
>
> This omits the actual pointer and prints some useless stu
Let's CC Gaby, who likes to keep an eye on patches involving
On 10 August 2012 20:17, Marc Glisse wrote:
> Ping
>
> http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01440.html
>
>
> On Sat, 28 Jul 2012, Marc Glisse wrote:
>
>> Hello,
>>
>> here is a patch for PR54112. It does 2 things:
>> * #undef c
On 8/10/12, Diego Novillo wrote:
> On 12-08-10 16:14 , Richard Henderson wrote:
> > On 2012-08-10 08:06, Diego Novillo wrote:
> > > The end point should be that the only thing we really need to
> > > tell gengtype about are the variable roots. Everything else
> > > would rely on user-provided mar
Hi,
I have added a release note for x86 builtins __builtin_cpu_is and
__builtin_cpu_supports. They were checked in to trunk in rev. 186789.
Is this ok to submit?
Thanks,
-Sri.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htd
New patch attached.
Bootstrapped and passed GCC regression tests.
Ok for trunk?
Thanks,
Dehao
gcc/ChangeLog
2012-08-07 Dehao Chen
* tree-eh.c (goto_queue_node): New field.
(record_in_goto_queue): New parameter.
(record_in_goto_queue_label): New parameter.
(l
The Go language does not permit a type switch on a non-interface type.
This patch modifies the gccgo frontend to reject this case.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r cadd7e3bec3f go/statements.cc
--- a/go/statements.cc
65 matches
Mail list logo
