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
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
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
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
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 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
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 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 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 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 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 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
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
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
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
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
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 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~
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 09:09, Jakub Jelinek wrote:
> * gcc.dg/torture/vector-shuffle1.c (f): Pass vectors indirectly
> to avoid warnings.
Ok.
r~
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 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 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 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
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
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
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
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
> -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 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
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 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
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
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
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
>
>
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 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
> -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 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
>>
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 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
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,
+
> - 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 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?
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
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
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
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
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.
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
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
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
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 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
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.
>
>
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/
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
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
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.
> OK for mainline.
Thanks!
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00264.html
K
Hi,
I've just merged upstream trunk on the aarch64-branch up to r190154.
Thanks
Sofiane
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
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
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.
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
65 matches
Mail list logo
