Re: Patch for constexpr variable templates
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 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 something I'm supposed to do to account for that? - Braden Obrzut
another gcov cleanup
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 essentially fall out.
nathan
2014-07-26 Nathan Sidwell
* libgcov-driver.c (struct gcov_filename_aux): Rename ...
(struct gcov_filename): ... here. Include buffer and max length
fields.
(gcov_max_filename): Remove.
(gi_filename): Remove.
(gcov_exit_compute_summary): Compute max filename here.
(gcov_exit_merge_gcda): Add filename parm, adjust.
(gcov_exit_merge_summary): Likewise.
(gcov_exit_dump_gcov): Adjust for struct gcov_filename changes.
(gcov_exit): Likewise.
(__gcov_init): Don't calculate max length here.
* libgcov_util.c (max_filename_len): Remove.
(read_gcda_file): Don't calculate max length here.
(gcov_read_profile_dir): Don't propagate here.
* libgcov-driver-system.c (alloc_filename_struct): Adjust for
struct gcov_filename changes.
(gcov_exit_open_gcda_file): Likewise.
Index: libgcc/libgcov-driver-system.c
===
--- libgcc/libgcov-driver-system.c (revision 213058)
+++ libgcc/libgcov-driver-system.c (working copy)
@@ -83,118 +83,105 @@ create_file_directory (char *filename)
}
static void
-allocate_filename_struct (struct gcov_filename_aux *gf)
+allocate_filename_struct (struct gcov_filename *gf)
{
const char *gcov_prefix;
- int gcov_prefix_strip = 0;
size_t prefix_length;
- char *gi_filename_up;
+ int strip = 0;
- gcc_assert (gf);
{
/* Check if the level of dirs to strip off specified. */
char *tmp = getenv("GCOV_PREFIX_STRIP");
if (tmp)
{
-gcov_prefix_strip = atoi (tmp);
+strip = atoi (tmp);
/* Do not consider negative values. */
-if (gcov_prefix_strip < 0)
- gcov_prefix_strip = 0;
+if (strip < 0)
+ strip = 0;
}
}
+ gf->strip = strip;
/* Get file name relocation prefix. Non-absolute values are ignored. */
gcov_prefix = getenv("GCOV_PREFIX");
- if (gcov_prefix)
-{
- prefix_length = strlen(gcov_prefix);
-
- /* Remove an unnecessary trailing '/' */
- if (IS_DIR_SEPARATOR (gcov_prefix[prefix_length - 1]))
-prefix_length--;
-}
- else
-prefix_length = 0;
+ prefix_length = gcov_prefix ? strlen (gcov_prefix) : 0;
+
+ /* Remove an unnecessary trailing '/' */
+ if (prefix_length && IS_DIR_SEPARATOR (gcov_prefix[prefix_length - 1]))
+prefix_length--;
/* If no prefix was specified and a prefix stip, then we assume
relative. */
- if (gcov_prefix_strip != 0 && prefix_length == 0)
+ if (!prefix_length && gf->strip)
{
gcov_prefix = ".";
prefix_length = 1;
}
- /* Allocate and initialize the filename scratch space plus one. */
- gi_filename = (char *) xmalloc (prefix_length + gcov_max_filename + 2);
- if (prefix_length)
-memcpy (gi_filename, gcov_prefix, prefix_length);
- gi_filename_up = gi_filename + prefix_length;
+ gf->prefix = prefix_length;
- gf->gi_filename_up = gi_filename_up;
- gf->prefix_length = prefix_length;
- gf->gcov_prefix_strip = gcov_prefix_strip;
+ /* Allocate and initialize the filename scratch space. */
+ gf->filename = (char *) xmalloc (gf->max_length + prefix_length + 2);
+ if (prefix_length)
+memcpy (gf->filename, gcov_prefix, prefix_length);
}
/* Open a gcda file specified by GI_FILENAME.
Return -1 on error. Return 0 on success. */
static int
-gcov_exit_open_gcda_file (struct gcov_info *gi_ptr, struct gcov_filename_aux
*gf)
+gcov_exit_open_gcda_file (struct gcov_info *gi_ptr,
+ struct gcov_filename *gf)
{
- int gcov_prefix_strip;
- size_t prefix_length;
- char *gi_filename_up;
- const char *fname, *s;
+ const char *fname = gi_ptr->filename;
+ char *dst = gf->filename + gf->prefix;
- gcov_prefix_strip = gf->gcov_prefix_strip;
- gi_filename_up = gf->gi_filename_up;
- prefix_length = gf->prefix_length;
fname = gi_ptr->filename;
- /* Avoid to add multiple drive letters into combined path. */
- if (prefix_length != 0 && HAS_DRIVE_SPEC(fname))
-fname += 2;
-
/* Build relocated filename, stripping off leading
directories from the initial filename if requested. */
- if (gcov_prefix_strip > 0)
+ if (gf->strip > 0)
{
- int level = 0;
+ const char *probe = fname;
+ int level;
- s = fname;
- if (IS_DIR_SEPARATOR(*s))
-++s;
-
- /* Skip selected directory levels. */
- for (; (*s != '\0') && (level < gcov_prefix_strip); s++)
-if (IS_DIR_SEPARATOR(*s))
+ /* Remove a leading separator, without counting it. */
+ if (IS_DIR_SEPARATOR (*probe))
Re: [PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string
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[*]. > > Where did you see this? Supposedly the snprintf of the custom function > type string should at most be of 'xnxx' format; 4 characters at most, I guess, your 'xnxx' means "%cn%c%c", not "%sn%s%s" (which is current implementation), also at present, "32 - n" is 17, not 4 for snprintf() length limitation. If we are always sure it must be no more than 4 characters (at present, it is, but in the future, I don't know). We can use strcpy() instead of strncpy() for it -- that will let other readers no doubt. 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. > not 5. Do you have a test case where the behavior you described appears? > I find it by reading source code, for me, it is simple code, test is welcomed, but not mandatory. But it really needs necessary discussion (for modification, and comments). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string
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. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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 the pbb1. I found out this after dumping of an index of pbb in the user statement S_3. Its index is 9. It is created in rewrite_reduction_out_of_ssa using new_pbb_from_pbb and the pbb with index 3. After that the user statement S_3 is removed in build_scop_drs, but the id of the pbb->domain and the pbb->transformed point to the old pbb with index 3. I've attached the patch, which may fix this. -- Cheers, Roman Gareev. Index: gcc/graphite-sese-to-poly.c === --- gcc/graphite-sese-to-poly.c (revision 212995) +++ gcc/graphite-sese-to-poly.c (working copy) @@ -2044,6 +2044,10 @@ break; pbb1->domain = isl_set_copy (pbb->domain); + char name[50]; + snprintf (name, sizeof (name), "S_%d", pbb_index (pbb1)); + pbb1->domain = isl_set_set_tuple_id (pbb1->domain, + isl_id_alloc (scop->ctx, name, pbb1)); GBB_PBB (gbb1) = pbb1; GBB_CONDITIONS (gbb1) = GBB_CONDITIONS (gbb).copy ();
Re: [PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string
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 add additional '\0' byte for custom_builtin_name[*]. >> >> Where did you see this? Supposedly the snprintf of the custom function >> type string should at most be of 'xnxx' format; 4 characters at most, > > I guess, your 'xnxx' means "%cn%c%c", not "%sn%s%s" (which is current > implementation), also at present, "32 - n" is 17, not 4 for snprintf() > length limitation. The use of %sn%s%s is intentional. That allows me to print "" directly using snprintf. '32 - n' is to represent the rest of the 32-byte buffer, harmless really, as it is at most 4 chars. Also, if I were to restrict it in the snprintf argument, it would be 5 (including the null char) not 4. > If we are always sure it must be no more than 4 characters (at present, > it is, but in the future, I don't know). We can use strcpy() instead of > strncpy() for it -- that will let other readers no doubt. > > 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. I don't understand what point you're trying to make here, really. As Andreas has noted in the other mail, strncpy does zero-termination automatically. Chung-Lin >> not 5. Do you have a test case where the behavior you described appears? >> > > I find it by reading source code, for me, it is simple code, test is > welcomed, but not mandatory. > > But it really needs necessary discussion (for modification, and comments).
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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 the id of the pbb), which contains pointer to the pbb1. > I found out this after dumping of an index of pbb in the user statement S_3. Its index is 9. It is created in rewrite_reduction_out_of_ssa using new_pbb_from_pbb and the pbb with index 3. After that the user statement S_3 is removed in build_scop_drs, but the id of the pbb->domain and the pbb->transformed point to the old pbb with index 3. Interesting. I was not even aware that we did statement splitting for reductions. Very nice analysis. I've attached the patch, which may fix this. -- Cheers, Roman Gareev. patch.txt Index: gcc/graphite-sese-to-poly.c === --- gcc/graphite-sese-to-poly.c (revision 212995) +++ gcc/graphite-sese-to-poly.c (working copy) @@ -2044,6 +2044,10 @@ break; pbb1->domain = isl_set_copy (pbb->domain); + char name[50]; + snprintf (name, sizeof (name), "S_%d", pbb_index (pbb1)); + pbb1->domain = isl_set_set_tuple_id (pbb1->domain, + isl_id_alloc (scop->ctx, name, pbb1)); Any reason you don't use isl_id_for_pbb() to create this isl_id? Otherwise, the patch looks good to me. You can commit it if the graphite tests still pass and you add an appropriate ChangeLog entry. Cheers, Tobias
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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_6(c1);
if (c1 <= 48) {
S_3(c1);
if (c1 >= 24)
S_4(c1);
S_5(c1);
}
}
S_7();
}
the pointer to Gimple basic block of S_3's poly basic block is NULL.
Could you please advise me possible reasons of this issue?
The source code of the example:
int
foo ()
{
int i, res = 0;
for (i = 0; i < 50; i++)
{
if (i >= 25)
res += i;
}
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 1225)
abort ();
return 0;
}
This patch looks also good. Can you quickly repost with the two test
cases as well as the appropriate ChangeLog, before I give the final OK.
Cheers,
Tobias
Re: [Patch, Fortran] PRs 61881/61888 - Fix issues with SIZEOF, CLASS(*) and assumed-rank
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_convert (result_type, tmp);
+ goto done;
+}
Is there any possibility that the class object will be adorned by any
kind of reference here? In which case, you should drill down through
the TREE_OPERANDS to find it.
Otherwise, this is OK for trunk.
Thanks for the patch
Paul
On 26 July 2014 01:47, Tobias Burnus wrote:
> The patch has been motivated by the needs for implementing the openacc
> module. In particular, it does:
>
> - Fix passing intrinsic types to CLASS(*) [F2003]
> - Fix STORAGE_SIZE for polymorphic arrays [F2003]
> - Permit the vendor intrinsic SIZEOF also for TYPE(*) if and only if an
> array descriptor has been used [extend GNU extension]
> - Fix SIZEOF with assumed-rank [fix GNU extension]
> - Document that SIZEOF's result are not well defined for noncontiguous
> arrays. [fix GNU extension]
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
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. Tweaking the pattern, I ended up with a copy of the mov pattern (the subreg is generated automatically when the modes don't match), so I just removed it. I know the comment in emit-rtl.c says splitters are a better way forward than subregs, but I haven't managed with splitters while the subreg patch is very simple :-) I added a -O0 testcase because when I was experimenting I had many versions that worked for -O2 but ICEd at -O0 (and vice versa), but it might be redundant with some other tests. Bootstrap+testsuite on x86_64-linux-gnu. 2014-06-10 Marc Glisse PR target/50829 gcc/ * config/i386/sse.md (enum unspec): Remove UNSPEC_CAST. (avx__): Remove. * config/i386/i386.c (builtin_description) [__builtin_ia32_si256_si, __builtin_ia32_ps256_ps, __builtin_ia32_pd256_pd]: Replace the removed insn with mov. * emit-rtl.c (validate_subreg): Allow vector-vector subregs. gcc/testsuite/ * gcc.target/i386/pr50829-1.c: New file. * gcc.target/i386/pr50829-2.c: New file. -- Marc Glisse
Re: [Patch, Fortran] PRs 61881/61888 - Fix issues with SIZEOF, CLASS(*) and assumed-rank
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 (argse.expr, 0));
+ tmp = fold_convert (result_type, tmp);
+ goto done;
+}
Is there any possibility that the class object will be adorned by any
kind of reference here? In which case, you should drill down through
the TREE_OPERANDS to find it.
I think it should be fine - it just removes the outermost component
reference, which should give the class struct, independently whether it
is class_var or dt(5)%comp(7)%class_comp.
Otherwise, this is OK for trunk.
Thanks for the patch
Assuming that the second part is okay, I have now committed it with the
comment-style change as Rev. 213079.
Thanks for the patch review!
Tobias
PS: Next on my to-do list is to post a RFC version of openacc_lib.h /
module openacc, using the patch, for the gomp-4_0-branch. And then I
want to continue on the locking/critical section support for coarrays.
PPS: I realized that the sub-pointer issues, where the actual stride is
not a multiple of the element length, very quickly and badly hits me
with scalar derived-type coarrays with array components. Thus, to
support those, I am also very interested in getting the new array
descriptor up and running and onto the trunk… I do not really like the
idea of coding around that issue.
Re: [GSoC] generation of Gimple code from isl_ast_node_if
> 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 out regression during testing with the graphite tests.
> This patch looks also good. Can you quickly repost with the two test cases as
> well as the appropriate ChangeLog, before I give the final OK.
If I'm not mistaken, I sent you only one test case. Should we create
another one?
--
Cheers, Roman Gareev.
2014-07-26 Roman Gareev
[gcc/]
* graphite-sese-to-poly.c:
(new_pbb_from_pbb): Set a new id of pbb1->domain (instead of using the
id of the pbb), which contains pointer to the pbb1.
2014-07-26 Roman Gareev
[gcc/]
* graphite-isl-ast-to-gimple.c:
(graphite_create_new_guard): New function.
(translate_isl_ast_node_if): New function.
(translate_isl_ast): Add calling of translate_isl_ast_node_if.
[gcc/testsuite]
* gcc.dg/graphite/isl-ast-gen-if-1.c: New testcase.
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 212995)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -2044,7 +2044,8 @@
break;
pbb1->domain = isl_set_copy (pbb->domain);
-
+ pbb1->domain = isl_set_set_tuple_id (pbb1->domain,
+ isl_id_for_pbb (scop, pbb1));
GBB_PBB (gbb1) = pbb1;
GBB_CONDITIONS (gbb1) = GBB_CONDITIONS (gbb).copy ();
GBB_CONDITION_CASES (gbb1) = GBB_CONDITION_CASES (gbb).copy ();
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212995)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -646,6 +646,43 @@
return next_e;
}
+/* Creates a new if region corresponding to ISL's cond. */
+
+static edge
+graphite_create_new_guard (edge entry_edge, __isl_take isl_ast_expr *if_cond,
+ ivs_params &ip)
+{
+ tree type =
+build_nonstandard_integer_type (graphite_expression_type_precision, 0);
+ tree cond_expr = gcc_expression_from_isl_expression (type, if_cond, ip);
+ edge exit_edge = create_empty_if_region_on_edge (entry_edge, cond_expr);
+ return exit_edge;
+}
+
+/* Translates an isl_ast_node_if to Gimple. */
+
+static edge
+translate_isl_ast_node_if (loop_p context_loop,
+ __isl_keep isl_ast_node *node,
+ edge next_e, ivs_params &ip)
+{
+ gcc_assert (isl_ast_node_get_type (node) == isl_ast_node_if);
+ isl_ast_expr *if_cond = isl_ast_node_if_get_cond (node);
+ edge last_e = graphite_create_new_guard (next_e, if_cond, ip);
+
+ edge true_e = get_true_edge_from_guard_bb (next_e->dest);
+ isl_ast_node *then_node = isl_ast_node_if_get_then (node);
+ translate_isl_ast (context_loop, then_node, true_e, ip);
+ isl_ast_node_free (then_node);
+
+ edge false_e = get_false_edge_from_guard_bb (next_e->dest);
+ isl_ast_node *else_node = isl_ast_node_if_get_else (node);
+ if (isl_ast_node_get_type (else_node) != isl_ast_node_error)
+translate_isl_ast (context_loop, else_node, false_e, ip);
+ isl_ast_node_free (else_node);
+ return last_e;
+}
+
/* Translates an ISL AST node NODE to GCC representation in the
context of a SESE. */
@@ -663,7 +700,8 @@
next_e, ip);
case isl_ast_node_if:
- return next_e;
+ return translate_isl_ast_node_if (context_loop, node,
+ next_e, ip);
case isl_ast_node_user:
return translate_isl_ast_node_user (node, next_e, ip);
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(working copy)
@@ -0,0 +1,29 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fgraphite-identity -fgraphite-code-generator=isl" } */
+
+static int __attribute__((noinline))
+foo ()
+{
+ int i, res = 0;
+
+ for (i = 0; i < 50; i++)
+{
+ if (i >= 25)
+res += i;
+}
+
+ return res;
+}
+
+extern void abort ();
+
+int
+main (void)
+{
+ int res = foo ();
+
+ if (res != 925)
+abort ();
+
+ return 0;
+}
Re: [PATCH, rs6000] Fix many powerpc*-linux ASAN test suite failures
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 before or whenever it
>> > > was added for other *-linux targets? This seems to define SPECs that
>> > > should have been necessary before now.
>> >
>> > All other Linux targets where asan is supported got the right definitions
>> > from gnu-user.h, it was needed even on the older release branches.
>>
>> Ok, I compiled a source file that #includes tm.h and looked at the -dD -E
>> output to see what macros get defined with and without this change.
>> There are a few macros the gnu-user.h defines that are identical to what
>> some of the rs6000/sysv4.h or rs6000/linux{,64}.h header files define, so
>> we could remove those. There are some that are different too, so we'd
>> need to keep those. The following are the macros that are identical:
>
> FYI, here is the mainline patch that removes the redundant macro defines
> in rs6000/linux.h and rs6000/linux64.h. This also passed bootstrap and
> regtesting with no regressions.
>
>
> Peter
>
>
> * config.gcc (powerpc*-*-linux*): Include gnu-user.h in tm_file.
> * config/rs6000/sysv4.h (CC!_SPEC): Undefine it before defining it.
> * config/rs6000/linux.h (CPLUSPLUS_CPP_SPEC): Delete define.
> (LINK_GCC_C_SEQUENCE_SPEC): Likewise.
> (USE_LD_AS_NEEDED): Likewise.
> (ASM_APP_ON): Likewise.
> (ASM_APP_OFF): Likewise.
> (TARGET_POSIX_IO): Likewise.
> * config/rs6000/linux64.h (CPLUSPLUS_CPP_SPEC): Likewise.
> (LINK_GCC_C_SEQUENCE_SPEC): Likewise.
> (USE_LD_AS_NEEDED): Likewise.
> (ASM_APP_ON): Likewise.
> (ASM_APP_OFF): Likewise.
> (TARGET_POSIX_IO): Likewise.
Okay.
Thanks, David
Re: [PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string
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 most 4 characters you > get zero-termination for free. > Yes. So at least, at present, it is no issue, so if we are focusing on solving issues, this patch can be skipped. And then I will continue discussing it in the other thread, please check that. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/config/nios2/nios2.c: Let custom_builtin_name[*] always be zero terminated string
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_builtin_name[*] is none-zero terminated. So add additional '\0' byte for custom_builtin_name[*]. >>> >>> Where did you see this? Supposedly the snprintf of the custom function >>> type string should at most be of 'xnxx' format; 4 characters at most, >> >> I guess, your 'xnxx' means "%cn%c%c", not "%sn%s%s" (which is current >> implementation), also at present, "32 - n" is 17, not 4 for snprintf() >> length limitation. > > The use of %sn%s%s is intentional. That allows me to print "" directly > using snprintf. > OK, thanks. > '32 - n' is to represent the rest of the 32-byte buffer, harmless > really, as it is at most 4 chars. > > Also, if I were to restrict it in the snprintf argument, it would be 5 > (including the null char) not 4. > OK, thanks. And for me, I'd like to use 'sizeof(custom_builtin_name[0])' instead of "32 - n" for snprintf(). >> If we are always sure it must be no more than 4 characters (at present, >> it is, but in the future, I don't know). We can use strcpy() instead of >> strncpy() for it -- that will let other readers no doubt. >> >> 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. > > I don't understand what point you're trying to make here, really. As > Andreas has noted in the other mail, strncpy does zero-termination > automatically. > strncpy will zero pad, but not be sure of the dest string will be zero terminated, please "man strncpy" to get more details. So for me, I'd like to use '4' instead of '5' for strncpy(), that will clear all doubts (although, at present, it is not a bug, so this patch can be skipped, if we are only focus on bug fix). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
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 will change in a future GCC. > (Avoiding the specific term "GCC 4.10" here since I'm not certain > whether the next GCC release will in fact be called that ...) > > Tested on powerpc64-linux and powerpc64le-linux; also verified using > the ABI compat suite (against an unpatched GCC) that this patch does > not change the ABI. this causes PR libobjc/61920, link failures with -lobjc.
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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 appropriate ChangeLog entry.
I haven't found out regression during testing with the graphite tests.
This patch looks also good. Can you quickly repost with the two test cases as
well as the appropriate ChangeLog, before I give the final OK.
If I'm not mistaken, I sent you only one test case. Should we create
another one?
Right, I got confused.
I would still add a test case which does not contain a reduction (+=)
and where graphite is not duplicating pbbs.
If you make res of type float I assume graphite will not detect it as a
reduction. On the other side, it may not even introduce if conditions.
So you may need a little bit more complicated code e.g:
for (i = 0; i < 50; i++)
{
res += i * 2.1;
if (i >= 25)
res += i * 3;
}
This should in the best case yield an isl_ast which matches the input code.
Also, please add a comment to the other test case that notes what kind
of issue this one is testing (reduction, where the pbbs are possibly
duplicated).
Cheers,
Tobias
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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->domain and pbb->transformed of S_3. A pointer to a
Gimple basic block is not NULL now, but it leads to the wrong answer.
I've tried different examples, which generate ISL AST, but they have
same problems. Could you please advise me another one?
--
Cheers, Roman Gareev.
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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);
S_5(c1);
}
}
S_7();
}
where S_9 has pbb->domain and pbb->transformed of S_3. A pointer to a
Gimple basic block is not NULL now, but it leads to the wrong answer.
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've tried different examples, which generate ISL AST, but they have
same problems. Could you please advise me another one?
To my understanding bb copies are introduced in case reductions are
seen. You could try to just initialize an array (maybe a little bit more
complex, but without += statements):
for i:
A[i] = ...
You could do the summation/verfication outside of the scop e.g. in the
main function.
Cheers
Tobias
Re: [GSoC] generation of Gimple code from isl_ast_node_if
> 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 is incorrect for S_9).
> To my understanding bb copies are introduced in case reductions are seen.
> You could try to just initialize an array (maybe a little bit more complex,
> but without += statements):
>
> for i:
> A[i] = ...
>
> You could do the summation/verfication outside of the scop e.g. in the main
> function.
It seems that it doesn't help (at least for now).
However, I've found out the following example:
static int __attribute__((noinline))
foo ()
{
int i, res = 0;
for (i = 0; i < 50; i++)
{
if (i < 5)
res += 1;
}
return res;
}
extern void abort ();
int
main (void)
{
int res = foo ();
if (res != 5)
abort ();
return 0;
}
It gives the correct result, inspite of duplicating of pbbs and
generates the following ISL AST
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
for (int c2 = 0; c2 <= 1; c2 += 1)
S_3(c1);
if (c1 <= 4)
S_4(c1);
S_5(c1);
}
S_7();
}
Maybe we could use it. What do you think about this?
--
Cheers, Roman Gareev.
Re: [PATCH, C++, CPP] Add C++1z to the preprocessor. Rename C++1y to C++14.
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, nice job. Here is another round - basically the same except testcases tweaked. built and tested on x86_64-linux. OK? libcpp/ 2014-07-16 Edward Smith-Rowland <3dw...@verizon.net> * include/cpplib.h (enum c_lang): Add CLK_GNUCXX1Z, CLK_CXX1Z; Rename CLK_GNUCXX1Y, CLK_CXX1Y to CLK_GNUCXX14, CLK_CXX14; * init.c (struct lang_flags lang_defaults): Add column for trigraphs; Add rows for CLK_GNUCXX1Z, CLK_CXX1Z; (cpp_set_lang): Set trigraphs; (cpp_init_builtins): Set __cplusplus to 201402L for C++14; Set __cplusplus to 201500L for C++17. gcc/c-family/ 2014-07-16 Edward Smith-Rowland <3dw...@verizon.net> * c-common.h (enum cxx_dialect): Add cxx14. * c-opts.c (set_std_cxx1y): Rename to set_std_cxx14; Use cxx14. * c-ubsan.c (ubsan_instrument_shift): Change comment and logic from cxx_dialect == cxx11 || cxx_dialect == cxx1y to cxx_dialect >= cxx11. gcc/cp/ 2014-07-16 Edward Smith-Rowland <3dw...@verizon.net> * decl.c (compute_array_index_type, grokdeclarator, undeduced_auto_decl): Change from cxx1y to cxx14. * parser.c (cp_parser_unqualified_id, cp_parser_pseudo_destructor_name, cp_parser_lambda_introducer, cp_parser_lambda_declarator_opt, cp_parser_decltype, cp_parser_conversion_type_id, cp_parser_simple_type_specifier, cp_parser_type_id_1, cp_parser_template_type_arg, cp_parser_std_attribute, cp_parser_template_declaration_after_export): Ditto. * pt.c (tsubst): Ditto. * semantics.c (force_paren_expr, finish_decltype_type): Ditto. * typeck.c (comp_template_parms_position, cxx_sizeof_or_alignof_type, cp_build_addr_expr_1, maybe_warn_about_useless_cast): Ditto. gcc/ 2014-07-16 Edward Smith-Rowland <3dw...@verizon.net> * doc/invoke.texi: Change c++1y to c++14 and gnu++1y to gnu++14. Deprecate c++1y. Change language to reflect greater confidence in C++14. gcc/testsuite/ 2014-07-16 Edward Smith-Rowland <3dw...@verizon.net> * g++.dg/cpp0x/cplusplus.C: New. * g++.dg/cpp0x/cplusplus_0x.C: New. * g++.dg/cpp0x/auto3.C: Change c++1y to c++14. * g++.dg/cpp0x/auto41.C: Ditto. * g++.dg/cpp0x/auto9.C: Ditto. * g++.dg/cpp0x/initlist26.C: Ditto. * g++.dg/cpp0x/pr59111.C: Ditto. * g++.dg/cpp0x/trailing2.C: Ditto. * g++.dg/cpp1y/attr-deprecated.C: Ditto. * g++.dg/cpp1y/auto-dtor1.C: Ditto. * g++.dg/cpp1y/auto-fn1.C: Ditto. * g++.dg/cpp1y/auto-fn2.C: Ditto. * g++.dg/cpp1y/auto-fn3.C: Ditto. * g++.dg/cpp1y/auto-fn4.C: Ditto. * g++.dg/cpp1y/auto-fn5.C: Ditto. * g++.dg/cpp1y/auto-fn6.C: Ditto. * g++.dg/cpp1y/auto-fn7.C: Ditto. * g++.dg/cpp1y/auto-fn8.C: Ditto. * g++.dg/cpp1y/auto-fn9.C: Ditto. * g++.dg/cpp1y/auto-fn10.C: Ditto. * g++.dg/cpp1y/auto-fn11.C: Ditto. * g++.dg/cpp1y/auto-fn12.C: Ditto. * g++.dg/cpp1y/auto-fn13.C: Ditto. * g++.dg/cpp1y/auto-fn14.C: Ditto. * g++.dg/cpp1y/auto-fn15.C: Ditto. * g++.dg/cpp1y/auto-fn16.C: Ditto. * g++.dg/cpp1y/auto-fn17.C: Ditto. * g++.dg/cpp1y/auto-fn18.C: Ditto. * g++.dg/cpp1y/auto-fn19.C: Ditto. * g++.dg/cpp1y/auto-fn20.C: Ditto. * g++.dg/cpp1y/auto-fn21.C: Ditto. * g++.dg/cpp1y/auto-fn22.C: Ditto. * g++.dg/cpp1y/auto-fn23.C: Ditto. * g++.dg/cpp1y/auto-fn24.C: Ditto. * g++.dg/cpp1y/auto-fn25.C: Ditto. * g++.dg/cpp1y/auto-mangle1.C: Ditto. * g++.dg/cpp1y/auto-neg1.C: Ditto. * g++.dg/cpp1y/digit-sep.C: Ditto. * g++.dg/cpp1y/digit-sep-neg.C: Ditto. * g++.dg/cpp1y/digit-sep-cxx11-neg.C: Ditto. * g++.dg/cpp1y/fn-generic-member-ool.C: Ditto. * g++.dg/cpp1y/lambda-deduce-mult.C: Ditto. * g++.dg/cpp1y/lambda-generic.C: Ditto. * g++.dg/cpp1y/lambda-generic-cfun.C: Ditto. * g++.dg/cpp1y/lambda-generic-dep.C: Ditto. * g++.dg/cpp1y/lambda-generic-mixed.C: Ditto. * g++.dg/cpp1y/lambda-generic-udt.C: Ditto. * g++.dg/cpp1y/lambda-generic-variadic.C: Ditto. * g++.dg/cpp1y/lambda-generic-vla1.C: Ditto. * g++.dg/cpp1y/lambda-generic-x.C: Ditto. * g++.dg/cpp1y/lambda-generic-xcfun.C: Ditto. * g++.dg/cpp1y/lambda-generic-xudt.C: Ditto. * g++.dg/cpp1y/lambda-init.C: Ditto. * g++.dg/cpp1y/lambda-init1.C: Ditto. * g++.dg/cpp1y/lambda-init2.C: Ditto. * g++.dg/cpp1y/lambda-init3.C: Ditto. * g++.dg/cpp1y/lambda-init4.C: Ditto. * g++.dg/cpp1y/lambda-init5
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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 by S_9
(It was correct for S_3, but it is incorrect for S_9).
Sorry Roman. I am still confused. Are we looking for a test case or are
we still trying to understand an issue. Specifically, do we still
incorrectly transform the code even after your isl_id_for_pbb() patch?
To my understanding bb copies are introduced in case reductions are seen.
You could try to just initialize an array (maybe a little bit more complex,
but without += statements):
for i:
A[i] = ...
You could do the summation/verfication outside of the scop e.g. in the main
function.
It seems that it doesn't help (at least for now).
Help for what? I was looking to create a simple test case. Is there
still an open bug?
I am looking for a simple test case that does _not_ contain a reduction
in addition to the test case you already have.
However, I've found out the following example:
static int __attribute__((noinline))
foo ()
{
int i, res = 0;
for (i = 0; i < 50; i++)
{
if (i < 5)
res += 1;
}
This one still has a reduction.
It gives the correct result, inspite of duplicating of pbbs and
generates the following ISL AST
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
for (int c2 = 0; c2 <= 1; c2 += 1)
S_3(c1);
if (c1 <= 4)
S_4(c1);
S_5(c1);
}
S_7();
And this one still duplicates pbbs. So this is not the simple test case
I am looking for. It introduces several new statements I do not
understand, so it does not seem to be a trivial test case.
Maybe we could use it. What do you think about this?
What do you want to use it for?
Cheers,
Tobias
Re: [GSoC] generation of Gimple code from isl_ast_node_if
> 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 related to graphite-sese-to-poly.c (patch1). > Sorry Roman. I am still confused. Are we looking for a test case or are we > still trying to understand an issue. Specifically, do we still incorrectly > transform the code even after your isl_id_for_pbb() patch? I gives a wrong answer without patch1. The code is transformed correctly with this patch. -- Cheers, Roman Gareev.
Re: [GSoC] generation of Gimple code from isl_ast_node_if
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 be able to test
graphite without patch related to graphite-sese-to-poly.c (patch1).
Right. I think we should have a simple test case that does not trigger
basic block duplication, which is basically triggered for reductions.
The test case:
static int __attribute__((noinline))
foo ()
{
int i, res = 0;
for (i = 0; i < 50; i++)
{
if (i < 5)
res += 1;
}
return res;
}
that you just proposed contains again a reduction and yields several bbs
that cause problems.
{
for (int c1 = 0; c1 <= 49; c1 += 1) {
for (int c2 = 0; c2 <= 1; c2 += 1)
S_3(c1);
if (c1 <= 4)
S_4(c1);
S_5(c1);
}
S_7();
}
I proposed a test case without a reduction (possibly a little bit more
complex):
> > for i:
> > A[i] = ...
> >
> > You could do the summation/verfication outside of the scop e.g. in
> > the main
> > function.
>
> It seems that it doesn't help (at least for now).
Can you explain why you believe it is hard/impossible to generate a test
case without reduction?
Sorry Roman. I am still confused. Are we looking for a test case or are we
still trying to understand an issue. Specifically, do we still incorrectly
transform the code even after your isl_id_for_pbb() patch?
I gives a wrong answer without patch1. The code is transformed
correctly with this patch.
OK. So we don't need to solve another bug. That is good.
Cheers,
Tobias
Re: Does anyone use Ada on Alpha?
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. >>> (Moreover, my understanding is > that the default memory model for Alpha, >>> is the largest memory model.) I used pristine 4.9.1 >>> sources, host compiler >> >> You will need attached patch. > > Ok for mainline with a ChangeLog. Why not. :) The patch with a ChangeLog is actually at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2011-05/msg00022.html I will commit it to 4.9 and mainline SVN. Uros.
Re: [PATCH, alpha]: Fix PR/47230 [4.6/4.7 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."
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 in order to finish the bootstrap. > > 2011-05-02 Uros Bizjak > > PR target/47230 > * configure.ac (alpha*-*-linux*): Use mh-alpha-linux. > * configure: Regenerate. > > config/ChangeLog: > > 2011-05-02 Uros Bizjak > > PR target/47230 > * mh-alpha-linux: New file. > > Patch was bootstrapped and regression tested with "GNU ld (GNU > Binutils) 2.21" on alphaev68-pc-linux-gnu [1]. > > OK for 4.6. and 4.7 ? > > [1] http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00089.html Patch was committed to mainline SVN, 4.9 and 4.8 branches. Uros. Index: configure.ac === --- configure.ac(revision 173233) +++ configure.ac(working copy) @@ -1100,6 +1100,9 @@ *-interix*) host_makefile_frag="config/mh-interix" ;; + alpha*-*-linux*) +host_makefile_frag="config/mh-alpha-linux" +;; hppa*-hp-hpux10*) host_makefile_frag="config/mh-pa-hpux10" ;; Index: configure === --- configure (revision 173233) +++ configure (working copy) @@ -3672,6 +3672,9 @@ *-interix*) host_makefile_frag="config/mh-interix" ;; + alpha*-*-linux*) +host_makefile_frag="config/mh-alpha-linux" +;; hppa*-hp-hpux10*) host_makefile_frag="config/mh-pa-hpux10" ;; Index: config/mh-alpha-linux === --- config/mh-alpha-linux (revision 0) +++ config/mh-alpha-linux (revision 0) @@ -0,0 +1,3 @@ +# Prevent GPREL16 relocation truncation +LDFLAGS += -Wl,--no-relax +BOOT_LDFLAGS += -Wl,--no-relax
Re: Patch for constexpr variable templates
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 something I'm supposed to do to account for that? Changing dg-error to dg-message should cover it. Jason
Re: Patch for constexpr variable templates
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 failures if this is changed. Is there something I'm supposed to do to account for that? Changing dg-error to dg-message should cover it. Actually, we shouldn't be treating that testcase as declaring variable templates at all. Adam, any thoughts? Jason
[committed] Fix pr61077.c test
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/gcc.dg/pr61077.c
index c0513f7..e29f23c 100644
--- gcc/testsuite/gcc.dg/pr61077.c
+++ gcc/testsuite/gcc.dg/pr61077.c
@@ -5,8 +5,8 @@
_Atomic int
main (_Atomic int argc, _Atomic char **argv)
/* { dg-warning "qualified return type" "return" { target *-*-* } 6 } */
-/* { dg-warning "qualified parameter type.*int" "parameter" { target *-*-* } 6
} */
-/* { dg-warning "qualified parameter type.*char" "parameter" { target *-*-* }
6 } */
+/* { dg-warning "qualified parameter type\[^\n\]*int" "parameter" { target
*-*-* } 6 } */
+/* { dg-warning "qualified parameter type\[^\n\]*char" "parameter" { target
*-*-* } 6 } */
{
return 0;
}
Marek
Re: another gcov cleanup
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 change and then David's required support for triggering dumping > across shared objects will essentially fall out. > > nathan
Re: [patch] Add libstdc++ pretty printers for Library Fundamentals TS types
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 versions of GDB didn't have the gdb.Type.name attribute. Confirmed fixed, by the way. Thanks! Paolo.
Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable))
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 answer seems to be "yes", but still investigating; I disabled Ada. It might be useful to run a modified config-list.mk using that version. BTW, I found the answer to be "no" for 4.8.1 as per gcc111 due to a common warning on a concat call. brgds, H-P
Re: Patch for constexpr variable templates
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 patch later? I see no reason why we can't add features in stages. I just wondered if you had already given it a look. Certainly constexpr variable templates are useful on their own. 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 something I'm supposed to do to account for that? - Braden Obrzut
Re: [i386] Replace builtins with vector extensions
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 them yet. To be very specific, could you
list which intrinsics you would like to remove from the posted
patch?
I am not a x86 maintainer, however while such a replacements produce
correct semantics and probably enable optimizations, I support your patch.
Probably you could try such your approach on AVX2, AVX-512 whose intrinsics
are well covered by tests?
I did some AVX and AVX512F intrinsics, and it still passes the testsuite
(on my old pre-AVX x86_64-linux-gnu).
2014-07-26 Marc Glisse
* config/i386/xmmintrin.h (_mm_add_ps, _mm_sub_ps, _mm_mul_ps,
_mm_div_ps, _mm_store_ss, _mm_cvtss_f32): Use vector extensions
instead of builtins.
* config/i386/avxintrin.h (_mm256_add_pd, _mm256_add_ps,
_mm256_div_pd, _mm256_div_ps, _mm256_mul_pd, _mm256_mul_ps,
_mm256_sub_pd, _mm256_sub_ps): Likewise.
* config/i386/avx512fintrin.h (_mm512_add_pd, _mm512_add_ps,
_mm512_sub_pd, _mm512_sub_ps, _mm512_mul_pd, _mm512_mul_ps,
_mm512_div_pd, _mm512_div_ps): Likewise.
* config/i386/emmintrin.h (_mm_store_sd, _mm_cvtsd_f64, _mm_storeh_pd,
_mm_cvtsi128_si64, _mm_cvtsi128_si64x, _mm_add_pd, _mm_sub_pd,
_mm_mul_pd, _mm_div_pd, _mm_storel_epi64, _mm_movepi64_pi64,
_mm_loadh_pd, _mm_loadl_pd): Likewise.
(_mm_sqrt_sd): Fix comment.
--
Marc GlisseIndex: gcc/config/i386/avx512fintrin.h
===
--- gcc/config/i386/avx512fintrin.h (revision 213083)
+++ gcc/config/i386/avx512fintrin.h (working copy)
@@ -10598,26 +10598,21 @@ _mm512_maskz_sqrt_ps (__mmask16 __U, __m
(__v16sf)
_mm512_setzero_ps (),
(__mmask16) __U,
_MM_FROUND_CUR_DIRECTION);
}
extern __inline __m512d
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_add_pd (__m512d __A, __m512d __B)
{
- return (__m512d) __builtin_ia32_addpd512_mask ((__v8df) __A,
-(__v8df) __B,
-(__v8df)
-_mm512_undefined_pd (),
-(__mmask8) -1,
-_MM_FROUND_CUR_DIRECTION);
+ return __A + __B;
}
extern __inline __m512d
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_add_pd (__m512d __W, __mmask8 __U, __m512d __A, __m512d __B)
{
return (__m512d) __builtin_ia32_addpd512_mask ((__v8df) __A,
(__v8df) __B,
(__v8df) __W,
(__mmask8) __U,
@@ -10633,26 +10628,21 @@ _mm512_maskz_add_pd (__mmask8 __U, __m51
(__v8df)
_mm512_setzero_pd (),
(__mmask8) __U,
_MM_FROUND_CUR_DIRECTION);
}
extern __inline __m512
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_add_ps (__m512 __A, __m512 __B)
{
- return (__m512) __builtin_ia32_addps512_mask ((__v16sf) __A,
- (__v16sf) __B,
- (__v16sf)
- _mm512_undefined_ps (),
- (__mmask16) -1,
- _MM_FROUND_CUR_DIRECTION);
+ return __A + __B;
}
extern __inline __m512
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_add_ps (__m512 __W, __mmask16 __U, __m512 __A, __m512 __B)
{
return (__m512) __builtin_ia32_addps512_mask ((__v16sf) __A,
(__v16sf) __B,
(__v16sf) __W,
(__mmask16) __U,
@@ -10668,26 +10658,21 @@ _mm512_maskz_add_ps (__mmask16 __U, __m5
(__v16sf)
_mm512_setzero_ps (),
(__mmask16) __U,
_MM_FROUND_CUR_DIRECTION);
}
extern __inline __m512d
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_sub_pd (__m512d __A, _
Re: [PATCH, C++, CPP] Add C++1z to the preprocessor. Rename C++1y to C++14.
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, nice job. In the last patch I has missed a few testcases. These are repaired and added to the patch. Sorry for the noise. built and tested on x86_64-linux. OK? libcpp/ 2014-07-26 Edward Smith-Rowland <3dw...@verizon.net> * include/cpplib.h (enum c_lang): Add CLK_GNUCXX1Z, CLK_CXX1Z; Rename CLK_GNUCXX1Y, CLK_CXX1Y to CLK_GNUCXX14, CLK_CXX14; * init.c (struct lang_flags lang_defaults): Add column for trigraphs; Add rows for CLK_GNUCXX1Z, CLK_CXX1Z; (cpp_set_lang): Set trigraphs; (cpp_init_builtins): Set __cplusplus to 201402L for C++14; Set __cplusplus to 201500L for C++17. gcc/c-family/ 2014-07-26 Edward Smith-Rowland <3dw...@verizon.net> * c-common.h (enum cxx_dialect): Add cxx14. * c-opts.c (set_std_cxx1y): Rename to set_std_cxx14; Use cxx14. * c-ubsan.c (ubsan_instrument_shift): Change comment and logic from cxx_dialect == cxx11 || cxx_dialect == cxx1y to cxx_dialect >= cxx11. gcc/cp/ 2014-07-26 Edward Smith-Rowland <3dw...@verizon.net> * decl.c (compute_array_index_type, grokdeclarator, undeduced_auto_decl): Change from cxx1y to cxx14. * parser.c (cp_parser_unqualified_id, cp_parser_pseudo_destructor_name, cp_parser_lambda_introducer, cp_parser_lambda_declarator_opt, cp_parser_decltype, cp_parser_conversion_type_id, cp_parser_simple_type_specifier, cp_parser_type_id_1, cp_parser_template_type_arg, cp_parser_std_attribute, cp_parser_template_declaration_after_export): Ditto. * pt.c (tsubst): Ditto. * semantics.c (force_paren_expr, finish_decltype_type): Ditto. * typeck.c (comp_template_parms_position, cxx_sizeof_or_alignof_type, cp_build_addr_expr_1, maybe_warn_about_useless_cast): Ditto. gcc/ 2014-07-26 Edward Smith-Rowland <3dw...@verizon.net> * doc/invoke.texi: Change c++1y to c++14 and gnu++1y to gnu++14. Deprecate c++1y. Change language to reflect greater confidence in C++14. gcc/testsuite/ 2014-07-26 Edward Smith-Rowland <3dw...@verizon.net> * g++.dg/cpp0x/cplusplus.C: New. * g++.dg/cpp0x/cplusplus_0x.C: New. * g++.dg/cpp0x/auto3.C: Change c++1y to c++14. * g++.dg/cpp0x/auto41.C: Ditto. * g++.dg/cpp0x/auto9.C: Ditto. * g++.dg/cpp0x/initlist26.C: Ditto. * g++.dg/cpp0x/pr59111.C: Ditto. * g++.dg/cpp0x/trailing2.C: Ditto. * g++.dg/cpp1y/attr-deprecated.C: Ditto. * g++.dg/cpp1y/auto-dtor1.C: Ditto. * g++.dg/cpp1y/auto-fn1.C: Ditto. * g++.dg/cpp1y/auto-fn2.C: Ditto. * g++.dg/cpp1y/auto-fn3.C: Ditto. * g++.dg/cpp1y/auto-fn4.C: Ditto. * g++.dg/cpp1y/auto-fn5.C: Ditto. * g++.dg/cpp1y/auto-fn6.C: Ditto. * g++.dg/cpp1y/auto-fn7.C: Ditto. * g++.dg/cpp1y/auto-fn8.C: Ditto. * g++.dg/cpp1y/auto-fn9.C: Ditto. * g++.dg/cpp1y/auto-fn10.C: Ditto. * g++.dg/cpp1y/auto-fn11.C: Ditto. * g++.dg/cpp1y/auto-fn12.C: Ditto. * g++.dg/cpp1y/auto-fn13.C: Ditto. * g++.dg/cpp1y/auto-fn14.C: Ditto. * g++.dg/cpp1y/auto-fn15.C: Ditto. * g++.dg/cpp1y/auto-fn16.C: Ditto. * g++.dg/cpp1y/auto-fn17.C: Ditto. * g++.dg/cpp1y/auto-fn18.C: Ditto. * g++.dg/cpp1y/auto-fn19.C: Ditto. * g++.dg/cpp1y/auto-fn20.C: Ditto. * g++.dg/cpp1y/auto-fn21.C: Ditto. * g++.dg/cpp1y/auto-fn22.C: Ditto. * g++.dg/cpp1y/auto-fn23.C: Ditto. * g++.dg/cpp1y/auto-fn24.C: Ditto. * g++.dg/cpp1y/auto-fn25.C: Ditto. * g++.dg/cpp1y/auto-mangle1.C: Ditto. * g++.dg/cpp1y/auto-neg1.C: Ditto. * g++.dg/cpp1y/digit-sep.C: Ditto. * g++.dg/cpp1y/digit-sep-neg.C: Ditto. * g++.dg/cpp1y/digit-sep-cxx11-neg.C: Ditto. * g++.dg/cpp1y/fn-generic-member-ool.C: Ditto. * g++.dg/cpp1y/lambda-deduce-mult.C: Ditto. * g++.dg/cpp1y/lambda-generic.C: Ditto. * g++.dg/cpp1y/lambda-generic-cfun.C: Ditto. * g++.dg/cpp1y/lambda-generic-dep.C: Ditto. * g++.dg/cpp1y/lambda-generic-mixed.C: Ditto. * g++.dg/cpp1y/lambda-generic-udt.C: Ditto. * g++.dg/cpp1y/lambda-generic-variadic.C: Ditto. * g++.dg/cpp1y/lambda-generic-vla1.C: Ditto. * g++.dg/cpp1y/lambda-generic-x.C: Ditto. * g++.dg/cpp1y/lambda-generic-xcfun.C: Ditto. * g++.dg/cpp1y/lambda-generic-xudt.C: Ditto. * g++.dg/cpp1y/lambda-init.C: Ditto. * g++.dg/cpp1y/lambda-init1.C: Ditto. * g++.dg/cpp1y/lambda-init2.C: Ditto. * g++.dg/cpp1y/lambda-init3.C: Ditto. * g++.dg/cpp1y/lambda-init4.
Re: [committed] Fix pr61077.c test
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.
Re: [Patch, Fortran] PRs 61881/61888 - Fix issues with SIZEOF, CLASS(*) and assumed-rank
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 committed the attached patch (as Rev. 213085) and
added also the PR numbers to the changelog, what I had missed before.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 213084)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,16 @@
2014-07-26 Tobias Burnus
+ PR fortran/61881
+ PR fortran/61888
+ PR fortran/57305
+ * intrinsic.texi (SIZEOF): Document changed behavior
+ for polymorphic arrays.
+
+2014-07-26 Tobias Burnus
+
+ PR fortran/61881
+ PR fortran/61888
+ PR fortran/57305
* check.c (gfc_check_sizeof): Permit for assumed type if and
only if it has an array descriptor.
* intrinsic.c (do_ts29113_check): Permit SIZEOF.
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi (Revision 213084)
+++ gcc/fortran/intrinsic.texi (Arbeitskopie)
@@ -12204,10 +12204,10 @@ number of bytes occupied by the argument. If the
to is returned. If the argument is of a derived type with @code{POINTER}
or @code{ALLOCATABLE} components, the return value does not account for
the sizes of the data pointed to by these components. If the argument is
-polymorphic, the size according to the declared type is returned. The argument
+polymorphic, the size according to the dynamic type is returned. The argument
may not be a procedure or procedure pointer. Note that the code assumes for
arrays that those are contiguous; for contiguous arrays, it returns the
-storage or an array element multiplicated by the size of the array.
+storage or an array element multiplied by the size of the array.
@item @emph{Example}:
@smallexample
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 213084)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -5,6 +5,9 @@
2014-07-26 Tobias Burnus
+ PR fortran/61881
+ PR fortran/61888
+ PR fortran/57305
* gfortran.dg/sizeof_2.f90: Change dg-error.
* gfortran.dg/sizeof_4.f90: New.
* gfortran.dg/storage_size_1.f08: Correct expected
Re: PR 60414: Patch proposal
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 preferably provided outside of the patch as they almost always conflict when applying it. > @@ -1,3 +1,11 @@ > +2014-07-19 Andre Vehreschild > + > + PR fortran/60414 > + * interface.c (compare_parameter): Fix compile bug: During resolution > + of generic an array reference in the actual argument was not > + respected. Fixed by checking, if the ref member is non-null. You don't need to explain why (in the Changelog I mean), only _what_ is changed should be there. > Testcase > + unlimited_polymorphism_18.f90 add. No need for that here; it's redundant with the testsuite Changelog. > + > 2014-06-15 Tobias Burnus > > * symbol.c (check_conflict): Add codimension conflict with > diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c > index b210d18..d84c888 100644 > --- a/gcc/fortran/interface.c > +++ b/gcc/fortran/interface.c > @@ -2156,7 +2156,11 @@ compare_parameter (gfc_symbol *formal, gfc_expr > *actual, >if (symbol_rank (formal) == actual->rank || symbol_rank (formal) == -1) > return 1; > > + /* Only check ranks compatibility, when the actual argument is not a > + reference of an array (foo(i)). A reference into an array is assumed > + when actual->ref is non null. */ >if (actual->ts.type == BT_CLASS && CLASS_DATA (actual)->as > +&& !actual->ref > && CLASS_DATA (actual)->as->rank == symbol_rank (formal)) > return 1; > I think you have spotted the right place where the bug happens, but the patch provided is not completely right for the following reason: actual->ref points to the beginning of the reference chain, so for example if actual is the gfc_expr struct for "var%comp%vec", actual->ref points to the gfc_ref struct for "comp". Furthermore, you have to be aware that even bare array variables without sub-reference get an implicit full array reference in the AST, so if actual is the gfc_expr struct for "array_var", actual->ref is non-null and points (indirectly) to a gfc_array_ref of type AR_FULL. So if you want to check for the absence of trailing sub-reference, you have to walk down to the last reference chain. But then you have to also support the case "var%array_comp%vec(1)" which is supposed to have the rank of array_comp. In fact I think the conditional supposed to support the CLASS cases is completely bogus, and I don't see why the generic conditional just above it wouldn't also support CLASS cases just fine. Did you try removing the CLASS conditional entirely? Mikael
[GSoC][match-and-simplify] reject for that has no pattern defined
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.c (working copy)
@@ -2059,14 +2059,18 @@ parse_for (cpp_reader *r, source_locatio
vec opers = vNULL;
+ const cpp_token *token;
while (1)
{
- const cpp_token *token = peek (r);
+ token = peek (r);
if (token->type != CPP_NAME)
break;
opers.safe_push (get_ident (r));
}
+ if (token->type == CPP_CLOSE_PAREN)
+fatal_at (token, "no pattern defined in for");
+
while (1)
{
Re: [committed] Fix pr61077.c test
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 .* in the regexp.
>
> diff --git gcc/testsuite/gcc.dg/pr61077.c gcc/testsuite/gcc.dg/pr61077.c
> index c0513f7..e29f23c 100644
> --- gcc/testsuite/gcc.dg/pr61077.c
> +++ gcc/testsuite/gcc.dg/pr61077.c
> @@ -5,8 +5,8 @@
> _Atomic int
> main (_Atomic int argc, _Atomic char **argv)
> /* { dg-warning "qualified return type" "return" { target *-*-* } 6 } */
> -/* { dg-warning "qualified parameter type.*int" "parameter" { target *-*-* }
> 6 } */
> -/* { dg-warning "qualified parameter type.*char" "parameter" { target *-*-*
> } 6 } */
> +/* { dg-warning "qualified parameter type\[^\n\]*int" "parameter" { target
> *-*-* } 6 } */
> +/* { dg-warning "qualified parameter type\[^\n\]*char" "parameter" { target
> *-*-* } 6 } */
Usually we use \[^\n\r\] instead.
Jakub
[Committed/AARCH64] Fix *extr_insv_lower_reg pattern
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.md (*extr_insv_lower_reg): Remove + from the read only register. Index: config/aarch64/aarch64.md === --- config/aarch64/aarch64.md (revision 213089) +++ config/aarch64/aarch64.md (working copy) @@ -3390,7 +3390,7 @@ (define_insn "*extr_insv_lower_reg [(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r") (match_operand 1 "const_int_operand" "n") (const_int 0)) - (zero_extract:GPI (match_operand:GPI 2 "register_operand" "+r") + (zero_extract:GPI (match_operand:GPI 2 "register_operand" "r") (match_dup 1) (match_operand 3 "const_int_operand" "n")))] "!(UINTVAL (operands[1]) == 0
Re: [GSoC] generation of Gimple code from isl_ast_node_if
> 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 rewrite_reductions_out_of_ssa (this function duplicates pbbs), the rewrite_reductions_out_of_ssa rewrite out of SSA all the reduction phi nodes of SCOP. What are reduction phi nodes? How are they related to 'reduction'? -- Cheers, Roman Gareev.
