> Can you explain why you believe it is hard/impossible to generate a test
> case without reduction?
I don't believe this. I only know that all the test cases considered
by me have the same problem.
Could you please explain what is 'reduction'? I've found out that,
according to the comment of the
The problem here is that the pattern marks the second operand as a
rewrite constraint but this operand is never written to. It looks
like it was a copy and pasto.
Committed as obvious and should improve register allocation in some cases.
Thanks,
Andrew Pinski
ChangeLog:
* config/aarch64/aarch64
On Sat, Jul 26, 2014 at 06:30:30PM +0200, Marek Polacek wrote:
> Marc reported that using .* regexp can cause spurious fails, so
> fixed by using \[^\n\]* instead.
>
> Tested on x86_64-linux, applying to trunk.
>
> 2014-07-26 Marek Polacek
>
> * gcc.dg/pr61077.c: Use \[^\n\]* instead of
Reject for that has no pattern defined.
eg - (for op in plus minus)
* genmatch.c (parse_for): Reject for that has no pattern defined.
Thanks and Regards,
Prathamesh
Index: genmatch.c
===
--- genmatch.c (revision 212928)
+++ genmatch.
Hello, thanks for your contribution.
here are some comments about the patch:
Le 21/07/2014 15:03, Andre Vehreschild a écrit :
> diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
> index c33936b..cb01a13 100644
> --- a/gcc/fortran/ChangeLog
> +++ b/gcc/fortran/ChangeLog
Changelogs are pre
Tobias Burnus wrote:
Assuming that the second part is okay, I have now committed it with
the comment-style change as Rev. 213079.
Dominique has pointed out (thanks!) that the patch fixed PR57305 - and
reading that PR, I saw that I missed the declared -> dynamic type
change. Hence, I have comm
On Jul 26, 2014, at 9:30 AM, Marek Polacek wrote:
> Marc reported that using .* regexp can cause spurious fails, so
> fixed by using \[^\n\]* instead.
Yeah, that’s a perennial non-obviousness and a slightly bad interface. Thanks.
On 07/16/2014 12:18 PM, Mike Stump wrote:
On Jul 16, 2014, at 7:51 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
Deprecate c++1y. Chane language to reflect greater confidence in C++14
Chane -> Change. I looked at your patch, all seems fine. I like the
documentation edits you did,
On Tue, 8 Jul 2014, Kirill Yukhin wrote:
Hello Marc.
On 04 Jul 21:11, Marc Glisse wrote:
On Thu, 3 Jul 2014, Kirill Yukhin wrote:
like combining 2 shuffles unless the result is the identity. And
expanding shuffles that can be done in a single instruction works
well.
But I am happy not doing th
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
Ed, I looked into partial specializations and it looks like, while not
trivial, it would be easy enough for me to do them. However, it is
not required for concepts (which can not be specialized), so should I
fix them for this patch or as a separate
On Fri, 25 Jul 2014, Hans-Peter Nilsson wrote:
> Anyway, on to the point of this message: by the quoted list it
> seems you have a local host called pluto using 4.9.1 as the host
> gcc for some build; does config-list.mk work for that?
Never mind, I found a 4.9.1 installation on gcc110 and the
ans
Hi,
On 07/23/2014 12:45 PM, Jonathan Wakely wrote:
On 15/07/14 13:03 +0100, Jonathan Wakely wrote:
On 14/07/14 20:31 +0100, Jonathan Wakely wrote:
This adds printers for the types in the std::experimental namespace.
This should fix the test failures that Paolo and HJ are seeing, older
versio
looks good. thanks.
David
On Sat, Jul 26, 2014 at 12:08 AM, Nathan Sidwell wrote:
> This patch removes 2 global variables -- gi_filename and gcov_max_filename.
> The relevant data is moved into the renamed gcov_filename structure and
> length is calculated later in the process.
>
> One more chan
Marc reported that using .* regexp can cause spurious fails, so
fixed by using \[^\n\]* instead.
Tested on x86_64-linux, applying to trunk.
2014-07-26 Marek Polacek
* gcc.dg/pr61077.c: Use \[^\n\]* instead of .* in the regexp.
diff --git gcc/testsuite/gcc.dg/pr61077.c gcc/testsuite/g
On 07/26/2014 12:11 PM, Jason Merrill wrote:
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
On 07/25/2014 05:24 PM, Jason Merrill wrote:
Fair enough, but in that case let's use 'sorry' rather then 'error' to
be clear that it's a missing feature.
Tests like g++.dg/cpp1y/pr59638.C produce extra
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
On 07/25/2014 05:24 PM, Jason Merrill wrote:
Fair enough, but in that case let's use 'sorry' rather then 'error' to
be clear that it's a missing feature.
Tests like g++.dg/cpp1y/pr59638.C produce extra failures if this is
changed. Is there somethi
On Mon, May 2, 2011 at 9:21 AM, Uros Bizjak wrote:
> It looks that GP relative relocations do not fit anymore into GPREL16
> reloc, so bootstrap on alpha hosts fail in stage2 with "relocation
> truncated to fit: GPREL16 against ...". I found no other solution but
> to pass --no-relax to linker i
On Fri, Jul 25, 2014 at 11:01 PM, Paolo Bonzini wrote:
>>> Well, I was lucky enough to gain access to an alpha pca56 for a day (I say
>>> lucky, this may not be repeatable!). However I was not able to build the Ada
>>>
>>> frontend, due (AFAICT) to the image being too big for relocations.
>>> (M
On 26/07/2014 16:16, Roman Gareev wrote:
I would still add a test case which does not contain a reduction (+=)
and where graphite is not duplicating pbbs.
Help for what? I was looking to create a simple test case. Is there still an
open bug?
Sorry, I thought, we should add this test case to
> I would still add a test case which does not contain a reduction (+=)
> and where graphite is not duplicating pbbs.
> Help for what? I was looking to create a simple test case. Is there still an
> open bug?
Sorry, I thought, we should add this test case to be able to test
graphite without patch
On 26/07/2014 15:48, Roman Gareev wrote:
What do you mean by wrong answer? Is there still a bug in the code
generation or the AST is just more complex as expected.
I mean that the value of res is wrong. I think it is because of the
wrong id of pbb->domain and pbb->transformed inherited from S_3
On 07/16/2014 12:18 PM, Mike Stump wrote:
On Jul 16, 2014, at 7:51 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
Deprecate c++1y. Chane language to reflect greater confidence in C++14
Chane -> Change. I looked at your patch, all seems fine. I like the
documentation edits you did,
> What do you mean by wrong answer? Is there still a bug in the code
> generation or the AST is just more complex as expected.
I mean that the value of res is wrong. I think it is because of the
wrong id of pbb->domain and pbb->transformed inherited from S_3 by S_9
(It was correct for S_3, but it
On 26/07/2014 14:59, Roman Gareev wrote:
I've tried to compile your example and had the similar problem. It
generates the following ISL AST
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S_6(c1);
if (c1 <= 48) {
S_3(c1);
S_9(c1);
if (c1 >= 24)
S_4(c1);
I've tried to compile your example and had the similar problem. It
generates the following ISL AST
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S_6(c1);
if (c1 <= 48) {
S_3(c1);
S_9(c1);
if (c1 >= 24)
S_4(c1);
S_5(c1);
}
}
S_7();
}
where S_9 has pbb-
On 26/07/2014 11:53, Roman Gareev wrote:
Any reason you don't use isl_id_for_pbb() to create this isl_id?
Yes, it is redundant. I've used isl_id_for_pbb() in the improved version.
Otherwise, the patch looks good to me. You can commit it if the graphite tests
still pass and you add an appropr
Am 17.07.2014 02:41, schrieb Ulrich Weigand:
> Hello,
>
> this is the variant intended for the 4.8/4.9 branches of the patch:
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html
>
> As discussed, it does *not* actually change ABI, but only warn when
> encountering a situation where the ABI
On 07/26/2014 05:07 PM, Chung-Lin Tang wrote:
> On 2014/7/26 03:33 PM, Chen Gang wrote:
>> On 07/26/2014 02:32 PM, Chung-Lin Tang wrote:
>>> On 14/7/26 11:28 AM, Chen Gang wrote:
The related strncpy() for custom_builtin_name[*] may set 5 none-zero
characters, which may cause custom_builti
On 07/26/2014 03:59 PM, Andreas Schwab wrote:
> Chen Gang writes:
>
>> If we need let custom_builtin_name[*] not only zero terminated, but also
>> zero pad, we need pass '4' to strncpy() instead of '5', that also will
>> clear all doubts.
>
> If you pass 5 to strncpy to copy a string of at mos
On Fri, Jul 25, 2014 at 3:26 PM, Peter Bergner wrote:
> On Wed, 2014-07-23 at 15:06 -0500, Peter Bergner wrote:
>> On Wed, 2014-07-16 at 11:23 +0200, Jakub Jelinek wrote:
>> > On Wed, Jul 16, 2014 at 05:18:06AM -0400, David Edelsohn wrote:
>> > > This seems weird. Why wasn't this file included bef
> Any reason you don't use isl_id_for_pbb() to create this isl_id?
Yes, it is redundant. I've used isl_id_for_pbb() in the improved version.
> Otherwise, the patch looks good to me. You can commit it if the graphite
> tests still pass and you add an appropriate ChangeLog entry.
I haven't found
Dear Paul,
Paul Richard Thomas wrote:
Whilst I am aware that we can now use the single line C++ comment,
would it perhaps be a better idea to stick with the C style comments
just for uniformity?
Okay.
+ if (arg->ts.type == BT_CLASS)
+{
+ tmp = gfc_vtable_size_get (TREE_OPERAND
Hello,
any comment on this patch?
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00769.html
On Tue, 10 Jun 2014, Marc Glisse wrote:
On Tue, 19 Mar 2013, Richard Henderson wrote:
I'm not fond of this, primarily because I believe the pattern should
not exist at all.
One year later, new try. T
Dear Tobias,
Whilst I am aware that we can now use the single line C++ comment,
would it perhaps be a better idea to stick with the C style comments
just for uniformity?
+ if (arg->ts.type == BT_CLASS)
+{
+ tmp = gfc_vtable_size_get (TREE_OPERAND (argse.expr, 0));
+ tmp = fold_
On 24/07/2014 12:09, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_if.
However, I've found out a problem. When I'm trying to generate Gimple
code from, for example, the following ISL AST:
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
S
On 26/07/2014 10:59, Roman Gareev wrote:
If I'm not mistaken, the reason of this bug is incorrect creation of a
poly_bb_p for basic_block from the existing pbb in new_pbb_from_pbb
(It is located in graphite-sese-to-poly.c). I think, that we should
set a new id of pbb1->domain (instead of using th
On 2014/7/26 03:33 PM, Chen Gang wrote:
> On 07/26/2014 02:32 PM, Chung-Lin Tang wrote:
>> On 14/7/26 11:28 AM, Chen Gang wrote:
>>> The related strncpy() for custom_builtin_name[*] may set 5 none-zero
>>> characters, which may cause custom_builtin_name[*] is none-zero
>>> terminated.
>>>
>>> So ad
If I'm not mistaken, the reason of this bug is incorrect creation of a
poly_bb_p for basic_block from the existing pbb in new_pbb_from_pbb
(It is located in graphite-sese-to-poly.c). I think, that we should
set a new id of pbb1->domain (instead of using the id of the pbb),
which contains pointer to
Chen Gang writes:
> If we need let custom_builtin_name[*] not only zero terminated, but also
> zero pad, we need pass '4' to strncpy() instead of '5', that also will
> clear all doubts.
If you pass 5 to strncpy to copy a string of at most 4 characters you
get zero-termination for free.
Andreas.
On 07/26/2014 02:32 PM, Chung-Lin Tang wrote:
> On 14/7/26 11:28 AM, Chen Gang wrote:
>> The related strncpy() for custom_builtin_name[*] may set 5 none-zero
>> characters, which may cause custom_builtin_name[*] is none-zero
>> terminated.
>>
>> So add additional '\0' byte for custom_builtin_name[*
This patch removes 2 global variables -- gi_filename and gcov_max_filename. The
relevant data is moved into the renamed gcov_filename structure and length is
calculated later in the process.
One more change and then David's required support for triggering dumping across
shared objects will es
Ed, I looked into partial specializations and it looks like, while not
trivial, it would be easy enough for me to do them. However, it is not
required for concepts (which can not be specialized), so should I fix
them for this patch or as a separate patch later?
On 07/25/2014 05:24 PM, Jason M
42 matches
Mail list logo
