[PATCH] Fix and improve tail recursion with pointer types (PR tree-optimization/58209)
Hi!
The tail recursion optimization hasn't been adjusted for POINTER_PLUS_EXPR
introduction, so we can try to produce PLUS_EXPR with 2 pointer operands or
not optimize testcases we could with preexisting POINTER_PLUS_EXPR.
The following patch attempts to fix that. The last two hunks teach it
to use sizetype for the addend and POINTER_PLUS_EXPR for pointer return
values, the middle-hunk just verifies we never attempt to multiply pointers
and the second hunk makes tail recursion optimization recognize
POINTER_PLUS_EXPR. Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
For the release branches I think I'd lean towards just applying
+ /* For pointers bail out if there are any additions or multiplications. */
+ if ((m || a)
+ && POINTER_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl
+return;
+
instead.
2013-08-23 Jakub Jelinek
PR tree-optimization/58209
* tree-tailcall.c (process_assignment): Handle POINTER_PLUS_EXPR.
(find_tail_calls): Give up for pointer result types if m is non-NULL.
(adjust_return_value_with_ops): For PLUS_EXPR and pointer result type
emit POINTER_PLUS_EXPR.
(create_tailcall_accumulator): For pointer result type accumulate in
sizetype type.
* gcc.c-torture/execute/pr58209.c: New test.
--- gcc/tree-tailcall.c.jj 2013-08-13 12:20:27.0 +0200
+++ gcc/tree-tailcall.c 2013-08-22 11:09:17.913399969 +0200
@@ -305,7 +305,7 @@ process_assignment (gimple stmt, gimple_
if (rhs_class == GIMPLE_UNARY_RHS)
;
else if (op0 == *ass_var
- && (non_ass_var = independent_of_stmt_p (op1, stmt, call)))
+ && (non_ass_var = independent_of_stmt_p (op1, stmt, call)))
;
else if (op1 == *ass_var
&& (non_ass_var = independent_of_stmt_p (op0, stmt, call)))
@@ -320,6 +320,13 @@ process_assignment (gimple stmt, gimple_
*ass_var = dest;
return true;
+case POINTER_PLUS_EXPR:
+ if (op0 != *ass_var)
+ return false;
+ *a = non_ass_var;
+ *ass_var = dest;
+ return true;
+
case MULT_EXPR:
*m = non_ass_var;
*ass_var = dest;
@@ -562,6 +569,10 @@ find_tail_calls (basic_block bb, struct
if (!tail_recursion && (m || a))
return;
+ /* For pointers only allow additions. */
+ if (m && POINTER_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl
+return;
+
nw = XNEW (struct tailcall);
nw->call_gsi = gsi;
@@ -604,15 +615,23 @@ adjust_return_value_with_ops (enum tree_
tree result = make_temp_ssa_name (ret_type, NULL, label);
gimple stmt;
- if (types_compatible_p (TREE_TYPE (acc), TREE_TYPE (op1)))
+ if (POINTER_TYPE_P (ret_type))
+{
+ gcc_assert (code == PLUS_EXPR && TREE_TYPE (acc) == sizetype);
+ code = POINTER_PLUS_EXPR;
+}
+ if (types_compatible_p (TREE_TYPE (acc), TREE_TYPE (op1))
+ && code != POINTER_PLUS_EXPR)
stmt = gimple_build_assign_with_ops (code, result, acc, op1);
else
{
- tree rhs = fold_convert (TREE_TYPE (acc),
- fold_build2 (code,
- TREE_TYPE (op1),
- fold_convert (TREE_TYPE (op1), acc),
- op1));
+ tree tem;
+ if (code == POINTER_PLUS_EXPR)
+ tem = fold_build2 (code, TREE_TYPE (op1), op1, acc);
+ else
+ tem = fold_build2 (code, TREE_TYPE (op1),
+ fold_convert (TREE_TYPE (op1), acc), op1);
+ tree rhs = fold_convert (ret_type, tem);
rhs = force_gimple_operand_gsi (&gsi, rhs,
false, NULL, true, GSI_SAME_STMT);
stmt = gimple_build_assign (result, rhs);
@@ -892,6 +911,9 @@ static tree
create_tailcall_accumulator (const char *label, basic_block bb, tree init)
{
tree ret_type = TREE_TYPE (DECL_RESULT (current_function_decl));
+ if (POINTER_TYPE_P (ret_type))
+ret_type = sizetype;
+
tree tmp = make_temp_ssa_name (ret_type, NULL, label);
gimple phi;
--- gcc/testsuite/gcc.c-torture/execute/pr58209.c.jj2013-08-22
11:15:36.827752889 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr58209.c 2013-08-22
11:15:17.0 +0200
@@ -0,0 +1,32 @@
+/* PR tree-optimization/58209 */
+
+extern void abort (void);
+typedef __INTPTR_TYPE__ T;
+T buf[1024];
+
+T *
+foo (T n)
+{
+ if (n == 0)
+return (T *) buf;
+ T s = (T) foo (n - 1);
+ return (T *) (s + sizeof (T));
+}
+
+T *
+bar (T n)
+{
+ if (n == 0)
+return buf;
+ return foo (n - 1) + 1;
+}
+
+int
+main ()
+{
+ int i;
+ for (i = 0; i < 27; i++)
+if (foo (i) != buf + i || bar (i) != buf + i)
+ abort ();
+ return 0;
+}
Jakub
[PATCH] Fix .lbss handling on x86-64 (PR target/58218)
Hi!
On the following testcase we generate
.section.lbss,"aw",@progbits
which causes assembler warning, it is supposed to be
.section.lbss,"aw",@nobits
instead. The following patch fixes that. I went through all of
default_section_type_flags and looked for which sections the default
decision is based on section name and which sections have large data
counterparts on x86-64 and I hope I've caught up all of them.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8?
2013-08-23 Jakub Jelinek
PR target/58218
* config/i386/x86-64.h (TARGET_SECTION_TYPE_FLAGS): Define.
* config/i386/i386.c (x86_64_elf_section_type_flags): New function.
* gcc.target/i386/pr58218.c: New test.
--- gcc/config/i386/x86-64.h.jj 2013-04-25 23:47:56.0 +0200
+++ gcc/config/i386/x86-64.h2013-08-22 20:15:12.197344591 +0200
@@ -103,3 +103,6 @@ see the files COPYING3 and COPYING.RUNTI
#undef TARGET_ASM_UNIQUE_SECTION
#define TARGET_ASM_UNIQUE_SECTION x86_64_elf_unique_section
+
+#undef TARGET_SECTION_TYPE_FLAGS
+#define TARGET_SECTION_TYPE_FLAGS x86_64_elf_section_type_flags
--- gcc/config/i386/i386.c.jj 2013-08-22 20:30:09.206333231 +0200
+++ gcc/config/i386/i386.c 2013-08-22 22:25:53.249919215 +0200
@@ -4912,6 +4912,31 @@ x86_64_elf_select_section (tree decl, in
return default_elf_select_section (decl, reloc, align);
}
+/* Select a set of attributes for section NAME based on the properties
+ of DECL and whether or not RELOC indicates that DECL's initializer
+ might contain runtime relocations. */
+
+static unsigned int x86_64_elf_section_type_flags (tree, const char *, int)
+ ATTRIBUTE_UNUSED;
+
+static unsigned int
+x86_64_elf_section_type_flags (tree decl, const char *name, int reloc)
+{
+ unsigned int flags = default_section_type_flags (decl, name, reloc);
+
+ if (decl == NULL_TREE
+ && (strcmp (name, ".ldata.rel.ro") == 0
+ || strcmp (name, ".ldata.rel.ro.local") == 0))
+flags |= SECTION_RELRO;
+
+ if (strcmp (name, ".lbss") == 0
+ || strncmp (name, ".lbss.", 5) == 0
+ || strncmp (name, ".gnu.linkonce.lb.", 16) == 0)
+flags |= SECTION_BSS;
+
+ return flags;
+}
+
/* Build up a unique section name, expressed as a
STRING_CST node, and assign it to DECL_SECTION_NAME (decl).
RELOC indicates whether the initial value of EXP requires
--- gcc/testsuite/gcc.target/i386/pr58218.c.jj 2013-08-22 20:26:56.827563563
+0200
+++ gcc/testsuite/gcc.target/i386/pr58218.c 2013-08-22 20:26:48.0
+0200
@@ -0,0 +1,5 @@
+/* PR target/58218 */
+/* { dg-do assemble { target lp64 } } */
+/* { dg-options "-mcmodel=medium" } */
+
+struct { float x[16385]; } a = { { 0.f, } };
Jakub
RE: [PING][PATCH ARM]Extend thumb1_reorg to save more comparison instructions
Ping^2 Thanks. bin -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of bin.cheng Sent: Thursday, August 08, 2013 4:51 PM To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw Subject: [PING][PATCH ARM]Extend thumb1_reorg to save more comparison instructions Ping this patch, http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01057.html Thanks. bin
Re: [PATCH] Fix and improve tail recursion with pointer types (PR tree-optimization/58209)
Jakub Jelinek wrote:
>Hi!
>
>The tail recursion optimization hasn't been adjusted for
>POINTER_PLUS_EXPR
>introduction, so we can try to produce PLUS_EXPR with 2 pointer
>operands or
>not optimize testcases we could with preexisting POINTER_PLUS_EXPR.
>
>The following patch attempts to fix that. The last two hunks teach it
>to use sizetype for the addend and POINTER_PLUS_EXPR for pointer return
>values, the middle-hunk just verifies we never attempt to multiply
>pointers
>and the second hunk makes tail recursion optimization recognize
>POINTER_PLUS_EXPR. Bootstrapped/regtested on x86_64-linux and
>i686-linux,
>ok for trunk?
>
>For the release branches I think I'd lean towards just applying
>+ /* For pointers bail out if there are any additions or
>multiplications. */
>+ if ((m || a)
>+ && POINTER_TYPE_P (TREE_TYPE (DECL_RESULT
>(current_function_decl
>+return;
>+
>instead.
Ok.
Thanks,
Richard.
>2013-08-23 Jakub Jelinek
>
> PR tree-optimization/58209
> * tree-tailcall.c (process_assignment): Handle POINTER_PLUS_EXPR.
> (find_tail_calls): Give up for pointer result types if m is non-NULL.
> (adjust_return_value_with_ops): For PLUS_EXPR and pointer result type
> emit POINTER_PLUS_EXPR.
> (create_tailcall_accumulator): For pointer result type accumulate in
> sizetype type.
>
> * gcc.c-torture/execute/pr58209.c: New test.
>
>--- gcc/tree-tailcall.c.jj 2013-08-13 12:20:27.0 +0200
>+++ gcc/tree-tailcall.c2013-08-22 11:09:17.913399969 +0200
>@@ -305,7 +305,7 @@ process_assignment (gimple stmt, gimple_
> if (rhs_class == GIMPLE_UNARY_RHS)
> ;
> else if (op0 == *ass_var
>- && (non_ass_var = independent_of_stmt_p (op1, stmt, call)))
>+ && (non_ass_var = independent_of_stmt_p (op1, stmt, call)))
> ;
> else if (op1 == *ass_var
> && (non_ass_var = independent_of_stmt_p (op0, stmt, call)))
>@@ -320,6 +320,13 @@ process_assignment (gimple stmt, gimple_
> *ass_var = dest;
> return true;
>
>+case POINTER_PLUS_EXPR:
>+ if (op0 != *ass_var)
>+ return false;
>+ *a = non_ass_var;
>+ *ass_var = dest;
>+ return true;
>+
> case MULT_EXPR:
> *m = non_ass_var;
> *ass_var = dest;
>@@ -562,6 +569,10 @@ find_tail_calls (basic_block bb, struct
> if (!tail_recursion && (m || a))
> return;
>
>+ /* For pointers only allow additions. */
>+ if (m && POINTER_TYPE_P (TREE_TYPE (DECL_RESULT
>(current_function_decl
>+return;
>+
> nw = XNEW (struct tailcall);
>
> nw->call_gsi = gsi;
>@@ -604,15 +615,23 @@ adjust_return_value_with_ops (enum tree_
> tree result = make_temp_ssa_name (ret_type, NULL, label);
> gimple stmt;
>
>- if (types_compatible_p (TREE_TYPE (acc), TREE_TYPE (op1)))
>+ if (POINTER_TYPE_P (ret_type))
>+{
>+ gcc_assert (code == PLUS_EXPR && TREE_TYPE (acc) == sizetype);
>+ code = POINTER_PLUS_EXPR;
>+}
>+ if (types_compatible_p (TREE_TYPE (acc), TREE_TYPE (op1))
>+ && code != POINTER_PLUS_EXPR)
> stmt = gimple_build_assign_with_ops (code, result, acc, op1);
> else
> {
>- tree rhs = fold_convert (TREE_TYPE (acc),
>- fold_build2 (code,
>- TREE_TYPE (op1),
>- fold_convert (TREE_TYPE (op1), acc),
>- op1));
>+ tree tem;
>+ if (code == POINTER_PLUS_EXPR)
>+ tem = fold_build2 (code, TREE_TYPE (op1), op1, acc);
>+ else
>+ tem = fold_build2 (code, TREE_TYPE (op1),
>+ fold_convert (TREE_TYPE (op1), acc), op1);
>+ tree rhs = fold_convert (ret_type, tem);
> rhs = force_gimple_operand_gsi (&gsi, rhs,
> false, NULL, true, GSI_SAME_STMT);
> stmt = gimple_build_assign (result, rhs);
>@@ -892,6 +911,9 @@ static tree
>create_tailcall_accumulator (const char *label, basic_block bb, tree
>init)
> {
> tree ret_type = TREE_TYPE (DECL_RESULT (current_function_decl));
>+ if (POINTER_TYPE_P (ret_type))
>+ret_type = sizetype;
>+
> tree tmp = make_temp_ssa_name (ret_type, NULL, label);
> gimple phi;
>
>--- gcc/testsuite/gcc.c-torture/execute/pr58209.c.jj 2013-08-22
>11:15:36.827752889 +0200
>+++ gcc/testsuite/gcc.c-torture/execute/pr58209.c 2013-08-22
>11:15:17.0 +0200
>@@ -0,0 +1,32 @@
>+/* PR tree-optimization/58209 */
>+
>+extern void abort (void);
>+typedef __INTPTR_TYPE__ T;
>+T buf[1024];
>+
>+T *
>+foo (T n)
>+{
>+ if (n == 0)
>+return (T *) buf;
>+ T s = (T) foo (n - 1);
>+ return (T *) (s + sizeof (T));
>+}
>+
>+T *
>+bar (T n)
>+{
>+ if (n == 0)
>+return buf;
>+ return foo (n - 1) + 1;
>+}
>+
>+int
>+main ()
>+{
>+ int i;
>+ for (i = 0; i < 27; i++)
>+if (foo (i) != buf + i || bar (i) != buf + i)
>+ abort ();
>+ return 0;
>+}
>
> Jakub
Re: RFA: AVR: Support building AVR Linux targets
Hi Joseph, Your patch itself makes sense on general principles, but the concept of an AVR Linux target doesn't - this is an 8-bit processor Really, the bug you've found is that there's an avr-*-* case that is too general, matching nonsensical targets such as AVR Linux rather than just avr-*-none / avr-*-elf. Fair enough. Would you like me to A. Apply the patch anyway. On the general principle that target specific sections in config.gcc add to tmake_file rather than override it. B. Do nothing. On the general principle that if it ain't broke don't fix it. C. Draw up another patch that restricts the AVR patterns in config.gcc to -none and -elf. Cheers Nick
Re: [PATCH i386 1/8] [AVX512] Adjust register classes.
Hello, On 22 Aug 12:06, Richard Henderson wrote: > Ok. I've updated ChangeLog (thanks, HJ!) and checked in to main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00545.html -- Thanks, K
[Patch 2/2] Localization problem in regex
Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html Thanks! -- Tim Shen regex-locale.patch Description: Binary data
Re: [PATCH] Rerun df_analyze after delete_unmarked_insns during DCE
> It was also on the mailing list too. If I'd had the reference to 57940, > I wouldn't have approved the patch given your comment from July 20. Understood. I missed the message on the list and remembered only the PR. -- Eric Botcazou
Re: [PATCH] Fix .lbss handling on x86-64 (PR target/58218)
On Fri, Aug 23, 2013 at 9:08 AM, Jakub Jelinek wrote: > On the following testcase we generate > .section.lbss,"aw",@progbits > which causes assembler warning, it is supposed to be > .section.lbss,"aw",@nobits > instead. The following patch fixes that. I went through all of > default_section_type_flags and looked for which sections the default > decision is based on section name and which sections have large data > counterparts on x86-64 and I hope I've caught up all of them. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8? > > 2013-08-23 Jakub Jelinek > > PR target/58218 > * config/i386/x86-64.h (TARGET_SECTION_TYPE_FLAGS): Define. > * config/i386/i386.c (x86_64_elf_section_type_flags): New function. > > * gcc.target/i386/pr58218.c: New test. > > --- gcc/config/i386/x86-64.h.jj 2013-04-25 23:47:56.0 +0200 > +++ gcc/config/i386/x86-64.h2013-08-22 20:15:12.197344591 +0200 > @@ -103,3 +103,6 @@ see the files COPYING3 and COPYING.RUNTI > > #undef TARGET_ASM_UNIQUE_SECTION > #define TARGET_ASM_UNIQUE_SECTION x86_64_elf_unique_section > + > +#undef TARGET_SECTION_TYPE_FLAGS > +#define TARGET_SECTION_TYPE_FLAGS x86_64_elf_section_type_flags > --- gcc/config/i386/i386.c.jj 2013-08-22 20:30:09.206333231 +0200 > +++ gcc/config/i386/i386.c 2013-08-22 22:25:53.249919215 +0200 > @@ -4912,6 +4912,31 @@ x86_64_elf_select_section (tree decl, in >return default_elf_select_section (decl, reloc, align); > } > > +/* Select a set of attributes for section NAME based on the properties > + of DECL and whether or not RELOC indicates that DECL's initializer > + might contain runtime relocations. */ > + > +static unsigned int x86_64_elf_section_type_flags (tree, const char *, int) > + ATTRIBUTE_UNUSED; > + > +static unsigned int > +x86_64_elf_section_type_flags (tree decl, const char *name, int reloc) Could we avoid prototype with: static unsigned int ATTRIBUTE_UNUSED x86_64_elf_section_type_flags ( ... ) ? The patch is OK with or without this change. We already have a mixture of declarations there... Thanks, Uros.
Re: Fix buffer overflow in ipa_profile
On 08/21/2013 04:30 PM, Jan Hubicka wrote:
Index: ipa.c
===
--- ipa.c (revision 201890)
+++ ipa.c (working copy)
@@ -1397,7 +1397,7 @@ ipa_profile_read_summary (void)
static unsigned int
ipa_profile (void)
{
- struct cgraph_node **order = XCNEWVEC (struct cgraph_node *, cgraph_n_nodes);
+ struct cgraph_node **order;
struct cgraph_edge *e;
int order_pos;
bool something_changed = false;
@@ -1575,6 +1575,7 @@ ipa_profile (void)
nuseless, nuseless * 100.0 / nindirect,
nconverted, nconverted * 100.0 / nindirect);
+ order = XCNEWVEC (struct cgraph_node *, cgraph_n_nodes);
order_pos = ipa_reverse_postorder (order);
for (i = order_pos - 1; i >= 0; i--)
{
Shouldn't the definition of order be moved down to the initialization,
like in the attached patch?
--
Florian Weimer / Red Hat Product Security Team
Index: gcc/ipa.c
===
--- gcc/ipa.c (revision 201937)
+++ gcc/ipa.c (working copy)
@@ -1397,9 +1397,7 @@
static unsigned int
ipa_profile (void)
{
- struct cgraph_node **order;
struct cgraph_edge *e;
- int order_pos;
bool something_changed = false;
int i;
gcov_type overall_time = 0, cutoff = 0, cumulated = 0, overall_size = 0;
@@ -1575,8 +1573,9 @@
nuseless, nuseless * 100.0 / nindirect,
nconverted, nconverted * 100.0 / nindirect);
- order = XCNEWVEC (struct cgraph_node *, cgraph_n_nodes);
- order_pos = ipa_reverse_postorder (order);
+ struct cgraph_node **order
+= XCNEWVEC (struct cgraph_node *, cgraph_n_nodes);
+ int order_pos = ipa_reverse_postorder (order);
for (i = order_pos - 1; i >= 0; i--)
{
if (order[i]->local.local && cgraph_propagate_frequency (order[i]))
Re: [Patch 1/2] Rewrite regex scanner
On 23 August 2013 10:15, Tim Shen wrote:
> These two patches are not logically relative, but the next patch is
> based on this one.
>
> This patch of the regex scanner(or lexer) supports all styles
> specified by N3376. It shall build an abstract layer of regex token
> sequence, so that, ideally, the parser and executor do not need to
> care which style they are handling.
>
> Originally _Scanner is a class in regex_compiler.{h,tcc}. Since it
> could be a standlone module, I move it to regex_scanner.{h,tcc}.
>
> I try my best to reduce duplicated code and make the logic
> clear(_M_escape_map and _M_spec_char help a lot). However, I'm still
> worrying about potential unexpected behaviors, because it's not about
> correctness, but about reading standards.
>
> More testcases are welcome!
>
> Thanks!
>
> PS: For personal reasons, I probably cannot make a response in several
> days, but I'll try my best ;)
If this bootstraps and passes tests then it's OK.
I would rearrange the ChangeLog, to put
* include/bits/regex_executor.tcc: Don't use reference for submatch.
after regex_scanner.tcc, so that the files the _Scanner is moved from
come immediately before the files it is moved to, otherwise it reads
like "move _Scanner from ... don't use reference ... here" which
doesn't make much sense :-)
Thanks.
Re: [Patch 2/2] Localization problem in regex
On 23 August 2013 10:17, Tim Shen wrote: > Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html This is OK too, thanks for the quick fix to the locale issue!
Re: [go-nuts] Re: libtool update for powerpc64le-linux
On Thu, Aug 22, 2013 at 06:09:40PM -0700, Ian Lance Taylor wrote: > On Thu, Aug 22, 2013 at 5:35 PM, Alan Modra wrote: > > On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote: > >> I'd like to apply the following patch to the gcc repository (well, > >> excluding the libgo part which I'm hoping someone will apply for me to > >> the master go repository). I know the normal procedure for autotools > >> is to submit upstream then update when the patch is in the upstream > >> autotools repository, but this simple libtool patch has been awaiting > >> review for over two months. > > > > The libtool.m4 patch has finally been reviewed and accepted upstream. > > > > I'd like to import upstream libtool into gcc to support powerpc64le, > > and please, can someone do the same for upstream libgo? The reason we > > need this patch is that on a powerpc64le linux host where the compiler > > defaulted to producing 64-bit objects (which is how we generally build > > compilers nowadays) libtool added -m elf64ppc to $LD. Being the > > option for 64-bit big-endian, that caused complete failure for > > 64-bit little-endian. > > I've updated libgo/config/libtool.m4 and libgo/configure on mainline. Thanks Ian, and I'm glad to see you patched libtool.m4 rather than importing upstream. Testing showed that importing libtool.m4 from upstream isn't such a great idea. For starters, we need to also import a new ltmain.sh, and then I ran into build problems in libsanitizer. libtool: compile: unable to infer tagged configuration libtool: error: specify a tag with '--tag' make[4]: *** [tsan_rtl_amd64.lo] Error 1 After rather a lot of time digging into libtool, I think this is due to a bad IFS init. The function that emits the error, func_infer_tag tries to see whether libtool is using $CC and fails because $CC has trailing spaces and a calculated $CC_expanded has tabs between the words of $CC. -- Alan Modra Australia Development Lab, IBM
Re: [Patch 2/2] Localization problem in regex
Hi, On 08/23/2013 11:17 AM, Tim Shen wrote: 2013-08-23 Tim Shen * include/bits/regex.h: Fix callers. * include/bits/regex_compiler.h: Store _Traits reference. * include/bits/regex_executor.h: Add _Traits member for _DFSExecutor. * include/bits/regex_executor.tcc: Likewise. * testsuite/28_regex/algorithms/regex_match/extended/wstring_locale.cc: New. Thanks a lot indeed. But: "Fix callers" of *what*?!? And from *where*? To be really honest this kind of ChangeLog entry doesn't make much sense. Please get used to list the specific functions you are changing. It's important. Thanks, Paolo.
Clean up pretty printers [11/n]
This patchlet is an easy low hanging fruit in the pile of local patches
I have. It turns old style emulation of inline functions into real inline
functions.
Tested on x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-23 Gabriel Dos Reis
* pretty-print.h (pp_newline_and_flush): Declare. Remove macro
definition.
(pp_newline_and_indent): Likewise.
(pp_separate_with): Likewise.
* pretty-print.c (pp_newline_and_flush): Define.
(pp_newline_and_indent): Likewise.
(pp_separate_with): Likewise.
Index: pretty-print.c
===
--- pretty-print.c (revision 201939)
+++ pretty-print.c (working copy)
@@ -902,6 +902,37 @@
pp->padding = pp_none;
}
}
+
+// Add a newline to the pretty printer PP and flush formatted text.
+
+void
+pp_newline_and_flush (pretty_printer *pp)
+{
+ pp_newline (pp);
+ pp_flush (pp);
+ pp_needs_newline (pp) = false;
+}
+
+// Add a newline to the pretty printer PP, followed by indentation.
+
+void
+pp_newline_and_indent (pretty_printer *pp, int n)
+{
+ pp_indentation (pp) += n;
+ pp_newline (pp);
+ pp_indent (pp);
+ pp_needs_newline (pp) = false;
+}
+
+// Add separator C, followed by a single whitespace.
+
+void
+pp_separate_with (pretty_printer *pp, char c)
+{
+ pp_character (pp, c);
+ pp_space (pp);
+}
+
/* The string starting at P has LEN (at least 1) bytes left; if they
start with a valid UTF-8 sequence, return the length of that
Index: pretty-print.h
===
--- pretty-print.h (revision 201939)
+++ pretty-print.h (working copy)
@@ -246,26 +246,8 @@
#define pp_backquote(PP)pp_character (PP, '`')
#define pp_doublequote(PP) pp_character (PP, '"')
#define pp_underscore(PP) pp_character (PP, '_')
-#define pp_newline_and_flush(PP) \
- do { \
-pp_newline (PP); \
-pp_flush (PP); \
-pp_needs_newline (PP) = false; \
- } while (0)
-#define pp_newline_and_indent(PP, N) \
- do { \
-pp_indentation (PP) += N;\
-pp_newline (PP); \
-pp_indent (PP); \
-pp_needs_newline (PP) = false; \
- } while (0)
#define pp_maybe_newline_and_indent(PP, N) \
if (pp_needs_newline (PP)) pp_newline_and_indent (PP, N)
-#define pp_separate_with(PP, C) \
- do { \
- pp_character (PP, C); \
- pp_space (PP); \
- } while (0)
#define pp_scalar(PP, FORMAT, SCALAR)\
do \
{\
@@ -298,6 +280,9 @@
extern const char *pp_last_position_in_text (const pretty_printer *);
extern void pp_emit_prefix (pretty_printer *);
extern void pp_append_text (pretty_printer *, const char *, const char *);
+extern void pp_newline_and_flush (pretty_printer *);
+extern void pp_newline_and_indent (pretty_printer *, int);
+extern void pp_separate_with (pretty_printer *, char);
/* If we haven't already defined a front-end-specific diagnostics
style, use the generic one. */
[ubsan] Fix bootstrap comparison
This patch fixes bootstrap comparison when doing bootstrap
with -fsanitize=undefined enabled. We need to hash the UID of the
type and also I had to switch two statements; we need to get
TYPE_MAIN_VARIANT of the type first...
Hence, no more bootstrap comparison failures. Woohoo!
Tested x86_64-linux, applying to the ubsan branch.
2013-08-23 Marek Polacek
* ubsan.c (ubsan_typedesc_hasher::hash): Hash the TYPE_UID of the
type.
(ubsan_type_descriptor): Get TYPE_MAIN_VARIANT before initializing
the type descriptor.
--- gcc/ubsan.c.mp 2013-08-23 14:28:15.780955545 +0200
+++ gcc/ubsan.c 2013-08-23 14:28:47.467059363 +0200
@@ -60,7 +60,7 @@ struct ubsan_typedesc_hasher
inline hashval_t
ubsan_typedesc_hasher::hash (const ubsan_typedesc *data)
{
- return iterative_hash_object (data->type, 0);
+ return iterative_hash_object (TYPE_UID (data->type), 0);
}
/* Compare two data types. */
@@ -298,11 +298,11 @@ ubsan_type_descriptor (tree type)
{
hash_table ht = get_typedesc_hash_table ();
ubsan_typedesc d;
- ubsan_typedesc_init (&d, type, NULL);
/* See through any typedefs. */
type = TYPE_MAIN_VARIANT (type);
+ ubsan_typedesc_init (&d, type, NULL);
ubsan_typedesc **slot = ht.find_slot (&d, INSERT);
if (*slot != NULL)
/* We have the VAR_DECL in the table. Return it. */
Marek
Re: [ubsan] Fix bootstrap comparison
On Fri, Aug 23, 2013 at 02:37:56PM +0200, Marek Polacek wrote:
> This patch fixes bootstrap comparison when doing bootstrap
> with -fsanitize=undefined enabled. We need to hash the UID of the
> type and also I had to switch two statements; we need to get
> TYPE_MAIN_VARIANT of the type first...
> Hence, no more bootstrap comparison failures. Woohoo!
>
> Tested x86_64-linux, applying to the ubsan branch.
>
> 2013-08-23 Marek Polacek
>
> * ubsan.c (ubsan_typedesc_hasher::hash): Hash the TYPE_UID of the
> type.
> (ubsan_type_descriptor): Get TYPE_MAIN_VARIANT before initializing
> the type descriptor.
>
> --- gcc/ubsan.c.mp2013-08-23 14:28:15.780955545 +0200
> +++ gcc/ubsan.c 2013-08-23 14:28:47.467059363 +0200
> @@ -60,7 +60,7 @@ struct ubsan_typedesc_hasher
> inline hashval_t
> ubsan_typedesc_hasher::hash (const ubsan_typedesc *data)
> {
> - return iterative_hash_object (data->type, 0);
> + return iterative_hash_object (TYPE_UID (data->type), 0);
Why not just return TYPE_UID (data->type); ?
Anyway, once you change the hash table uses into pointer_map, this will
all go away.
Jakub
Re: GDB hooks for debugging GCC
Hi,
On Fri, Aug 02, 2013 at 09:48:43PM -0400, David Malcolm wrote:
> GDB 7.0 onwards supports hooks written in Python to improve the
> quality-of-life within the debugger. The best known are the
> pretty-printing hooks [1], which we already use within libstdc++ for
> printing better representations of STL containers.
>
> I've written debug hooks for when the inferior process is *GCC*, which
> I'm attaching.
>
For what it is worth, I have put together a python script that I do
plan to use as a replacement for the current .gdbinit. However, I
have intended it to be just for my personal use only so I have never
bothered to clean it up in anyway. I do not like copying .gdbinit
around manually and I planned to (at least for now) be loading the
script manually using the source gdb command - everything else just
looked too complicated (and I did not manage to put it into ~/gdbinit
in any non-dumb way).
In summary, the attached script provides the following :
- Commands:
- pt to call debug_tree on its one argument
- pge to call debug_generic_expr on its one argument
- pgg to call debug_gimple_stmt on its one argument
- pr to call debug_rtx on its one argument
- Very short and basic pretty Printers for
- tree
- symtab_node
- cgraph_node
- varpool_node
- cgraph_edge
- ipa_jump_func
- Functions accessible from gdb prompt
- $vec_len to get a vector's length
- $vec_item to get an ite in a vector
- $cgn_count_callees to count callers of a cgraph_node
- $cgn_count_callees to count callees of a cgraph_node
- sets breakpoints in fancy_abort and internal_error if there are no
breakpoints there yet.
...and I plan to add more. I am not sure how I will coexist with an
"official" python extension, probably by regularly stealing stuff from
it (I already did) but running my own, as long as it will be feasible
:-) I suppose the "official" script can take some stuff from mine too,
if anything seems useful.
In any event, thanks for posting it,
Martin
import gdb
from gdb.printing import PrettyPrinter, register_pretty_printer, RegexpCollectionPrettyPrinter
# Basic commands to call internal pretty printers
class CallCompiledPrinter (gdb.Command):
"""Base class to facilitate commands calling internal pretty printers"""
def __init__(self, command, function, typename = "tree"):
super (CallCompiledPrinter, self).__init__(command, gdb.COMMAND_DATA,
gdb.COMPLETE_SYMBOL)
self.function = function
self.typename = typename
return
def invoke (self, arg_str, from_tty):
argv = gdb.string_to_argv(arg_str)
if len (argv) != 1:
raise gdb.GdbError ("Provide the tree to print as an argument");
try:
t = gdb.parse_and_eval (argv[0])
except:
raise gdb.GdbError ("Could not evaluate %s" % argv[0])
if t.is_optimized_out:
raise gdb.GdbError ("Value optimized out")
self.dont_repeat()
gdb.execute ("call %s ((%s) 0x%x)" % (self.function, self.typename,
long(t)))
return
class TreeDebug (CallCompiledPrinter):
"""Call debug_tree on a tree"""
def __init__(self):
super (TreeDebug, self).__init__("pt", "debug_tree")
return
class TreeGenericExpr (CallCompiledPrinter):
"""Call debug_generic_expr on a tree"""
def __init__(self):
super (TreeGenericExpr, self).__init__("pge", "debug_generic_expr")
return
class GimpleDebug (CallCompiledPrinter):
"""Call debug_gimple_stmt on a gimple statement"""
def __init__(self):
super (GimpleDebug, self).__init__("pgg", "debug_gimple_stmt", "gimple")
return
class RtxDebug (CallCompiledPrinter):
"""Call debug_rtx on an rtx"""
def __init__(self):
super (RtxDebug, self).__init__("pr", "debug_rtx", "rtl")
return
# Vector related stuff
def vec_get_length (gdbval):
try:
if long(gdbval) == 0:
return 0
except:
pass
try:
gdbval = gdbval["vec_"]
except:
pass
try:
if long(gdbval) == 0:
return 0
except:
pass
pfx = gdbval["vecpfx_"]
return int(pfx["num_"])
def vec_get_item (gdbval, i):
"""Return i-th item in vector represented by gdbval"""
l = True;
try:
l = long(gdbval)
except:
pass
if l == 0:
raise gdb.GdbError("Cannot access item of NULL vector")
try:
gdbval = gdbval["vec_"]
except:
pass
try:
l = long(gdbval)
except:
pass
if l == 0:
raise gdb.GdbError("Cannot access item of NULL vector")
if i >= vec_get_length(gdbval):
raise gdb.GdbError(("Index %i out of vector bounds %i"
% (i, vec_get_length(gdbval
return gdbval["vecdata_"][i]
def vec_iter (gdbval):
Re: [ubsan] Fix bootstrap comparison
On Fri, Aug 23, 2013 at 02:44:49PM +0200, Jakub Jelinek wrote: > Why not just return TYPE_UID (data->type); ? Wasn't aware it's enough. > Anyway, once you change the hash table uses into pointer_map, this will > all go away. Right. Marek
[C++ RFC / Patch] Another recursive template instantiation issue (c++/51488, etc)
Hi,
besides the issue discussed a bit some time ago, we have got in Bugzilla
a number of other issues, all essentially dups of each other (modulo
irrelevant details, AFAICS)
c++/51488
c++/53618
c++/58059
c++/56163 (this is two bugs, the second one is dup of c++/55843)
In these the infinite recursion involves instantiate_class_template_1
but via most_specialized_class (c++/51488 has a backtrace) thus at the
beginning of the function, and we don't catch it.
To explain *in practice* what I mean, the attached patchlet p avoid all
these crashes (+ passes the testsuite as-is modulo an XPASS for line 8
of template/recurse.C).
Unfortunately, at the time I didn't follow in detail the implementation
of the push_tinst_level mechanism, now I see it used many times with
little variations, thus I definitely need further guidance (my patchlet
is loosely inspired by the use in maybe_instantiate_noexcept). In
particular, I fear memory leaks or mismanagement (I see a ggc_free
(tinst); in instantiate_alias_template which I don't fully understand).
Also, I wonder if we could provide more detailed information...
Thanks in advance!
Paolo.
///
Index: pt.c
===
--- pt.c(revision 201927)
+++ pt.c(working copy)
@@ -8658,7 +8658,15 @@ instantiate_class_template_1 (tree type)
/* Determine what specialization of the original template to
instantiate. */
- t = most_specialized_class (type, templ, tf_warning_or_error);
+
+ if (push_tinst_level (type))
+{
+ t = most_specialized_class (type, templ, tf_warning_or_error);
+ pop_tinst_level ();
+}
+ else
+t = error_mark_node;
+
if (t == error_mark_node)
{
TYPE_BEING_DEFINED (type) = 1;
[PING 3] [Patch RX] Add assembler option "-mcu" for generating assembler
Hi,
Please find the patch to add assembler option "-mcu" for generating assembler
error messages when target not supporting hardware FPU were seeing FPU code,
namely RX100 and RX200.
KPIT has recently submitted a patch to add warnings of RX variants that do not
have hardware FPU support,
http://www.sourceware.org/ml/binutils/2013-07/msg00085.html
Index: gcc/config/rx/rx.h
===
--- gcc/config/rx/rx.h.orig 2013-07-18 18:03:11.0 +0530
+++ gcc/config/rx/rx.h 2013-07-11 14:57:17.0 +0530
@@ -101,6 +101,7 @@
%{mpid} \
%{mint-register=*} \
%{mgcc-abi:-mgcc-abi} %{!mgcc-abi:-mrx-abi} \
+%{mcpu=*} \
"
No regression found with this patch.
Please let me know if this is OK?
Regards,
Sandeep Kumar Singh,
KPIT Cummins InfoSystems Ltd.
Pune, India
gas/config:
2013-07-18 Sandeep Kumar Singh
* rx.h: Add option -mcpu for target variants RX100 and RX200.
Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)
Hi Steve and Kaz,
Sorry about that. Kaz has a fix shown in rtl-optimization/58220:
--- ORIG/trunk/gcc/final.c 2013-08-22 09:43:35.0 +0900
+++ trunk/gcc/final.c 2013-08-22 14:36:51.0 +0900
@@ -1650,7 +1650,7 @@ reemit_insn_block_notes (void)
rtx insn, note;
insn = get_insns ();
- for (; insn; insn = next_insn (insn))
+ for (; insn; insn = NEXT_INSN (insn))
{
tree this_block;
It should be committed soon, by Kaz or myself once testing finishes.
Please let me know if that doesn't fix your failures.
Thanks,
Teresa
On Thu, Aug 22, 2013 at 4:59 PM, Kaz Kojima wrote:
> Steve Ellcey wrote:
>> On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:
>>
>>> 2013-08-19 Teresa Johnson
>>>
>>> PR rtl-optimizations/57451
>>> * final.c (reemit_insn_block_notes): Prevent lexical blocks
>>> from crossing split section boundaries.
>>>
>>> * testsuite/g++.dg/tree-prof/pr57451.C: New test.
>>
>> Teresa,
>>
>> This patch is causing a problem in my mips compiler. I am creating a
>> cross-toolchain running on x86 targeting mips-mti-linux-gnu and if I
>> compile glibc using a GCC that has this patch all of the programs I
>> compile go into an infinite loop when run under the qemu simulator. I
>> think it is the dynamic linker that is getting miscompiled, but I
>> haven't tracked down the exact nature of the miscompilation yet. Has
>> anyone else reported any problems with it? I am adding Richard
>> Sandiford to the email list since he is a mips expert and also might
>> have some insight to using next_active_insn vs. next_real_insn vs.
>> next_insn, though it doesn't look like you have changed what is used
>> here.
>
> Similar on SH. I've just filed rtl-optimization/58220.
>
> Regards,
> kaz
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [C++ patch] Move FINAL flag to middle-end trees.
On 08/22/2013 12:05 PM, Paolo Carlini wrote: Sorry if I'm saying something rather vague: I suppose you mean BINFO_FLAG_6? Because it's the last one. No, that's a language-specific flag. Jason
Re: [C++ patch] Move FINAL flag to middle-end trees.
On 08/22/2013 11:22 AM, Jan Hubicka wrote: This option did not occured to me and of course I would be bit fearing of C++ FE not having binfos ready all the time it wants to touch the type. But probably you know if that can happen ;) Classes (including struct and union) always have binfos. Jason
Re: [C++ patch] Move FINAL flag to middle-end trees.
> On 08/22/2013 11:22 AM, Jan Hubicka wrote: > >This option did not occured to me and of course I would be bit fearing of > >C++ FE > >not having binfos ready all the time it wants to touch the type. But > >probably > >you know if that can happen ;) > > Classes (including struct and union) always have binfos. Ok, I will prepare variant using public_flag of BINFO that seeems unused. I.e. having BINFO_FINAL_P and C++ specific macro CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)). Or shall I go ahead and update all users of CLASSTYPE_FINAL? Thank you, Honza
Re: [C++ patch] Move FINAL flag to middle-end trees.
On 08/23/2013 03:47 PM, Jason Merrill wrote: On 08/22/2013 12:05 PM, Paolo Carlini wrote: Sorry if I'm saying something rather vague: I suppose you mean BINFO_FLAG_6? Because it's the last one. No, that's a language-specific flag. Ah great. Thanks! Paolo.
Re: [Patch 2/2] Localization problem in regex
On Fri, Aug 23, 2013 at 6:29 PM, Paolo Carlini wrote: > Thanks a lot indeed. But: "Fix callers" of *what*?!? And from *where*? To be > really honest this kind of ChangeLog entry doesn't make much sense. Please > get used to list the specific functions you are changing. It's important. I see. Actually I find a mistake by this review /w\, thanks! -- Tim Shen regex-locale.patch Description: Binary data
Re: [Patch 1/2] Rewrite regex scanner
On Fri, Aug 23, 2013 at 5:40 PM, Jonathan Wakely wrote: > I would rearrange the ChangeLog, to put > > * include/bits/regex_executor.tcc: Don't use reference for submatch. > > after regex_scanner.tcc, so that the files the _Scanner is moved from > come immediately before the files it is moved to, otherwise it reads > like "move _Scanner from ... don't use reference ... here" which > doesn't make much sense :-) Hmmm...it turns out there's no specified file order? // I always use default order before. So here it is. By the way, it seems to take surprisingly short time to review; after all, it's a huge patch. -- Tim Shen changelog Description: Binary data
RE: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
Hello,
This is new patch version.
Optimization does not use BIT_FIELD_REF any more, instead it generates new
COMPONENT_REF and FIELD_DECL.
Existing Bit field representative is associated with newly created field
declaration.
During analysis phase optimization uses bit field representatives when deciding
which bit-fields accesses can be merged.
Instead of having separate pass optimization is moved to tree-sra.c and
executed with sra early.
New test case involving unions is added.
Also, some other comments received on first patch are applied in new
implementation.
Example:
Original code:
D.1351;
D.1350;
D.1349;
D.1349_2 = p1_1(D)->f1;
p2_3(D)->f1 = D.1349_2;
D.1350_4 = p1_1(D)->f2;
p2_3(D)->f2 = D.1350_4;
D.1351_5 = p1_1(D)->f3;
p2_3(D)->f3 = D.1351_5;
Optimized code:
D.1358;
_16 = pr1_2(D)->_field0;
pr2_4(D)->_field0 = _16;
Algorithm works on basic block level and consists of following 3 major steps:
1. Go trough basic block statements list. If there are statement pairs that
implement copy of bit field content from one memory location to another record
statements pointers and other necessary data in corresponding data structure.
2. Identify records that represent adjacent bit field accesses and mark them as
merged.
3. Modify trees accordingly.
New command line option "-ftree-bitfield-merge" is introduced.
Tested - passed gcc regression tests.
Changelog -
gcc/ChangeLog:
2013-08-22 Zoran Jovanovic (zoran.jovano...@imgtec.com)
* Makefile.in : Added tree-sra.c to GTFILES.
* common.opt (ftree-bitfield-merge): New option.
* doc/invoke.texi: Added reference to "-ftree-bitfield-merge".
* tree-sra.c (ssa_bitfield_merge): New function.
Entry for (-ftree-bitfield-merge).
(bitfield_stmt_access_pair_htab_hash): New function.
(bitfield_stmt_access_pair_htab_eq): New function.
(cmp_access): New function.
(create_and_insert_access): New function.
(get_bit_offset): New function.
(get_merged_bit_field_size): New function.
(add_stmt_access_pair): New function.
* dwarf2out.c (simple_type_size_in_bits): moved to tree.c.
(field_byte_offset): declaration moved to tree.h, static removed.
* testsuite/gcc.dg/tree-ssa/bitfldmrg1.c: New test.
* testsuite/gcc.dg/tree-ssa/bitfldmrg2.c: New test.
* tree-ssa-sccvn.c (expressions_equal_p): moved to tree.c.
* tree-ssa-sccvn.h (expressions_equal_p): declaration moved to tree.h.
* tree.c (expressions_equal_p): moved from tree-ssa-sccvn.c.
(simple_type_size_in_bits): moved from dwarf2out.c.
* tree.h (expressions_equal_p): declaration added.
(field_byte_offset): declaration added.
Patch -
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6034046..dad9337 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3831,6 +3831,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h
$(srcdir)/coretypes.h \
$(srcdir)/vtable-verify.c \
$(srcdir)/asan.c \
$(srcdir)/tsan.c $(srcdir)/ipa-devirt.c \
+ $(srcdir)/tree-sra.c \
@all_gtfiles@
# Compute the list of GT header files from the corresponding C sources,
diff --git a/gcc/common.opt b/gcc/common.opt
index 9082280..fe0ecd9 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2160,6 +2160,10 @@ ftree-sra
Common Report Var(flag_tree_sra) Optimization
Perform scalar replacement of aggregates
+ftree-bitfield-merge
+Common Report Var(flag_tree_bitfield_merge) Init(0) Optimization
+Enable bit-field merge on trees
+
ftree-ter
Common Report Var(flag_tree_ter) Optimization
Replace temporary expressions in the SSA->normal pass
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index dae7605..7abe538 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -412,7 +412,7 @@ Objective-C and Objective-C++ Dialects}.
-fsplit-ivs-in-unroller -fsplit-wide-types -fstack-protector @gol
-fstack-protector-all -fstack-protector-strong -fstrict-aliasing @gol
-fstrict-overflow -fthread-jumps -ftracer -ftree-bit-ccp @gol
--ftree-builtin-call-dce -ftree-ccp -ftree-ch @gol
+-ftree-bitfield-merge -ftree-builtin-call-dce -ftree-ccp -ftree-ch @gol
-ftree-coalesce-inline-vars -ftree-coalesce-vars -ftree-copy-prop @gol
-ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse @gol
-ftree-forwprop -ftree-fre -ftree-loop-if-convert @gol
@@ -7646,6 +7646,11 @@ pointer alignment information.
This pass only operates on local scalar variables and is enabled by default
at @option{-O} and higher. It requires that @option{-ftree-ccp} is enabled.
+@item -ftree-bitfield-merge
+@opindex ftree-bitfield-merge
+Combines several adjacent bit-field accesses that copy values
+from one memory location to another into single bit-field access.
+
@item -ftree-ccp
@opindex ftree-ccp
Perform sparse conditional constant propagation (CCP) on trees. This
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index fc1c3f2..f3530ef 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3104,8 +3104,6 @@ static HOST_WIDE_INT ceiling (HOST_WIDE_INT, unsigned
int);
static tree field
Re: [C++ patch] Move FINAL flag to middle-end trees.
On 08/23/2013 09:57 AM, Jan Hubicka wrote: Ok, I will prepare variant using public_flag of BINFO that seeems unused. I.e. having BINFO_FINAL_P and C++ specific macro CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)). Sounds good. Jason
Re: [RFC] Issues with intraprocedural devirtualization
> Hi, > I went through some statistics on firefox build (it is a source combining > many coding styles). > I was basically curious where we do devirtualization. The result is: > > Before inline (i.e. important devirtualization) > 624 ssa-pre devirt 0 > this is interaprocedural devirutalization happening during early FRE > by propagating > constant accesses into vtables entries. (i.e. not type based at all) > > 10 ssa-pre devirt2 0 > this is type based intraprocedural analysis during early optimizations > 177 ipa-prop devirt > devirtualization in ipa-cp > 243 ipa-cp inline devirt > this is devirtualization happening at IPA stage during inlining The promesed stats with this change. 59 Single type devirt this is my new code devirtualizing types in anonymous namespaces when there is only one node. I will send separate patch for this. 696 ssa-pre devirt 0 11% better than w/o patch (probably because of more early inline) 537 ipa-cp inline devirt 120% better than w/o patch 5 ssa-pre devirt2 0 50% less probably because I handle it earlier 309 ipa-prop devirt 74% more 10 gimple-fold devirt2 0 type based code in gimple-fold. It now does something. > > After inline (i.e. devirtualization where we missed the chance to do > something useful) > 82 gimple-fold devirt 1 > this is the gimple-fold function in question (it also run pre-inline > but apparently > always fail. I will try the proposed patch and sed updated stats > tomorrow) I was having trakcing bug here. This is standard folding based propagation. The type based path never suceeded. > > 27 ipa-prop intra devirt 1 > intraprocedural type based analysis >1569 ssa-pre devirt 1 > this is interaprocedural devirutalization happening during late FRE > (not type based) 83 gimple-fold devirt 1 One more. 7 gimple-fold devirt2 1 type based path now does something 27 ssa-pre devirt2 1 type based path, no change. 1847 ssa-pre devirt 1 17% up. > > So overall type based analyssi accounts 430 devirtualizations pre-inline and > 109 post inline. > Low level propagation of vtable accesses gets 624 pre-inline and 1569 post > inline. > > Obviously the post inline numbers shows that we miss majority of interesting > cases. > I hope we can noticeably improve this. > > I am re-building with the proposed change now. > > Honza
Re: [Patch 2/2] Localization problem in regex
On 08/23/2013 03:59 PM, Tim Shen wrote: On Fri, Aug 23, 2013 at 6:29 PM, Paolo Carlini wrote: Thanks a lot indeed. But: "Fix callers" of *what*?!? And from *where*? To be really honest this kind of ChangeLog entry doesn't make much sense. Please get used to list the specific functions you are changing. It's important. I see. Actually I find a mistake by this review /w\, thanks! Great. But please but the names of the functions you are changing between round brackets. You have tons of examples everywhere. Paolo.
Re: [C++ patch] Move FINAL flag to middle-end trees.
> On 08/23/2013 09:57 AM, Jan Hubicka wrote:
> >Ok, I will prepare variant using public_flag of BINFO that seeems unused.
> >I.e. having BINFO_FINAL_P and C++ specific macro
> >CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)).
>
> Sounds good.
Hi,
this is patch I am testing. Does it look OK?
I have run across the following testcase:
namespace {
class A {
public:
virtual int foo(void)
{
return 0;
}
};
}
class A *b;
main()
{
return b->foo();
}
here I now can devirtualize b->foo into A because A is in anonymous namespace.
We however won't remove b because it is externally visible. Is it valid to
bring b local based on fact that A is anonymous and thus no valid C++ program
can read it?
The pointer type probably isn't anonymous anymore?
Honza
* cp-tree.h (struct lang_type_class): Free is_final bit.
(CLASSTYPE_FINAL): Define using BINFO_FINAL_P.
(DECL_FINAL_P): Remove.
* pt.c (instantiate_class_template_1): Guard CLASSTYPE_FINAL
by CLASS_TYPE_P
* tree.h (tree_base): Add BINFO_FINAL_P docs
(BINFO_FINAL_P): Define.
(tree_decl_with_vis): One bit is taken for FINAL.
(DECL_FINAL_P): New.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 201910)
+++ cp/cp-tree.h(working copy)
@@ -1416,7 +1416,6 @@ struct GTY(()) lang_type_class {
unsigned has_complex_move_ctor : 1;
unsigned has_complex_move_assign : 1;
unsigned has_constexpr_ctor : 1;
- unsigned is_final : 1;
/* When adding a flag here, consider whether or not it ought to
apply to a template instance if it applies to the template. If
@@ -1425,7 +1424,7 @@ struct GTY(()) lang_type_class {
/* There are some bits left to fill out a 32-bit word. Keep track
of this by updating the size of this bitfield whenever you add or
remove a flag. */
- unsigned dummy : 2;
+ unsigned dummy : 3;
tree primary_base;
vec *vcall_indices;
@@ -1535,7 +1534,7 @@ struct GTY((variable_size)) lang_type {
/* Nonzero means that NODE (a class type) is final */
#define CLASSTYPE_FINAL(NODE) \
- (LANG_TYPE_CLASS_CHECK (NODE)->is_final)
+ BINFO_FINAL_P (TYPE_BINFO (NODE))
/* Nonzero means that this _CLASSTYPE node overloads operator=(X&). */
@@ -2400,10 +2399,6 @@ struct GTY((variable_size)) lang_decl {
an override virt-specifier */
#define DECL_OVERRIDE_P(NODE) (TREE_LANG_FLAG_0 (NODE))
-/* True (in a FUNCTION_DECL) if NODE is a function declared with
- a final virt-specifier */
-#define DECL_FINAL_P(NODE) (TREE_LANG_FLAG_1 (NODE))
-
/* The thunks associated with NODE, a FUNCTION_DECL. */
#define DECL_THUNKS(NODE) \
(DECL_VIRTUAL_P (NODE) ? LANG_DECL_FN_CHECK (NODE)->context : NULL_TREE)
Index: cp/pt.c
===
--- cp/pt.c (revision 201910)
+++ cp/pt.c (working copy)
@@ -8730,7 +8730,8 @@ instantiate_class_template_1 (tree type)
/* Adjust visibility for template arguments. */
determine_visibility (TYPE_MAIN_DECL (type));
}
- CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
+ if (CLASS_TYPE_P (type))
+CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
pbinfo = TYPE_BINFO (pattern);
Index: tree.h
===
--- tree.h (revision 201910)
+++ tree.h (working copy)
@@ -563,6 +563,9 @@ struct GTY(()) tree_base {
TRANSACTION_EXPR_RELAXED in
TRANSACTION_EXPR
+ BINFO_FINAL_P in
+ BINFO
+
private_flag:
TREE_PRIVATE in
@@ -2314,6 +2317,10 @@ enum cv_qualifier
#define TYPE_CONTAINS_PLACEHOLDER_INTERNAL(NODE) \
(TYPE_CHECK (NODE)->type_common.contains_placeholder_bits)
+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
+#define BINFO_FINAL_P(NODE) \
+ (TREE_BINFO_CHECK (NODE)->base.public_flag)
+
/* The debug output functions use the symtab union field to store
information specific to the debugging format. The different debug
output hooks store different types in the union field. These three
@@ -3224,7 +3231,9 @@ struct GTY(()) tree_decl_with_vis {
unsigned init_priority_p : 1;
/* Used by C++ only. Might become a generic decl flag. */
unsigned shadowed_for_var_p : 1;
- /* 14 unused bits. */
+ /* Belong to FUNCTION_DECL exclusively. */
+ unsigned final : 1;
+ /* 13 unused bits. */
};
extern tree decl_debug_expr_lookup (tree);
@@ -3474,6 +3483,11 @@ extern vec **decl_debug_arg
#define DECL_FUNCTION_VERSIONED(NODE)\
(FUNCTION_DECL_CHECK (NODE)->function_decl.versioned_function)
+/* In FUNCTION_DECL that represent an virtual method this is set when
+ the method is final. */
+#define DECL_FINAL_P(NODE)\
+ (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.final)
+
/* FUNCTION_DECL inherits from DECL_NON_COMMON because of the use of the
arguments/result/saved_tree fields by front ends. It was either
Fixed PR rtl-optimization/58220 and PR regression/58221
The following patch was just committed as r201941 (pre-approved by
Jakub) to fix PR rtl-optimization/58220 and PR regression/58221.
Bootstrapped and tested on x86_64-unknown-linux-gnu. also confirmed
that I could reproduce the problem in PR rtl-optimization/58220 and
that the patch fixes it. Thanks to Kaz for the fix.
Index: final.c
===
--- final.c (revision 201940)
+++ final.c (revision 201941)
@@ -1650,7 +1650,7 @@ reemit_insn_block_notes (void)
rtx insn, note;
insn = get_insns ();
- for (; insn; insn = next_insn (insn))
+ for (; insn; insn = NEXT_INSN (insn))
{
tree this_block;
Index: ChangeLog
===
--- ChangeLog (revision 201940)
+++ ChangeLog (revision 201941)
@@ -1,3 +1,10 @@
+2013-08-23 Kaz Kojima
+
+ PR rtl-optimization/58220
+ PR regression/58221
+ * final.c (reemit_insn_block_notes): Use NEXT_INSN to
+ handle SEQUENCE insns properly.
+
2013-08-23 Gabriel Dos Reis
* pretty-print.h (pp_newline_and_flush): Declare. Remove macro
Teresa
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)
On Fri, Aug 23, 2013 at 6:34 AM, Teresa Johnson wrote:
> Hi Steve and Kaz,
>
> Sorry about that. Kaz has a fix shown in rtl-optimization/58220:
>
> --- ORIG/trunk/gcc/final.c 2013-08-22 09:43:35.0 +0900
> +++ trunk/gcc/final.c 2013-08-22 14:36:51.0 +0900
> @@ -1650,7 +1650,7 @@ reemit_insn_block_notes (void)
>rtx insn, note;
>
>insn = get_insns ();
> - for (; insn; insn = next_insn (insn))
> + for (; insn; insn = NEXT_INSN (insn))
> {
>tree this_block;
>
> It should be committed soon, by Kaz or myself once testing finishes.
> Please let me know if that doesn't fix your failures.
Fix committed as r201941. Let me know if you still have issues.
Teresa
>
> Thanks,
> Teresa
>
> On Thu, Aug 22, 2013 at 4:59 PM, Kaz Kojima wrote:
>> Steve Ellcey wrote:
>>> On Mon, 2013-08-19 at 22:21 -0700, Teresa Johnson wrote:
>>>
2013-08-19 Teresa Johnson
PR rtl-optimizations/57451
* final.c (reemit_insn_block_notes): Prevent lexical blocks
from crossing split section boundaries.
* testsuite/g++.dg/tree-prof/pr57451.C: New test.
>>>
>>> Teresa,
>>>
>>> This patch is causing a problem in my mips compiler. I am creating a
>>> cross-toolchain running on x86 targeting mips-mti-linux-gnu and if I
>>> compile glibc using a GCC that has this patch all of the programs I
>>> compile go into an infinite loop when run under the qemu simulator. I
>>> think it is the dynamic linker that is getting miscompiled, but I
>>> haven't tracked down the exact nature of the miscompilation yet. Has
>>> anyone else reported any problems with it? I am adding Richard
>>> Sandiford to the email list since he is a mips expert and also might
>>> have some insight to using next_active_insn vs. next_real_insn vs.
>>> next_insn, though it doesn't look like you have changed what is used
>>> here.
>>
>> Similar on SH. I've just filed rtl-optimization/58220.
>>
>> Regards,
>> kaz
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [C++ patch] Move FINAL flag to middle-end trees.
> Hi, > this is patch I am testing. Does it look OK? > Index: cp/pt.c > === > --- cp/pt.c (revision 201910) > +++ cp/pt.c (working copy) > @@ -8730,7 +8730,8 @@ instantiate_class_template_1 (tree type) >/* Adjust visibility for template arguments. */ >determine_visibility (TYPE_MAIN_DECL (type)); > } > - CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern); > + if (CLASS_TYPE_P (type)) > +CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern); Sadly we ICE here because BINFO of type is not built yet. I tried to move the code after xref_binfos and it does seem to lead to errors while building libstdc++ PCH. Any idea what to do here? Honza
Re: [Patch 2/2] Localization problem in regex
On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini wrote: > Great. But please but the names of the functions you are changing between > round brackets. You have tons of examples everywhere. ...like this? -- Tim Shen changelog Description: Binary data
Re: [Patch 2/2] Localization problem in regex
On 23 August 2013 15:53, Tim Shen wrote: > On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini > wrote: >> Great. But please but the names of the functions you are changing between >> round brackets. You have tons of examples everywhere. > > ...like this? Yes, that makes it clear what part of the file is affected. That's important when searching ChangeLogs to find what change last touched e.g. basic_regex::assign.
Re: wide-int branch now up for public comment and review
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with Richard B.'s comments.
I also expect many of them are going to be annoying, sorry, but this
first one definitely will. The coding conventions say that functions
should be defined outside the class:
http://gcc.gnu.org/codingconventions.html
and that opening braces should be on their own line, so most of the file
needs to be reformatted. I went through and made that change with the
patch below, in the process of reading through. I also removed "SGN
must be SIGNED or UNSIGNED." because it seemed redundant when those are
the only two values available. The patch fixes a few other coding standard
problems and typos, but I've not made any actual code changes (or at least,
I didn't mean to).
Does it look OK to install?
I'm still unsure about these "infinite" precision types, but I understand
the motivation and I have no objections. However:
> * Code that does widening conversions. The canonical way that
> this is performed is to sign or zero extend the input value to
> the max width based on the sign of the type of the source and
> then to truncate that value to the target type. This is in
> preference to using the sign of the target type to extend the
> value directly (which gets the wrong value for the conversion
> of large unsigned numbers to larger signed types).
I don't understand this particular reason. Using the sign of the source
type is obviously right, but why does that mean we need "infinite" precision,
rather than just doubling the precision of the source?
> * When a constant that has an integer type is converted to a
> wide-int it comes in with precision 0. For these constants the
> top bit does accurately reflect the sign of that constant; this
> is an exception to the normal rule that the signedness is not
> represented. When used in a binary operation, the wide-int
> implementation properly extends these constants so that they
> properly match the other operand of the computation. This allows
> you write:
>
>tree t = ...
>wide_int x = t + 6;
>
> assuming t is a int_cst.
This seems dangerous. Not all code that uses "unsigned HOST_WIDE_INT"
actually wants it to be an unsigned value. Some code uses it to avoid
the undefinedness of signed overflow. So these overloads could lead
to us accidentally zero-extending what's conceptually a signed value
without any obvious indication that that's happening. Also, hex constants
are unsigned int, but it doesn't seem safe to assume that 0x8000 was
meant to be zero-extended.
I realise the same thing can happen if you mix "unsigned int" with
HOST_WIDE_INT, but the point is that you shouldn't really do that
in general, whereas we're defining these overloads precisely so that
a mixture can be used.
I'd prefer some explicit indication of the sign, at least for anything
other than plain "int" (so that the compiler will complain about uses
of "unsigned int" and above).
> Note that the bits above the precision are not defined and the
> algorithms used here are careful not to depend on their value. In
> particular, values that come in from rtx constants may have random
> bits.
I have a feeling I'm rehashing a past debate, sorry, but rtx constants can't
have random bits. The upper bits must be a sign extension of the value.
There's exactly one valid rtx for each (value, mode) pair. If you saw
something different then that sounds like a bug. The rules should already
be fairly well enforced though, since something like (const_int 128) --
or (const_int 256) -- will not match a QImode operand.
This is probably the part of the representation that I disagree most with.
There seem to be two main ways we could hande the extension to whole HWIs:
(1) leave the stored upper bits undefined and extend them on read
(2) keep the stored upper bits in extended form
The patch goes for (1) but (2) seems better to me, for a few reasons:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts naturally preserve
the sign-extended form, so only a subset of write operations need
to take special measures.
* You have a public interface that exposes the underlying HWIs
(which is fine with me FWIW), so it seems better to expose a fully-defined
HWI rather than only a partially-defined HWI.
E.g. zero_p is:
HOST_WIDE_INT x;
if (precision && precision < HOST_BITS_PER_WIDE_INT)
x = sext_hwi (val[0], precision);
else if (len == 0)
{
gcc_assert (precision == 0);
return true;
}
else
x = val[0];
return l
Re: [Patch 2/2] Localization problem in regex
On 08/23/2013 04:53 PM, Tim Shen wrote: On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini wrote: Great. But please but the names of the functions you are changing between round brackets. You have tons of examples everywhere. ...like this? The assign change is fine. But I would also put between round brackets (class _Compiler<>) for the _M_traits change and use something like (_DFSExecutor<>::_DFSExecutor): Adjust. for the last change (remember that constructors are special member *functions* thus should be normally listed). Paolo.
Re: [RFC] Issues with intraprocedural devirtualization
Hi, On Mon, Aug 19, 2013 at 11:10:31AM +0200, Jan Hubicka wrote: > Hi, > here is variant of patch that drops the field walking from > gimple_extract_devirt_binfo_from_cst completely. As pointed out > by Jason, it is pointless since all structures have BINFO in C++ > and thus get_binfo_at_offset will do the job. > > I would like to return the code back eventually to handle arrays&unions > but that can be done incrementally (and this is not the only place that > sufers from the problem) > > Martin: I am still not quite certain about the dynamic type changing logic. > if this is the case ipa-prop needs to deal with and it handles only 0 offsets > within the outer type, I guess it can just test the offset by itself? In these cases, devirtualization is done according ipa invariants, no dynamic type checks are in place, we did away with requiring the artificial-ness of the field we devirtualize according to. I believe your new check that the function has not been overridden is sufficient and superior. Thanks, Martin > > Honza > > Bootstrapped/regtested x86_64-linux, OK? > > * ipa-cp.c (ipa_get_indirect_edge_target_1): Update use > of gimple_extract_devirt_binfo_from_cst. > * gimple-fold.c (gimple_extract_devirt_binfo_from_cst): Rework. > (gimple_fold_call): Update use of gimple_extract_devirt_binfo_from_cst. > * ipa-prop.c (try_make_edge_direct_virtual_call): Likewise. > * gimple.h (gimple_extract_devirt_binfo_from_cst): Update.
Re: [PING PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK
Hi Jakub and/or Joseph,
the reporter of this bug seems to be very anxious to have it fixed in
the repository. While Richi is away, do you think you could have a
look? It is very small.
Thanks a lot,
Martin
On Fri, Aug 02, 2013 at 01:45:31PM +0200, Martin Jambor wrote:
> Hi,
>
> while compute_record_mode in stor-layout.c makes sure it assigns BLK
> mode to structs with flexible arrays, it has no such provisions for
> zero length arrays
> (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html). I
> think that in order to avoid problems and surprises like PR 57748
> (where this triggered code that was intended for small structures that
> fit into a scalar mode and ICEd), we should assign both variable array
> possibilities the same mode.
>
> Bootstrapped and tested on x86_64-linux without any problems. OK for
> trunk and the 4.8 branch? (I'm not sure about the 4.7, this PR does
> not happen there despite the wrong mode so I'd ignore it for now.)
>
> Thanks,
>
> Martin
>
>
> 2013-08-01 Martin Jambor
>
> PR middle-end/57748
> * stor-layout.c (compute_record_mode): Treat zero-sized array fields
> like incomplete types.
>
> testsuite/
> * gcc.dg/torture/pr57748.c: New test.
>
>
> *** /tmp/lV6Ba8_stor-layout.c Thu Aug 1 16:28:25 2013
> --- gcc/stor-layout.c Thu Aug 1 15:36:18 2013
> *** compute_record_mode (tree type)
> *** 1604,1610
> && integer_zerop (TYPE_SIZE (TREE_TYPE (field)
> || ! host_integerp (bit_position (field), 1)
> || DECL_SIZE (field) == 0
> ! || ! host_integerp (DECL_SIZE (field), 1))
> return;
>
> /* If this field is the whole struct, remember its mode so
> --- 1604,1612
> && integer_zerop (TYPE_SIZE (TREE_TYPE (field)
> || ! host_integerp (bit_position (field), 1)
> || DECL_SIZE (field) == 0
> ! || ! host_integerp (DECL_SIZE (field), 1)
> ! || (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
> ! && tree_low_cst (DECL_SIZE (field), 1) == 0))
> return;
>
> /* If this field is the whole struct, remember its mode so
> *** /dev/null Tue Jun 4 12:34:56 2013
> --- gcc/testsuite/gcc.dg/torture/pr57748.cThu Aug 1 15:42:14 2013
> ***
> *** 0
> --- 1,45
> + /* PR middle-end/57748 */
> + /* { dg-do run } */
> +
> + #include
> +
> + extern void abort (void);
> +
> + typedef long long V
> + __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
> +
> + typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
> +
> + struct __attribute__((packed)) T { char c; P s; };
> +
> + void __attribute__((noinline, noclone))
> + check (struct T *t)
> + {
> + if (t->s.b[0][0] != 3 || t->s.b[0][1] != 4)
> + abort ();
> + }
> +
> + int __attribute__((noinline, noclone))
> + get_i (void)
> + {
> + return 0;
> + }
> +
> + void __attribute__((noinline, noclone))
> + foo (P *p)
> + {
> + V a = { 3, 4 };
> + int i = get_i();
> + p->b[i] = a;
> + }
> +
> + int
> + main ()
> + {
> + struct T *t = (struct T *) malloc (128);
> +
> + foo (&t->s);
> + check (t);
> +
> + return 0;
> + }
Type inheritance graph analysis & speculative devirtualization, part 4a/6 simple anonymous namespace devirtualization during cgraph construction
Hi,
this patch makes cgraphunit.c to do very simple devirtualization when method
being called is from anonymous namespace class and none of its derivations
overwrite the method. I do it in cgraph build only because later we need
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01007.html first so the code works
correctly during LTO.
To my surprise this actualy matches on firefox build and seems to help. Once I
have final flag passed from FE.
The patch also modifies reachability walk to not look for methods of anonymous
types. Here we know that if the method is used, its vtable is reachable and
therefore the method will be walked later. This saves us from lowering the
method in the second testcase.
Once the final flag is passed to middle end I will be able to handle final
types the same way.
Honza
Bootstrapped/regtested x86_64-linux, will commit it shortly.
* g++.dg/ipa/devirt-13.C: New testcase.
* g++.dg/ipa/devirt-14.C: New testcase.
* cgraphunit.c (analyze_functions): Do basic devirtualization;
do not walk base classes of anonymous types.
Index: testsuite/g++.dg/ipa/devirt-13.C
===
--- testsuite/g++.dg/ipa/devirt-13.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-13.C(revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+/* Call to foo should be devirtualized because there are no derived types of
A. */
+/* { dg-options "-O2 -fdump-ipa-cgraph -fdump-tree-ssa" } */
+namespace {
+class A {
+public:
+ virtual int foo(void)
+{
+ return 0;
+}
+};
+}
+class A a, *b=&a;
+main()
+{
+ return b->foo();
+}
+
+/* { dg-final { scan-ipa-dump "Devirtualizing call" "cgraph" } } */
+/* { dg-final { scan-tree-dump-times "OBJ_TYPE_REF" 0 "ssa"} } */
+/* { dg-final { cleanup-ipa-dump "cgraph" } } */
+/* { dg-final { cleanup-tree-dump "ssa" } } */
Index: testsuite/g++.dg/ipa/devirt-14.C
===
--- testsuite/g++.dg/ipa/devirt-14.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-14.C(revision 0)
@@ -0,0 +1,34 @@
+/* No devirtualization happens here, but A::foo should not end up as reachable
+ because the constructor of A is unreachable and therefore the virtual
+ method table referring to A::foo is optimized out. */
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-tree-ssa" } */
+class B {
+public:
+ virtual int foo(void)
+{
+ return 0;
+}
+};
+namespace {
+class A : public B {
+public:
+ virtual int foo(void)
+{
+ return 1;
+}
+};
+}
+class B a, *b=&a;
+main()
+{
+ if (0)
+{
+class A a;
+a.foo();
+}
+ return b->foo();
+}
+
+/* { dg-final { scan-tree-dump-nop "A::foo" 0 "ssa"} } */
+/* { dg-final { cleanup-tree-dump "ssa" } } */
Index: cgraphunit.c
===
--- cgraphunit.c(revision 201919)
+++ cgraphunit.c(working copy)
@@ -922,26 +922,73 @@ analyze_functions (void)
enqueue_node ((symtab_node)edge->callee);
if (optimize && flag_devirtualize)
{
- for (edge = cnode->indirect_calls; edge; edge =
edge->next_callee)
- if (edge->indirect_info->polymorphic)
- {
- unsigned int i;
- void *cache_token;
- vec targets
- = possible_polymorphic_call_targets
- (edge, NULL, &cache_token);
+ struct cgraph_edge *next;
+ for (edge = cnode->indirect_calls; edge; edge = next)
+ {
+ next = edge->next_callee;
+ if (edge->indirect_info->polymorphic)
+ {
+ unsigned int i;
+ void *cache_token;
+ bool final;
+ vec targets
+ = possible_polymorphic_call_targets
+ (edge, &final, &cache_token);
- if (!pointer_set_insert (reachable_call_targets,
-cache_token))
- {
- if (cgraph_dump_file)
- dump_possible_polymorphic_call_targets
- (cgraph_dump_file, edge);
+ if (!pointer_set_insert (reachable_call_targets,
+ cache_token))
+ {
+ if (cgraph_dump_file)
+ dump_possible_polymorphic_call_targets
+ (cgraph_dump_file, edge);
- for (i = 0; i < targets.length(); i++)
- enqueue_node ((symtab_node) targets[i]);
- }
- }
+ for (
Re: powerpc64le multilibs and multiarch dir
On Thu, Aug 22, 2013 at 7:15 PM, Alan Modra wrote: > Without another tmake file it really is exactly the same as before. > > old, after applying "make" string gunk > MULTILIB_OPTIONS = m64/m32 > MULTILIB_OSDIRNAMES = ../lib64 ../lib > > new > MULTILIB_OPTIONS = m64/m32 > MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib > > Either way, -m64 objects use ../lib64 and -m32 ../lib. > > > new with le multilib > MULTILIB_OPTIONS = m64/m32 mlittle > MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib m64.mlittle=../lib64le > m32.mlittle=../lible Okay, I see how it's duplicating the meaning of the positional arguments. The patch is okay. Thanks, David
Re: [PING PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK
On Fri, Aug 23, 2013 at 05:11:22PM +0200, Martin Jambor wrote: > Hi Jakub and/or Joseph, > > the reporter of this bug seems to be very anxious to have it fixed in > the repository. While Richi is away, do you think you could have a > look? It is very small. Isn't this ABI incompatible change (at least potential on various targets)? If so, then it shouldn't be applied to release branches, because it would create (potential?) ABI incompatibility between 4.8.[01] and 4.8.2. Jakub
Re: Type inheritance graph analysis & speculative devirtualization, part 4a/6 simple anonymous namespace devirtualization during cgraph construction
Jan, This has broken all builds because method_type_class() is defined. Graham
Re: [Patch 2/2] Localization problem in regex
On Fri, Aug 23, 2013 at 11:03 PM, Paolo Carlini wrote: > The assign change is fine. But I would also put between round brackets > (class _Compiler<>) for the _M_traits change and use something like > (_DFSExecutor<>::_DFSExecutor): Adjust. for the last change (remember that > constructors are special member *functions* thus should be normally listed). I see. On Fri, Aug 23, 2013 at 10:57 PM, Jonathan Wakely wrote: > Yes, that makes it clear what part of the file is affected. That's > important when searching ChangeLogs to find what change last touched > e.g. basic_regex::assign. Why don't we `svn blame`? By the way, do we seariously need to keep ChangeLog in files? Is it more like a tradition than a solution? After all, we have SVN or Git now. I remember a mail metioned this but cannot find it >.< -- Tim Shen changelog Description: Binary data
Re: Type inheritance graph analysis & speculative devirtualization, part 4a/6 simple anonymous namespace devirtualization during cgraph construction
> Jan,
>
> This has broken all builds because method_type_class() is defined.
Oops, sorry for that. I happened to make partial diff only.
This patch adds the missing bit.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 201943)
+++ ChangeLog (working copy)
@@ -1,5 +1,8 @@
2013-08-23 Jan Hubicka
+ * ipa-utils.h (method_class_type): Declare.
+ * ipa-devirt.c (method_class_type): Export.
+
* cgraphunit.c (analyze_functions): Do basic devirtualization;
do not walk base classes of anonymous types.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 201919)
+++ ipa-devirt.c(working copy)
@@ -342,7 +342,7 @@ dump_type_inheritance_graph (FILE *f)
/* Given method type T, return type of class it belongs to.
Lookup this pointer and get its type.*/
-static tree
+tree
method_class_type (tree t)
{
tree first_parm_type = TREE_VALUE (TYPE_ARG_TYPES (t));
Index: ipa-utils.h
===
--- ipa-utils.h (revision 201919)
+++ ipa-utils.h (working copy)
@@ -59,6 +59,7 @@ odr_type get_odr_type (tree, bool insert
void dump_possible_polymorphic_call_targets (FILE *, tree, HOST_WIDE_INT);
bool possible_polymorphic_call_target_p (tree, HOST_WIDE_INT,
struct cgraph_node *n);
+tree method_class_type (tree);
/* Return vector containing possible targets of polymorphic call E.
If FINALP is non-NULL, store true if the list is complette.
Re: [Patch 2/2] Localization problem in regex
On 23 August 2013 16:48, Tim Shen wrote: > By the way, do we seariously need to keep ChangeLog in files? Is it > more like a tradition than a solution? After all, we have SVN or Git > now. I remember a mail metioned this but cannot find it >.< It's not a tradition, they are required, see http://www.gnu.org/prep/standards/standards.html#Change-Logs
Re: [PATCH] Fix PR57451 (Incorrect debug ranges emitted for -freorder-blocks-and-partition -g)
On Fri, 2013-08-23 at 07:38 -0700, Teresa Johnson wrote: > > It should be committed soon, by Kaz or myself once testing finishes. > > Please let me know if that doesn't fix your failures. > > Fix committed as r201941. Let me know if you still have issues. > > Teresa This patch fixes the problem for me. Thanks Teresa, Thanks Kaz. Steve Ellcey
Re: [Patch, Fortran, OOP] PR 57843: Type-bound assignment is resolved to non-polymorphic procedure call
2013/8/22 Mikael Morin : > Le 22/08/2013 17:41, Janus Weil a écrit : >> Hi all, >> >> here is a wrong-code fix for type-bound assignments, which makes sure >> that these are resolved to polymorphic procedure calls. This was not >> always the case, because we used the wrong ordering when checking for >> defined-assignment procedures (looking for non-typebound ones first, >> and for typebound ones only afterwards). See in particular comment 3 - >> 5 in the PR. >> >> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? >> > OK. Thanks. Thanks, committed as r201946. Cheers, Janus
Re: [Patch 2/2] Localization problem in regex
Am Fri, 23 Aug 2013 17:17:41 +0800
schrieb Tim Shen :
> Inspired by this mail:
> http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
>
> Thanks!
>
>
Hi Tim,
I applied the patch + compiled everything - it's working now! Thanks!
But... I found a problem with .imbue():
int main()
{
std::setlocale(LC_ALL, "");
std::wstring str2 = L"öäü";
std::wregex re2;
re2.imbue(std::locale(""));
re2.assign(L"([[:lower:]]+)");
std::wsmatch m2;
std::wsregex_token_iterator end {};
for (std::wsregex_token_iterator p{str2.begin(), str2.end(),
re2, {1}}; p != end; ++p) { std::wcout << *p << std::endl;
}
return 0;
}
Works fine! But when there's no imbue() call, a Segmentation
fault occurs.
int main()
{
std::setlocale(LC_ALL, "");
std::wstring str2 = L"öäü";
std::wregex re2;
//re2.imbue(std::locale(""));
re2.assign(L"([[:lower:]]+)");
std::wsmatch m2;
std::wsregex_token_iterator end {};
for (std::wsregex_token_iterator p{str2.begin(), str2.end(),
re2, {1}}; p != end; ++p) { std::wcout << *p << std::endl;
}
return 0;
}
May be it's better to throw an exception here? Thanks in advance,
Stefan
Re: vector conditional expression with scalar arguments
On Sun, 4 Aug 2013, Gerald Pfeifer wrote:
On Sat, 13 Jul 2013, Marc Glisse wrote:
2013-07-14 Marc Glisse
gcc/cp/
* call.c (build_conditional_expr_1): Handle the case with 1 vector
and 2 scalars. Call save_expr before building a vector.
* typeck.c (cp_build_binary_op): Check complain before complaining.
Shouldn't this be documented somewhere (gcc/doc/*.texi and our web based
release notes)?
Yes, it should. I had posted this some time ago:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00664.html
Here is an updated version that also mentions the new scalar case:
2013-08-23 Marc Glisse
* doc/extend.texi (Vector Extensions): Document ?: in C++.
--
Marc GlisseIndex: doc/extend.texi
===
--- doc/extend.texi (revision 201948)
+++ doc/extend.texi (working copy)
@@ -7023,20 +7023,33 @@ otherwise. Consider the following exampl
typedef int v4si __attribute__ ((vector_size (16)));
v4si a = @{1,2,3,4@};
v4si b = @{3,2,1,4@};
v4si c;
c = a > b; /* The result would be @{0, 0,-1, 0@} */
c = a == b; /* The result would be @{0,-1, 0,-1@} */
@end smallexample
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @code{a} is an
+integer vector of the same size and number of elements as @code{b} and
+@code{c}, computes all three arguments and creates a vector
+@code{@{a[0]?b[0]:c[0], a[1]?b[1]:c[1], @dots{}@}}. Note that unlike in
+OpenCL, @code{a} is thus interpreted as @code{a != 0} and not @code{a < 0}.
+As in the case of binary operations, this syntax is also accepted when
+one of @code{b} or @code{c} is a scalar that is then transformed into a
+vector. If both @code{b} and @code{c} are scalars and the type of
+@code{true?b:c} has the same size as the element type of @code{a}, then
+@code{b} and @code{c} are converted to a vector type whose elements have
+this type and with the same number of elements as @code{a}.
+
Vector shuffling is available using functions
@code{__builtin_shuffle (vec, mask)} and
@code{__builtin_shuffle (vec0, vec1, mask)}.
Both functions construct a permutation of elements from one or two
vectors and return a vector of the same type as the input vector(s).
The @var{mask} is an integral vector with the same width (@var{W})
and element count (@var{N}) as the output vector.
The elements of the input vectors are numbered in memory ordering of
@var{vec0} beginning at 0 and @var{vec1} beginning at @var{N}. The
Re: msp430 port
so... can I get an official "ok to commit with you and Nick as maintainers" then?
Re: wide-int branch now up for public comment and review
On 08/23/2013 11:02 AM, Richard Sandiford wrote: Hi Kenny, This is the first time I've looked at the implementation of wide-int.h (rather than just looking at the rtl changes, which as you know I like in general), so FWIW here are some comments on wide-int.h. I expect a lot of them overlap with Richard B.'s comments. I also expect many of them are going to be annoying, sorry, but this first one definitely will. The coding conventions say that functions should be defined outside the class: http://gcc.gnu.org/codingconventions.html and that opening braces should be on their own line, so most of the file needs to be reformatted. I went through and made that change with the patch below, in the process of reading through. I also removed "SGN must be SIGNED or UNSIGNED." because it seemed redundant when those are the only two values available. The patch fixes a few other coding standard problems and typos, but I've not made any actual code changes (or at least, I didn't mean to). I had started the file with the functions outside of the class and mike had stated putting them in the class, and so i went with putting them in the class since many of them were one liners and so having them out of line just doubled the size of everything. however, we did not look at the coding conventions and that really settles the argument. Thanks for doing this. Does it look OK to install? you can check it in. I'm still unsure about these "infinite" precision types, but I understand the motivation and I have no objections. However: * Code that does widening conversions. The canonical way that this is performed is to sign or zero extend the input value to the max width based on the sign of the type of the source and then to truncate that value to the target type. This is in preference to using the sign of the target type to extend the value directly (which gets the wrong value for the conversion of large unsigned numbers to larger signed types). I don't understand this particular reason. Using the sign of the source type is obviously right, but why does that mean we need "infinite" precision, rather than just doubling the precision of the source? in a sense, "infinite" does not really mean infinite, it really just means large enough so that you never loose any information from the top.For widening all that you really need to be "infinite" is one more bit larger than the destination type. We could have had an abi where you specified the precision of every operation based on the precisions of the inputs. Instead, for these kinds of operations, we decided to sniff the port and determine a fixed width that was large enough for everything that was needed for the port. We call that number infinite. This sort of follows the convention that double-int was used with were infinite was 128 bits, but with our design/implementation, we (hopefully) have no bugs where the size of the datatypes needed never runs into implementation limits. * When a constant that has an integer type is converted to a wide-int it comes in with precision 0. For these constants the top bit does accurately reflect the sign of that constant; this is an exception to the normal rule that the signedness is not represented. When used in a binary operation, the wide-int implementation properly extends these constants so that they properly match the other operand of the computation. This allows you write: tree t = ... wide_int x = t + 6; assuming t is a int_cst. This seems dangerous. Not all code that uses "unsigned HOST_WIDE_INT" actually wants it to be an unsigned value. Some code uses it to avoid the undefinedness of signed overflow. So these overloads could lead to us accidentally zero-extending what's conceptually a signed value without any obvious indication that that's happening. Also, hex constants are unsigned int, but it doesn't seem safe to assume that 0x8000 was meant to be zero-extended. I realise the same thing can happen if you mix "unsigned int" with HOST_WIDE_INT, but the point is that you shouldn't really do that in general, whereas we're defining these overloads precisely so that a mixture can be used. I'd prefer some explicit indication of the sign, at least for anything other than plain "int" (so that the compiler will complain about uses of "unsigned int" and above). There is a part of me that finds this scary and a part of me that feels that the concern is largely theoretical.It does make it much easier to read and understand the code to be able to write "t + 6" rather than "wide_int (t) + wide_int::from_uhwi" (6) but of course you loose some control over how 6 is converted. Note that the bits above the precision are not defined and the algorithms used here are careful not to depend on their value. In particular, values that come in from r
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
On Tue, 20 Aug 2013, Cong Hou wrote: > When a sin() (cos(), log(), etc.) function is called on a value of > float type and the returned double value is converted to another value > of float type, GCC converts this function call into a float version > (sinf()) in the optimization mode. This avoids two type conversions > and the float version function call usually takes less time. However, > this can result in different result and therefore is unsafe. Whether it's safe depends on the existence of input values for which the double-rounded result is different from the single-rounded result. It's certainly safe for some of the functions for which the optimization is enabled, regardless of the precisions involved (fabs, logb). For sqrt, if the smaller precision is p then the larger precision being at least 2p+3 (I think) makes things same. For the other cases, exhaustive searches may be needed to determine when the conversion is safe. (Actually, this code appears to deal with cases with up to three types involved - the operand, the result and the function that's called. This complicates the analysis a bit, but the same principles apply.) -- Joseph S. Myers jos...@codesourcery.com
Ping: RFA: fix find_valid_class to accept classes w/out last hard reg
This patch has not been reviewed for more than three months: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00113.html
Go patch commited: Don't export embedded builtins
This patch from Chris Manghane fixes a bug in the type reflection
information for a struct with an anonymous field of a builtin type.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
diff -r ea33e34cb12d go/types.cc
--- a/go/types.cc Thu Aug 22 18:07:47 2013 -0700
+++ b/go/types.cc Fri Aug 23 13:59:24 2013 -0700
@@ -4221,6 +4221,22 @@
}
}
+// Return whether this field is an embedded built-in type.
+
+bool
+Struct_field::is_embedded_builtin(Gogo* gogo) const
+{
+ const std::string& name(this->field_name());
+ // We know that a field is an embedded type if it is anonymous.
+ // We can decide if it is a built-in type by checking to see if it is
+ // registered globally under the field's name.
+ // This allows us to distinguish between embedded built-in types and
+ // embedded types that are aliases to built-in types.
+ return (this->is_anonymous()
+ && !Gogo::is_hidden_name(name)
+ && gogo->lookup_global(name.c_str()) != NULL);
+}
+
// Class Struct_type.
// A hash table used to find identical unnamed structs so that they
@@ -4835,11 +4851,16 @@
++q;
go_assert(q->is_field_name("pkgPath"));
- if (!Gogo::is_hidden_name(pf->field_name()))
- fvals->push_back(Expression::make_nil(bloc));
+ bool is_embedded_builtin = pf->is_embedded_builtin(gogo);
+ if (!Gogo::is_hidden_name(pf->field_name()) && !is_embedded_builtin)
+fvals->push_back(Expression::make_nil(bloc));
else
{
- std::string n = Gogo::hidden_name_pkgpath(pf->field_name());
+ std::string n;
+ if (is_embedded_builtin)
+n = gogo->package_name();
+ else
+n = Gogo::hidden_name_pkgpath(pf->field_name());
Expression* s = Expression::make_string(n, bloc);
fvals->push_back(Expression::make_unary(OPERATOR_AND, s, bloc));
}
diff -r ea33e34cb12d go/types.h
--- a/go/types.h Thu Aug 22 18:07:47 2013 -0700
+++ b/go/types.h Fri Aug 23 13:59:24 2013 -0700
@@ -1926,6 +1926,10 @@
bool
is_field_name(const std::string& name) const;
+ // Return whether this struct field is an embedded built-in type.
+ bool
+ is_embedded_builtin(Gogo*) const;
+
// The field type.
Type*
type() const
Re: [RFC] Add conditional compare support
On Wed, 21 Aug 2013, Zhenqiang Chen wrote: > SHORT_CIRCUIT expression will be converted to CCMP expressions > at the end of front-end. That doesn't sound like the right place to me. We want the same code to be generated whether users write && and || directly or write corresponding sequences of if conditions. In general we want to move away from optimizing complicated expressions in fold-const, towards having GIMPLE passes that detect the relevant patterns however they were written (and without needing to combine GIMPLE back into trees for passing through the old folder). So, I think you should detect this at some point in the GIMPLE optimizations rather than changing fold-const at all (and as a consequence, you then shouldn't need to change front-end pretty-printers). -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Add conditional compare support
> That doesn't sound like the right place to me. We want the same code to > be generated whether users write && and || directly or write corresponding > sequences of if conditions. In general we want to move away from > optimizing complicated expressions in fold-const, towards having GIMPLE > passes that detect the relevant patterns however they were written (and > without needing to combine GIMPLE back into trees for passing through the > old folder). I'm not convinced that it's an "either or". Certainly the optimization needs to be in one of the GIMPLE passes for exactly the reason you give. Theoretically, fold-const need do nothing, but I think that's only in "theory". Giving later-pass optimizers better code when possible at least speeds up the process and at best produces better generated code. Obviously, one can't do everything everywhere, but I wouldn't reject doing something earlier just because it's also done later.
Re: powerpc64le multilibs and multiarch dir
On Thu, 22 Aug 2013, Alan Modra wrote: > For multiarch, powerpc64le-linux now will use powerpc64le-linux-gnu. > Given a typical big-endian native toolchain with os dirs /lib and > /lib64, we'll use /lible and /lib64le if supporting little-endian as > well. If you happen to use /lib and /lib32, then the little-endian > variants are /lible and /lib32le. For completeness I also support > building big-endian multilibs on a little-endian host. Given those directory names, what are the defined dynamic linker paths for 32-bit and 64-bit little-endian (which can't depend on which of the various directory arrangements may be in use)? Does the Power Architecture support, in principle, a single system running both big-endian and little-endian processes at the same time, or is it a matter of hardware configuration or boot-time setup? Unless both can run at once, it doesn't seem particularly useful to define separate directories for big and little endian since a particular system would be just one or the other. Other architectures don't define separate directory names for endianness variants unless multiarch naming conventions are in use. (ARM does support having processes with both endiannesses - indeed, a process can change its own endianness with the unprivileged SETEND instruction (deprecated in ARMv8) - although the Linux kernel has no support for this the last time I checked, and big-endian ARM is rarely used.) -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch] Fix infinite loop/crash if array initializer index equals max value
On Thu, 22 Aug 2013, Selvaraj, Senthil_Kumar wrote: > 2013-08-23 Senthil Kumar Selvaraj > * c-typeck.c (output_pending_init_elements): Handle overflow of > constructor_unfilled_index. This patch needs to add include a testcase to the testsuite that fails before and passes after the patch. (I realise such a test may only be able to run for a subset of targets.) -- Joseph S. Myers jos...@codesourcery.com
Re: libtool update for powerpc64le-linux
On Fri, 23 Aug 2013, Alan Modra wrote: > I'd like to import upstream libtool into gcc to support powerpc64le, Has the sysroot semantics issue been resolved in upstream libtool, or do you mean "import with 3334f7ed5851ef1e96b052f2984c4acdbf39e20c reverted"? -- Joseph S. Myers jos...@codesourcery.com
Re: RFA: AVR: Support building AVR Linux targets
On Fri, 23 Aug 2013, nick clifton wrote: > Hi Joseph, > > Your patch itself makes sense on general principles, but the concept of an > > AVR Linux target doesn't - this is an 8-bit processor Really, the bug > > you've found is that there's an avr-*-* case that is too general, matching > > nonsensical targets such as AVR Linux rather than just avr-*-none / > > avr-*-elf. > > Fair enough. Would you like me to > > A. Apply the patch anyway. On the general principle that target specific > sections in config.gcc add to tmake_file rather than override it. > > B. Do nothing. On the general principle that if it ain't broke don't fix > it. > > C. Draw up another patch that restricts the AVR patterns in config.gcc to > -none and -elf. A and C - I think both changes should be applied. -- Joseph S. Myers jos...@codesourcery.com
RE: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
On Fri, 23 Aug 2013, Zoran Jovanovic wrote: > New test case involving unions is added. Tests for unions should include *execution* tests that the relevant bits have the right values after the sequence of assignments. -- Joseph S. Myers jos...@codesourcery.com
Re: Request to merge Undefined Behavior Sanitizer in
On Thu, 8 Aug 2013, Joseph S. Myers wrote: On Fri, 26 Jul 2013, Marc Glisse wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 (that is using llvm's sanitizer) and for a first patch (unreviewed): http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html (started at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01402.html ) That patch is OK. Applied at r201953 after retesting, thanks. -- Marc Glisse
Re: wide-int branch now up for public comment and review
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> /* Negate THIS. */
>> inline wide_int_ro
>> wide_int_ro::operator - () const
>> {
>> wide_int_ro r;
>> r = wide_int_ro (0) - *this;
>> return r;
>> }
>>
>> /* Negate THIS. */
>> inline wide_int_ro
>> wide_int_ro::neg () const
>> {
>> wide_int_ro z = wide_int_ro::from_shwi (0, precision);
>>
>> gcc_checking_assert (precision);
>> return z - *this;
>> }
>
> Why do we need both of these, and why are they implemented slightly
> differently?
Thanks for the review.
neg can go away. There was a time when operator names weren't used, and I
added them to make client code more natural. I've removed neg () and updated
neg (overflow) to match the style of operator -().
Index: wide-int.cc
===
--- wide-int.cc (revision 201894)
+++ wide-int.cc (working copy)
@@ -1545,7 +1545,7 @@ wide_int_ro::abs () const
gcc_checking_assert (precision);
if (sign_mask ())
-result = neg ();
+result = -*this;
else
result = *this;
Index: wide-int.h
===
--- wide-int.h (revision 201950)
+++ wide-int.h (working copy)
@@ -1800,19 +1800,7 @@ class GTY(()) wide_int_ro {
/* Negate this. */
inline wide_int_ro operator - () const {
-wide_int_ro r;
-r = wide_int_ro (0) - *this;
-return r;
- }
-
- /* Negate THIS. */
- inline wide_int_ro
- neg () const
- {
-wide_int_ro z = wide_int_ro::from_shwi (0, precision);
-
-gcc_checking_assert (precision);
-return z - *this;
+return wide_int_ro (0) - *this;
}
/* Negate THIS. OVERFLOW is set true if the value cannot be
@@ -1820,12 +1808,11 @@ class GTY(()) wide_int_ro {
inline wide_int_ro
neg (bool *overflow) const
{
-wide_int_ro z = wide_int_ro::from_shwi (0, precision);
-
gcc_checking_assert (precision);
+
*overflow = only_sign_bit_p ();
-return z - *this;
+return wide_int_ro (0) - *this;
}
wide_int_ro parity () const;
>> template
>> inline bool
>> fixed_wide_int ::multiple_of_p (const wide_int_ro &factor,
>> signop sgn,
>> fixed_wide_int *multiple) const
>> {
>> return wide_int_ro::multiple_of_p (factor, sgn,
>> reinterpret_cast (multiple));
>> }
>
> The patch has several instances of this kind of reinterpret_cast.
> It looks like an aliasing violation.
The cast is completely unneeded, so I removed it. sdivmod_floor was of the
same class, so I removed it as well. These two uses of reinterpret_cast are a
bit different from the rest of them. I'll see about addressing the remaining
ones in a followup.
diff --git a/gcc/wide-int.h b/gcc/wide-int.h
index 0a906a9..3fef0d5 100644
--- a/gcc/wide-int.h
+++ b/gcc/wide-int.h
@@ -3081,9 +3081,7 @@ public:
bool multiple_of_p (const wide_int_ro &factor,
signop sgn,
fixed_wide_int *multiple) const {
-return wide_int_ro::multiple_of_p (factor,
- sgn,
- reinterpret_cast
(multiple));
+return wide_int_ro::multiple_of_p (factor, sgn, multiple);
}
/* Conversion to and from GMP integer representations. */
@@ -3336,7 +3334,7 @@ public:
}
template
inline fixed_wide_int sdivmod_floor (const T &c, fixed_wide_int *mod) const {
-return wide_int_ro::sdivmod_floor (c, reinterpret_cast (mod));
+return wide_int_ro::sdivmod_floor (c, mod);
}
/* Shifting rotating and extracting. */
Clean up pretty printers [12/n]
The primary function of this patch is to formally make the class
pretty_printer polymorphic (in the OO sense.) It has always been
conceptually polymorphic -- we just didn't have linguistic support to
say so in C. As a secondary change, the patch makes a systematic use of
pp_buffer -- making it easier to search for a pretty printer's output
buffer access.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-08-23 Gabriel Dos Reis
* diagnostic.c (diagnostic_set_caret_max_width): Use pp_buffer.
* gimple-pretty-print.c (gimple_dump_bb_buff): Likewise.
* pretty-print.c (pp_formatted_text_data): Likewise.
(pp_write_text_to_stream): Likewise.
(pp_write_text_as_dot_label_to_stream): Likewise.
(pp_append_r): Likewise.
(pp_format): Likewise.
(pp_flush): Likewise.
(pp_clear_output_area): Likewise.
(pp_append_text): Likewise.
(pp_formatted_text): Likewise.
(pp_remaining_character_count_for_line): Likewise.
(pp_newline): Likewise.
(pp_character): Likewise.
(output_buffer::~output_buffer): Define.
(pretty_printer::~pretty_printer): Destruct output buffer.
* pretty-print.h (output_buffer::~output_buffer): Declare.
(pretty_printer::~pretty_printer): Declare virtual.
c/
* c-objc-common.c (c_tree_printer): Document the nature of the cast.
(c_initialize_diagnostics): Call a destructor for the early printer.
cp/
* cp-objcp-common.c (cxx_initialize_diagnostics): Call a
destructor for the early printer.
* error.c (type_to_string): Use pp_buffer.
Index: c/c-objc-common.c
===
--- c/c-objc-common.c (revision 201955)
+++ c/c-objc-common.c (working copy)
@@ -92,6 +92,7 @@
{
tree t = NULL_TREE;
tree name;
+ // FIXME: the next cast should be a dynamic_cast, when it is permitted.
c_pretty_printer *cpp = (c_pretty_printer *) pp;
pp->padding = pp_none;
@@ -192,6 +193,7 @@
context->printer = new (pp) c_pretty_printer ();
/* It is safe to free this object because it was previously XNEW()'d. */
+ base->~pretty_printer ();
XDELETE (base);
}
Index: cp/cp-objcp-common.c
===
--- cp/cp-objcp-common.c(revision 201955)
+++ cp/cp-objcp-common.c(working copy)
@@ -140,6 +140,7 @@
context->printer = new (pp) cxx_pretty_printer ();
/* It is safe to free this object because it was previously XNEW()'d. */
+ base->~pretty_printer ();
XDELETE (base);
}
Index: cp/error.c
===
--- cp/error.c (revision 201955)
+++ cp/error.c (working copy)
@@ -2881,7 +2881,7 @@
&& !uses_template_parms (typ))
{
int aka_start; char *p;
- struct obstack *ob = cxx_pp->buffer->obstack;
+ struct obstack *ob = pp_buffer (cxx_pp)->obstack;
/* Remember the end of the initial dump. */
int len = obstack_object_size (ob);
tree aka = strip_typedefs (typ);
Index: diagnostic.c
===
--- diagnostic.c(revision 201955)
+++ diagnostic.c(working copy)
@@ -104,7 +104,7 @@
{
/* One minus to account for the leading empty space. */
value = value ? value - 1
-: (isatty (fileno (context->printer->buffer->stream))
+: (isatty (fileno (pp_buffer (context->printer)->stream))
? getenv_columns () - 1: INT_MAX);
if (value <= 0)
Index: gimple-pretty-print.c
===
--- gimple-pretty-print.c (revision 201955)
+++ gimple-pretty-print.c (working copy)
@@ -2249,7 +2249,7 @@
pp_newline_and_flush (buffer);
gcc_checking_assert (DECL_STRUCT_FUNCTION (current_function_decl));
dump_histograms_for_stmt (DECL_STRUCT_FUNCTION (current_function_decl),
- buffer->buffer->stream, stmt);
+ pp_buffer(buffer)->stream, stmt);
}
dump_implicit_edges (buffer, bb, indent, flags);
Index: pretty-print.c
===
--- pretty-print.c (revision 201955)
+++ pretty-print.c (working copy)
@@ -46,9 +46,17 @@
obstack_init (&chunk_obstack);
}
+// Release resources owned by an output buffer at the end of lifetime.
+
+output_buffer::~output_buffer ()
+{
+ obstack_free (&chunk_obstack, obstack_finish (&chunk_obstack));
+ obstack_free (&formatted_obstack, obstack_finish (&formatted_obstack));
+}
+
/* A pointer to the formatted diagnostic message. */
#define pp_formatted_text_data(PP) \
- ((const char *) obstack_base ((PP)->buffer->obstack))
+ ((const char *) obstack_base (pp_buffer (PP)->obstack))
/* Format an integer given by va_arg (ARG, type-specifier T) where
type-specifier is
Re: [C++ patch] Set attributes for C++ runtime library calls
On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
wrote:
>>> My reasoning (for C++98, but the same is true for C++11) is based
>>> on 3.8/1:
>>> […]
>>> The lifetime of an object of type T ends when:
>>> -- if T is a class type with a non-trivial destructor (12.4),
>>> the destructor call starts, or
>>> -- the storage which the object occupies is reused or released.
>>>
>>> Doing a placement-new on the storage occupied by 'a' is reusing
>>> its storage, therefore ending its lifetime.
>>
>> The problem is that reused is not well defined,
>
> I am not quite so sure.
If it were, there would be a definition of it. If there were, you could quote
it and we could discuss it. I know what it means, and I have a nice
theoretical backing for it and the actual definition would require 3 pages to
explain.
> But even so, in light of this, I don't think you original assertion is
> definitive.
Nothing is ever definitive. Now, if you want to say I quoted something wrong,
or that I am reading the standard wrong, or that it doesn't apply as I think it
does, feel free to point this out. I do view this as as a two way street,
despite the certainty I might profess.
>> so, we are into the weeds right there.
>>
>> int i, j;
>>
>> int *ip = &i;
>>
>> i = 1;
>> j = 2;
>> *ip = j;
>> ++i;
>> ++j;
>>
>> here, we sees the storage being reused in the *ip = j;
>
> Really?
>> statement, or, is it merely changing the value?
>
> That is an assignment to an existing int storage.
>> And what if we do a memcpy (ip, &j, sizeof (int));
>
> Well, the case of 'memcpy' isn't defined by the standard
Odd, in the c++98 standard memcpy was defined by the standard, as well as the
open code that memcpy would be. I find memcpy in [diff.library]. I can quote
all the requirements that makes the open code work as well. It is defined.
You can see evidence that we meant for it to work here:
2 For any complete POD object type T, whether or not the object holds a
valid value of type T, the underlying bytes (_intro.memory_) making up
the object can be copied into an array of char or unsigned char.36) If
the content of the array of char or unsigned char is copied back into
the object, the object shall subsequently hold its original value.
[Example:
#define N sizeof(T)
char buf[N];
T obj; // obj initialized to its original value
memcpy(buf, &obj, N); // between these two calls to memcpy,
// obj might be modified
memcpy(&obj, buf, N); // at this point, each subobject of obj of
scalar type
// holds its original value
thought, I view this as completely redundant with the standard and should just
be a note. From the base standard, in C99 is it defined in 7.24.4.2.3 and I
suspect remains largely unchanged from previous standards.
>> Is that reused, or merely changing the value.
>
> The current proposal is that it constructs an int value, therefore
> is moral equivalent of copy-constructor call.
I'd be interested in the final resolution. You have a DR number for the issue
or a paper where they talk about the issues?
>> I think the most logical line of reasoning is that when the requirements of
>> [basic.lval] are met, the, this is a change of value of an object, not a
>> modification to it's lifetime.
>
> Why?
Because if you end the lifetime of the original int, you destroy the semantic
that everyone knows for C. This cannot be done.
>> So, in the case quoted, since the type of the accesses are both int, we
>> don't reuse the storage, since the requirements of [basic.lval] are met.
>
> Consider:
>
>struct S {
>S(int);
>~S();
>// …
>};
>
>int main() {
>S s(8);
>
> new (&s) S(9); // #1
>}
>
> Is #1 a reuse of storage to create a new object or assignment?
Behaves as assignment, s exists post the new, til the closing }.
>> Indeed, the programmer expects that they can access i after *ip = j; and
>> that the _value_ that object, while changed from the original 1, will be 2
>> just after the *ip = j; statement.
>>
>> Since we know that i must be 3 at the end, we then know what the wording,
>> reused, must mean, cause other meanings that could possibly make it work for
>> you in the case you are considering, would destroy this property of
>> pointers, and everyone knows the semantics of pointers, they are undisputed.
>> Or put another way, you cannot misread reused in this way.
>
> And why do you assert that I misread 'reused' in this way?
See your email that I originally replied to.
Let me quote it here:
> If the user-supplied operator new returns &a, then it must
> also ensure that 'a' is not used anywhere else -- e.g. I you can't
> do lvalue-to-value conversion on 'a' to see what is written there.
> Because its storage has been reused.
You said it was reused, this is wrong. You use that as backing to
Re: [PATCH v3 12/18] convert the Go front end to automatic dependencies
2013/8/20 Tom Tromey : > This converts Go. > > It renames gospec.o to go/gospec.o, for uniformity and so we can > remove an explicit rule. > > It defines go_OBJS, to conform to the documented Make-lang.in > conventions, and to ensure that Go objects are given the correct > order-only dependencies on generated files. > > * Make-lang.in (gospec.o): Remove. > (CFLAGS-go/gospec.o): New variable. > (GCCGO_OBJS): Update to use go/gospec.o. > (go_OBJS): Define. > (GO_SYSTEM_H, GO_C_H, GO_LINEMAP_H, GO_LEX_H, GO_PARSE_H) > (GO_GOGO_H, GO_TYPES_H, GO_STATEMENTS_H, GO_EXPRESSIONS_H) > (GO_EXPORT_H, GO_IMPORT_H, GO_RUNTIME_H, GO_AST_DUMP_H) > (go/go-backend.o, go/go-lang.o, go/go-gcc.o, go/go-linemap.o) > (go/ast-dump.o, go/dataflow.o, go/export.o, go/expressions.o) > (go/go.o, go/go-dump.o, go/go-optimize.o, go/gogo-tree.o) > (go/gogo.o, go/import.o, go/import-archive.o, go/lex.o) > (go/parse.o, go/runtime.o, go/statements.o, go/types.o) > (go/unsafe.o): Remove. > (CFLAGS-go/go-gcc.o, CFLAGS-go/go-linemap.o): New variables. > (go/%.o: go/gofrontend/%.cc): Use COMPILE and POSTCOMPILE. This is OK. I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked at the new definition of $(COMPILE). Many thanks. Ian
Re: Type inheritance graph analysis & speculative devirtualization, part 4a/6 simple anonymous namespace devirtualization during cgraph construction
Hi,
On 08/23/2013 05:12 PM, Jan Hubicka wrote:
+/* { dg-final { scan-tree-dump-nop "A::foo" 0 "ssa"} } */
This should be scan-tree-dump-not right?
Paolo.
Re: [C++ patch] Set attributes for C++ runtime library calls
On Fri, Aug 23, 2013 at 7:32 PM, Mike Stump wrote:
> On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
> wrote:
>> But even so, in light of this, I don't think you original assertion is
>> definitive.
>
> Nothing is ever definitive. Now, if you want to say I quoted something
> wrong, or that I am reading the standard wrong, or that it doesn't apply as I
> think it does, feel free to point this out. I do view this as as a two way
> street, despite the certainty I might profess.
Ha!
If you quoted the standard to back up your assertions, I would have been
able to "feel free to point this out" :-)
The thing is I am still trying to figure out what (1) what you would have liked;
(2) what you believe the standards mandate, with appropriate quote; and
(3) what you consider QoI.
(3) would be a matter of GCC design choice discussion: for example,
what we would like to guarantee under certain flags, etc.
You need to separate those three things so we can make progress.
>>
>> Really?
>
>>> statement, or, is it merely changing the value?
>>
>> That is an assignment to an existing int storage.
>
>>> And what if we do a memcpy (ip, &j, sizeof (int));
>>
>> Well, the case of 'memcpy' isn't defined by the standard
>
> Odd, in the c++98 standard memcpy was defined by the standard, as well as the
> open code that memcpy would be. I find memcpy in [diff.library]. I can
> quote all the requirements that makes the open code work as well. It is
> defined.
When I say "the case of 'memcpy' isn't defined", I was not saying that
the function "memcpy" itself isn't defined by the standard. I was discussing
its effect in the scope of this discussion, e.g. lifetime vs. assignment.
That isn't defined in the standard.
>
> You can see evidence that we meant for it to work here:
>
> 2 For any complete POD object type T, whether or not the object holds a
> valid value of type T, the underlying bytes (_intro.memory_) making up
> the object can be copied into an array of char or unsigned char.36) If
> the content of the array of char or unsigned char is copied back into
> the object, the object shall subsequently hold its original value.
> [Example:
> #define N sizeof(T)
> char buf[N];
> T obj; // obj initialized to its original value
> memcpy(buf, &obj, N); // between these two calls to memcpy,
> // obj might be modified
> memcpy(&obj, buf, N); // at this point, each subobject of obj of
> scalar type
> // holds its original value
>
> thought, I view this as completely redundant with the standard and should
> just be a note. From the base standard, in C99 is it defined in 7.24.4.2.3
> and I suspect remains largely unchanged from previous standards.
>
This does not say whether the effect of memcpy is assigment or copy
construction.
Which was the point I was making.
>>> Is that reused, or merely changing the value.
>>
>> The current proposal is that it constructs an int value, therefore
>> is moral equivalent of copy-constructor call.
>
> I'd be interested in the final resolution. You have a DR number for the
> issue or a paper where they talk about the issues?
This came out of a discussion of a larger issue on the SG12 mailing list.
I do not have the paper number yet since it is to be part of the Chicago
mailing list.
>>> I think the most logical line of reasoning is that when the requirements of
>>> [basic.lval] are met, the, this is a change of value of an object, not a
>>> modification to it's lifetime.
>>
>> Why?
>
> Because if you end the lifetime of the original int, you destroy the semantic
> that everyone knows for C. This cannot be done.
But:
(1) we are not talking about C
(2) C does not have a notion of lifetime -- at least not in the sense of C++.
So, whatever notion of semantics you think everyone knows of C
is largely irrelevant.
>>> So, in the case quoted, since the type of the accesses are both int, we
>>> don't reuse the storage, since the requirements of [basic.lval] are met.
>>
>> Consider:
>>
>>struct S {
>>S(int);
>>~S();
>>// …
>>};
>>
>>int main() {
>>S s(8);
>>
>> new (&s) S(9); // #1
>>}
>>
>> Is #1 a reuse of storage to create a new object or assignment?
>
> Behaves as assignment, s exists post the new, til the closing }.
What does not mean concretely? Note that the "// …" could
have declared S::operator= to behave differently or be entirely deleted.
>>> Indeed, the programmer expects that they can access i after *ip = j; and
>>> that the _value_ that object, while changed from the original 1, will be 2
>>> just after the *ip = j; statement.
>>>
>>> Since we know that i must be 3 at the end, we then know what the wording,
>>> reused, must mean, cause other meanings that could possibly make it work
>>> for you in the case you are considering, would destroy this property of
>>> poi
Re: wide-int branch now up for public comment and review
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> #define addr_max_bitsize (64)
>> #define addr_max_precision \
>
> These should either be lower-case C++ constants or upper-case macros.
Fixed:
diff --git a/gcc/wide-int.h b/gcc/wide-int.h
index 9ccdf7c..b40962c 100644
--- a/gcc/wide-int.h
+++ b/gcc/wide-int.h
@@ -247,15 +247,15 @@ along with GCC; see the file COPYING3. If not see
on any platform is 64 bits. When that changes, then it is likely
that a target hook should be defined so that targets can make this
value larger for those targets. */
-#define addr_max_bitsize (64)
+const int addr_max_bitsize = 64;
/* This is the internal precision used when doing any address
arithmetic. The '4' is really 3 + 1. Three of the bits are for
the number of extra bits needed to do bit addresses and single bit is
allow everything to be signed without loosing any precision. Then
everything is rounded up to the next HWI for efficiency. */
-#define addr_max_precision \
- ((addr_max_bitsize + 4 + HOST_BITS_PER_WIDE_INT - 1) &
~(HOST_BITS_PER_WIDE_INT - 1))
+const int addr_max_precision
+ = ((addr_max_bitsize + 4 + HOST_BITS_PER_WIDE_INT - 1) &
~(HOST_BITS_PER_WIDE_INT - 1));
enum ShiftOp {
NONE,
Re: wide-int branch now up for public comment and review
On Aug 23, 2013, at 8:02 AM, Richard Sandiford wrote: >> * When a constant that has an integer type is converted to a >>wide-int it comes in with precision 0. For these constants the >>top bit does accurately reflect the sign of that constant; this >>is an exception to the normal rule that the signedness is not >>represented. When used in a binary operation, the wide-int >>implementation properly extends these constants so that they >>properly match the other operand of the computation. This allows >>you write: >> >> tree t = ... >> wide_int x = t + 6; >> >>assuming t is a int_cst. > > This seems dangerous. Not all code that uses "unsigned HOST_WIDE_INT" > actually wants it to be an unsigned value. Some code uses it to avoid > the undefinedness of signed overflow. So these overloads could lead > to us accidentally zero-extending what's conceptually a signed value > without any obvious indication that that's happening. Also, hex constants > are unsigned int, but it doesn't seem safe to assume that 0x8000 was > meant to be zero-extended. > > I realise the same thing can happen if you mix "unsigned int" with > HOST_WIDE_INT, but the point is that you shouldn't really do that > in general, whereas we're defining these overloads precisely so that > a mixture can be used. So, I don't like penalizing all users, because one user might write incorrect code. We have the simple operators so that users can retain some of the simplicity and beauty that is the underlying language. Those semantics are well known and reasonable. We reasonably match those semantics. At the end of the day, we have to be able to trust what the user writes. Now, a user that doesn't trust themselves, can elect to not use these functions; they aren't required to use them.
Re: [C++ patch] Set attributes for C++ runtime library calls
On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
wrote:
> If you quoted the standard to back up your assertions, I would have been
> able to "feel free to point this out" :-)
>
> The thing is I am still trying to figure out what (1) what you would have
> liked;
I've directly stated it, not sure how you missed it. The life of the original
object does not end.
> (2) what you believe the standards mandate, with appropriate quote; and
The life of the original object does not end. See below for the quote.
>>> Really?
>>
statement, or, is it merely changing the value?
>>>
>>> That is an assignment to an existing int storage.
>>
And what if we do a memcpy (ip, &j, sizeof (int));
>>>
>>> Well, the case of 'memcpy' isn't defined by the standard
>>
>> Odd, in the c++98 standard memcpy was defined by the standard, as well as
>> the open code that memcpy would be. I find memcpy in [diff.library]. I can
>> quote all the requirements that makes the open code work as well. It is
>> defined.
>
> When I say "the case of 'memcpy' isn't defined", I was not saying that
> the function "memcpy" itself isn't defined by the standard. I was discussing
> its effect in the scope of this discussion, e.g. lifetime vs. assignment.
> That isn't defined in the standard.
And yet memcpy is exactly defined and all interactions with the entire rest of
the standard are as specified. Those semantics that are defined and required,
are, by definition. You can't make them go away by claiming they are undefined.
int i = 1, j = 2;
{
memcpy (&i, &j)
// here i exists and is 2.
}
3.7.1 Static storage duration [basic.stc.static]
1 All objects which neither have dynamic storage duration nor are local
have static storage duration. The storage for these objects shall
last for the duration of the program (_basic.start.init_,
_basic.start.term_).
This covers why i exists. As for why i has the value 2, gosh:
7.21.2.1 The memcpy function
Synopsis
[#1]
#include
void *memcpy(void * restrict s1,
const void * restrict s2,
size_t n);
Description
[#2] The memcpy function copies n characters from the object
pointed to by s2 into the object pointed to by s1. If
copying takes place between objects that overlap, the
behavior is undefined.
1.6 The C++ memory model [intro.memory]
1 The fundamental storage unit in the C++ memory model is the byte.
An object of POD4) type
(_basic.types_) shall occupy contiguous bytes of storage.
5.3.3 Sizeof[expr.sizeof]
1 The sizeof operator yields the number of bytes in the object represen-
tation of its operand. The operand is either an expression, which is
not evaluated, or a parenthesized type-id. The sizeof operator shall
4 The object representation of an object of type T is the sequence of N
unsigned char objects taken up by the object of type T, where N equals
sizeof(T). The value representation of an object is the set of bits
that hold the value of type T. For POD types, the value representa-
tion is a set of bits in the object representation that determines a
value, which is one discrete element of an implementation-defined set
of values.37)
>> You can see evidence that we meant for it to work here:
>>
>> 2 For any complete POD object type T, whether or not the object holds a
>> valid value of type T, the underlying bytes (_intro.memory_) making up
>> the object can be copied into an array
Re: [C++ patch] Set attributes for C++ runtime library calls
On Fri, Aug 23, 2013 at 10:34 PM, Mike Stump wrote:
> On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
> wrote:
>> If you quoted the standard to back up your assertions, I would have been
>> able to "feel free to point this out" :-)
>>
>> The thing is I am still trying to figure out what (1) what you would have
>> liked;
>
> I've directly stated it, not sure how you missed it. The life of the
> original object does not end.
You made a statement. It was not clear whether it was what you want
or whether it is what the standards mandate.
>> (2) what you believe the standards mandate, with appropriate quote; and
>
> The life of the original object does not end. See below for the quote.
Your assertion or a quote from the standards?
>
Really?
>>>
> statement, or, is it merely changing the value?
That is an assignment to an existing int storage.
>>>
> And what if we do a memcpy (ip, &j, sizeof (int));
Well, the case of 'memcpy' isn't defined by the standard
>>>
>>> Odd, in the c++98 standard memcpy was defined by the standard, as well as
>>> the open code that memcpy would be. I find memcpy in [diff.library]. I
>>> can quote all the requirements that makes the open code work as well. It
>>> is defined.
>>
>> When I say "the case of 'memcpy' isn't defined", I was not saying that
>> the function "memcpy" itself isn't defined by the standard. I was discussing
>> its effect in the scope of this discussion, e.g. lifetime vs. assignment.
>> That isn't defined in the standard.
>
> And yet memcpy is exactly defined and all interactions with the entire rest
> of the standard are as specified. Those semantics that are defined and
> required, are, by definition. You can't make them go away by claiming they
> are undefined.
I have no idea what exactly you are talking about.
If you have a rule in that standards that say that mempcy is assignment,
please share it with us.
>
> int i = 1, j = 2;
> {
> memcpy (&i, &j)
> // here i exists and is 2.
> }
>
> 3.7.1 Static storage duration [basic.stc.static]
>
> 1 All objects which neither have dynamic storage duration nor are local
> have static storage duration. The storage for these objects shall
> last for the duration of the program (_basic.start.init_,
> _basic.start.term_).
>
> This covers why i exists.
The storage duration of an object is not necessarily the same
as its lifetime.
> As for why i has the value 2, gosh:
>
>7.21.2.1 The memcpy function
>
>Synopsis
>
>[#1]
>
>#include
>void *memcpy(void * restrict s1,
>const void * restrict s2,
>size_t n);
>
>Description
>
>[#2] The memcpy function copies n characters from the object
>pointed to by s2 into the object pointed to by s1. If
>copying takes place between objects that overlap, the
>behavior is undefined.
>
>
> 1.6 The C++ memory model [intro.memory]
>
> 1 The fundamental storage unit in the C++ memory model is the byte.
>
> An object of POD4) type
> (_basic.types_) shall occupy contiguous bytes of storage.
>
> 5.3.3 Sizeof[expr.sizeof]
>
> 1 The sizeof operator yields the number of bytes in the object represen-
> tation of its operand. The operand is either an expression, which is
> not evaluated, or a parenthesized type-id. The sizeof operator shall
>
> 4 The object representation of an object of type T is the sequence of N
> unsigned char objects taken up by the object of type T, where N equals
> sizeof(T). The value representation of an object is the set of bits
> that hold the value of type T. For POD types, the value representa-
> tion is a set of bits in the object representation that determines a
> value, which is one discrete element of an implementation-defined set
> of values.37)
Yes, but what is the relevance?
>
>>> You can see evidence that we meant for it to work here:
>>>
>>> 2 For any complete POD object type T, whether or not the object holds a
>>> valid value of type T, the underlying bytes (_intro.memory_) making up
>>> the object can be copied into an array of char or unsigned char.36) If
>>> the content of the array of char or unsigned char is copied back into
>>> the object, the object shall subsequently hold its original value.
>>> [Example:
>>> #define N sizeof(T)
>>> char buf[N];
>>> T obj; // obj initialized to its original value
>>> memcpy(buf, &obj, N); // between these two calls to memcpy,
>>> // obj might be modified
>>> memcpy(&obj, buf, N); // at this point, each subobject of obj of
>>> scalar type
>>> // holds its original value
>>>
>>> thought, I view this as c
Trivial improvement to PRE debug dumps
I was looking at a performance issue with some jump threading
improvements when I had to dig through the PRE dumps.
PRE notes when it finds fully redundant expressions, but fails to
actually include fully redundant expression in a textual form in the
debugging dump.
ie, before my patch PRE would dump something like this:
Starting insert iteration 1
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
With my patch it will dump:
Starting insert iteration 1
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_defs.23_269}@.MEM_14
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_defs.23_269}@.MEM_14
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_defs.23_269}@.MEM_14
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_defs.23_269}@.MEM_14
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_uses.22_365}@.MEM_10
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_uses.22_365}@.MEM_10
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_uses.22_365}@.MEM_10
Found fully redundant value:
{component_ref,component_ref,mem_ref<0B>,build_uses.22_365}@.MEM_10
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
Jeff
commit cd3e98d9581722fbf4509bba6812b9a0929d7783
Author: law
Date: Sat Aug 24 04:48:19 2013 +
* tree-ssa-pre.c (do_regular_insertion): Include the expression
in the debugging dump when the expression is fully redundant.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@201963
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b35e5f3..cd8b3f6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-08-23 Jeff Law
+
+ * tree-ssa-pre.c (do_regular_insertion): Include the expression in
+ the debugging dump when the expression is fully redundant.
+
2013-08-23 Gabriel Dos Reis
* diagnostic.c (diagnostic_set_caret_max_width): Use pp_buffer.
diff --git a/gcc/tree-ssa-pre.c b/gcc/tree-ssa-pre.c
index f6928a8..56b0573 100644
--- a/gcc/tree-ssa-pre.c
+++ b/gcc/tree-ssa-pre.c
@@ -3341,7 +3341,11 @@ do_regular_insertion (basic_block block, basic_block dom)
if (bitmap_set_contains_value (AVAIL_OUT (dom), val))
{
if (dump_file && (dump_flags & TDF_DETAILS))
- fprintf (dump_file, "Found fully redundant value\n");
+ {
+ fprintf (dump_file, "Found fully redundant value: ");
+ print_pre_expr (dump_file, expr);
+ fprintf (dump_file, "\n");
+ }
continue;
}
Re: msp430 port
On 08/23/2013 01:52 PM, DJ Delorie wrote: so... can I get an official "ok to commit with you and Nick as maintainers" then? Just need to clear it with the steering committee, which for this sort of thing has been pretty trivial. Basically it has to pass the technical review (which y'all have already done) and if y'all become unresponsive, then the port will be deprecated. Jeff
Re: [Patch 2/2] Localization problem in regex
On Sat, Aug 24, 2013 at 1:51 AM, Stefan Schweter wrote:
> Am Fri, 23 Aug 2013 17:17:41 +0800
> schrieb Tim Shen :
>
>> Inspired by this mail:
>> http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
>>
>> Thanks!
>>
>>
>
> Hi Tim,
>
> I applied the patch + compiled everything - it's working now! Thanks!
>
> But... I found a problem with .imbue():
>
> int main()
> {
> std::setlocale(LC_ALL, "");
>
> std::wstring str2 = L"öäü";
> std::wregex re2;
> re2.imbue(std::locale(""));
> re2.assign(L"([[:lower:]]+)");
> std::wsmatch m2;
>
> std::wsregex_token_iterator end {};
>
> for (std::wsregex_token_iterator p{str2.begin(), str2.end(),
> re2, {1}}; p != end; ++p) { std::wcout << *p << std::endl;
> }
>
> return 0;
> }
>
> Works fine! But when there's no imbue() call, a Segmentation
> fault occurs.
>
> int main()
> {
> std::setlocale(LC_ALL, "");
>
> std::wstring str2 = L"öäü";
> std::wregex re2;
> //re2.imbue(std::locale(""));
> re2.assign(L"([[:lower:]]+)");
> std::wsmatch m2;
>
> std::wsregex_token_iterator end {};
>
> for (std::wsregex_token_iterator p{str2.begin(), str2.end(),
> re2, {1}}; p != end; ++p) { std::wcout << *p << std::endl;
> }
>
> return 0;
> }
>
> May be it's better to throw an exception here? Thanks in advance,
>
> Stefan
Fixed.
It's not fully tested. I just run the 28_regex testcases. I'll do a
full test before committing.
Thanks again!
--
Tim Shen
regex-locale.patch
Description: Binary data
Re: [C++ patch] Move FINAL flag to middle-end trees.
On 08/23/2013 10:51 AM, Jan Hubicka wrote: Sadly we ICE here because BINFO of type is not built yet. I tried to move the code after xref_binfos and it does seem to lead to errors while building libstdc++ PCH. Any idea what to do here? If it's causing trouble, let's just put the flag on the type. here I now can devirtualize b->foo into A because A is in anonymous namespace. We however won't remove b because it is externally visible. Is it valid to bring b local based on fact that A is anonymous and thus no valid C++ program can read it? Hmm, determine_visibility ought to be doing that already. Jason
