Re: PATCH RFA: New configure option --with-native-system-header-dir
On 10/09/2011 08:18 AM, Ian Lance Taylor wrote: +#undef NATIVE_HEADER_HEADER_COMPONENT +#define NATIVE_SYSTEM_HEADER_COMPONENT "MINGW" Typo (I think), otherwise okay. Paolo
Re: [wwwdocs] gcc-4.6/porting_to.html
Hi Benjamin,
On Wed, 16 Mar 2011, Benjamin Kosnik wrote:
> Needs some more work, here's a rough draft.
I realized this one hasn't made it in, but is really nice. I made a
number of minor edits (typos, markup, simplifying headings,... among
others). What do you think -- should we include this?
Many users still won't have GCC 4.6 deployed yet, so I think it's
still worth it.
What do you think?
Gerald
Index: porting_to.html
===
RCS file: porting_to.html
diff -N porting_to.html
--- /dev/null 1 Jan 1970 00:00:00 -
+++ porting_to.html 11 Oct 2011 04:47:14 -
@@ -0,0 +1,142 @@
+
+
+
+Porting to GCC 4.6
+
+
+
+Porting to GCC 4.6
+
+
+The GCC 4.6 release series differs from previous GCC releases in more
+than the usual list of
+http://gcc.gnu.org/gcc-4.6/changes.html";>changes. Some of
+these are a result of bug fixing, and some old behaviors have been
+intentionally changed in order to support new standards, or relaxed
+instandards-conforming ways to facilitate compilation or runtime
+performance. Some of these changes are not visible to the naked eye
+and will not cause problems when updating from older versions.
+
+
+
+However, some of these changes are visible, and can cause grief to
+users porting to GCC 4.6. This document is an effort to identify major
+issues and provide clear solutions in a quick and easily searched
+manner. Additions and suggestions for improvement are welcome.
+
+
+C language issues
+
+New warnings for unused variables and parameters
+
+
+The behavior of -Wall has changed and now includes the
+new warning flags -Wunused-but-set-variable and
+(with -Wall
+-Wextra) -Wunused-but-set-parameter. This may
+result in new warnings in code that compiled cleanly with previous
+versions of GCC.
+
+
+
+For example,
+
+ void fn (void)
+ {
+int foo;
+foo = bar (); /* foo is never used. */
+ }
+
+Gives the following diagnostic:
+
+warning: variable "foo" set but not used [-Wunused-but-set-variable]
+
+
+low flag
+with -Werror and optimization flags above -O2
+may result in compile errors when using glibc optimizations
+for strcmp.
+
+
+
+For example,
+
+#include
+void do_rm_rf (const char *p) { if (strcmp (p, "/") == 0) return; }
+
+Results in the following diagnostic:
+
+error: assuming signed overflow does not occur when changing X +- C1 cmp C2 to
X cmp C1 +- C2 [-Werror=strict-overflow]
+
+
+
+
+To work around this, use -D__NO_STRING_INLINES.
+
+
+C++ language issues
+
+Header dependency changes
+
+
+Many of the standard C++ library include files have been edited to no
+longer include to get namespace std
+-scoped versions of size_t and ptrdiff_t.
+
+
+
+As such, C++ programs that used the macros NULL
+or offsetof without including will no
+longer compile. The diagnostic produced is similar to:
+
+
+
+error: 'ptrdiff_t' does not name a type
+
+
+
+error: 'size_t' has not been declared
+
+
+
+error: 'NULL' was not declared in this scope
+
+
+
+error: there are no arguments to 'offsetof' that depend on a template
+parameter, so a declaration of 'offsetof' must be available
+
+
+
+Fixing this issue is easy: just include .
+
+
+
+
+Links
+
+
+Jakub Jelinek,
+ http://lists.fedoraproject.org/pipermail/devel/2011-February/148523.html";>GCC
+4.6 related common package rebuild failures (was Re: mass rebuild status)
+
+
+
+Matthias Klose,
+http://lists.debian.org/debian-devel-announce/2011/02/msg00012.html";>prepare
+to fix build failures with new GCC versions
+
+
+
+Jim Meyering,
+ http://lists.fedoraproject.org/pipermail/devel/2011-March/149355.html";>gcc-4.6.0-0.12.fc15.x86_64
breaks strcmp?
+
+
+
+
+
+
+
+
Re: Fix for PR libobjc/49883 ("clang + gcc 4.6 runtime = broken") and a small related clang fix
On Oct 9, 2011, at 3:30 AM, Nicola Pero wrote: > Unfortunately, the report was correct in that clang is producing incorrect > code and > abusing the higher bits of the class->info field to store some other > information. The clang folks are pretty responsive. I'd always give them a chance to `fix' thier code, before putting hack-arounds in our code in general. > PS: In case anyone wonders, I do want the GNU Objective-C Runtime to be > usable with > free, non-GCC Objective-C compilers. I think that's a fine goal. I like compatibility.
Re: [google] record compiler options to .note sections
How about .gnu.switches.text.quote_paths? Thanks, Dehao On Tue, Oct 11, 2011 at 8:42 AM, Cary Coutant wrote: >> Ok for google branches. >> >> 1) document the difference of this option with -grecord-gcc-switches >> (this one only record codegen related options, and recorded in debug >> section), and with -frecord-gcc-switches? >> 2) may be better to use option name: -frecord-gcc-switches-in-object > > Sections whose name begins with ".note" are usually SHT_NOTE sections, > and have a specific format. It might be better to choose different > names (like Sri was asked to do with callgraph annotations). > > -cary >
Re: [patches] several gcc.target/powerpc tests require hard_float
On Mon, 10 Oct 2011, Janis Johnson wrote: > This patch skips several Power-specific tests if hard_float support > isn't available. OK for trunk? It looks like these are testing for particular instructions using FPRs and so powerpc_fprs is more appropriate; you don't want to match e500v2 hard float. -- Joseph S. Myers jos...@codesourcery.com
Re: [C++ Patch / RFC] PR 33067
On 10/10/2011 12:40 PM, Paolo Carlini wrote: + // The fraction 643/2136 approximates log10(2) to 7 significant digits. + int max_digits10 = 2 + (is_decimal ? fmt->p : fmt->p * 643L / 2136); Please cite N1822 in the comment and convert it to C syntax. OK with that change. Jason
Re: [PATCH, testsuite]: Close and unlink test file before exit
On Tue, 11 Oct 2011, Uros Bizjak wrote: > Hello! > > Remove another orphan file from the testsuite directory. > > 2011-10-11 Uros Bizjak > > * lib/target-supports.exp (check_effective_target_fd_truncate): > Close and unlink test file before exit. (can't quote attachment...) Or save a few lines and unlink it in the tcl/expect framework as "remote_file target delete tst.tmp"? brgds, H-P
Re: [C++ Patch] PR 50660
On 10/11/2011 01:10 AM, Paolo Carlini wrote: Great, this works (and I even learned something ;) Shall I commit it when testing finishes? Please. Jason
[patches] several gcc.target/powerpc tests require hard_float
This patch skips several Power-specific tests if hard_float support
isn't available. OK for trunk?
2011-10-10 Janis Johnson
* gcc.target/powerpc/ppc-fma-3.c: Require hard_float.
* gcc.target/powerpc/ppc-fma-4.c: Likewise.
* gcc.target/powerpc/ppc-fma-5.c: Likewise.
* gcc.target/powerpc/ppc-fma-7.c: Likewise.
* gcc.target/powerpc/ppc-fpconv-11.c: Likewise.
* gcc.target/powerpc/ppc-fpconv-3.c: Likewise.
* gcc.target/powerpc/ppc-fpconv-7.c: Likewise.
* gcc.target/powerpc/ppc-fpconv-8.c: Likewise.
* gcc.target/powerpc/ppc-pow.c: Likewise.
* gcc.target/powerpc/recip-1.c: Likewise.
* gcc.target/powerpc/recip-2.c: Likewise.
* gcc.target/powerpc/recip-3.c: Likewise.
* gcc.target/powerpc/recip-4.c: Likewise.
* gcc.target/powerpc/recip-5.c: Likewise.
Index: gcc.target/powerpc/ppc-fma-3.c
===
--- gcc.target/powerpc/ppc-fma-3.c (revision 343951)
+++ gcc.target/powerpc/ppc-fma-3.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-require-effective-target hard_float } */
/* { dg-options "-O3 -ftree-vectorize -mcpu=power6 -maltivec -ffast-math" } */
/* { dg-final { scan-assembler-times "vmaddfp" 2 } } */
/* { dg-final { scan-assembler-times "fmadd " 2 } } */
Index: gcc.target/powerpc/ppc-fma-4.c
===
--- gcc.target/powerpc/ppc-fma-4.c (revision 343951)
+++ gcc.target/powerpc/ppc-fma-4.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-require-effective-target hard_float } */
/* { dg-options "-O3 -ftree-vectorize -mcpu=power6 -maltivec -ffast-math
-ffp-contract=off" } */
/* { dg-final { scan-assembler-times "vmaddfp" 1 } } */
/* { dg-final { scan-assembler-times "fmadd " 1 } } */
Index: gcc.target/powerpc/ppc-fma-5.c
===
--- gcc.target/powerpc/ppc-fma-5.c (revision 343951)
+++ gcc.target/powerpc/ppc-fma-5.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do run { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target hard_float } */
/* { dg-options "-O2 -mcpu=power5 -std=c99" } */
#ifndef __FP_FAST_FMA
Index: gcc.target/powerpc/ppc-fma-7.c
===
--- gcc.target/powerpc/ppc-fma-7.c (revision 343951)
+++ gcc.target/powerpc/ppc-fma-7.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-require-effective-target hard_float } */
/* { dg-options "-O3 -ftree-vectorize -mcpu=power6 -ffast-math" } */
/* { dg-final { scan-assembler-times "fmadd" 1 } } */
/* { dg-final { scan-assembler-times "fmsub " 1 } } */
Index: gcc.target/powerpc/ppc-fpconv-11.c
===
--- gcc.target/powerpc/ppc-fpconv-11.c (revision 343951)
+++ gcc.target/powerpc/ppc-fpconv-11.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target hard_float } */
/* { dg-options "-O2 -mcpu=power5+ -ffast-math" } */
/* { dg-final { scan-assembler-not "xsrdpiz" } } */
/* { dg-final { scan-assembler "friz" } } */
Index: gcc.target/powerpc/ppc-fpconv-3.c
===
--- gcc.target/powerpc/ppc-fpconv-3.c (revision 343951)
+++ gcc.target/powerpc/ppc-fpconv-3.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-require-effective-target ilp32 } */
+/* { dg-require-effective-target hard_float } *
/* { dg-options "-O2 -mcpu=power5 -ffast-math" } */
/* { dg-final { scan-assembler-not "lfiwax" } } */
/* { dg-final { scan-assembler-not "lfiwzx" } } */
Index: gcc.target/powerpc/ppc-fpconv-7.c
===
--- gcc.target/powerpc/ppc-fpconv-7.c (revision 343951)
+++ gcc.target/powerpc/ppc-fpconv-7.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-require-effective-target ilp32 } */
+/* { dg-require-effective-target hard_float } *
/* { dg-options "-O3 -mcpu=power5 -ffast-math" } */
/* { dg-final { scan-assembler
Re: [google] record compiler options to .note sections
> Ok for google branches. > > 1) document the difference of this option with -grecord-gcc-switches > (this one only record codegen related options, and recorded in debug > section), and with -frecord-gcc-switches? > 2) may be better to use option name: -frecord-gcc-switches-in-object Sections whose name begins with ".note" are usually SHT_NOTE sections, and have a specific format. It might be better to choose different names (like Sri was asked to do with callgraph annotations). -cary
Re: [C++ Patch] PR 50660
On 10/11/2011 01:46 AM, Jason Merrill wrote:
On 10/10/2011 12:44 AM, Paolo Carlini wrote:
If I just do this (I hope it's what you had in mind):
- tree t = non_reference (totype);
+ tree t = totype; /*non_reference (totype); */
variadic111.C:16:22: warning: converting ‘false’ to pointer type for
argument 3 of ‘void S::f(Args1 ..., Args2&& ...) [with Args2 =
{bool, char}; Args1 = {int, double}]’ [-Wconversion-null]
Hmm, need to also change POINTER_TYPE_P to TYPE_PTR_P.
Great, this works (and I even learned something ;) Shall I commit it
when testing finishes?
Thanks,
Paolo.
///
2011-10-10 Paolo Carlini
PR c++/50660
* call.c (conversion_null_warnings): Don't look through references.
Index: call.c
===
--- call.c (revision 179765)
+++ call.c (working copy)
@@ -5514,10 +5514,9 @@
static void
conversion_null_warnings (tree totype, tree expr, tree fn, int argnum)
{
- tree t = non_reference (totype);
-
/* Issue warnings about peculiar, but valid, uses of NULL. */
- if (expr == null_node && TREE_CODE (t) != BOOLEAN_TYPE && ARITHMETIC_TYPE_P
(t))
+ if (expr == null_node && TREE_CODE (totype) != BOOLEAN_TYPE
+ && ARITHMETIC_TYPE_P (totype))
{
if (fn)
warning_at (input_location, OPT_Wconversion_null,
@@ -5525,11 +5524,11 @@
argnum, fn);
else
warning_at (input_location, OPT_Wconversion_null,
- "converting to non-pointer type %qT from NULL", t);
+ "converting to non-pointer type %qT from NULL", totype);
}
/* Issue warnings if "false" is converted to a NULL pointer */
- else if (expr == boolean_false_node && POINTER_TYPE_P (t))
+ else if (expr == boolean_false_node && TYPE_PTR_P (totype))
{
if (fn)
warning_at (input_location, OPT_Wconversion_null,
@@ -5537,7 +5536,7 @@
"of %qD", argnum, fn);
else
warning_at (input_location, OPT_Wconversion_null,
- "converting % to pointer type %qT", t);
+ "converting % to pointer type %qT", totype);
}
}
Re: [C++ Patch] PR 50660
On 10/10/2011 12:44 AM, Paolo Carlini wrote:
If I just do this (I hope it's what you had in mind):
- tree t = non_reference (totype);
+ tree t = totype; /*non_reference (totype); */
variadic111.C:16:22: warning: converting ‘false’ to pointer type for
argument 3 of ‘void S::f(Args1 ..., Args2&& ...) [with Args2 =
{bool, char}; Args1 = {int, double}]’ [-Wconversion-null]
Hmm, need to also change POINTER_TYPE_P to TYPE_PTR_P.
Jason
Re: Intrinsics for N2965: Type traits and base classes
This is looking pretty good, from the libstdc++ side. This latest round of gcc hacking fixes the previous testsuite fixes, so once you get the gcc bits OK'd by Jason you can check in. > I'd still like to see some testcases for the intrinsic, independent > of the library. Seems like some simple test case along the lines of gcc/testsuite/g++.dg/ext/is_base_of.C will suffice. -benjamin
Re: [patch] Don't try to reload match_operator
On Mon, 19 Sep 2011, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
> > On 19/09/11 15:14, Ulrich Weigand wrote:
> > > So it seems to me that for match_operator operands, the
> > > goal_alternative_win flag should always be true ...
> > >
> > > Can you find out why this isn't true in your case?
> >
> > Hmm, I think it must be because of this:
> >
> > /* If the operand is a SUBREG, extract
> > the REG or MEM (or maybe even a constant) within.
> > (Constants can occur as a result of reg_equiv_constant.) */
> >
> > while (GET_CODE (operand) == SUBREG)
> > {
> > ...
> > force_reload = 1;
> > }
>
> Ah, right. Note that immediately before this "while" we have:
>
> /* If the predicate accepts a unary operator, it means that
> we need to reload the operand, but do not do this for
> match_operator and friends. */
> if (UNARY_P (operand) && *p != 0)
> operand = XEXP (operand, 0);
>
> The "... but do not do this for match_operator and friends" part is
> implemented by the "*p != 0" check here. It seems we need the same
> check for the SUBREG test.
FWIW, if anyone wonders, the comment refers to a special-case
misfeature that should be removed (if a predicate matches an
unop, the constraint will only see the inner expression).
Reload doesn't do what's intended - at least not what the SH
port intended with its use at the time, and there be bugs there
too. While we had agreement that the misfeature should be
removed, the removal never happened. This was 6 years ago, JFTR
and
(what a yucky macro, consider the latter patch withdrawn. :)
brgds, H-P
Re: PATCH RFA: New configure option --with-native-system-header-dir
On Sat, 8 Oct 2011, Ian Lance Taylor wrote: > This patch implements this proposal. Only lightly tested so far. How > does this look if testing succeeds? OK in the absence of build system maintainer objections within 24 hours. -- Joseph S. Myers jos...@codesourcery.com
Re: [C++ Patch / RFC] PR 33067
On Mon, 10 Oct 2011, Paolo Carlini wrote: > + // The fraction 643/2136 approximates log10(2) to 7 significant digits. Whatever the conclusion on the approach to take, note that we don't use C++ comments in GCC at present. -- Joseph S. Myers jos...@codesourcery.com
Re: [google] record compiler options to .note sections
Ok for google branches. 1) document the difference of this option with -grecord-gcc-switches (this one only record codegen related options, and recorded in debug section), and with -frecord-gcc-switches? 2) may be better to use option name: -frecord-gcc-switches-in-object thanks, David On Sun, Oct 9, 2011 at 6:16 PM, Dehao Chen wrote: > On Sun, Oct 9, 2011 at 5:28 PM, Jakub Jelinek wrote: >> On Sun, Oct 09, 2011 at 09:18:25AM +0800, Dehao Chen wrote: >>> Unfortunately -frecord-gcc-switches cannot serve our purpose because >>> the recorded switches are mergable, i.e. the linker will merge all >>> options to a set of strings. However, object files may have distinct >>> compile options. We want to preserve every object file's compile >>> options when doing LIPO build. >> >> And -grecord-gcc-switches? That one, although it is mergeable, still >> preserves every object files's compile options. > > I tried -grecord-gcc-switches, but looks like it's not recording > options that I want. > > e.g. the following two commands output the same assembly code, while > the former should record one more options. > > gcc -g3 -grecord-gcc-switches a.c -Dabcdefgh -Dxy -I/usr/ -S > gcc -g3 -grecord-gcc-switches a.c -Dabcdefgh -Dxy -S > > Thanks, > Dehao > >> >> Jakub >> >
[PATCH, testsuite]: Close and unlink test file before exit
Hello!
Remove another orphan file from the testsuite directory.
2011-10-11 Uros Bizjak
* lib/target-supports.exp (check_effective_target_fd_truncate):
Close and unlink test file before exit.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 179773)
+++ lib/target-supports.exp (working copy)
@@ -3739,16 +3739,25 @@
int fd;
const char t[] = "test writing more than ten characters";
char s[11];
- fd = fileno (f);
+ int status = 0;
+ fd = fileno (f);
write (fd, t, sizeof (t) - 1);
lseek (fd, 0, 0);
if (ftruncate (fd, 10) != 0)
- exit (1);
+ status = 1;
close (fd);
+ fclose (f);
+ if (status)
+ {
+ unlink ("tst.tmp");
+ exit (status);
+ }
f = fopen ("tst.tmp", "rb");
if (fread (s, 1, sizeof (s), f) != 10 || strncmp (s, t, 10) != 0)
- exit (1);
- exit (0);
+ status = 1;
+ fclose (f);
+ unlink ("tst.tmp");
+ exit (status);
}
}
[gimplefe][patch] The symbol table for declarations
Hi,
The following patch is a basic attempt to build a symbol table that
stores the names of all the declarations made in the input file.
Index: gcc/gimple/parser.c
===
--- gcc/gimple/parser.c (revision 174754)
+++ gcc/gimple/parser.c (working copy)
@@ -28,6 +28,7 @@
#include "tree.h"
#include "gimple.h"
#include "parser.h"
+#include "hashtab.h"
#include "ggc.h"
/* The GIMPLE parser. Note: do not use this variable directly. It is
@@ -44,6 +45,43 @@
/* EOF token. */
static gimple_token gl_eof_token = { CPP_EOF, 0, 0, 0 };
+/* The GIMPLE symbol table entry. */
+
+struct GTY (()) gimple_symtab_entry_def
+{
+ /* Variable that is declared. */
+ tree decl;
+
+};
+
+/* Gimple symbol table. */
+static htab_t gimple_symtab;
+
+/* Return the hash value of the declaration name of a gimple_symtab_entry_def
+ object pointed by ENTRY. */
+
+static hashval_t
+gimple_symtab_entry_hash (const void *entry)
+{
+ const struct gimple_symtab_entry_def *base =
+(const struct gimple_symtab_entry_def *)entry;
+ return IDENTIFIER_HASH_VALUE (DECL_NAME(base->decl));
+}
+
+/* Returns non-zero if ENTRY1 and ENTRY2 points to gimple_symtab_entry_def
+ objects corresponding to the same declaration. */
+
+static int
+gimple_symtab_eq_hash (const void *entry1, const void *entry2)
+{
+ const struct gimple_symtab_entry_def *p1 =
+(const struct gimple_symtab_entry_def *)entry1;
+ const struct gimple_symtab_entry_def *p2 =
+(const struct gimple_symtab_entry_def *)entry2;
+
+ return DECL_NAME(p1->decl) == DECL_NAME(p2->decl);
+}
+
/* Return the string representation of token TOKEN. */
static const char *
@@ -807,6 +845,7 @@
}
}
+
/* The Declaration section within a .gimple file can consist of
a) Declaration of variables.
b) Declaration of functions.
@@ -870,11 +909,17 @@
static void
gp_parse_var_decl (gimple_parser *parser)
{
- const gimple_token *next_token;
+ const gimple_token *next_token, *name_token;
+ const char* name;
enum tree_code code ;
+ struct gimple_symtab_entry_def e;
gl_consume_expected_token (parser->lexer, CPP_LESS);
- gl_consume_expected_token (parser->lexer, CPP_NAME);
+ name_token = gl_consume_expected_token (parser->lexer, CPP_NAME);
+ name = gl_token_as_text (name_token);
+ e.decl =
+ build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier(name),
void_type_node);
+ htab_find_slot (gimple_symtab, &e, INSERT);
gl_consume_expected_token (parser->lexer, CPP_COMMA);
next_token = gl_consume_token (parser->lexer);
@@ -981,6 +1027,7 @@
gimple_parser *parser = ggc_alloc_cleared_gimple_parser ();
line_table = parser->line_table = ggc_alloc_cleared_line_maps ();
parser->ident_hash = ident_hash;
+
linemap_init (parser->line_table);
parser->lexer = gl_init (parser, fname);
@@ -1403,6 +1450,9 @@
if (parser->lexer->filename == NULL)
return;
+ gimple_symtab =
+htab_create_ggc (1021, gimple_symtab_entry_hash,
+gimple_symtab_eq_hash, NULL);
gl_lex (parser->lexer);
gp_parse (parser);
gp_finish (parser);
The changelog is as follows:
2011-10-11 Sandeep Soni
* parser.c : Include hashtab.h.
(struct gimple_symtab_entry_def): New.
(gimple_symtab): New. The symbol table.
(gimple_symtab_entry_hash): New.
(gimple_symtab_eq_hash): New.
(gp_parse_var_decl): Build the declaration and put it in the symbol
table.
(gimple_main): Creates the symbol table
--
Cheers
Sandy
[gimplefe][patch] A bugfix for a missed symbol
Ketaki had pointed a minor bug a long time back. This patch fixes it.
Index: parser.c
===
--- parser.c(revision 174754)
+++ parser.c(working copy)
@@ -882,6 +882,7 @@
switch (code)
{
case INTEGER_TYPE:
+ gl_consume_expected_token (parser->lexer, CPP_LESS);
gl_consume_expected_token (parser->lexer, CPP_NUMBER);
gl_consume_expected_token (parser->lexer, CPP_RSHIFT);
break;
The changelog is:
2011-10-11 Sandeep Soni
* parser.c (gp_parse_var_decl): Fixed a bug for the
missing symbol 'CPP_LESS' in the 'INTEGER_TYPE' declaration.
--
Cheers
Sandy
Re: fix for c++/44473, mangling of decimal types, checked in
On Mon, 2011-10-10 at 14:18 -0700, Janis Johnson wrote: > Sorry, I didn't see that note about backports, but then I'm way behind > on gcc mail. Heh, no problem. I can sympathize! > Peter, would you be able to test this patch for a backport? I'm kind of > swamped right now, and decimal float is definitely not a priority for me > right now. I certainly don't mind if someone else backports it. Ok, I'll give it a try. I just didn't want to step on your toes if you were planning on doing it. Peter
Re: fix for c++/44473, mangling of decimal types, checked in
On 10/10/2011 02:13 PM, Peter Bergner wrote: > On Wed, 2011-10-05 at 11:40 -0500, Peter Bergner wrote: >> On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote: >>> Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was >>> approved by Jason last December but I never got around to checking >>> it in. Paolo Carlini said in PR44473 that it was already approved >>> and doesn't need a new approval, so I checked it in after a >>> bootstrap and regtest of c,c++ for i686-pc-linux-gnu. >> >> Hi Janis, >> >> Thanks for committing this to mainline! One note though, you asked >> for permission to commit this also to the 4.5 release branch and Jason >> approved that. So do you have plans for committing it there too (and to >> the 4.6 branch since that was created between when you submitted that >> patch and committed it)? I'd like to see this fixed on both of those >> FSF release branches. > > Ping. > > Peter Sorry, I didn't see that note about backports, but then I'm way behind on gcc mail. Peter, would you be able to test this patch for a backport? I'm kind of swamped right now, and decimal float is definitely not a priority for me right now. I certainly don't mind if someone else backports it. Janis
Re: fix for c++/44473, mangling of decimal types, checked in
On Wed, 2011-10-05 at 11:40 -0500, Peter Bergner wrote: > On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote: > > Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was > > approved by Jason last December but I never got around to checking > > it in. Paolo Carlini said in PR44473 that it was already approved > > and doesn't need a new approval, so I checked it in after a > > bootstrap and regtest of c,c++ for i686-pc-linux-gnu. > > Hi Janis, > > Thanks for committing this to mainline! One note though, you asked > for permission to commit this also to the 4.5 release branch and Jason > approved that. So do you have plans for committing it there too (and to > the 4.6 branch since that was created between when you submitted that > patch and committed it)? I'd like to see this fixed on both of those > FSF release branches. Ping. Peter
Re: [PATCH, testsuite, i386] FMA3 testcases + typo fix in MD
On Mon, Oct 10, 2011 at 10:56 PM, Uros Bizjak wrote:
>>> BTW, don't you also need "-mfmpath=sse" in dg-options?
>>>
>>
>> According to doc/invoke.texi
>> ...
>> @itemx -mfma
>> ...
>> These options will enable GCC to use these extended instructions in
>> generated code, even without @option{-mfpmath=sse}.
>>
>> Seems it -mfpmath=sse is useless..
>> Although, if this is wrong, we probably have to update doc as well.
>
> Apparently [1], this is wrong, you need -mfpmath=sse in dg-options.
>
> The reason you didn't see these failures with -m32 is due to
> -mfpmath=sse added to your ./configure flags.
Please read the above as: -with-fpmath=sse.
Uros.
Re: [PATCH, testsuite, i386] FMA3 testcases + typo fix in MD
On Thu, Oct 6, 2011 at 3:48 PM, Kirill Yukhin wrote:
>>
>> BTW, don't you also need "-mfmpath=sse" in dg-options?
>>
>
> According to doc/invoke.texi
> ...
> @itemx -mfma
> ...
> These options will enable GCC to use these extended instructions in
> generated code, even without @option{-mfpmath=sse}.
>
> Seems it -mfpmath=sse is useless..
> Although, if this is wrong, we probably have to update doc as well.
Apparently [1], this is wrong, you need -mfpmath=sse in dg-options.
The reason you didn't see these failures with -m32 is due to
-mfpmath=sse added to your ./configure flags.
[1] http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01151.html
Uros.
Re: [RFC] Slightly fix up vgather* patterns
On 10/08/2011 08:43 AM, Jakub Jelinek wrote:
> (define_expand "avx2_gathersi"
> - [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "")
> - (unspec:VEC_GATHER_MODE
> - [(match_operand:VEC_GATHER_MODE 1 "register_operand" "")
> -(match_operand: 2 "memory_operand" "")
> -(match_operand: 3 "register_operand" "")
> -(match_operand:VEC_GATHER_MODE 4 "register_operand" "")
> -(match_operand:SI 5 "const1248_operand " "")]
> - UNSPEC_GATHER))]
> + [(parallel [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "")
> +(unspec:VEC_GATHER_MODE
> + [(match_operand:VEC_GATHER_MODE 1 "register_operand" "")
> + (match_operand: 2 "memory_operand" "")
> + (match_operand: 3 "register_operand" "")
> + (match_operand:VEC_GATHER_MODE 4 "register_operand" "")
> + (match_operand:SI 5 "const1248_operand " "")]
> + UNSPEC_GATHER))
> + (clobber (match_dup 4))])]
>"TARGET_AVX2")
The use of match_dup in the clobber is wrong. We should not be
clobbering the user-visible copy of the operand. That does not
make sense when dealing with the user-visible builtin.
>
> (define_insn "*avx2_gathersi"
> - [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "=x")
> + [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "=&x")
> (unspec:VEC_GATHER_MODE
> - [(match_operand:VEC_GATHER_MODE 1 "register_operand" "0")
> + [(match_operand:VEC_GATHER_MODE 2 "register_operand" "0")
> (mem:
> - (match_operand:P 2 "register_operand" "r"))
> -(match_operand: 3 "register_operand" "x")
> -(match_operand:VEC_GATHER_MODE 4 "register_operand" "x")
> -(match_operand:SI 5 "const1248_operand" "n")]
> - UNSPEC_GATHER))]
> + (match_operand:P 3 "register_operand" "r"))
> +(match_operand: 4 "register_operand" "x")
> +(match_operand:VEC_GATHER_MODE 5 "register_operand" "1")
> +(match_operand:SI 6 "const1248_operand" "n")]
> + UNSPEC_GATHER))
> + (clobber (match_operand:VEC_GATHER_MODE 1 "register_operand" "=&x"))]
>"TARGET_AVX2"
> - "vgatherd\t{%4, (%2, %3, %c5), %0|%0, (%2, %3,
> %c5), %4}"
> + "vgatherd\t{%1, (%3, %4, %c6), %0|%0, (%3, %4,
> %c6), %1}"
>[(set_attr "type" "ssemov")
> (set_attr "prefix" "vex")
> (set_attr "mode" "")])
Instead, use (clobber (match_scratch)) and matching constraints with operand 4.
> Still, the insn description is imprecise, saying that it loads from mem
> at the address register is wrong and perhaps some DCE might delete
> what shouldn't be deleted. So, either it should (use (mem (scratch)))
> or something similar, or in the unspec list all the memory locations
> that are being read
> (mem: (plus:SI (reg:SI) (vec_select:SI (match_operand:V4SI)
> (parallel [(const_int N)]
> for N 0 through something (but it is complicated by Pmode size vs.
> the need to do nothing/truncate/sign_extend the vec_select to the right
> mode).
I think that a (mem (scratch)) as input to the unspec is probably best.
The exact memory usage is almost certainly too complex to describe
in a useful way.
r~
[PATCH] [Annotalysis] Bugfix for spurious thread safety warnings with shared mutexes
This patch fixes an error where Annotalysis generates bogus warnings
when a shared lock is released in a function that has a "universal
lock" -- typically produced when gcc cannot parse a lock expression.
Bootstrapped and passed gcc regression testsuite on
x86_64-unknown-linux-gnu. Okay for google/gcc-4_6?
-DeLesley
Changelog.google-4_6:
2011-10-10 DeLesley Hutchins
* tree-threadsafe-analyze.c (remove_lock_from_lockset)
testsuite/Changelog.google-4_6:
2011-10-10 DeLesley Hutchins
* g++.dg/thread-ann/thread_annot_lock-83.C:
New regression test
Index: gcc/testsuite/g++.dg/thread-ann/thread_annot_lock-83.C
===
--- gcc/testsuite/g++.dg/thread-ann/thread_annot_lock-83.C (revision 0)
+++ gcc/testsuite/g++.dg/thread-ann/thread_annot_lock-83.C (revision 0)
@@ -0,0 +1,31 @@
+// Regression test for bugfix, where shared locks are not properly
+// removed from locksets if a "universal lock" is present.
+// { dg-do compile }
+// { dg-options "-Wthread-safety" }
+
+#include "thread_annot_common.h"
+
+class Foo;
+
+class Bar {
+public:
+ Foo* foo;
+ Mutex mu_;
+
+ // foo->mu_ is not visible at this point in the code.
+ // so the attribute will become a "universal lock."
+ void bar() EXCLUSIVE_LOCKS_REQUIRED(foo->mu_);
+};
+
+
+class Foo {
+public:
+ Mutex mu_;
+ int a;
+};
+
+
+void Bar::bar() {
+ ReaderMutexLock rlock(&mu_);
+}
+
Index: gcc/tree-threadsafe-analyze.c
===
--- gcc/tree-threadsafe-analyze.c (revision 179771)
+++ gcc/tree-threadsafe-analyze.c (working copy)
@@ -1830,14 +1830,27 @@ remove_lock_from_lockset (tree lockable, struct po
{
tree lock_contained;
- if ((lock_contained = lock_set_contains(live_excl_locks, lockable, NULL_TREE,
- false)) != NULL_TREE)
+ /* Try to remove the actual lock. */
+ if ((lock_contained = lock_set_contains(live_excl_locks, lockable,
+ NULL_TREE, true)) != NULL_TREE)
pointer_set_delete (live_excl_locks, lock_contained);
else if ((lock_contained = lock_set_contains(live_shared_locks, lockable,
- NULL_TREE, false)) != NULL_TREE)
+ NULL_TREE, true)) != NULL_TREE)
pointer_set_delete (live_shared_locks, lock_contained);
- return lock_contained;
+ if (lock_contained)
+return lock_contained;
+
+ /* If either of lock sets contains the universal lock, then pretend that
+ we've removed it, to avoid a warning about unlocking a lock that was
+ not acquired. */
+ if (pointer_set_contains (live_excl_locks, error_mark_node))
+return lockable;
+
+ if (pointer_set_contains(live_shared_locks, error_mark_node))
+return lockable;
+
+ return NULL_TREE;
}
/* This function handles function calls that release locks (i.e. the
Patch committed: Correct demangling of qualified function types
PR 48665 points out that qualified function types are not correctly
demangled. These types can only appear as template parameters. This
patch fixes the problem. Bootstrapped and ran C++ testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2011-10-10 Ian Lance Taylor
PR c++/48665
* cp-demangle.c (d_cv_qualifiers): If qualifiers are applied to a
function type, change them to apply to the "this" parameter.
* testsuite/demangle-expected: Add test case.
Index: testsuite/demangle-expected
===
--- testsuite/demangle-expected (revision 179771)
+++ testsuite/demangle-expected (working copy)
@@ -4198,3 +4198,8 @@ f1
_Z3fooi._omp_cpyfn.6
foo(int) [clone ._omp_cpyfn.6]
foo
+#
+--format=gnu-v3 --no-params
+_Z1fIKFvvES0_Evv
+void f()
+f
Index: cp-demangle.c
===
--- cp-demangle.c (revision 179771)
+++ cp-demangle.c (working copy)
@@ -2294,8 +2294,10 @@ static struct demangle_component **
d_cv_qualifiers (struct d_info *di,
struct demangle_component **pret, int member_fn)
{
+ struct demangle_component **pstart;
char peek;
+ pstart = pret;
peek = d_peek_char (di);
while (peek == 'r' || peek == 'V' || peek == 'K')
{
@@ -2332,6 +2334,28 @@ d_cv_qualifiers (struct d_info *di,
peek = d_peek_char (di);
}
+ if (!member_fn && peek == 'F')
+{
+ while (pstart != pret)
+ {
+ switch ((*pstart)->type)
+ {
+ case DEMANGLE_COMPONENT_RESTRICT:
+ (*pstart)->type = DEMANGLE_COMPONENT_RESTRICT_THIS;
+ break;
+ case DEMANGLE_COMPONENT_VOLATILE:
+ (*pstart)->type = DEMANGLE_COMPONENT_VOLATILE_THIS;
+ break;
+ case DEMANGLE_COMPONENT_CONST:
+ (*pstart)->type = DEMANGLE_COMPONENT_CONST_THIS;
+ break;
+ default:
+ break;
+ }
+ pstart = &d_left (*pstart);
+ }
+}
+
return pret;
}
[testsuite] modify powerpc test for hard_float target, skip powerpc/warn-[12].c for soft-float
Tests gcc.target/powerpc/warn-[12].c fail for soft-float multilibs with
the unexpected warning "-mvsx requires hardware floating point [enabled
by default]". This patch skips those tests for soft-float multilibs and
modifies the powerpc check for a soft-float effective target to return
true for either __NO_FPRS__ or _SOFT_FLOAT being defined.
Is this OK for trunk? I must admit that I'm not sure what all those
Power float variants are for.
2011-10-10 Janis Johnson
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_hard_float):
Special-case powerpc.
* gcc.target/powerpc/warn-1.c: Skip if not hard_float.
* gcc.target/powerpc/warn-2.c: Ditto.
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp (revision 179771)
+++ gcc/testsuite/lib/target-supports.exp (working copy)
@@ -792,6 +792,14 @@
}]
}
+if { [istarget powerpc*-*-*] } {
+ return [check_no_compiler_messages hard_float assembly {
+ #if (defined _SOFT_FLOAT || defined __NO_FPRS__)
+ #error FOO
+ #endif
+ }]
+}
+
# This proc is actually checking the availabilty of FPU
# support for doubles, so on the RX we must fail if the
# 64-bit double multilib has been selected.
Index: gcc/testsuite/gcc.target/powerpc/warn-1.c
===
--- gcc/testsuite/gcc.target/powerpc/warn-1.c (revision 179771)
+++ gcc/testsuite/gcc.target/powerpc/warn-1.c (working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target hard_float } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-options "-O -mvsx -mno-altivec" } */
Index: gcc/testsuite/gcc.target/powerpc/warn-2.c
===
--- gcc/testsuite/gcc.target/powerpc/warn-2.c (revision 179771)
+++ gcc/testsuite/gcc.target/powerpc/warn-2.c (working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target hard_float } */
/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
/* { dg-options "-O -mcpu=power7 -mno-altivec" } */
Re: [Patch] PR c++/26256
Hi, 2011/9/26 Jason Merrill : > On 09/25/2011 05:06 PM, Fabien Chêne wrote: >> >> + else if ((using_decl = strip_using_decl (member)) != member) > >> + /* If it is a using decl, use its underlying decl. */ >> + type_decl = strip_using_decl (type_decl); > >> - if (DECL_NAME (field) == name >> + if (DECL_NAME (decl) == name >> && (!want_type >> - || TREE_CODE (field) == TYPE_DECL >> - || DECL_CLASS_TEMPLATE_P (field))) >> - return field; >> + || TREE_CODE (decl) == TYPE_DECL >> + || DECL_CLASS_TEMPLATE_P (decl))) >> + return decl; > > Why do we need to strip the USING_DECL both in lookup_field_1 and in > callers? Sorry but I've failed to see why you called them callers of lookup_field_1, could you elaborate ? -- Fabien
PR c++/30195
2011/9/23 Jason Merrill :
> On 09/22/2011 05:11 PM, Fabien Chêne wrote:
>>
>> 2011/9/22 Jason Merrill:
>
>>> I don't, it just seemed strange to handle functions differently from
>>> other
>>> decls here. But when I look more closely I see that we're in
>>> lookup_field_1, which isn't interested in functions, so I guess we do
>>> want
>>> to ignore function using-declarations here.
>>
>> That's strange because if we do return FUNCTION_DECL, PR c++/30195 seems
>> solved.
>
> It works for that testcase, but we need to handle functions in
> lookup_fnfields_1 since it's also called from other places.
It tried to add the target declaration of a USING_DECL in the
method_vec of the class where the USING_DECL is declared. Thus, I
copied the target decl, adjusted its access, and then called
add_method with the target decl. Unfortunaltely, it ends up with an
undefined reference...
struct Base {
protected:
void *Return () { return this; }
};
struct Derived : Base {
using Base::Return;
};
int main ()
{
Derived d;
d.Return();
}
In the above example, it behaves as if Derived::Return (introduced via
using Base::Return) were not tied to the definition. I do not know
where I can fix it, any clues ?
Thanks,
--
Fabien
Re: Force aliases to be output when cgraph decides so
> Honza, > > I filed PR50689. After your change, the alias is moved from near the > end of the file to just before the definition. AIX assembler is a > single pass assembler that does not allow forward references. I see, I guess the easy bugfix is to make the aliases output afterwards. I will send you patch for that. Honza
[patch] remove empty directory in libgomp
2011-10-10 Matthias Klose * config/posix95: Remove empty directory. The last files in config/posix95 were removed in r177568. Comitted as obvious. Matthias
Re: [v3] cxxabi.h vs. unwind-cxx.h
Here's a patch that works for both C and C++.
tested x86/linux
-benjamin
2011-10-10 Benjamin Kosnik
PR libstdc++/49818
* config/abi/pre/gnu.ver (CXXABI_1.3.6): Add symbols.
* testsuite/util/testsuite_abi.cc: Same.
* libsupc++/unwind-cxx.h: Move required eh API...
* libsupc++/cxxabi.h: ... to here. Add required forward declarations.
Use _GLIBCXX_NOTHROW.
* libsupc++/pure.cc (__cxa_deleted_virtual): Add.
* libsupc++/eh_alloc.cc: Use _GLIBCXX_NOTHROW.
* libsupc++/eh_catch.cc: Same.
* libsupc++/eh_globals.cc: Same.
* libsupc++/eh_type.cc: Same.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index 5e5aa6a..c45b7db 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -104,7 +104,7 @@ GLIBCXX_3.4 {
std::logic_error*;
std::locale::[A-Za-e]*;
std::locale::facet::[A-Za-z]*;
- std::locale::facet::_S_get_c_locale*;
+ std::locale::facet::_S_get_c_locale*;
std::locale::facet::_S_clone_c_locale*;
std::locale::facet::_S_create_c_locale*;
std::locale::facet::_S_destroy_c_locale*;
@@ -145,7 +145,7 @@ GLIBCXX_3.4 {
std::strstream*;
std::strstreambuf*;
# std::t[a-q]*;
- std::t[a-g]*;
+ std::t[a-g]*;
std::th[a-h]*;
std::th[j-q]*;
std::th[s-z]*;
@@ -238,7 +238,7 @@ GLIBCXX_3.4 {
_ZNKSs8_M_limit*;
_ZNKSs9_M_ibeginEv;
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_E*;
-_ZNKSs7compare*;
+_ZNKSs7compare*;
_ZNKSs5c_strEv;
_ZNKSs8capacityEv;
_ZNKSs4copyEPc[jmy][jmy];
@@ -435,10 +435,10 @@ GLIBCXX_3.4 {
# std::locale destructors
_ZNSt6localeD*;
-
+
# std::locale::facet destructors
_ZNSt6locale5facetD*;
-
+
# std::locale::_Impl constructors, destructors
_ZNSt6locale5_ImplC*;
_ZNSt6locale5_ImplD*;
@@ -447,7 +447,7 @@ GLIBCXX_3.4 {
_ZNSt8ios_baseD*;
_ZNSt8ios_base4InitD*;
-# bool std::has_facet
+# bool std::has_facet
_ZSt9has_facetIS*;
# std::use_facet
@@ -486,7 +486,7 @@ GLIBCXX_3.4 {
# std::time_get_byname
_ZNSt15time_get_byname*;
-
+
# std::time_put
_ZNSt8time_put*;
_ZNKSt8time_put*;
@@ -569,7 +569,7 @@ GLIBCXX_3.4 {
_ZNK11__gnu_debug16_Error_formatter13_M_print_word*;
_ZNK11__gnu_debug16_Error_formatter15_M_print_string*;
_ZNK11__gnu_debug16_Error_formatter8_M_error*;
-
+
# exceptions as functions
_ZSt16__throw_bad_castv;
_ZSt17__throw_bad_allocv;
@@ -809,11 +809,11 @@ GLIBCXX_3.4 {
};
GLIBCXX_3.4.1 {
-
+
_ZNSt12__basic_fileIcE4fileEv;
-
+
} GLIBCXX_3.4;
-
+
GLIBCXX_3.4.2 {
_ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE4fileEv;
@@ -825,7 +825,7 @@ GLIBCXX_3.4.2 {
} GLIBCXX_3.4.1;
GLIBCXX_3.4.3 {
-
+
# stub functions from libmath
acosf;
acosl;
@@ -969,7 +969,7 @@ GLIBCXX_3.4.10 {
_ZNKSt4hashIeEclEe;
_ZSt17__verify_grouping*;
-
+
_ZNSt8__detail12__prime_listE;
_ZNSt3tr18__detail12__prime_listE;
@@ -992,7 +992,7 @@ GLIBCXX_3.4.10 {
} GLIBCXX_3.4.9;
GLIBCXX_3.4.11 {
-
+
# atomic
__atomic_flag_for_address;
__atomic_flag_wait_explicit;
@@ -1328,16 +1328,16 @@ CXXABI_1.3 {
__cxa_rethrow;
__cxa_throw;
__cxa_type_match;
+__cxa_vec_ctor;
__cxa_vec_cctor;
__cxa_vec_cleanup;
-__cxa_vec_ctor;
+__cxa_vec_delete;
__cxa_vec_delete2;
__cxa_vec_delete3;
-__cxa_vec_delete;
__cxa_vec_dtor;
+__cxa_vec_new;
__cxa_vec_new2;
__cxa_vec_new3;
-__cxa_vec_new;
__gxx_personality_v0;
__gxx_personality_sj0;
__dynamic_cast;
@@ -1491,3 +1491,12 @@ CXXABI_1.3.5 {
_ZTVSt16nested_exception;
} CXXABI_1.3.4;
+
+CXXABI_1.3.6 {
+
+__cxa_allocate_dependent_exception;
+__cxa_free_dependent_exception;
+__cxa_get_exception_ptr;
+__cxa_deleted_virtual;
+
+} CXXABI_1.3.5;
\ No newline at end of file
diff --git a/libstdc++-v3/libsupc++/cxxabi.h b/libstdc++-v3/libsupc++/cxxabi.h
index 0f3856e..e78f551 100644
--- a/libstdc++-v3/libsupc++/cxxabi.h
+++ b/libstdc++-v3/libsupc++/cxxabi.h
@@ -123,23 +123,26 @@ namespace __cxxabiv1
void
__cxa_guard_abort(__guard*) _GLIBCXX_NOTHROW;
+ // DSO destruction.
+ int
+ __cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW;
+
+ int
+ __cxa_finalize(void*);
+
// Pure virtual functions.
void
__cxa_pure_virtual(void) __attribute__ ((__noreturn__));
- // Exception handling.
void
- __cxa_bad_cast();
+ __cxa_deleted_virtual(void) __attribute__ ((__noreturn__));
- void
- __cxa_bad_typeid();
-
- // DSO destruction.
- int
- __cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW;
+ // Exception handling auxillary.
+ void
+ __cxa_bad_cast() __attribute__((__noreturn__));
- int
- __cxa_finalize(void*);
+ void
+ __cxa_bad_typeid() __attribute__((__noreturn__));
/**
@@ -185,6 +188,7 @@ namespace __cxxabiv
Re: Force aliases to be output when cgraph decides so
Honza, I filed PR50689. After your change, the alias is moved from near the end of the file to just before the definition. AIX assembler is a single pass assembler that does not allow forward references. - David On Sun, Sep 25, 2011 at 6:27 AM, Jan Hubicka wrote: >> Jan, >> >> This patch causes a bootstrap failure on AIX because some symbols no >> longer are exported by libstdc++. When I remove your patch, bootstrap >> proceeds past this failure. > > Oops, would be possible to see what kind of difference the path does on the > assembly > output? (i.e. have .s file from working and non-working build?) > > Thanks, > Honza >
Re: PATCH RFA: New configure option --with-native-system-header-dir
> + yes|no) AC_MSG_ERROR([bad value ${withval} given for
> --with-native-system-header-dir]) ;;
> + /*) ;;
> + *) AC_MSG_ERROR([--with-native-system-header-dir argument ${withval} must
> be an absolute directory]) ;;
This doesn't handle DOS-style absolute paths (like c:/Users). Not
sure if we care about '\' separators but they probably should be
checked for too (if the user can figure out how to make those work
elsewhere, we shouldn't prevent it here).
Otherwise, I'm OK with the build-specific portions of the patch (and
the djgpp-specific ones).
Re: [Patch, Fortran] Fix PR 50564
Hi Tobias,
In conclusion: I am fine with the FORALL part, but not with the
DO CONCURRENT part.
Yep, you're right. I have modified the patch accordingly. Here
is what I committed.
Best regards
Thomas
Index: fortran/ChangeLog
===
--- fortran/ChangeLog (revision 179768)
+++ fortran/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2011-10-10 Thomas Koenig
+
+ PR fortran/50564
+ * frontend-passes (forall_level): New variable.
+ (cfe_register_funcs): Don't register functions if we
+ are within a forall loop.
+ (optimize_namespace): Set forall_level to 0 before entry.
+ (gfc_code_walker): Increase/decrease forall_level.
+
2011-10-09 Tobias Burnus
PR fortran/45044
Index: fortran/frontend-passes.c
===
--- fortran/frontend-passes.c (revision 179709)
+++ fortran/frontend-passes.c (working copy)
@@ -62,6 +62,10 @@
gfc_namespace *current_ns;
+/* If we are within any forall loop. */
+
+static int forall_level;
+
/* Entry point - run all passes for a namespace. So far, only an
optimization pass is run. */
@@ -165,6 +169,12 @@
|| (*e)->ts.u.cl->length->expr_type != EXPR_CONSTANT))
return 0;
+ /* We don't do function elimination within FORALL statements, it can
+ lead to wrong-code in certain circumstances. */
+
+ if (forall_level > 0)
+return 0;
+
/* If we don't know the shape at compile time, we create an allocatable
temporary variable to hold the intermediate result, but only if
allocation on assignment is active. */
@@ -493,6 +503,7 @@
{
current_ns = ns;
+ forall_level = 0;
gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
gfc_code_walker (&ns->code, cfe_code, cfe_expr_0, NULL);
@@ -1193,6 +1204,8 @@
WALK_SUBEXPR (fa->end);
WALK_SUBEXPR (fa->stride);
}
+ if (co->op == EXEC_FORALL)
+ forall_level ++;
break;
}
@@ -1335,6 +1348,10 @@
WALK_SUBEXPR (b->expr2);
WALK_SUBCODE (b->next);
}
+
+ if (co->op == EXEC_FORALL)
+ forall_level --;
+
}
}
return 0;
Re: [PATCH, testsuite]: Remove *.gdb files from testsuite dir
On Sun, Oct 9, 2011 at 9:38 PM, Uros Bizjak wrote:
> Attached patch removes *.gdb temporary files from testsuite directory.
>
> 2011-10-09 Uros Bizjak
>
> * lib/gcc-gdb-test.exp (gdb-test): Delete $cmd_file before return.
>
> Tested on x86_64-pc-linux-gnu {,-m32}. OK for mainline and branches?
I went ahead and install this patch to mainline SVN. It looks kind of
obvious, though.
Uros.
Re: [C++ Patch / RFC] PR 33067
Hi, On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote: Yes, I suspect the max_digits10 patch would be definitely an improvement. Good. It's at the beginning of this thread, passes testing. Please have a closer look. I did, but you seemed to show a preference for '6' digits which prompted my comments. OK for 4.6 Did I understand correctly, only 4.6, not 4.7? Works for me but seems a little unusual not applying anything to mainline. If you like it, we can have it for 4.7.0 and otherwise also mark this specific PR as duplicate of 49152 (which, actually, for this *specific* case leans toward not printing any constant at all, similarly to the status quo of the C front end) I suspect printing the literal is better. I believe the actual fix is to print the lexeme as it appears in the source code. I would suggest adding something to the audit trail of 49152. I understand that otherwise for this specific type of error message people will lean toward not printing the constants. In general, I (we) hear you, of course, it's a lond standing issue, isn't it? Paolo.
Re: [C++ Patch / RFC] PR 33067
On Mon, Oct 10, 2011 at 1:07 PM, Paolo Carlini wrote: > On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote: >> >> Yes, I suspect the max_digits10 patch would be definitely an improvement. > > Good. It's at the beginning of this thread, passes testing. Please have a > closer look. I did, but you seemed to show a preference for '6' digits which prompted my comments. OK for 4.6 > > If you like it, we can have it for 4.7.0 and otherwise also mark this > specific PR as duplicate of 49152 (which, actually, for this *specific* case > leans toward not printing any constant at all, similarly to the status quo > of the C front end) I suspect printing the literal is better. I believe the actual fix is to print the lexeme as it appears in the source code.
Re: [C++ Patch / RFC] PR 33067
On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote: Yes, I suspect the max_digits10 patch would be definitely an improvement. Good. It's at the beginning of this thread, passes testing. Please have a closer look. If you like it, we can have it for 4.7.0 and otherwise also mark this specific PR as duplicate of 49152 (which, actually, for this *specific* case leans toward not printing any constant at all, similarly to the status quo of the C front end) Paolo.
Re: [C++ Patch / RFC] PR 33067
On Mon, Oct 10, 2011 at 12:30 PM, Paolo Carlini wrote: > On 10/10/2011 07:28 PM, Gabriel Dos Reis wrote: >> >> A GCC user not interested in numerics probably won't care. However, I do >> not think that extends to people who do care about numerics and have >> literals in their program. If GCC displays an error message with literals >> truncated, it is not at clear to the user that GCC is behaving correctly: >> for one thing, the error might be mysterious and hard to understand, now the >> compiler is indicating that apparently it does not even parse and understand >> correctly his or her numbers. How if you have several numbers like that that >> differs only on the 10th digit? If the user is using an IDE that pattern >> match the output on the source code, it would be even more confusing (as it >> is now.) > > Would you like to see the max_digits10 - inspired patch for 4.7.0? Again, no > strong opinion, just let me know. Personally, I find that too quite a bit > better than the current behavior. Yes, I suspect the max_digits10 patch would be definitely an improvement. Of course, the actual fix would be to write back what was in the input source program, but I understand that is more work that you would like to tackle or have time for.
Re: [PATCH 1/5] Use MADV_DONTNEED for freeing in garbage collector
> So can we move the param patch back as a possible followup? I can drop it, however it will still mean fragmentation on any non Linux (or rather non MADV_DONTNEED) hosts. -Andi
Re: [C++ Patch / RFC] PR 33067
On 10/10/2011 07:28 PM, Gabriel Dos Reis wrote: A GCC user not interested in numerics probably won't care. However, I do not think that extends to people who do care about numerics and have literals in their program. If GCC displays an error message with literals truncated, it is not at clear to the user that GCC is behaving correctly: for one thing, the error might be mysterious and hard to understand, now the compiler is indicating that apparently it does not even parse and understand correctly his or her numbers. How if you have several numbers like that that differs only on the 10th digit? If the user is using an IDE that pattern match the output on the source code, it would be even more confusing (as it is now.) Would you like to see the max_digits10 - inspired patch for 4.7.0? Again, no strong opinion, just let me know. Personally, I find that too quite a bit better than the current behavior. Paolo.
Re: [C++ Patch / RFC] PR 33067
On Mon, Oct 10, 2011 at 12:16 PM, Paolo Carlini wrote: > On 10/10/2011 07:13 PM, Gabriel Dos Reis wrote: >> >> on this particular input, '6' looks OK. However, the question is why '6'? >> Why can't we retain the original number spelling from the source code and >> use that instead? > > Yes, that would be 49152, no? It's quite a bit of work, I don't think > somebody will be able to do that in time for 4.7.0, right? I I were a user > of gcc, I would not be suprised to see 6 used, which after all it's the > historical printf default, I would find it much better anyway than the > current behavior. But I don't have a strong opinion, I already unassigned > myself from the PR, fwiw. I bet most C++ programers don't know what printf default is :-) In any case that is a compiler implementation detail that has no bearing with the input program. A GCC user not interested in numerics probably won't care. However, I do not think that extends to people who do care about numerics and have literals in their program. If GCC displays an error message with literals truncated, it is not at clear to the user that GCC is behaving correctly: for one thing, the error might be mysterious and hard to understand, now the compiler is indicating that apparently it does not even parse and understand correctly his or her numbers. How if you have several numbers like that that differs only on the 10th digit? If the user is using an IDE that pattern match the output on the source code, it would be even more confusing (as it is now.) > > Paolo. >
Re: [C++ Patch / RFC] PR 33067
On 10/10/2011 07:13 PM, Gabriel Dos Reis wrote: on this particular input, '6' looks OK. However, the question is why '6'? Why can't we retain the original number spelling from the source code and use that instead? Yes, that would be 49152, no? It's quite a bit of work, I don't think somebody will be able to do that in time for 4.7.0, right? I I were a user of gcc, I would not be suprised to see 6 used, which after all it's the historical printf default, I would find it much better anyway than the current behavior. But I don't have a strong opinion, I already unassigned myself from the PR, fwiw. Paolo.
Re: [C++ Patch / RFC] PR 33067
On Mon, Oct 10, 2011 at 7:47 AM, Paolo Carlini wrote:
> On 10/10/2011 02:13 PM, Paolo Carlini wrote:
>>
>> . looks like we want to do something else, not printing the number at all.
>> See audit trail.
>
> An option, for 4.7 at least, would be, instead of just closing 33067 as a
> duplicate of the much more general 49152, doing something like:
>
> Index: c-family/c-pretty-print.c
> ===
> --- c-family/c-pretty-print.c (revision 179745)
> +++ c-family/c-pretty-print.c (working copy)
> @@ -1019,7 +1019,7 @@ static void
> pp_c_floating_constant (c_pretty_printer *pp, tree r)
> {
> real_to_decimal (pp_buffer (pp)->digit_buffer, &TREE_REAL_CST (r),
> - sizeof (pp_buffer (pp)->digit_buffer), 0, 1);
> + sizeof (pp_buffer (pp)->digit_buffer), 6, 1);
> pp_string (pp, pp_buffer(pp)->digit_buffer);
> if (TREE_TYPE (r) == float_type_node)
> pp_character (pp, 'f');
>
> which gives:
>
> 33067.C:2:18: error: no match for ‘operator<’ in ‘1.1e+0 < t’
>
> Given in particular that we now have column numbers, as a user of GCC I
> would certainly consider it a good improvement.
>
> Just let me know...
on this particular input, '6' looks OK. However, the
question is why '6'?
Why can't we retain the original number spelling from the
source code and use that instead?
Re: [Patch,AVR]: Avoid unwind warning from toplev.c
2011/10/10 Georg-Johann Lay : > toplev.c complains about "unwind tables currently require a frame pointer for > correctness". > > This patchlet supplies a fix to avoid build warnings/test fails in that it > sets > flag_omit_frame_pointer to 0 if unwind needs FP. > > toplev.c:process_options sets flag_unwind_tables depending on > flag_non_call_exceptions and flag_asynchronous_unwind_tables after calling > targetm.target_option.override() so that the test includes these flags, too. > > Ok? > > Johann > > * config/avr/avr.c (avr_option_override): Set > flag_omit_frame_pointer to 0 if frame pointer is needed for > unwinding. > Approved. Denis.
[PATCH]: Fix PR bootstrap/50665
Hello! Attached patch moves DOI_vec_perm index to the right place. 2011-10-10 Uros Bizjak PR bootstrap/50665 * optabs.h (DOI_vec_perm): Rename from OTI_vec_perm. Move from enum optab_index to enum direct_optab_index. (vec_perm_optab): Update. Tested by bootstrapping i686-pc-linux-gnu, committed to mainline SVN as obvious. Uros. Index: optabs.h === --- optabs.h(revision 179754) +++ optabs.h(working copy) @@ -377,9 +377,6 @@ enum optab_index OTI_vec_pack_sfix_trunc, OTI_vec_pack_ufix_trunc, - /* Vector shuffling. */ - OTI_vec_perm, - /* Perform a raise to the power of integer. */ OTI_powi, @@ -560,7 +557,6 @@ enum optab_index #define vec_pack_usat_optab (&optab_table[OTI_vec_pack_usat]) #define vec_pack_sfix_trunc_optab (&optab_table[OTI_vec_pack_sfix_trunc]) #define vec_pack_ufix_trunc_optab (&optab_table[OTI_vec_pack_ufix_trunc]) -#define vec_perm_optab (&direct_optab_table[(int) OTI_vec_perm]) #define powi_optab (&optab_table[OTI_powi]) @@ -642,6 +638,9 @@ enum direct_optab_index DOI_reload_in, DOI_reload_out, + /* Vector shuffling. */ + DOI_vec_perm, + /* Block move operation. */ DOI_movmem, @@ -705,6 +704,7 @@ typedef struct direct_optab_d *direct_optab; #endif #define reload_in_optab (&direct_optab_table[(int) DOI_reload_in]) #define reload_out_optab (&direct_optab_table[(int) DOI_reload_out]) +#define vec_perm_optab (&direct_optab_table[(int) DOI_vec_perm]) #define movmem_optab (&direct_optab_table[(int) DOI_movmem]) #define setmem_optab (&direct_optab_table[(int) DOI_setmem]) #define cmpstr_optab (&direct_optab_table[(int) DOI_cmpstr])
int_cst_hash_table mapping persistence and the garbage collector
Recently, a few UPC test programs failed to compile
due to mis-matches of parameters in a prototype and its
corresponding function definition. The mis-match was
based upon the apparent inequality of UPC layout qualifiers
(blocking factors).
UPC blocking factors are integer constants. They are
recorded in a hash table indexed by the type tree node
that they correspond to.
Currently, the test for equality of blocking factors
tests only the pointer to the tree node defining the constant.
All blocking factors are recorded as "sizetype" type'd nodes.
Given that integer constants are hashed by type/value, it seemed
safe to assume that a given blocking factor would map to
a single tree node due to the underlying hash method that is used
when integral constants are created.
Is it valid to assume that pointer equality is sufficient
to ensure that two integer constants are equal as long
as their type and values are equal?
The bug that we ran into occurred because a garbage collection
pass was run between the point that the function prototype
tree node was created and the point at which the function declaration
was processed. The garbage collector decided that the integer
constant representing the blocking factor was no longer in use,
because it had not been marked.
In fact, the integer constant was needed because it appeared
in the blocking factor hash table, but not via a direct pointer.
Rather it was referenced by nature of the fact that
the blocking factor hash table referenced the integer constant
that is mapped in the integer constant hash table.
Here's a rough diagram:
tree (type) -> [ blocking factor hash ] -> tree (integer constant)
tree (integer constant) -> [ integer constant hash ] {unique map}
-> tree (integer constant)
When the garbage collector deleted the entry from the
"integer constant hash", it forced a new integer constant tree
node to be created for the same (type, value) integral constant
blocking factor.
One easy way to address the current issue is to call
tree_int_cst_equal() if the integer constant tree pointers
do not match:
if ((c1 != c2) && !tree_int_cst_equal (c1, c2))
/* integer constants aren't equal. */
This may be necessary if 'int_cst_hash_table' is viewed as
a cache rather than a persistent, unique mapping.
Another approach, would be to somehow mark the node
in int_cst_hash_table as in use when the blocking factor
hash table is traversed by the garbage collector, or
to add logic the hash table delete function associated
with int_cst_hash_table; to dis-allow the delete if the
integer constant is present in the UPC blocking factor
hash table.
To effect this change in a modular way probably the hash table
delete function associated with 'int_cst_hash_table' would have
to be daisy-chained, where the UPC blocking factor check is made
first. The difficulty with implementing the daisy chaining is that
int_cst_hash_table needs to exist before the UPC-related initialization
code is run. One way to handle this might be yet another language
hook, called from the code that creates 'int_cst_hash_table'.
That seems overly complex.
For reference, the current blocking factor mapping table
is created as follows:
upc_block_factor_for_type = htab_create_ggc (512, tree_map_hash,
tree_map_eq, 0);
Summary:
1. Is it valid to assume that pointer equality is sufficient
to compare two integer constants for equality as long as they
have identical type and value?
2. Should 'int_cst_hash_table' be viewed as a cache, where
the mapping of a given (type, value) integer constant may
vary over time?
3. If the answer to 1. is "yes" and the answer to 2. is "no"
then what is the recommended way to ensure that nodes in
'int_cst_hash_table' are not removed if the integer constant
is being referenced via the 'upc_block_factor_for_type'
hash table?
thanks,
- Gary
Re: [patch, libgo] remove empty directories
Matthias Klose writes: > libgo currently has some empty directories. ok to remove? > > D go/encoding/line > D go/exp/ogle > D go/exp/eval > D go/exp/draw > D go/exp/draw/x11 Yes, thanks. Ian
[Patch,AVR]: Avoid unwind warning from toplev.c
toplev.c complains about "unwind tables currently require a frame pointer for
correctness".
This patchlet supplies a fix to avoid build warnings/test fails in that it sets
flag_omit_frame_pointer to 0 if unwind needs FP.
toplev.c:process_options sets flag_unwind_tables depending on
flag_non_call_exceptions and flag_asynchronous_unwind_tables after calling
targetm.target_option.override() so that the test includes these flags, too.
Ok?
Johann
* config/avr/avr.c (avr_option_override): Set
flag_omit_frame_pointer to 0 if frame pointer is needed for
unwinding.
Index: config/avr/avr.c
===
--- config/avr/avr.c (revision 179744)
+++ config/avr/avr.c (working copy)
@@ -351,6 +351,20 @@ avr_option_override (void)
{
flag_delete_null_pointer_checks = 0;
+ /* Avoid warning from toplev.c:process_options */
+
+ if ((flag_unwind_tables
+ || flag_non_call_exceptions
+ || flag_asynchronous_unwind_tables)
+ && !ACCUMULATE_OUTGOING_ARGS)
+{
+ flag_omit_frame_pointer = 0;
+}
+ else
+{
+ flag_omit_frame_pointer = (optimize >= 1);
+}
+
avr_current_device = &avr_mcu_types[avr_mcu_index];
avr_current_arch = &avr_arch_types[avr_current_device->arch];
avr_extra_arch_macro = avr_current_device->macro;
Re: Rename vshuffle/vec_shuffle to vec_perm
On 10/09/2011 06:09 AM, Joseph S. Myers wrote:
> That looks like it broke "make pdf" (something did at about that time and
> this patch is the most likely candidate).
>
>> +@cindex @code{vec_perm_const@var{m}) instruction pattern
>
> has opening '{' matched with closing ')'.
>
Fixed, thanks.
r~
Re: simulate-thread changes to avoid infinite loops
On 10/10/11 09:54, Aldy Hernandez wrote: Hi folks. This was a change Andrew had made to the simulate-thread framework to avoid infinite loops in hostile threads. I forgot to merge this in my original submission, and am doing so now. The original patch is here: http://permalink.gmane.org/gmane.comp.gcc.patches/247678 My patch is a mere sed run on Andrew's patch, plus a few fixed typos in the comments. I also kept the original simulate_thread_fini name as opposed to the __gdb_memmodel_fini name Andrew has (to keep names homogeneous throughout). Tested on x86-64 Linux by running "make check RUNTESTFLAGS=simulate-thread.exp" on the build tree I already had for the original submission. OK for trunk? OK. jeff
Re: [PATCH, testsuite, i386] FMA3 testcases + typo fix in MD
Thank you K On Mon, Oct 10, 2011 at 8:08 PM, H.J. Lu wrote: > On Sun, Oct 9, 2011 at 12:49 PM, Kirill Yukhin > wrote: >> Hi guys, >> This is a Ping. Could anyboady with appropriate rights commit that? >> >> > > I checked it in for you. Please provide ChangeLog entries together > with the new patch next time. > > -- > H.J. >
Re: [PATCH, testsuite, i386] FMA3 testcases + typo fix in MD
On Sun, Oct 9, 2011 at 12:49 PM, Kirill Yukhin wrote: > Hi guys, > This is a Ping. Could anyboady with appropriate rights commit that? > > I checked it in for you. Please provide ChangeLog entries together with the new patch next time. -- H.J.
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
2011/10/10 Richard Guenther :
> On Mon, Oct 10, 2011 at 5:07 PM, Kai Tietz wrote:
>> 2011/10/10 Richard Guenther :
>>> On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz wrote:
2011/10/10 Richard Guenther :
> On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz
> wrote:
>> Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
>> has to be checked that the LHS code is same as outer CODE, as
>> otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
>> LHS, which is of course wrong.
>>
>> Index: gcc/gcc/fold-const.c
>> ===
>> --- gcc.orig/gcc/fold-const.c
>> +++ gcc/gcc/fold-const.c
>> @@ -111,14 +111,13 @@ static tree decode_field_reference (loca
>> tree *, tree *);
>> static int all_ones_mask_p (const_tree, int);
>> static tree sign_bit_p (tree, const_tree);
>> -static int simple_operand_p (const_tree);
>> +static int simple_operand_p (tree);
>> static tree range_binop (enum tree_code, tree, tree, int, tree, int);
>> static tree range_predecessor (tree);
>> static tree range_successor (tree);
>> static tree fold_range_test (location_t, enum tree_code, tree, tree,
>> tree);
>> static tree fold_cond_expr_with_comparison (location_t, tree, tree,
>> tree, tree);
>> static tree unextend (tree, int, int, tree);
>> -static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
>> static tree optimize_minmax_comparison (location_t, enum tree_code,
>> tree, tree, tree);
>> static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
>> @@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
>> return lhs;
>> }
>>
>> -/* Subroutine for fold_truthop: decode a field reference.
>> +/* Subroutine for fold_truth_andor_1: decode a field reference.
>>
>> If EXP is a comparison reference, we return the innermost reference.
>>
>> @@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
>> return NULL_TREE;
>> }
>>
>> -/* Subroutine for fold_truthop: determine if an operand is simple enough
>> +/* Subroutine for fold_truth_andor_1: determine if an operand is simple
>> enough
>> to be evaluated unconditionally. */
>>
>> static int
>> -simple_operand_p (const_tree exp)
>> +simple_operand_p (tree exp)
>> {
>> + enum tree_code code;
>> /* Strip any conversions that don't change the machine mode. */
>> STRIP_NOPS (exp);
>>
>> + code = TREE_CODE (exp);
>> +
>> + /* Handle some trivials */
>> + if (TREE_CODE_CLASS (code) == tcc_comparison)
>> + return (tree_could_trap_p (exp)
>> + && simple_operand_p (TREE_OPERAND (exp, 0))
>> + && simple_operand_p (TREE_OPERAND (exp, 1)));
>
> And that's still wrong.
>
> Stopped reading here.
>
> Richard.
Oh, there is a not missing. I didn't spot that, sorry.
To the point why we need to handle comparisons within simple_operand_p.
If we reject comparisons and logical not here, we won't have any
branching optimization anymore, as this the patch moves into
fold_truthandor.
The result with rejecting in simple_operand_p compares and logic-not
provides for the following example:
>>>
>>> But you change what simple_operand_p accepts and thus change what
>>> fold_truthop accepts as operands to its simplifications.
>>>
>>> Richard.
>>
>> Well, not really. I assume you mean fold_truth_andor_1 (aka fold_truthop).
>>
>> It checks for
>> ...
>> if (TREE_CODE_CLASS (lcode) != tcc_comparison
>> || TREE_CODE_CLASS (rcode) != tcc_comparison)
>> return 0;
>> ...
>> before checking for simple_operand_p. So there is actual no change.
>> It might be of some interest here to add in a different patch support
>> for logic-not, but well, this is would be material for a different
>> patch.
>> So, it won't operate on anything else then comparisons as before.
>
> Sure, because simple_operand_p is checked on the comparison
> operands, not the comparison itself.
>
> Richard.
Right, we would allow by this things like (a != b) < (c != d) etc.
Here it seems that only some cases for comparison in comparison are
folded. (eg (a == b) == (c == d) -> (a == b) ^ (c == d) ). Well,
other material for a different patch.
To ensure that we use simple_operand_p in all cases, beside for
branching AND/OR chains, in same way as before, I added to this
function an additional argument, by which
the looking into comparisons can be activated.
Regards,
Kai
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -111,14 +111,13 @@ static tree decode_field_reference (loca
simulate-thread changes to avoid infinite loops
Hi folks.
This was a change Andrew had made to the simulate-thread framework to
avoid infinite loops in hostile threads. I forgot to merge this in my
original submission, and am doing so now.
The original patch is here:
http://permalink.gmane.org/gmane.comp.gcc.patches/247678
My patch is a mere sed run on Andrew's patch, plus a few fixed typos in
the comments. I also kept the original simulate_thread_fini name as
opposed to the __gdb_memmodel_fini name Andrew has (to keep names
homogeneous throughout).
Tested on x86-64 Linux by running "make check
RUNTESTFLAGS=simulate-thread.exp" on the build tree I already had for
the original submission.
OK for trunk?
* gcc.dg/simulate-thread/simulate-thread.gdb: Call
wrappers for *other_threads() and *final_verify().
* gcc.dg/simulate-thread/simulate-thread.h
(simulate_thread_wrapper_other_threads): New.
(simulate_thread_wrapper_final_verify): New.
Index: gcc.dg/simulate-thread/simulate-thread.gdb
===
--- gcc.dg/simulate-thread/simulate-thread.gdb (revision 179751)
+++ gcc.dg/simulate-thread/simulate-thread.gdb (working copy)
@@ -5,13 +5,13 @@ run
set $ret = 0
while (simulate_thread_fini != 1) && (! $ret)
- call simulate_thread_other_threads()
+ call simulate_thread_wrapper_other_threads()
stepi
set $ret |= simulate_thread_step_verify()
end
if (! $ret)
- set $ret |= simulate_thread_final_verify()
+ set $ret |= simulate_thread_wrapper_final_verify()
end
continue
quit $ret
Index: gcc.dg/simulate-thread/simulate-thread.h
===
--- gcc.dg/simulate-thread/simulate-thread.h(revision 179751)
+++ gcc.dg/simulate-thread/simulate-thread.h(working copy)
@@ -5,3 +5,107 @@ simulate_thread_done ()
{
simulate_thread_fini = 1;
}
+
+/* A hostile thread is one which changes a memory location so quickly
+ that another thread may never see the same value again. This is
+ simulated when simulate_thread_other_thread() is defined to modify
+ a memory location every cycle.
+
+ A process implementing a dependency on this value can run into
+ difficulties with such a hostile thread. For instance,
+ implementing an add with a compare_and_swap loop goes something
+ like:
+
+ expected = *mem;
+ loop:
+ new = expected += value;
+ if (!succeed (expected = compare_and_swap (mem, expected, new)))
+ goto loop;
+
+ If the content of 'mem' are changed every cycle by
+ simulate_thread_other_thread () this will become an infinite loop
+ since the value *mem will never be 'expected' by the time the
+ compare_and_swap is executed.
+
+ HOSTILE_THREAD_THRESHOLD defines the number of intructions which a
+ program will execute before triggering the hostile thread
+ pause. The pause will last for HOSTILE_THREAD_PAUSE instructions,
+ and then the counter will reset and begin again. During the pause
+ period, simulate_thread_other_thread will not be called.
+
+ This provides a chance for forward progress to be made and the
+ infinite loop to be avoided.
+
+ If the testcase defines HOSTILE_PAUSE_ERROR, then it will be
+ considered an RUNTIME FAILURE if the hostile pause is triggered.
+ This will allow to test for guaranteed forward progress routines.
+
+ If the default values for HOSTILE_THREAD_THRESHOLD or
+ HOSTILE_THREAD_PAUSE are insufficient, then the testcase may
+ override these by defining the values before including this file.
+
+ Most testcase are intended to run for very short periods of time,
+ so these defaults are considered to be high enough to not trigger
+ on a typical case, but not drag the test time out too much if a
+ hostile condition is interferring. */
+
+
+/* Define the threshold to start pausing the hostile thread. */
+#if !defined (HOSTILE_THREAD_THRESHOLD)
+#define HOSTILE_THREAD_THRESHOLD 500
+#endif
+
+/* Define the length of pause in cycles for the hostile thread to pause to
+ allow forward progress to be made. */
+#if !defined (HOSTILE_THREAD_PAUSE)
+#define HOSTILE_THREAD_PAUSE 20
+#endif
+
+void simulate_thread_other_threads (void);
+int simulate_thread_final_verify (void);
+
+static int simulate_thread_hostile_pause = 0;
+
+/* This function wraps simulate_thread_other_threads an monitors for
+ an infinite loop. If the threshold value HOSTILE_THREAD_THRESHOLD
+ is reached, the other_thread process is paused for
+ HOSTILE_THREAD_PAUSE cycles before resuming, and the counters start
+ again. */
+void
+simulate_thread_wrapper_other_threads()
+{
+ static int count = 0;
+ static int pause = 0;
+
+ if (++count >= HOSTILE_THREAD_THRESHOLD)
+{
+ if (!simulate_thread_hostile_pause)
+simulate_thread_hostile_pause = 1;
+
+ /* Count cycles before calling the hostile thread again. */
+ if (pause++ < HOSTILE_THREAD_PAUSE)
+ return;
+
+ /
Re: [PATCH] Mark static const strings as read-only.
> So, the patch for build_constant_desc does not have the desired effect. OK, too bad that we need to play this back-and-forth game with MEMs. So the original patch is OK (with TREE_READONLY (base) on the next line to mimic what is done just above and without the gcc/ prefix in the ChangeLog). If you have some available cycles, you can test and install the build_constant_desc change in the same commit, otherwise I'll do it myself. -- Eric Botcazou
Re: [Patch,AVR]: Reuse __tablejump2__
2011/10/10 Georg-Johann Lay : > This patch does better re-usage of __tablejump2__ from libgcc so that > switch/case statements with jump tables become smaller because the sequence > needs 6 to 9 words compared to 2 when JMPing to __tablejump2__. > > Moreover, __tablejump2__ does no more rely in the content of EIND (by using > EIJMP) and uses RET instead. > > The insn conditions of tablejump insns now are the same as in > avr_output_addr_vec_elt. > > Ok for trunk? Approved. Denis.
[PATCH] Fix PR50389
This fixes missed placements of VUSEs during
gimplify_and_update_call_from_tree. The gimplifier doesn't fill
out virtual operands (it doesn't call update_stmt) - for a reason,
we'd mark it for renaming else. So we have to stick a VUSE on
every stmt that can possibly have one. update_stmt will remove
it again when it is not necessary.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-10-10 Richard Guenther
PR middle-end/50389
* gimple-fold.c (gimplify_and_update_call_from_tree): Do not
mark symbols for renaming. Append the VUSE to all statements
that possibly can have one.
* gcc.dg/torture/pr50389.c: New testcase.
Index: gcc/gimple-fold.c
===
*** gcc/gimple-fold.c (revision 179738)
--- gcc/gimple-fold.c (working copy)
*** gimplify_and_update_call_from_tree (gimp
*** 588,600
}
new_stmt = gsi_stmt (i);
if (gimple_in_ssa_p (cfun))
! {
! find_new_referenced_vars (new_stmt);
! mark_symbols_for_renaming (new_stmt);
! }
! /* If the new statement has a VUSE, update it with exact SSA name we
! know will reach this one. */
! if (gimple_vuse (new_stmt))
{
/* If we've also seen a previous store create a new VDEF for
the latter one, and make that the new reaching VUSE. */
--- 588,597
}
new_stmt = gsi_stmt (i);
if (gimple_in_ssa_p (cfun))
! find_new_referenced_vars (new_stmt);
! /* If the new statement possibly has a VUSE, update it with exact SSA
!name we know will reach this one. */
! if (gimple_has_mem_ops (new_stmt))
{
/* If we've also seen a previous store create a new VDEF for
the latter one, and make that the new reaching VUSE. */
Index: gcc/testsuite/gcc.dg/torture/pr50389.c
===
*** gcc/testsuite/gcc.dg/torture/pr50389.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr50389.c (revision 0)
***
*** 0
--- 1,15
+ /* { dg-do compile } */
+ /* { dg-options "-freorder-blocks -ftracer" } */
+
+ extern int data[];
+ extern int i;
+
+ void
+ foo (void)
+ {
+ char buf[8];
+ __builtin___memcpy_chk (buf, data, i ? 8 : 4,
+ __builtin_object_size (buf, 0));
+ __builtin___memcpy_chk (buf, data, i ? 8 : 4,
+ __builtin_object_size (buf, 0));
+ }
Re: [4/4] Make SMS schedule register moves
On Mon, Oct 10, 2011 at 1:57 PM, Richard Sandiford wrote: > Ayal Zaks writes: >>> I agree it's natural to schedule moves for intra-iteration dependencies >>> in the normal get_sched_window way. But suppose we have a dependency: >>> >>> A --(T,N,1)--> B >>> >>> that requires two moves M1 and M2. If we think in terms of cycles >>> (in the SCHED_TIME sense), then this effectively becomes: >>> >>> A --(T,N1,1)--> M1 -->(T,N2,0)--> M2 -->(T,N3,0)--> B >>> >>> because it is now M1 that is fed by both the loop and the incoming edge. >>> But if there is a second dependency: >>> >>> A --(T,M,0)--> C >>> >>> that also requires two moves, we end up with: >>> >>> A --(T,N1,1)--> M1 -->(T,N2,0)--> M2 -->(T,N3,0)--> B >>> -->(T,M3,-1)--> B >>> >>> and dependence distances of -1 feel a bit weird. :-) Of course, >>> what we really have are two parallel dependencies: >>> >>> A --(T,N1,1)--> M1 -->(T,N2,0)--> M2 -->(T,N3,0)--> B >>> >>> A --(T,M1,0)--> M1' -->(T,M2,0)--> M2' -->(T,N3,0)--> B >>> >>> where M1' and M2' occupy the same position as M1 and M2 in the schedule, >>> but are one stage further along. But we only schedule them once, >>> so if we take the cycle/SCHED_TIME route, we have to introduce >>> dependencies of distance -1. >>> >> >> Interesting; had to digest this distance 1 business, a result of >> thinking in cycles instead of rows (or conversely), and mixing >> dependences with scheduling; here's my understanding, based on your >> explanations: >> >> Suppose a Use is truely dependent on a Def, where both have been >> scheduled at some absolute cycles; think of them as timing the first >> iteration of the loop. >> Assume first that Use appears originally after Def in the original >> instruction sequence of the loop (dependence distance 0). In this >> case, Use requires register moves if its distance D from Def according >> to the schedule is more than ii cycles long -- by the time Use is >> executed, the value it needs is no longer available in the def'd >> register due to intervening occurrences of Def. So in this case, the >> first reg-move (among D/ii) should appear after Def, recording its >> value before the next occurrence of Def overwrites it, and feeding >> subsequent moves as needed before each is overwritten. Thus the >> scheduling window of this first reg-move is within (Def, Def+ii). >> >> Now, suppose Use appears before Def, i.e., Use is upwards-exposed; if >> it remains scheduled before the Def, no reg-move is needed. If, otoh, >> Def is scheduled (D>0 cycles) before Use, breaking the anti-dependence >> between them, (D/ii + 1) reg-moves are needed in order to feed Use >> with the live-in value before Def. So in this case, the first reg-move >> should appear before Def (again feeding subsequent moves as needed >> before each is overwritten). Thus the scheduling window of this first >> reg-move is within (Def-ii, Def). >> >> In any case, each use requires a specific number of reg-moves, which >> begin either before or after the def; it is always safe (though >> potentially redundant) to start reg-moving before the def -- uses that >> do not need the live-in value will ignore it by feeding from a later >> reg-move. > > Right. The distance on the Def->Use dependency is effectively transferred > to the dependency between the Def and first move. > > And we can potentially have both kinds of Use at the same time. > We then end up scheduling two moves, one in each window, but require > them to occupy the same row and column. It feels more convenient to > schedule the earlier of the two moves. > >> Q: if we generate reg-moves starting from before the def, would >> redundant reg-moves be eliminated if no use needs access to live-in >> value? If so, would that simplify their generation? (If not, it may be >> interesting to understand how to improve DCE to catch it.) > > To be clear, the new version of the patch (unlike the old one) > doesn't emit reg-moves before the def if all uses are distance 0. > We only do it where some or all uses are distance 1. The first move > before the def is always needed in that case. > Understood. The question was whether it would simplify things if we always emit reg-moves before the def. And rely on DCE to hopefully eliminate redundancies. > So redudant moves are confined to the case where (a) we have more > than one move, (b) we have both distance 0 and distance 1 uses, and > (c) one of the two distance sets requires more moves than the other. > If the distance 0 dependencies require more moves than the distance > 1 dependencies, we will have a redudant move in the prologue. > If the distance 1 dependencies require more moves than the distance > 0 dependencies, we will have a redudant move in the epilogue. > But I believe that this is already handled by dce. > > (For avoidance of doubt, the new code is more accurate than > current trunk in this respect.) > >> The issue of assigning stages to reg-moves is mostl
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
On Mon, Oct 10, 2011 at 5:07 PM, Kai Tietz wrote:
> 2011/10/10 Richard Guenther :
>> On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz wrote:
>>> 2011/10/10 Richard Guenther :
On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz wrote:
> Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
> has to be checked that the LHS code is same as outer CODE, as
> otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
> LHS, which is of course wrong.
>
> Index: gcc/gcc/fold-const.c
> ===
> --- gcc.orig/gcc/fold-const.c
> +++ gcc/gcc/fold-const.c
> @@ -111,14 +111,13 @@ static tree decode_field_reference (loca
> tree *, tree *);
> static int all_ones_mask_p (const_tree, int);
> static tree sign_bit_p (tree, const_tree);
> -static int simple_operand_p (const_tree);
> +static int simple_operand_p (tree);
> static tree range_binop (enum tree_code, tree, tree, int, tree, int);
> static tree range_predecessor (tree);
> static tree range_successor (tree);
> static tree fold_range_test (location_t, enum tree_code, tree, tree,
> tree);
> static tree fold_cond_expr_with_comparison (location_t, tree, tree,
> tree, tree);
> static tree unextend (tree, int, int, tree);
> -static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
> static tree optimize_minmax_comparison (location_t, enum tree_code,
> tree, tree, tree);
> static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
> @@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
> return lhs;
> }
>
> -/* Subroutine for fold_truthop: decode a field reference.
> +/* Subroutine for fold_truth_andor_1: decode a field reference.
>
> If EXP is a comparison reference, we return the innermost reference.
>
> @@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
> return NULL_TREE;
> }
>
> -/* Subroutine for fold_truthop: determine if an operand is simple enough
> +/* Subroutine for fold_truth_andor_1: determine if an operand is simple
> enough
> to be evaluated unconditionally. */
>
> static int
> -simple_operand_p (const_tree exp)
> +simple_operand_p (tree exp)
> {
> + enum tree_code code;
> /* Strip any conversions that don't change the machine mode. */
> STRIP_NOPS (exp);
>
> + code = TREE_CODE (exp);
> +
> + /* Handle some trivials */
> + if (TREE_CODE_CLASS (code) == tcc_comparison)
> + return (tree_could_trap_p (exp)
> + && simple_operand_p (TREE_OPERAND (exp, 0))
> + && simple_operand_p (TREE_OPERAND (exp, 1)));
And that's still wrong.
Stopped reading here.
Richard.
>>>
>>> Oh, there is a not missing. I didn't spot that, sorry.
>>>
>>> To the point why we need to handle comparisons within simple_operand_p.
>>>
>>> If we reject comparisons and logical not here, we won't have any
>>> branching optimization anymore, as this the patch moves into
>>> fold_truthandor.
>>>
>>> The result with rejecting in simple_operand_p compares and logic-not
>>> provides for the following example:
>>
>> But you change what simple_operand_p accepts and thus change what
>> fold_truthop accepts as operands to its simplifications.
>>
>> Richard.
>
> Well, not really. I assume you mean fold_truth_andor_1 (aka fold_truthop).
>
> It checks for
> ...
> if (TREE_CODE_CLASS (lcode) != tcc_comparison
> || TREE_CODE_CLASS (rcode) != tcc_comparison)
> return 0;
> ...
> before checking for simple_operand_p. So there is actual no change.
> It might be of some interest here to add in a different patch support
> for logic-not, but well, this is would be material for a different
> patch.
> So, it won't operate on anything else then comparisons as before.
Sure, because simple_operand_p is checked on the comparison
operands, not the comparison itself.
Richard.
> Kai
>
Re: [PATCH] sel-sched: forbid differing modes in substitution (PR 50205)
Ping?
On Wed, 7 Sep 2011, Alexander Monakov wrote:
> Hello,
>
> The patch repairs a problem when we attempt to substitute an insn like
> (... (cmp (mem (reg:DI ax)) (reg:SI ax))) (note different modes) through
> (set (reg:DI ax) (reg:DI dx)), which leaves the (reg:SI ax) part of the
> comparison intact, causing an ICE later on when we notice that the dependency
> on ax is still present. As this is quite rare, we can simply forbid
> substitution in such circumstances, much like substitution of multiple hard
> reg references is forbidden now.
>
> En passant, the patch simplifes the code a little, as we never try to
> substitute anything but registers.
>
> Bootstrapped and regtested on x86_64-linux with sel-sched enabled at -O2, OK?
> (I'll add the testcase from Bugzilla when committing)
>
> 2011-09-07 Alexander Monakov
>
> PR rtl-optimization/50205
> * sel-sched.c (count_occurrences_1): Simplify on the assumption that
> p->x is a register. Forbid substitution when the same register is
> found in a different mode.
> (count_occurrences_equiv): Assert that 'what' is a register.
>
> diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
> index f11faca..2af01ae 100644
> --- a/gcc/sel-sched.c
> +++ b/gcc/sel-sched.c
> @@ -813,18 +813,12 @@ count_occurrences_1 (rtx *cur_rtx, void *arg)
> {
>rtx_search_arg_p p = (rtx_search_arg_p) arg;
>
> - /* The last param FOR_GCSE is true, because otherwise it performs excessive
> -substitutions like
> - r8 = r33
> - r16 = r33
> -for the last insn it presumes r33 equivalent to r8, so it changes it to
> -r33. Actually, there's no change, but it spoils debugging. */
> - if (exp_equiv_p (*cur_rtx, p->x, 0, true))
> -{
> - /* Bail out if we occupy more than one register. */
> - if (REG_P (*cur_rtx)
> - && HARD_REGISTER_P (*cur_rtx)
> - && hard_regno_nregs[REGNO(*cur_rtx)][GET_MODE (*cur_rtx)] > 1)
> + if (REG_P (*cur_rtx) && REGNO (*cur_rtx) == REGNO (p->x))
> +{
> + /* Bail out if mode is different or more than one register is used. */
> + if (GET_MODE (*cur_rtx) != GET_MODE (p->x)
> + || (HARD_REGISTER_P (*cur_rtx)
> + && hard_regno_nregs[REGNO(*cur_rtx)][GET_MODE (*cur_rtx)] > 1))
> {
>p->n = 0;
>return 1;
> @@ -837,7 +831,6 @@ count_occurrences_1 (rtx *cur_rtx, void *arg)
> }
>
>if (GET_CODE (*cur_rtx) == SUBREG
> - && REG_P (p->x)
>&& (!REG_P (SUBREG_REG (*cur_rtx))
> || REGNO (SUBREG_REG (*cur_rtx)) == REGNO (p->x)))
> {
> @@ -859,6 +852,7 @@ count_occurrences_equiv (rtx what, rtx where)
> {
>struct rtx_search_arg arg;
>
> + gcc_assert (REG_P (what));
>arg.x = what;
>arg.n = 0;
>
>
>
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
Hi,
On Mon, 10 Oct 2011, Kai Tietz wrote:
> extern int foo (void); /* foo modifies gbl1 */
> int gbl1 = 0;
>
> int foo (int ns1)
> {
> if (ns1 && foo () && gbl1)
> return 1;
> return 0;
> }
>
> so chain of trees has to look like this:
> (ANDIF (ns1 (ANDIF foo () gbl1))
Okay, indeed. I was wrong when I claimed that only the RHS needs to be
side-effect-free for ANDIF->AND to be valid. It's true when the RHS can't
depend on the LHS, but I only thought about the fact that the side-effect
must occur, not that it possibly influences RHS.
Ciao,
Michael.
Re: [PATCH] Don't assume that constants can clobber vtbl
On Mon, Oct 10, 2011 at 05:05:14PM +0200, Martin Jambor wrote: > Hi, > > sorry that taking care of the devirtualization patches takes me longer > than expected for various reasons. But I have not forgotten about > this. Ah, please ignore the attachment, I was trying to persuade mutt to add it to the original email so that I could comment on it inline but it re-attached it instead, for some weird reason. Thanks, Martin
[PATCH] Verify stuff after IPA split
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2011-10-10 Richard Guenther * ipa-split.c (pass_split_functions): Add verification TODOs. (pass_feedback_split_functions): Likewise. Index: gcc/ipa-split.c === --- gcc/ipa-split.c (revision 179738) +++ gcc/ipa-split.c (working copy) @@ -1451,7 +1451,7 @@ struct gimple_opt_pass pass_split_functi 0, /* properties_provided */ 0, /* properties_destroyed */ 0, /* todo_flags_start */ - 0/* todo_flags_finish */ + TODO_verify_all /* todo_flags_finish */ } }; @@ -1492,6 +1492,6 @@ struct gimple_opt_pass pass_feedback_spl 0, /* properties_provided */ 0, /* properties_destroyed */ 0, /* todo_flags_start */ - 0/* todo_flags_finish */ + TODO_verify_all /* todo_flags_finish */ } };
Re: [PATCH] sel-sched: fix merging of LHS reg availability (PR 50340)
Ping. This is now a P1 bug, as it breaks spec2k gcc on ia64. On Tue, 13 Sep 2011, Alexander Monakov wrote: > Hello, > > This patches fixes an ICE on an assert that performs a sanity check on > target_available field of expr_t, which is tri-state: LHS register is > available (1), not available (0) or unknown (-1). > > The problem is, when merging expr data of separable exprs with differing > LHSes, we can't claim we know anything about availability of the target > register if the unavailable LHS of the other expr is not the same register. > Thus, we should set the field to -1, not 0. > > Fixed as follows, bootstrapped and regtested on x86_64-linux and ia64-linux > (without java, with one recent SRA patch reverted to unbreak bootstrap) with > sel-sched enabled at -O2. OK for trunk? > > (a small testcase is not available at the moment, but I can try to produce one > using delta before committing) > > > 2011-09-13 Andrey Belevantsev > > * sel-sched-ir.c (update_target_availability): LHS register > availability is not known if the unavailable LHS of the other > expression is a different register. > > diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c > index 4878460..b132392 100644 > --- a/gcc/sel-sched-ir.c > +++ b/gcc/sel-sched-ir.c > @@ -1746,7 +1746,13 @@ update_target_availability (expr_t to, expr_t from, > insn_t split_point) > EXPR_TARGET_AVAILABLE (to) = -1; > } >else > -EXPR_TARGET_AVAILABLE (to) &= EXPR_TARGET_AVAILABLE (from); > +if (EXPR_TARGET_AVAILABLE (from) == 0 > +&& EXPR_LHS (from) > +&& REG_P (EXPR_LHS (from)) > +&& REGNO (EXPR_LHS (to)) != REGNO (EXPR_LHS (from))) > + EXPR_TARGET_AVAILABLE (to) = -1; > +else > + EXPR_TARGET_AVAILABLE (to) &= EXPR_TARGET_AVAILABLE (from); > } > } >
Re: [Patch,testsuite,AVR]: target-supports.exp: AVR does not support TLS
Georg-Johann Lay writes: >> This has nothing to do with AVR, but is PR middle-end/50638. It breaks >> TLS on all emutls targets. A patch has been posted and approved, but >> apparently not yet installed. > > Thanks for the notice. > The GCC documentation says that TLS need support of a dynamic linker. It's > unlikely there will ever be a dynamic linker on a device with some tens k for > code and some k of RAM? I suppose this applies to native TLS, not emutls. >> So please be more careful investigating testsuite failures before >> XFAILing or skipping them. > > Sorry, experience is that many test cases are not well written to parametrize > for small targets and it's merely impossible to catch up with hundreds of test Not only small, but unusual targets in general ;-) > case fall out from them and to see the real problems. But it's still important to either do the analysis (or have someone who knows that area in depth do the analysis :-) to avoid papering over the real problem. I like to keep the number of testsuite failure manageable myself, so I know how your feeling ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Mark static const strings as read-only.
On 10/10/2011 03:44 PM, Eric Botcazou wrote:
>> The patch makes sure that the src_mem computed here in
>> expand_builtin_memcpy is marked as MEM_READONLY_P:
>> ...
>> src_mem = get_memory_rtx (src, len);
>> ...
>>
>> build and reg-tested on i686, arm, and mips.
>>
>> OK for trunk?
>
> Do you get the same result by calling gen_const_mem from build_constant_desc
> instead of gen_rtx_MEM? If so, this would be better I think.
>
I tried the patch that you describe:
...
Index: gcc/varasm.c
===
--- gcc/varasm.c (revision 179662)
+++ gcc/varasm.c (working copy)
@@ -3119,7 +3119,7 @@ build_constant_desc (tree exp)
SET_SYMBOL_REF_DECL (symbol, decl);
TREE_CONSTANT_POOL_ADDRESS_P (symbol) = 1;
- rtl = gen_rtx_MEM (TYPE_MODE (TREE_TYPE (exp)), symbol);
+ rtl = gen_const_mem (TYPE_MODE (TREE_TYPE (exp)), symbol);
set_mem_attributes (rtl, exp, 1);
set_mem_alias_set (rtl, 0);
set_mem_alias_set (rtl, const_alias_set);
...
The src_mem in expand_builtin_memcpy is generated in get_memory_rtx:
...
static rtx
get_memory_rtx (tree exp, tree len)
{
tree orig_exp = exp;
rtx addr, mem;
HOST_WIDE_INT off;
/* When EXP is not resolved SAVE_EXPR, MEM_ATTRS can be still derived
from its expression, for expr->a.b only .a.b is recorded. */
if (TREE_CODE (exp) == SAVE_EXPR && !SAVE_EXPR_RESOLVED_P (exp))
exp = TREE_OPERAND (exp, 0);
addr = expand_expr (orig_exp, NULL_RTX, ptr_mode, EXPAND_NORMAL);
mem = gen_rtx_MEM (BLKmode, memory_address (BLKmode, addr));
...
With the patch for build_constant_desc, a mem with MEM_READONLY_P set (/u) is
generated in expand_expr_constant during expand_expr:
...
(mem/s/u/c:BLK (symbol_ref/f:SI ("*$LC0") [flags 0x2] ) [1 S4 A32])
...
but the expand_expr returns this:
...
(symbol_ref/f:SI ("*$LC0") [flags 0x2] )
...
The subsequent gen_rtx_MEM generates this:
...
(mem:BLK (lo_sum:SI (reg:SI 195)
(symbol_ref/f:SI ("*$LC0") [flags 0x2] )) [0
A8])
...
and after set_mem_attributes it looks like this:
...
(mem/s/c:BLK (lo_sum:SI (reg:SI 195)
(symbol_ref/f:SI ("*$LC0") [flags 0x2] )) [0
S4 A32])
...
So, the patch for build_constant_desc does not have the desired effect.
Thanks,
- Tom
Re: [Patch,testsuite,AVR]: target-supports.exp: AVR does not support TLS
Rainer Orth schrieb: > Georg-Johann Lay writes: > >> For example, after updating trunk to 179738, >> >> (gdb) set args -fpreprocessed tls-1.i -quiet -dumpbase tls-1.c >> -mmcu=atmega128 >> -auxbase tls-1 -gdwarf-2 -O3 -O2 -version -o tls-1.s >> (gdb) cd ~/test >> (gdb) r >> GNU C (GCC) version 4.7.0 20111010 (experimental) (avr) >> compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP >> version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 >> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 >> GNU C (GCC) version 4.7.0 20111010 (experimental) (avr) >> compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP >> version >> 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 >> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 >> Compiler executable checksum: 4e4900df2fe6cd3a5bd440dbb3a30bf2 >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0864e398 in set_is_used (var=0xb7dd3600) at >> ../../../gcc.gnu.org/trunk/gcc/tree-flow-inline.h:562 >> (gdb) bt >> #0 0x0864e398 in set_is_used (var=0xb7dd3600) at >> ../../../gcc.gnu.org/trunk/gcc/tree-flow-inline.h:562 >> #1 0x0864e256 in mark_all_vars_used_1 (tp=0xb7dc97c4, >> walk_subtrees=0xbfffe004, data=0x0) at >> ../../../gcc.gnu.org/trunk/gcc/tree-ssa-live.c:379 > > This has nothing to do with AVR, but is PR middle-end/50638. It breaks > TLS on all emutls targets. A patch has been posted and approved, but > apparently not yet installed. Thanks for the notice. The GCC documentation says that TLS need support of a dynamic linker. It's unlikely there will ever be a dynamic linker on a device with some tens k for code and some k of RAM? > So please be more careful investigating testsuite failures before > XFAILing or skipping them. Sorry, experience is that many test cases are not well written to parametrize for small targets and it's merely impossible to catch up with hundreds of test case fall out from them and to see the real problems. Johann > > Rainer >
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
2011/10/10 Richard Guenther :
> On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz wrote:
>> 2011/10/10 Richard Guenther :
>>> On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz wrote:
Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
has to be checked that the LHS code is same as outer CODE, as
otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
LHS, which is of course wrong.
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -111,14 +111,13 @@ static tree decode_field_reference (loca
tree *, tree *);
static int all_ones_mask_p (const_tree, int);
static tree sign_bit_p (tree, const_tree);
-static int simple_operand_p (const_tree);
+static int simple_operand_p (tree);
static tree range_binop (enum tree_code, tree, tree, int, tree, int);
static tree range_predecessor (tree);
static tree range_successor (tree);
static tree fold_range_test (location_t, enum tree_code, tree, tree,
tree);
static tree fold_cond_expr_with_comparison (location_t, tree, tree,
tree, tree);
static tree unextend (tree, int, int, tree);
-static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
static tree optimize_minmax_comparison (location_t, enum tree_code,
tree, tree, tree);
static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
@@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
return lhs;
}
-/* Subroutine for fold_truthop: decode a field reference.
+/* Subroutine for fold_truth_andor_1: decode a field reference.
If EXP is a comparison reference, we return the innermost reference.
@@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
return NULL_TREE;
}
-/* Subroutine for fold_truthop: determine if an operand is simple enough
+/* Subroutine for fold_truth_andor_1: determine if an operand is simple
enough
to be evaluated unconditionally. */
static int
-simple_operand_p (const_tree exp)
+simple_operand_p (tree exp)
{
+ enum tree_code code;
/* Strip any conversions that don't change the machine mode. */
STRIP_NOPS (exp);
+ code = TREE_CODE (exp);
+
+ /* Handle some trivials */
+ if (TREE_CODE_CLASS (code) == tcc_comparison)
+ return (tree_could_trap_p (exp)
+ && simple_operand_p (TREE_OPERAND (exp, 0))
+ && simple_operand_p (TREE_OPERAND (exp, 1)));
>>>
>>> And that's still wrong.
>>>
>>> Stopped reading here.
>>>
>>> Richard.
>>
>> Oh, there is a not missing. I didn't spot that, sorry.
>>
>> To the point why we need to handle comparisons within simple_operand_p.
>>
>> If we reject comparisons and logical not here, we won't have any
>> branching optimization anymore, as this the patch moves into
>> fold_truthandor.
>>
>> The result with rejecting in simple_operand_p compares and logic-not
>> provides for the following example:
>
> But you change what simple_operand_p accepts and thus change what
> fold_truthop accepts as operands to its simplifications.
>
> Richard.
Well, not really. I assume you mean fold_truth_andor_1 (aka fold_truthop).
It checks for
...
if (TREE_CODE_CLASS (lcode) != tcc_comparison
|| TREE_CODE_CLASS (rcode) != tcc_comparison)
return 0;
...
before checking for simple_operand_p. So there is actual no change.
It might be of some interest here to add in a different patch support
for logic-not, but well, this is would be material for a different
patch.
So, it won't operate on anything else then comparisons as before.
Kai
Re: [PATCH] Don't assume that constants can clobber vtbl
Hi,
sorry that taking care of the devirtualization patches takes me longer
than expected for various reasons. But I have not forgotten about
this.
On Sat, Oct 01, 2011 at 01:58:57PM +1300, Maxim Kuvyrkov wrote:
> This patch makes detect_type_change analysis assume that only ADDR_EXPRs can
> be assigned to vtable entries.
>
> Initially, the patch made a less strict assumption that constants
> are not assigned to vtables. I then bumped the assumption to "only
> ADDR_EXPRs can be assigned to vtables". I have this patch since GCC
> 4.6 and did not came across a testcase that would invalidate either
> of the assumptions.
>
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 3e56e70..491bb11 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -320,6 +320,7 @@ stmt_may_be_vtbl_ptr_store (gimple stmt)
>else if (is_gimple_assign (stmt))
> {
>tree lhs = gimple_assign_lhs (stmt);
> + tree rhs;
>
>if (!AGGREGATE_TYPE_P (TREE_TYPE (lhs)))
> {
> @@ -334,6 +335,13 @@ stmt_may_be_vtbl_ptr_store (gimple stmt)
> if there is a field corresponding to the offset and if
> so, procee> d
> almost like if it was a component ref. */
> }
Just before this, there is the following test (guarded by
flag_strict_aliasing per explicit Richi's request).
if (flag_strict_aliasing
&& !POINTER_TYPE_P (TREE_TYPE (lhs)))
return false;
Why is it not enough to catch integer constants?
I'd be OK with ignoring invariants which are not pointers but those
should already be handled by the test above. Your code also ignores
even variable right hand sides which I think might be dangerous,
e.g. if SRA ever decided to copy an object by copying all fields.
Thanks,
Martin
> +
> + /* Assume that only ADDR_EXPRs can be assigned to vtables.
> +In particular, ignore *ptr = when searching for aliasing
> +entries. */
> + rhs = gimple_assign_rhs1 (stmt);
> + if (TREE_CODE (rhs) != ADDR_EXPR)
> + return false;
> }
>return true;
> }
>
>
> Martin, you are the author of stmt_may_be_vtbl_ptr_store; is there
> any reaso> n to assume that something other than ADDR_EXPR can be
> assigned to a vtable?
>
> Bootstrapped and regtested on x86_64-linux-gnu {-m64/-m32} with no
> regressions.
>
> OK for trunk?
>
> Thank you,
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>
>
fsf-gcc-vtbl-assign.patch
Description: Binary data
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz wrote:
> 2011/10/10 Richard Guenther :
>> On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz wrote:
>>> Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
>>> has to be checked that the LHS code is same as outer CODE, as
>>> otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
>>> LHS, which is of course wrong.
>>>
>>> Index: gcc/gcc/fold-const.c
>>> ===
>>> --- gcc.orig/gcc/fold-const.c
>>> +++ gcc/gcc/fold-const.c
>>> @@ -111,14 +111,13 @@ static tree decode_field_reference (loca
>>> tree *, tree *);
>>> static int all_ones_mask_p (const_tree, int);
>>> static tree sign_bit_p (tree, const_tree);
>>> -static int simple_operand_p (const_tree);
>>> +static int simple_operand_p (tree);
>>> static tree range_binop (enum tree_code, tree, tree, int, tree, int);
>>> static tree range_predecessor (tree);
>>> static tree range_successor (tree);
>>> static tree fold_range_test (location_t, enum tree_code, tree, tree, tree);
>>> static tree fold_cond_expr_with_comparison (location_t, tree, tree,
>>> tree, tree);
>>> static tree unextend (tree, int, int, tree);
>>> -static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
>>> static tree optimize_minmax_comparison (location_t, enum tree_code,
>>> tree, tree, tree);
>>> static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
>>> @@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
>>> return lhs;
>>> }
>>>
>>> -/* Subroutine for fold_truthop: decode a field reference.
>>> +/* Subroutine for fold_truth_andor_1: decode a field reference.
>>>
>>> If EXP is a comparison reference, we return the innermost reference.
>>>
>>> @@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
>>> return NULL_TREE;
>>> }
>>>
>>> -/* Subroutine for fold_truthop: determine if an operand is simple enough
>>> +/* Subroutine for fold_truth_andor_1: determine if an operand is simple
>>> enough
>>> to be evaluated unconditionally. */
>>>
>>> static int
>>> -simple_operand_p (const_tree exp)
>>> +simple_operand_p (tree exp)
>>> {
>>> + enum tree_code code;
>>> /* Strip any conversions that don't change the machine mode. */
>>> STRIP_NOPS (exp);
>>>
>>> + code = TREE_CODE (exp);
>>> +
>>> + /* Handle some trivials */
>>> + if (TREE_CODE_CLASS (code) == tcc_comparison)
>>> + return (tree_could_trap_p (exp)
>>> + && simple_operand_p (TREE_OPERAND (exp, 0))
>>> + && simple_operand_p (TREE_OPERAND (exp, 1)));
>>
>> And that's still wrong.
>>
>> Stopped reading here.
>>
>> Richard.
>
> Oh, there is a not missing. I didn't spot that, sorry.
>
> To the point why we need to handle comparisons within simple_operand_p.
>
> If we reject comparisons and logical not here, we won't have any
> branching optimization anymore, as this the patch moves into
> fold_truthandor.
>
> The result with rejecting in simple_operand_p compares and logic-not
> provides for the following example:
But you change what simple_operand_p accepts and thus change what
fold_truthop accepts as operands to its simplifications.
Richard.
> extern int doo (void);
> extern int doo2 (void);
>
> int foo (int a, int b, int c, int d, int e, int f)
> {
> if (a && b && c && d && e && f)
> return doo ();
> return doo2 ();
> }
>
> we get the following gimple dump (-fdump-tree-gimple):
>
> foo (int a, int b, int c, int d, int e, int f)
> {
> int D.2752;
>
> if (a != 0) goto ; else goto ;
> :
> if (b != 0) goto ; else goto ;
> :
> if (c != 0) goto ; else goto ;
> :
> if (d != 0) goto ; else goto ;
> :
> if (e != 0) goto ; else goto ;
> :
> if (f != 0) goto ; else goto ;
> :
> D.2752 = doo ();
> return D.2752;
> :
> :
> :
> :
> :
> :
> D.2752 = doo2 ();
> return D.2752;
> }
>
> So this result is caused by the fact that a logical-and/or is always a
> comparison. As we are rejecting comparisons/logical-not, we end up
> with a sequence of TRUTH_(AND|OR)_IFs. So the hole loop in
> fold_truth_andor for trying to pack simple and side-effect-less
> operands in tupels of two is useless.
>
> For the new patch (attached with proper ! fix for compares) we get for
> the same sample gimple output:
>
> foo (int a, int b, int c, int d, int e, int f)
> {
> _Bool D.2740;
> _Bool D.2741;
> _Bool D.2742;
> _Bool D.2745;
> _Bool D.2746;
> _Bool D.2747;
> _Bool D.2750;
> _Bool D.2751;
> _Bool D.2752;
> int D.2755;
>
> D.2740 = a != 0;
> D.2741 = b != 0;
> D.2742 = D.2740 & D.2741;
> if (D.2742 != 0) goto ; else goto ;
> :
> D.2745 = c != 0;
> D.2746 = d != 0;
> D.2747 = D.2745 & D.2746;
> if (D.2747 != 0) goto ; else goto ;
> :
> D.2750 = e != 0;
> D.2751 = f != 0;
> D.2752 = D.2750 & D.2751;
> if (D.2752 != 0) goto ; else goto ;
> :
> D.2755 = doo ();
> return D.2755;
> :
> :
> :
> D.2755 = doo2
Re: [PATCH 1/5] Use MADV_DONTNEED for freeing in garbage collector
On Mon, Oct 10, 2011 at 4:04 PM, Andi Kleen wrote: >> Shouldn't we prefer still "mapped" pages when allocating? Thus, keep >> the freepages list "sorted"? > > Possibly. I can look at it in a followup if you want. > I would prefer to not complicate this patch too much. > >> >> With the new params to call release_pages less, how does this >> interact with using MADV_DONTNEED? The only reason to delay >> MADV_DONTNEED is to avoid splitting huge-pages? Which would >> mean that we should rather be better at controlling where we allocate >> from from the free-list? > > I first had a patch that tried to cluster inside the freelist > with multiple passes (and only free aligned quire clusters first), but it > ran into various problems, so I chose this simpler approach. > > With MADV_DONTNEED the param is not really needed I think, > I mainly added the param for the benefit of hosts that don't > have MADV_DONTNEED to let them not suffer from fragmentation too much. > It would be possible to set the thresholds all to 0 if MADV_DONTNEED > is available. So can we move the param patch back as a possible followup? Thanks, Richard. > -Andi >
Re: [PATCH 4/5] Add a freeing threshold for the garbage collector.
On Mon, Oct 10, 2011 at 3:58 PM, Andi Kleen wrote: > On Mon, Oct 10, 2011 at 12:20:53PM +0200, Richard Guenther wrote: >> On Sun, Oct 9, 2011 at 9:55 PM, Andi Kleen wrote: >> > From: Andi Kleen >> > >> > Add a threshold to avoid freeing pages back too early to the OS. >> > This avoid virtual memory map fragmentation. >> > >> > Based on a idea from Honza >> >> Less than 20% looks high. Shouldn't ggc-free-min be enough to >> avoid fragmentation? > > It depends on the working set. If there's more to garbage collect > than max(ggc-free-min, threshold*total) a host without MADV_DONTNEED > will get holes. And ggc-free-min isn't very much on a large > build. > > So it seems safer to me to have a threshold which adjusts for large > working sets. What value do you prefer instead of 20%? (or just 0) I'm not sure honestly - 10% maybe? I realize it's quite arbitrary ... >> >> This will hide gc bugs with always-collect (ggc-checking), so >> the parameter(s) need to be adjusted for that case to always >> give pages back. The current values should probably be printed >> where the two existing ones are printed as well (with -v). > > Will fix. > -Andi >
[PATCH] Fix PR50195
Canonicalize x*x to pow(x,2) only when optimizing which is when
we do optimized expansion.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-10-10 Richard Guenther
PR middle-end/50195
* fold-const.c (fold_binary_loc): Canonicalize x*x to pow (x, 2)
only when optimizing.
* gcc.dg/builtins-47.c: Optimize.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 179738)
+++ gcc/fold-const.c(working copy)
@@ -10693,9 +10693,9 @@ fold_binary_loc (location_t loc,
}
}
- /* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
+ /* Canonicalize x*x as pow(x,2.0), which is expanded as x*x. */
if (!in_gimple_form
- && optimize_function_for_speed_p (cfun)
+ && optimize
&& operand_equal_p (arg0, arg1, 0))
{
tree powfn = mathfn_built_in (type, BUILT_IN_POW);
Index: gcc/testsuite/gcc.dg/builtins-47.c
===
--- gcc/testsuite/gcc.dg/builtins-47.c (revision 179738)
+++ gcc/testsuite/gcc.dg/builtins-47.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-ffast-math -fdump-tree-gimple" } */
+/* { dg-options "-O -ffast-math -fdump-tree-gimple" } */
extern double sqrt (double);
extern double pow (double, double);
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
2011/10/10 Richard Guenther :
> On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz wrote:
>> Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
>> has to be checked that the LHS code is same as outer CODE, as
>> otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
>> LHS, which is of course wrong.
>>
>> Index: gcc/gcc/fold-const.c
>> ===
>> --- gcc.orig/gcc/fold-const.c
>> +++ gcc/gcc/fold-const.c
>> @@ -111,14 +111,13 @@ static tree decode_field_reference (loca
>> tree *, tree *);
>> static int all_ones_mask_p (const_tree, int);
>> static tree sign_bit_p (tree, const_tree);
>> -static int simple_operand_p (const_tree);
>> +static int simple_operand_p (tree);
>> static tree range_binop (enum tree_code, tree, tree, int, tree, int);
>> static tree range_predecessor (tree);
>> static tree range_successor (tree);
>> static tree fold_range_test (location_t, enum tree_code, tree, tree, tree);
>> static tree fold_cond_expr_with_comparison (location_t, tree, tree,
>> tree, tree);
>> static tree unextend (tree, int, int, tree);
>> -static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
>> static tree optimize_minmax_comparison (location_t, enum tree_code,
>> tree, tree, tree);
>> static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
>> @@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
>> return lhs;
>> }
>>
>> -/* Subroutine for fold_truthop: decode a field reference.
>> +/* Subroutine for fold_truth_andor_1: decode a field reference.
>>
>> If EXP is a comparison reference, we return the innermost reference.
>>
>> @@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
>> return NULL_TREE;
>> }
>>
>> -/* Subroutine for fold_truthop: determine if an operand is simple enough
>> +/* Subroutine for fold_truth_andor_1: determine if an operand is simple
>> enough
>> to be evaluated unconditionally. */
>>
>> static int
>> -simple_operand_p (const_tree exp)
>> +simple_operand_p (tree exp)
>> {
>> + enum tree_code code;
>> /* Strip any conversions that don't change the machine mode. */
>> STRIP_NOPS (exp);
>>
>> + code = TREE_CODE (exp);
>> +
>> + /* Handle some trivials */
>> + if (TREE_CODE_CLASS (code) == tcc_comparison)
>> + return (tree_could_trap_p (exp)
>> + && simple_operand_p (TREE_OPERAND (exp, 0))
>> + && simple_operand_p (TREE_OPERAND (exp, 1)));
>
> And that's still wrong.
>
> Stopped reading here.
>
> Richard.
Oh, there is a not missing. I didn't spot that, sorry.
To the point why we need to handle comparisons within simple_operand_p.
If we reject comparisons and logical not here, we won't have any
branching optimization anymore, as this the patch moves into
fold_truthandor.
The result with rejecting in simple_operand_p compares and logic-not
provides for the following example:
extern int doo (void);
extern int doo2 (void);
int foo (int a, int b, int c, int d, int e, int f)
{
if (a && b && c && d && e && f)
return doo ();
return doo2 ();
}
we get the following gimple dump (-fdump-tree-gimple):
foo (int a, int b, int c, int d, int e, int f)
{
int D.2752;
if (a != 0) goto ; else goto ;
:
if (b != 0) goto ; else goto ;
:
if (c != 0) goto ; else goto ;
:
if (d != 0) goto ; else goto ;
:
if (e != 0) goto ; else goto ;
:
if (f != 0) goto ; else goto ;
:
D.2752 = doo ();
return D.2752;
:
:
:
:
:
:
D.2752 = doo2 ();
return D.2752;
}
So this result is caused by the fact that a logical-and/or is always a
comparison. As we are rejecting comparisons/logical-not, we end up
with a sequence of TRUTH_(AND|OR)_IFs. So the hole loop in
fold_truth_andor for trying to pack simple and side-effect-less
operands in tupels of two is useless.
For the new patch (attached with proper ! fix for compares) we get for
the same sample gimple output:
foo (int a, int b, int c, int d, int e, int f)
{
_Bool D.2740;
_Bool D.2741;
_Bool D.2742;
_Bool D.2745;
_Bool D.2746;
_Bool D.2747;
_Bool D.2750;
_Bool D.2751;
_Bool D.2752;
int D.2755;
D.2740 = a != 0;
D.2741 = b != 0;
D.2742 = D.2740 & D.2741;
if (D.2742 != 0) goto ; else goto ;
:
D.2745 = c != 0;
D.2746 = d != 0;
D.2747 = D.2745 & D.2746;
if (D.2747 != 0) goto ; else goto ;
:
D.2750 = e != 0;
D.2751 = f != 0;
D.2752 = D.2750 & D.2751;
if (D.2752 != 0) goto ; else goto ;
:
D.2755 = doo ();
return D.2755;
:
:
:
D.2755 = doo2 ();
return D.2755;
}
which is the proper output for high branching cost, as it tries to
avoid branches and not to tend them.
--
Kai
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -111,14 +111,13 @@ static tree decode_field_reference (loca
Re: [PATCH 1/5] Use MADV_DONTNEED for freeing in garbage collector
> Shouldn't we prefer still "mapped" pages when allocating? Thus, keep > the freepages list "sorted"? Possibly. I can look at it in a followup if you want. I would prefer to not complicate this patch too much. > > With the new params to call release_pages less, how does this > interact with using MADV_DONTNEED? The only reason to delay > MADV_DONTNEED is to avoid splitting huge-pages? Which would > mean that we should rather be better at controlling where we allocate > from from the free-list? I first had a patch that tried to cluster inside the freelist with multiple passes (and only free aligned quire clusters first), but it ran into various problems, so I chose this simpler approach. With MADV_DONTNEED the param is not really needed I think, I mainly added the param for the benefit of hosts that don't have MADV_DONTNEED to let them not suffer from fragmentation too much. It would be possible to set the thresholds all to 0 if MADV_DONTNEED is available. -Andi
Re: [PATCH 4/5] Add a freeing threshold for the garbage collector.
On Mon, Oct 10, 2011 at 12:20:53PM +0200, Richard Guenther wrote: > On Sun, Oct 9, 2011 at 9:55 PM, Andi Kleen wrote: > > From: Andi Kleen > > > > Add a threshold to avoid freeing pages back too early to the OS. > > This avoid virtual memory map fragmentation. > > > > Based on a idea from Honza > > Less than 20% looks high. Shouldn't ggc-free-min be enough to > avoid fragmentation? It depends on the working set. If there's more to garbage collect than max(ggc-free-min, threshold*total) a host without MADV_DONTNEED will get holes. And ggc-free-min isn't very much on a large build. So it seems safer to me to have a threshold which adjusts for large working sets. What value do you prefer instead of 20%? (or just 0) > > This will hide gc bugs with always-collect (ggc-checking), so > the parameter(s) need to be adjusted for that case to always > give pages back. The current values should probably be printed > where the two existing ones are printed as well (with -v). Will fix. -Andi
Re: [PATCH 3/5] On a Linux kernel ask explicitely for a huge page in ggc
On Mon, Oct 10, 2011 at 12:29:03PM +0200, Jakub Jelinek wrote: > On Mon, Oct 10, 2011 at 12:15:14PM +0200, Richard Guenther wrote: > > On Sun, Oct 9, 2011 at 9:55 PM, Andi Kleen wrote: > > > From: Andi Kleen > > > > > > Benchmarks show slightly faster build times on a kernel > > > build, near the measurement error unfortunately. > > > > > > This will only work with a recent glibc that defines MADV_HUGEPAGE. > > > > Will partial unmaps fail or split the page? > > I think it will not do anything, because with G.pagesize * GGC_QUIRE_SIZE On large builds (LTO) I see the vmstat THP counter increasing, it doesn't do too much on small builds. > being just 2MB (and most likely not 2MB aligned either) it would do > something only if it happens to be 2MB aligned or the following VMA > is also MADV_HUGEPAGE hinted and no pages in the 2MB region have been > paged in yet. > So, either we need to ensure that the address is likely 2MB aligned, > or use on x86_64 even bigger GGC_QUIRE_SIZE (such as 16MB or 32MB) and > then huge pages would be likely used at least for the aligned inner > huge pages in the region. Hmm, that gets too complicated for mee. I'll drop the patch for now. It's not strictly needed to fix the fragmentation problem and it's also possible to force THP from the kernel. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [PATCH 2/5] Increase the GGC quite size to 2MB
> From: Andi Kleen > > Using 2MB allows modern kernels to use 2MB huge pages on x86. > > gcc/: > > 2011-10-08 Andi Kleen > > * ggc-page.c (GGC_QUIRE_SIZE): Increase to 512 > --- > gcc/ggc-page.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c > index b0b3b3f..1f52b56 100644 > --- a/gcc/ggc-page.c > +++ b/gcc/ggc-page.c > @@ -469,7 +469,7 @@ static struct globals > can override this by defining GGC_QUIRE_SIZE explicitly. */ > #ifndef GGC_QUIRE_SIZE > # ifdef USING_MMAP > -# define GGC_QUIRE_SIZE 256 > +# define GGC_QUIRE_SIZE 512 /* 2MB for 4K pages */ Perhaps comment that 2MB was chosen to help Kernel huge pages logic? Honza > # else > # define GGC_QUIRE_SIZE 16 > # endif > -- > 1.7.5.4
Re: [PATCH 3/5] On a Linux kernel ask explicitely for a huge page in ggc
On Mon, Oct 10, 2011 at 12:15:14PM +0200, Richard Guenther wrote: > On Sun, Oct 9, 2011 at 9:55 PM, Andi Kleen wrote: > > From: Andi Kleen > > > > Benchmarks show slightly faster build times on a kernel > > build, near the measurement error unfortunately. > > > > This will only work with a recent glibc that defines MADV_HUGEPAGE. > > Will partial unmaps fail or split the page? They split the page. -Andi
Re: [PATCH] Mark static const strings as read-only.
> The patch makes sure that the src_mem computed here in > expand_builtin_memcpy is marked as MEM_READONLY_P: > ... > src_mem = get_memory_rtx (src, len); > ... > > build and reg-tested on i686, arm, and mips. > > OK for trunk? Do you get the same result by calling gen_const_mem from build_constant_desc instead of gen_rtx_MEM? If so, this would be better I think. -- Eric Botcazou
Re: patch ping: thread testing infrastructure
On 10/07/11 17:50, Mike Stump wrote: On Oct 7, 2011, at 2:52 PM, Aldy Hernandez wrote: First, thanks so much for tackling this review. I don't think anyone's overly enthusiastic about reviewing dejagnu crap^H^H^H^Hcode. I'll review it. :-) The last version looks fine to me, watch out for failures. How do you like this approach? Ok. Thank you. Tested on x86-64 Linux and committed. I will now adjust the cxx-memory-model branch accordingly and merge these changes into the branch. Aldy
Re: Avoid double mangling at WHOPR
> Can you try the "obvious" and simply mangle all local statics at > partitioning time? (leaving the non-conflict case for a further > improvement) Hmm, it needs to be done with non-WHOPR too, but sure I can give it a try. I should however finally push out the weakref bits. (here one can produce weakref of static that is bit nonsential but possible and that breaks at renaming time). Will try to look into that today. Will lto-symtab be happy about this? Honza > > Richard.
Re: Avoid double mangling at WHOPR
On Mon, 10 Oct 2011, Jan Hubicka wrote: > > > Actually it seems to me that mangling at WPA makes more sense - you don't > > > get > > > symbol name sensitive on partitioning decisions so things go a bit more > > > consistently. Partitioning depends on global properties of program so any > > > code > > > that depends on particular partitioning decisions will have tendency to > > > randomly break and unbreak. > > > > > > We can not really make any promises about our ability to not mangle > > > particular > > > symbol (for use in asm code or whatever): we need to mangle on the > > > occasion of > > > conflict with another static symbol but also when we decide to promote it > > > hidden. We have no information about another hidden symbol in the non-LTO > > > world. Either linker plugin API needs to be extended by providing us > > > with list > > > of forbidden names or ability to have "hidden in LTO world" visibility or > > > we > > > probably need to start using random seeds on all promoted symbols. > > > (in fact I already do sort of mangling to avoid conflict on comdats that > > > has been > > > brought local and then again promoted global, I just did not noticed it > > > is a general > > > problem back then when I first saw the linker complaining). > > > > Ok, I see why it makes sense on WPA time. But then why not mangle > > during partitioning? I think it still makes sense to avoid mangling local > > decls, if not for debugging experience. > > Yeah, we could do that. Debugging experience is quite good reason (though it > will > also make bogus asm statements magically work and break on random basis. In a > way > just breaking them seems more sensible behaviour to me ;) ). ;) > > We do mangle late when we bring symbols local anyway, no? I also > > seem to remember we mangle at LTO time, too ... > > Hmm, I think we mangle at stream in since we do make hashtables based on > symbol names > that are supposed to be unique, but perhaps I am wrong. I think we do not hash local symbols, so that shouldn't be an issue. > LTO time you mean at compilation time when streaming out? I am not aware of > that. Maybe that changed then or I misremember. Can you try the "obvious" and simply mangle all local statics at partitioning time? (leaving the non-conflict case for a further improvement) Richard.
[Patch,AVR]: Reuse __tablejump2__
This patch does better re-usage of __tablejump2__ from libgcc so that switch/case statements with jump tables become smaller because the sequence needs 6 to 9 words compared to 2 when JMPing to __tablejump2__. Moreover, __tablejump2__ does no more rely in the content of EIND (by using EIJMP) and uses RET instead. The insn conditions of tablejump insns now are the same as in avr_output_addr_vec_elt. Ok for trunk? Johann * config/avr/avr.md (*tablejump_rjmp): Change insn condition to !AVR_HAVE_JMP_CALL. (*tablejump_lib): Change insn condition to AVR_HAVE_JMP_CALL. (*tablejump_enh, *tablejump): Remove insns. * config/avr/libgcc.S (__tablejump__): Use RET instead of EIND + EIJM for indirect jump. Use LPM Z+ where available. Index: config/avr/libgcc.S === --- config/avr/libgcc.S (revision 179744) +++ config/avr/libgcc.S (working copy) @@ -821,13 +821,17 @@ ENDF __tablejump2__ DEFUN __tablejump__ #if defined (__AVR_HAVE_LPMX__) +#if defined (__AVR_HAVE_EIJMP_EICALL__) + lpm __tmp_reg__, Z+ + push __tmp_reg__ + lpm __tmp_reg__, Z + push __tmp_reg__ + push __zero_reg__ + ret +#else lpm __tmp_reg__, Z+ lpm r31, Z mov r30, __tmp_reg__ - -#if defined (__AVR_HAVE_EIJMP_EICALL__) - eijmp -#else ijmp #endif Index: config/avr/avr.md === --- config/avr/avr.md (revision 179744) +++ config/avr/avr.md (working copy) @@ -3719,62 +3719,36 @@ (define_insn "*indirect_jump_avr6" (set_attr "cc" "none")]) ;; table jump +;; For entries in jump table see avr_output_addr_vec_elt. -;; Table made from "rjmp" instructions for <=8K devices. +;; Table made from "rjmp .L" instructions for <= 8K devices. (define_insn "*tablejump_rjmp" - [(set (pc) (unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r")] - UNSPEC_INDEX_JMP)) + [(set (pc) +(unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r")] + UNSPEC_INDEX_JMP)) (use (label_ref (match_operand 1 "" ""))) (clobber (match_dup 0))] - "(!AVR_HAVE_JMP_CALL) && (!AVR_HAVE_EIJMP_EICALL)" + "!AVR_HAVE_JMP_CALL" "@ ijmp push %A0\;push %B0\;ret" [(set_attr "length" "1,3") (set_attr "cc" "none,none")]) -;; Not a prologue, but similar idea - move the common piece of code to libgcc. +;; Move the common piece of code to libgcc. +;; Table made from ".word gs(.L)" addresses for > 8K devices. +;; Read jump address from table and perform indirect jump. (define_insn "*tablejump_lib" - [(set (pc) (unspec:HI [(match_operand:HI 0 "register_operand" "z")] - UNSPEC_INDEX_JMP)) + [(set (pc) +(unspec:HI [(match_operand:HI 0 "register_operand" "z")] + UNSPEC_INDEX_JMP)) (use (label_ref (match_operand 1 "" ""))) (clobber (match_dup 0))] - "AVR_HAVE_JMP_CALL && TARGET_CALL_PROLOGUES" - "%~jmp __tablejump2__" + "AVR_HAVE_JMP_CALL" + "jmp __tablejump2__" [(set_attr "length" "2") (set_attr "cc" "clobber")]) -(define_insn "*tablejump_enh" - [(set (pc) (unspec:HI [(match_operand:HI 0 "register_operand" "z")] - UNSPEC_INDEX_JMP)) - (use (label_ref (match_operand 1 "" ""))) - (clobber (match_dup 0))] - "AVR_HAVE_JMP_CALL && AVR_HAVE_LPMX" - "lsl r30 - rol r31 - lpm __tmp_reg__,Z+ - lpm r31,Z - mov r30,__tmp_reg__ - %!ijmp" - [(set_attr "length" "6") - (set_attr "cc" "clobber")]) - -(define_insn "*tablejump" - [(set (pc) (unspec:HI [(match_operand:HI 0 "register_operand" "z")] - UNSPEC_INDEX_JMP)) - (use (label_ref (match_operand 1 "" ""))) - (clobber (match_dup 0))] - "AVR_HAVE_JMP_CALL && !AVR_HAVE_EIJMP_EICALL" - "lsl r30 - rol r31 - lpm - inc r30 - push r0 - lpm - push r0 - ret" - [(set_attr "length" "8") - (set_attr "cc" "clobber")]) (define_expand "casesi" [(set (match_dup 6)
Re: Avoid double mangling at WHOPR
> > Actually it seems to me that mangling at WPA makes more sense - you don't > > get > > symbol name sensitive on partitioning decisions so things go a bit more > > consistently. Partitioning depends on global properties of program so any > > code > > that depends on particular partitioning decisions will have tendency to > > randomly break and unbreak. > > > > We can not really make any promises about our ability to not mangle > > particular > > symbol (for use in asm code or whatever): we need to mangle on the > > occasion of > > conflict with another static symbol but also when we decide to promote it > > hidden. We have no information about another hidden symbol in the non-LTO > > world. Either linker plugin API needs to be extended by providing us with > > list > > of forbidden names or ability to have "hidden in LTO world" visibility or we > > probably need to start using random seeds on all promoted symbols. > > (in fact I already do sort of mangling to avoid conflict on comdats that > > has been > > brought local and then again promoted global, I just did not noticed it is > > a general > > problem back then when I first saw the linker complaining). > > Ok, I see why it makes sense on WPA time. But then why not mangle > during partitioning? I think it still makes sense to avoid mangling local > decls, if not for debugging experience. Yeah, we could do that. Debugging experience is quite good reason (though it will also make bogus asm statements magically work and break on random basis. In a way just breaking them seems more sensible behaviour to me ;) ). > > We do mangle late when we bring symbols local anyway, no? I also > seem to remember we mangle at LTO time, too ... Hmm, I think we mangle at stream in since we do make hashtables based on symbol names that are supposed to be unique, but perhaps I am wrong. LTO time you mean at compilation time when streaming out? I am not aware of that. Honza > > Richard.
Re: New warning for expanded vector operations
On Mon, Oct 10, 2011 at 12:02 PM, Richard Guenther
wrote:
> On Fri, Oct 7, 2011 at 9:44 AM, Artem Shinkarov
> wrote:
>> On Fri, Oct 7, 2011 at 6:22 AM, Artem Shinkarov
>> wrote:
>>> On Wed, Oct 5, 2011 at 12:35 PM, Richard Guenther
>>> wrote:
On Wed, Oct 5, 2011 at 1:28 PM, Artem Shinkarov
wrote:
> On Wed, Oct 5, 2011 at 9:40 AM, Richard Guenther
> wrote:
>> On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
>> wrote:
>>> Hi
>>>
>>> Here is a patch to inform a programmer about the expanded vector
>>> operation.
>>> Bootstrapped on x86-unknown-linux-gnu.
>>>
>>> ChangeLog:
>>>
>>> * gcc/tree-vect-generic.c (expand_vector_piecewise): Adjust to
>>> produce the warning.
>>> (expand_vector_parallel): Adjust to produce the warning.
>>
>> Entries start without gcc/, they are relative to the gcc/ChangeLog file.
>
> Sure, sorry.
>
>>> (lower_vec_shuffle): Adjust to produce the warning.
>>> * gcc/common.opt: New warning Wvector-operation-expanded.
>>> * gcc/doc/invoke.texi: Document the wawning.
>>>
>>>
>>> Ok?
>>
>> I don't like the name -Wvector-operation-expanded. We emit a
>> similar warning for missed inline expansions with -Winline, so
>> maybe -Wvector-extensions (that's the name that appears
>> in the C extension documentation).
>
> Hm, I don't care much about the name, unless it gets clear what the
> warning is used for. I am not really sure that Wvector-extensions
> makes it clear. Also, I don't see anything bad if the warning will
> pop up during the vectorisation. Any vector operation performed
> outside the SIMD accelerator looks suspicious, because it actually
> doesn't improve performance. Such a warning during the vectorisation
> could mean that a programmer forgot some flag, or the constant
> propagation failed to deliver a constant, or something else.
>
> Conceptually the text I am producing is not really a warning, it is
> more like an information, but I am not aware of the mechanisms that
> would allow me to introduce a flag triggering inform () or something
> similar.
>
> What I think we really need to avoid is including this warning in the
> standard Ox.
>
>> + location_t loc = gimple_location (gsi_stmt (*gsi));
>> +
>> + warning_at (loc, OPT_Wvector_operation_expanded,
>> + "vector operation will be expanded piecewise");
>>
>> v = VEC_alloc(constructor_elt, gc, (nunits + delta - 1) / delta);
>> for (i = 0; i < nunits;
>> @@ -260,6 +264,10 @@ expand_vector_parallel (gimple_stmt_iter
>> tree result, compute_type;
>> enum machine_mode mode;
>> int n_words = tree_low_cst (TYPE_SIZE_UNIT (type), 1) / UNITS_PER_WORD;
>> + location_t loc = gimple_location (gsi_stmt (*gsi));
>> +
>> + warning_at (loc, OPT_Wvector_operation_expanded,
>> + "vector operation will be expanded in parallel");
>>
>> what's the difference between 'piecewise' and 'in parallel'?
>
> Parallel is a little bit better for performance than piecewise.
I see. That difference should probably be documented, maybe with
an example.
Richard.
>> @@ -301,16 +309,15 @@ expand_vector_addition (gimple_stmt_iter
>> {
>> int parts_per_word = UNITS_PER_WORD
>> / tree_low_cst (TYPE_SIZE_UNIT (TREE_TYPE (type)),
>> 1);
>> + location_t loc = gimple_location (gsi_stmt (*gsi));
>>
>> if (INTEGRAL_TYPE_P (TREE_TYPE (type))
>> && parts_per_word >= 4
>> && TYPE_VECTOR_SUBPARTS (type) >= 4)
>> - return expand_vector_parallel (gsi, f_parallel,
>> - type, a, b, code);
>> + return expand_vector_parallel (gsi, f_parallel, type, a, b, code);
>> else
>> - return expand_vector_piecewise (gsi, f,
>> - type, TREE_TYPE (type),
>> - a, b, code);
>> + return expand_vector_piecewise (gsi, f, type,
>> + TREE_TYPE (type), a, b, code);
>> }
>>
>> /* Check if vector VEC consists of all the equal elements and
>>
>> unless i miss something loc is unused here. Please avoid random
>> whitespace changes (just review your patch yourself before posting
>> and revert pieces that do nothing).
>
> Yes you are right, sorry.
>
>> +@item -Wvector-operation-expanded
>> +@opindex Wvector-operation-expanded
>> +@opindex Wno-vector-operation-expanded
>> +Warn if vector operation is not implemented via SIMD capabilities of the
>> +architecture. Mainly useful for the performance tuning.
>>
>> I'd mention that this is for vector operations as of the C extension
Re: Avoid double mangling at WHOPR
On Mon, 10 Oct 2011, Jan Hubicka wrote: > > On Sun, 9 Oct 2011, Jan Hubicka wrote: > > > > > Hi, > > > whopr currently produce local_static.1234.43124 type symbols. This is > > > because > > > everything gets mangled at WPA time and then again at ltrans time. This > > > simply > > > avoids the second mangling. This save some space & makes WHOPR/non_WHOPR > > > symbol > > > tables comparable more directly. > > > > > > Bootstrapped/regtested x86_64-linux, also tested with Mozilla LTO, OK? > > > > Hmmm. I'd really like to defer mangling to LTRANS at one point, as > > we will know if there will be conflicts of local symbols at that point > > (another point would be the partitioning code). So this patch goes > > backward ... (ideally a first step would move it to symbol resolution > > time, another place where we can check for conflicts, and then only > > apply it a LTRANs stage). > > Actually it seems to me that mangling at WPA makes more sense - you don't get > symbol name sensitive on partitioning decisions so things go a bit more > consistently. Partitioning depends on global properties of program so any code > that depends on particular partitioning decisions will have tendency to > randomly break and unbreak. > > We can not really make any promises about our ability to not mangle particular > symbol (for use in asm code or whatever): we need to mangle on the occasion > of > conflict with another static symbol but also when we decide to promote it > hidden. We have no information about another hidden symbol in the non-LTO > world. Either linker plugin API needs to be extended by providing us with > list > of forbidden names or ability to have "hidden in LTO world" visibility or we > probably need to start using random seeds on all promoted symbols. > (in fact I already do sort of mangling to avoid conflict on comdats that has > been > brought local and then again promoted global, I just did not noticed it is a > general > problem back then when I first saw the linker complaining). Ok, I see why it makes sense on WPA time. But then why not mangle during partitioning? I think it still makes sense to avoid mangling local decls, if not for debugging experience. We do mangle late when we bring symbols local anyway, no? I also seem to remember we mangle at LTO time, too ... Richard.
Re: Avoid double mangling at WHOPR
> On Sun, 9 Oct 2011, Jan Hubicka wrote: > > > Hi, > > whopr currently produce local_static.1234.43124 type symbols. This is > > because > > everything gets mangled at WPA time and then again at ltrans time. This > > simply > > avoids the second mangling. This save some space & makes WHOPR/non_WHOPR > > symbol > > tables comparable more directly. > > > > Bootstrapped/regtested x86_64-linux, also tested with Mozilla LTO, OK? > > Hmmm. I'd really like to defer mangling to LTRANS at one point, as > we will know if there will be conflicts of local symbols at that point > (another point would be the partitioning code). So this patch goes > backward ... (ideally a first step would move it to symbol resolution > time, another place where we can check for conflicts, and then only > apply it a LTRANs stage). Actually it seems to me that mangling at WPA makes more sense - you don't get symbol name sensitive on partitioning decisions so things go a bit more consistently. Partitioning depends on global properties of program so any code that depends on particular partitioning decisions will have tendency to randomly break and unbreak. We can not really make any promises about our ability to not mangle particular symbol (for use in asm code or whatever): we need to mangle on the occasion of conflict with another static symbol but also when we decide to promote it hidden. We have no information about another hidden symbol in the non-LTO world. Either linker plugin API needs to be extended by providing us with list of forbidden names or ability to have "hidden in LTO world" visibility or we probably need to start using random seeds on all promoted symbols. (in fact I already do sort of mangling to avoid conflict on comdats that has been brought local and then again promoted global, I just did not noticed it is a general problem back then when I first saw the linker complaining). Honza
Re: Ping^3: PR middle-end/48660: Assigning to BLKmode RESULT_DECL
On Mon, Oct 10, 2011 at 2:35 PM, Richard Sandiford wrote: > Ping for: > > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00558.html > > which fixes an expand-time bug in thunks that return BLKmode structures > in registers. Tested on x86_64-linux-gnu and arm-linux-gnueabi. Ok with the changes suggested by Micha. Richard. > Thanks, > Richard >
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz wrote:
> Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
> has to be checked that the LHS code is same as outer CODE, as
> otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
> LHS, which is of course wrong.
>
> Index: gcc/gcc/fold-const.c
> ===
> --- gcc.orig/gcc/fold-const.c
> +++ gcc/gcc/fold-const.c
> @@ -111,14 +111,13 @@ static tree decode_field_reference (loca
> tree *, tree *);
> static int all_ones_mask_p (const_tree, int);
> static tree sign_bit_p (tree, const_tree);
> -static int simple_operand_p (const_tree);
> +static int simple_operand_p (tree);
> static tree range_binop (enum tree_code, tree, tree, int, tree, int);
> static tree range_predecessor (tree);
> static tree range_successor (tree);
> static tree fold_range_test (location_t, enum tree_code, tree, tree, tree);
> static tree fold_cond_expr_with_comparison (location_t, tree, tree,
> tree, tree);
> static tree unextend (tree, int, int, tree);
> -static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
> static tree optimize_minmax_comparison (location_t, enum tree_code,
> tree, tree, tree);
> static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
> @@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
> return lhs;
> }
>
> -/* Subroutine for fold_truthop: decode a field reference.
> +/* Subroutine for fold_truth_andor_1: decode a field reference.
>
> If EXP is a comparison reference, we return the innermost reference.
>
> @@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
> return NULL_TREE;
> }
>
> -/* Subroutine for fold_truthop: determine if an operand is simple enough
> +/* Subroutine for fold_truth_andor_1: determine if an operand is simple
> enough
> to be evaluated unconditionally. */
>
> static int
> -simple_operand_p (const_tree exp)
> +simple_operand_p (tree exp)
> {
> + enum tree_code code;
> /* Strip any conversions that don't change the machine mode. */
> STRIP_NOPS (exp);
>
> + code = TREE_CODE (exp);
> +
> + /* Handle some trivials */
> + if (TREE_CODE_CLASS (code) == tcc_comparison)
> + return (tree_could_trap_p (exp)
> + && simple_operand_p (TREE_OPERAND (exp, 0))
> + && simple_operand_p (TREE_OPERAND (exp, 1)));
And that's still wrong.
Stopped reading here.
Richard.
> + if (FLOAT_TYPE_P (TREE_TYPE (exp))
> + && tree_could_trap_p (exp))
> + return false;
> +
> + switch (code)
> + {
> + case SSA_NAME:
> + return true;
> + case TRUTH_NOT_EXPR:
> + return simple_operand_p (TREE_OPERAND (exp, 0));
> + case BIT_NOT_EXPR:
> + if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE)
> + return false;
> + return simple_operand_p (TREE_OPERAND (exp, 0));
> + default:
> + break;
> + }
> +
> return (CONSTANT_CLASS_P (exp)
> - || TREE_CODE (exp) == SSA_NAME
> || (DECL_P (exp)
> && ! TREE_ADDRESSABLE (exp)
> && ! TREE_THIS_VOLATILE (exp)
> @@ -4888,7 +4913,7 @@ fold_range_test (location_t loc, enum tr
> return 0;
> }
>
> -/* Subroutine for fold_truthop: C is an INTEGER_CST interpreted as a P
> +/* Subroutine for fold_truth_andor_1: C is an INTEGER_CST interpreted as a P
> bit value. Arrange things so the extra bits will be set to zero if and
> only if C is signed-extended to its full width. If MASK is nonzero,
> it is an INTEGER_CST that should be AND'ed with the extra bits. */
> @@ -5025,8 +5050,8 @@ merge_truthop_with_opposite_arm (locatio
> We return the simplified tree or 0 if no optimization is possible. */
>
> static tree
> -fold_truthop (location_t loc, enum tree_code code, tree truth_type,
> - tree lhs, tree rhs)
> +fold_truth_andor_1 (location_t loc, enum tree_code code, tree truth_type,
> + tree lhs, tree rhs)
> {
> /* If this is the "or" of two comparisons, we can do something if
> the comparisons are NE_EXPR. If this is the "and", we can do something
> @@ -5054,8 +5079,6 @@ fold_truthop (location_t loc, enum tree_
> tree lntype, rntype, result;
> HOST_WIDE_INT first_bit, end_bit;
> int volatilep;
> - tree orig_lhs = lhs, orig_rhs = rhs;
> - enum tree_code orig_code = code;
>
> /* Start by getting the comparison codes. Fail if anything is volatile.
> If one operand is a BIT_AND_EXPR with the constant one, treat it as if
> @@ -5119,8 +5142,7 @@ fold_truthop (location_t loc, enum tree_
> /* If the RHS can be evaluated unconditionally and its operands are
> simple, it wins to evaluate the RHS unconditionally on machines
> with expensive branches. In this case, this isn't a comparison
> - that can be merged. Avoid doing this if the RHS is a floating-point
> - comparison since those can trap. */
> + th
Re: [C++ Patch / RFC] PR 33067
On 10/10/2011 02:13 PM, Paolo Carlini wrote:
. looks like we want to do something else, not printing the number at
all. See audit trail.
An option, for 4.7 at least, would be, instead of just closing 33067 as
a duplicate of the much more general 49152, doing something like:
Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c (revision 179745)
+++ c-family/c-pretty-print.c (working copy)
@@ -1019,7 +1019,7 @@ static void
pp_c_floating_constant (c_pretty_printer *pp, tree r)
{
real_to_decimal (pp_buffer (pp)->digit_buffer, &TREE_REAL_CST (r),
- sizeof (pp_buffer (pp)->digit_buffer), 0, 1);
+ sizeof (pp_buffer (pp)->digit_buffer), 6, 1);
pp_string (pp, pp_buffer(pp)->digit_buffer);
if (TREE_TYPE (r) == float_type_node)
pp_character (pp, 'f');
which gives:
33067.C:2:18: error: no match for ‘operator<’ in ‘1.1e+0 < t’
Given in particular that we now have column numbers, as a user of GCC I
would certainly consider it a good improvement.
Just let me know...
Paolo.
Ping^3: PR middle-end/48660: Assigning to BLKmode RESULT_DECL
Ping for: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00558.html which fixes an expand-time bug in thunks that return BLKmode structures in registers. Tested on x86_64-linux-gnu and arm-linux-gnueabi. Thanks, Richard
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
has to be checked that the LHS code is same as outer CODE, as
otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
LHS, which is of course wrong.
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -111,14 +111,13 @@ static tree decode_field_reference (loca
tree *, tree *);
static int all_ones_mask_p (const_tree, int);
static tree sign_bit_p (tree, const_tree);
-static int simple_operand_p (const_tree);
+static int simple_operand_p (tree);
static tree range_binop (enum tree_code, tree, tree, int, tree, int);
static tree range_predecessor (tree);
static tree range_successor (tree);
static tree fold_range_test (location_t, enum tree_code, tree, tree, tree);
static tree fold_cond_expr_with_comparison (location_t, tree, tree,
tree, tree);
static tree unextend (tree, int, int, tree);
-static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
static tree optimize_minmax_comparison (location_t, enum tree_code,
tree, tree, tree);
static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
@@ -3500,7 +3499,7 @@ optimize_bit_field_compare (location_t l
return lhs;
}
-/* Subroutine for fold_truthop: decode a field reference.
+/* Subroutine for fold_truth_andor_1: decode a field reference.
If EXP is a comparison reference, we return the innermost reference.
@@ -3668,17 +3667,43 @@ sign_bit_p (tree exp, const_tree val)
return NULL_TREE;
}
-/* Subroutine for fold_truthop: determine if an operand is simple enough
+/* Subroutine for fold_truth_andor_1: determine if an operand is simple enough
to be evaluated unconditionally. */
static int
-simple_operand_p (const_tree exp)
+simple_operand_p (tree exp)
{
+ enum tree_code code;
/* Strip any conversions that don't change the machine mode. */
STRIP_NOPS (exp);
+ code = TREE_CODE (exp);
+
+ /* Handle some trivials */
+ if (TREE_CODE_CLASS (code) == tcc_comparison)
+return (tree_could_trap_p (exp)
+ && simple_operand_p (TREE_OPERAND (exp, 0))
+ && simple_operand_p (TREE_OPERAND (exp, 1)));
+
+ if (FLOAT_TYPE_P (TREE_TYPE (exp))
+ && tree_could_trap_p (exp))
+return false;
+
+ switch (code)
+{
+case SSA_NAME:
+ return true;
+case TRUTH_NOT_EXPR:
+ return simple_operand_p (TREE_OPERAND (exp, 0));
+case BIT_NOT_EXPR:
+ if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE)
+return false;
+ return simple_operand_p (TREE_OPERAND (exp, 0));
+default:
+ break;
+}
+
return (CONSTANT_CLASS_P (exp)
- || TREE_CODE (exp) == SSA_NAME
|| (DECL_P (exp)
&& ! TREE_ADDRESSABLE (exp)
&& ! TREE_THIS_VOLATILE (exp)
@@ -4888,7 +4913,7 @@ fold_range_test (location_t loc, enum tr
return 0;
}
-/* Subroutine for fold_truthop: C is an INTEGER_CST interpreted as a P
+/* Subroutine for fold_truth_andor_1: C is an INTEGER_CST interpreted as a P
bit value. Arrange things so the extra bits will be set to zero if and
only if C is signed-extended to its full width. If MASK is nonzero,
it is an INTEGER_CST that should be AND'ed with the extra bits. */
@@ -5025,8 +5050,8 @@ merge_truthop_with_opposite_arm (locatio
We return the simplified tree or 0 if no optimization is possible. */
static tree
-fold_truthop (location_t loc, enum tree_code code, tree truth_type,
- tree lhs, tree rhs)
+fold_truth_andor_1 (location_t loc, enum tree_code code, tree truth_type,
+ tree lhs, tree rhs)
{
/* If this is the "or" of two comparisons, we can do something if
the comparisons are NE_EXPR. If this is the "and", we can do something
@@ -5054,8 +5079,6 @@ fold_truthop (location_t loc, enum tree_
tree lntype, rntype, result;
HOST_WIDE_INT first_bit, end_bit;
int volatilep;
- tree orig_lhs = lhs, orig_rhs = rhs;
- enum tree_code orig_code = code;
/* Start by getting the comparison codes. Fail if anything is volatile.
If one operand is a BIT_AND_EXPR with the constant one, treat it as if
@@ -5119,8 +5142,7 @@ fold_truthop (location_t loc, enum tree_
/* If the RHS can be evaluated unconditionally and its operands are
simple, it wins to evaluate the RHS unconditionally on machines
with expensive branches. In this case, this isn't a comparison
- that can be merged. Avoid doing this if the RHS is a floating-point
- comparison since those can trap. */
+ that can be merged. */
if (BRANCH_COST (optimize_function_for_speed_p (cfun),
false) >= 2
@@ -5149,13 +5171,6 @@ fold_truthop (location_t loc, enum tree_
build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
ll_arg, rl_arg),
Re: [patch] C6X unwinding/exception handling
> Index: libjava/exception.cc
> ===
> --- libjava/exception.cc (revision 179739)
> +++ libjava/exception.cc (working copy)
> @@ -135,6 +135,7 @@
> {
>_Unwind_Ptr Start;
>_Unwind_Ptr LPStart;
> + _Unwind_Ptr ttype_base;
>const unsigned char *TType;
>const unsigned char *action_table;
>unsigned char ttype_encoding;
> @@ -184,7 +185,7 @@
>_Unwind_Ptr ptr;
>
>ptr = (_Unwind_Ptr) (info->TType - (i * 4));
> - ptr = _Unwind_decode_target2(ptr);
> + ptr = _Unwind_decode_typeinfo_ptr (info->ttype_base, (_Unwind_Word)
> ptr);
>
>return reinterpret_cast(ptr);
> }
> @@ -325,6 +326,7 @@
>
>// Parse the LSDA header.
>p = parse_lsda_header (context, language_specific_data, &info);
> + info.ttype_base = base_of_encoded_value (info.ttype_encoding, context);
> #ifdef HAVE_GETIPINFO
>ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> #else
No. The purpose of my patch was to remove the arm specific code.
The only difference I can see in this bit of code is that libstdc++ uses
base_of_encoded_value/read_encoded_value_with_base whereas libjava uses
context/read_encoded_value.
I expect you want something like the patch below (completely untested).
Paul
Index: exception.cc
===
--- exception.cc(revision 178906)
+++ exception.cc(working copy)
@@ -161,6 +161,11 @@ parse_lsda_header (_Unwind_Context *cont
info->ttype_encoding = *p++;
if (info->ttype_encoding != DW_EH_PE_omit)
{
+#if _GLIBCXX_OVERRIDE_TTYPE_ENCODING
+ /* Older ARM EABI toolchains set this value incorrectly, so use a
+hardcoded OS-specific format. */
+ info->ttype_encoding = _GLIBCXX_OVERRIDE_TTYPE_ENCODING;
+#endif
p = read_uleb128 (p, &tmp);
info->TType = p + tmp;
}
@@ -176,21 +181,6 @@ parse_lsda_header (_Unwind_Context *cont
return p;
}
-#ifdef __ARM_EABI_UNWINDER__
-
-static void **
-get_ttype_entry(_Unwind_Context *, lsda_header_info* info, _uleb128_t i)
-{
- _Unwind_Ptr ptr;
-
- ptr = (_Unwind_Ptr) (info->TType - (i * 4));
- ptr = _Unwind_decode_target2(ptr);
-
- return reinterpret_cast(ptr);
-}
-
-#else
-
static void **
get_ttype_entry (_Unwind_Context *context, lsda_header_info *info, long i)
{
@@ -202,8 +192,6 @@ get_ttype_entry (_Unwind_Context *contex
return reinterpret_cast(ptr);
}
-#endif
-
// Using a different personality function name causes link failures
// when trying to mix code using different exception handling models.
#ifdef SJLJ_EXCEPTIONS
Re: [PATCH] Remove "bogus" g++.dg/init/copy7.C testcase
On Mon, Aug 15, 2011 at 2:42 PM, Richard Guenther wrote:
>
> The g++.dg/init/copy7.C testcase checks whether the C++ frontend
> guards memcpy it emits via a conditional verifying that src != dst
> because calling memcpy with overlapping source / destination is
> not supported.
>
> The testcase is misguided though (and the C++ frontend was, until
> recently) - the middle-end itself will replace aggregate copies
> with memcpy libcalls if it suits - without such conditional.
> As PR39480 shows (the bug that prompted to "fixing" the C++ frontend),
> the "error" was diagnosed by valgrind, not any real memcpy implemenation.
>
> The argument still holds that no reasonable memcpy implementation
> will reject the src == dest case. Arguing about explicit cache
> write-allocation is moot, as you'd still have to handle the
> case of memcpy (&a, &a+1, 1) correctly - and thus any reasonable
> implementation would handle the src == dest case explicitly if
> that is necessary.
>
> Thus, the following simply removes the now FAILing testcase on
> the basis that it never was PASSing really (as my modified
> C testcases in PR50079 show). If we ever encounter a platform
> that fails for memcpy (&a, &a, ...) and we decide it's not the
> platform that is broken we have to invent a fix in the middle-end
> and (conditionally) guard any libcall block moves.
>
> Comments? Ok to commit?
Ping? Richard? Jason?
Thanks,
Richard.
> Thanks,
> Richard.
>
> 2011-08-15 Richard Guenther
>
> PR middle-end/50079
> * g++.dg/init/copy7.C: Remove testcase.
>
> Index: gcc/testsuite/g++.dg/init/copy7.C
> ===
> --- gcc/testsuite/g++.dg/init/copy7.C (revision 177759)
> +++ gcc/testsuite/g++.dg/init/copy7.C (working copy)
> @@ -1,39 +0,0 @@
> -// PR c++/39480
> -// It isn't always safe to call memcpy with identical arguments.
> -// { dg-do run }
> -
> -extern "C" void abort();
> -extern "C" void *
> -memcpy(void *dest, void *src, __SIZE_TYPE__ n)
> -{
> - if (dest == src)
> - abort();
> - else
> - {
> - __SIZE_TYPE__ i;
> - for (i = 0; i < n; i++)
> - ((char *)dest)[i] = ((const char*)src)[i];
> - }
> -}
> -
> -struct A
> -{
> - double d[10];
> -};
> -
> -struct B: public A
> -{
> - char bc;
> -};
> -
> -B b;
> -
> -void f(B *a1, B* a2)
> -{
> - *a1 = *a2;
> -}
> -
> -int main()
> -{
> - f(&b,&b);
> -}
>
Re: [C++ Patch / RFC] PR 33067
. looks like we want to do something else, not printing the number at all. See audit trail. Paolo.
