Re: GCC 4.0.2 RC3
On 9/23/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > On 9/23/05, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > Christian Joensson wrote: > > > > > FAIL: g++.dg/other/profile1.C (test for excess errors) > > > FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors) > > > XPASS: g++.old-deja/g++.other/init5.C execution test > > > FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors) > > > > Do you have g++.log output for these failures? > > sorry, I didn't see this before I just sent off this: > > http://gcc.gnu.org/ml/gcc/2005-09/msg00777.html well, a clean bootstrap (not bubblestrap) is fine... sorry for the noise... -- Cheers, /ChJ
Re: [4.0] version '400p', expected version '400*'
On 9/24/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > On 9/23/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > > Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: > > > LAST_UPDATED: Fri Sep 23 04:57:40 UTC 2005 > > > > Currently, using bubblestrap, in gcc cvs 4.0 branch, I get failures like > > this: > > double-checking this from a clean bootstrap, with LAST_UPDATED: Sat > Sep 24 07:34:57 UTC 2005 well, a clean bootstrap (not bubblestrap) is fine... sorry for the noise... -- Cheers, /ChJ
PATCH RFC: Increase support for restrict qualifier
In gcc 4.0, the restrict qualifier became less useful than in gcc 3.4.
One of the main uses of the restrict qualifier is in scheduling. The
scheduler currently uses only RTL level aliasing information--we
currently have no mechanism for letting the RTL level query the alias
information at the tree level. The RTL level aliasing analysis can
only handle restrict when the RTL level can determine whether a memory
reference is made through a restricted pointer. In gcc 3.4, that
mostly worked. In gcc 4.0, it often fails. It fails because the
gimplification process introduces temporary variables, and those
variables do not carry the restrict qualifier.
I mentioned on IRC that I had a simple patch to let the RTL level
aliasing analysis see the underlying decl, the one with the restrict
qualifier. My original patch was for the 4.0 branch. This is a
version updated for the 4.1 branch.
I'm not proposing to install it yet. I would like to hear from people
with access to some standard benchmarks whether it makes any
difference.
This patch isn't quite right, because it doesn't record underlying
declarations for FIELD_DECLs. I wrote it that way because of concerns
about the different decl structs. Actually I now suspect that that
was a mistake, and that the patch could handle FIELD_DECLs more or
less as written. But, whatever.
If the patch helps on benchmarks I will clean it up and check it in.
If it does not help, I will discard it. Obviously it is only going to
help for benchmarks which use the restrict qualifier. And it is
obviously a short-term fix: the correct long-term fix is to implement
full support for the restrict qualifier at the tree level and to
expose the tree level alias analysis at RTL level. I know that both
are being worked on, but that this work is unlikely to be in the 4.1
release.
This patch passes a bootstrap and testsuite run on i686-pc-linux-gnu.
Any comments are appreciated.
Ian
Index: alias.c
===
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.254
diff -p -u -r1.254 alias.c
--- alias.c 21 Jul 2005 22:34:33 - 1.254
+++ alias.c 25 Sep 2005 09:00:23 -
@@ -395,9 +395,12 @@ find_base_decl (tree t)
if (t == 0 || t == error_mark_node || ! POINTER_TYPE_P (TREE_TYPE (t)))
return 0;
- /* If this is a declaration, return it. */
+ /* If this is a declaration, return the underlying decl. */
if (DECL_P (t))
-return t;
+{
+ tree u = DECL_UNDERLYING_NONSCALAR_DECL (t);
+ return u ? u : t;
+}
/* Handle general expressions. It would be nice to deal with
COMPONENT_REFs here. If we could tell that `a' and `b' were the
Index: gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.154
diff -p -u -r2.154 gimplify.c
--- gimplify.c 24 Sep 2005 16:21:43 - 2.154
+++ gimplify.c 25 Sep 2005 09:00:23 -
@@ -298,6 +298,57 @@ create_artificial_label (void)
return lab;
}
+/* Subroutine for find_single_nonscalar_decl. */
+
+struct find_decl
+{
+ int c;
+ tree decl;
+};
+
+static tree
+find_single_nonscalar_decl_1 (tree *tp, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data)
+{
+ struct find_decl *pfd = (struct find_decl *) data;
+
+ if (DECL_P (*tp)
+ && !INTEGRAL_TYPE_P (TREE_TYPE (*tp))
+ && !SCALAR_FLOAT_TYPE_P (TREE_TYPE (*tp)))
+{
+ ++pfd->c;
+ pfd->decl = *tp;
+}
+
+ return NULL_TREE;
+}
+
+/* Find the single DECL of non-scalar type in the tree T and return
+ it. If there are zero or more than one such DECLs, return
+ NULL. */
+
+static tree
+find_single_nonscalar_decl (tree t)
+{
+ struct find_decl fd;
+
+ fd.c = 0;
+ fd.decl = NULL_TREE;
+ walk_tree (&t, find_single_nonscalar_decl_1, &fd, NULL);
+
+ /* We are only interestd in variables. FIXME: We should probably
+ accept FIELD_DECL here, but it doesn't have the right decl
+ structure. */
+ if (fd.c != 1
+ || TREE_CODE (fd.decl) == FUNCTION_DECL
+ || TREE_CODE (fd.decl) == LABEL_DECL
+ || TREE_CODE (fd.decl) == FIELD_DECL
+ || TREE_CODE (fd.decl) == TYPE_DECL)
+return NULL_TREE;
+
+ return fd.decl;
+}
+
/* Create a new temporary name with PREFIX. Returns an identifier. */
static GTY(()) unsigned int tmp_var_id_num;
@@ -470,6 +521,18 @@ internal_get_tmp_var (tree val, tree *pr
t = lookup_tmp_var (val, is_formal);
+ if (is_formal)
+{
+ tree u = find_single_nonscalar_decl (val);
+
+ if (u && DECL_UNDERLYING_NONSCALAR_DECL (u))
+ u = DECL_UNDERLYING_NONSCALAR_DECL (u);
+ gcc_assert (!DECL_UNDERLYING_NONSCALAR_DECL (t)
+ || DECL_UNDERLYING_NONSCALAR_DECL (t) == u);
+ if (u && lang_hooks.types_compatible_p (TREE_TYPE (u), TREE_TYPE (t)))
+ DECL_UNDERLYING_NONSCALAR_DECL (t) = u;
+}
+
if (TREE_CODE (TREE_TYPE (t)) == COMPLEX_TY
Re: PATCH RFC: Increase support for restrict qualifier
Ian Lance Taylor writes:
> I mentioned on IRC that I had a simple patch to let the RTL level
> aliasing analysis see the underlying decl, the one with the restrict
> qualifier. My original patch was for the 4.0 branch. This is a
> version updated for the 4.1 branch.
I forgot to add the effects. For this test case:
void
copy (int * __restrict p, const int * __restrict q, unsigned int n)
{
unsigned int i;
for (i = 0; i < n; ++i)
{
p[0] = q[0];
p[1] = q[1];
p[2] = q[2];
p[3] = q[3];
p += 4;
q += 4;
}
}
compiled with -O2 -fschedule-insns on i686-pc-linux-gnu, the unpatched
compiler generates this code in the loop:
movl(%edx), %eax
incl%ebx
movl%eax, (%ecx)
movl4(%edx), %eax
movl%eax, 4(%ecx)
movl8(%edx), %eax
movl%eax, 8(%ecx)
movl12(%edx), %eax
addl$16, %edx
movl%eax, 12(%ecx)
addl$16, %ecx
The patched compiler generates this code:
movl4(%esi), %eax
movl(%esi), %ebx
movl8(%esi), %edx
movl12(%esi), %ecx
addl$16, %esi
incl-16(%ebp)
movl%eax, 4(%edi)
movl%ebx, (%edi)
movl-16(%ebp), %eax
movl%edx, 8(%edi)
movl%ecx, 12(%edi)
addl$16, %edi
In the unpatched compiler, the RTL level does not see that p and q can
not alias each other, and therefore does the assignments precisely as
they appear in the program. In the patched compiler, the compiler
sees that there is no aliasing, and all the loads are done before all
the stores. The latter code will normally minimize load delays. Of
course this will have a more dramatic effect on processors which do
in-order execution.
Ian
Compile Without Libc
I am cross compiling an application to an architecture where the libc functions won't really be useful to me. Whenever I try to compile my application, I get the following message "ld: cannot find -lc" After searching the internet, I came to the conclusion that it is looking for libc. Are there any flags that I can use so it doesn't require libc? Or should I just build libc so it will link? -- Sent from the gcc - General forum at Nabble.com: http://www.nabble.com/Compile-Without-Libc-t324886.html#a904939
Re: Compile Without Libc
"aetherane \(sent by Nabble.com\)" <[EMAIL PROTECTED]> writes: > I am cross compiling an application to an architecture where the libc > functions won't really be useful to me. Whenever I try to compile my > application, I get the following message > "ld: cannot find -lc" > After searching the internet, I came to the conclusion that it is looking for > libc. Are there any flags that I can use so it doesn't require libc? > Or should I just build libc so it will link? This question would be more appropriate on gcc-help. See the -nodefaultlibs option. See also the note about -lgcc in the -nostdlib option. Ian
g++.dg not having one .exp per directory
I have noticed that g++.dg does not have one .exp file per directory, and I could not figure out how to run, say, a single test case in the g++.dg/tree-ssa directory. I have modified g++.dg/dg.exp to do so, by using "glob" rather than "find", and then I could copy dg.exp to all the directories that don't already have a .exp file. Would the patch be acceptable for 4.1? What about 4.2? If not, how do I achieve the same result? :-) Paolo
Re: PATCH RFC: Increase support for restrict qualifier
> +
> /* Create a new temporary name with PREFIX. Returns an identifier. */
>
> static GTY(()) unsigned int tmp_var_id_num;
> @@ -470,6 +521,18 @@ internal_get_tmp_var (tree val, tree *pr
>
>t = lookup_tmp_var (val, is_formal);
>
> + if (is_formal)
> +{
> + tree u = find_single_nonscalar_decl (val);
> +
> + if (u && DECL_UNDERLYING_NONSCALAR_DECL (u))
> + u = DECL_UNDERLYING_NONSCALAR_DECL (u);
> + gcc_assert (!DECL_UNDERLYING_NONSCALAR_DECL (t)
> + || DECL_UNDERLYING_NONSCALAR_DECL (t) == u);
> + if (u && lang_hooks.types_compatible_p (TREE_TYPE (u), TREE_TYPE (t)))
> + DECL_UNDERLYING_NONSCALAR_DECL (t) = u;
> +}
> +
First, i'd rather see this named something that implies it's only used
for restrict. Otherwise, people are going to start using it for other
things (the other possible uses i can think of, which possibly include
debug info, are already taken care of by DECL_VALUE_EXPR and
DECL_DEBUG_EXPR).
second, how often does this actually set anything useful with restrict
types (I assume the value is not interesting in any other cases)?
ISTM you'd be better off doing what we do with DECL_VALUE_EXPR,
DECL_DEBUG_EXPR, and DECL_INIT_PRIORITY, which is to use 1 bit to say
whether it has an "underlying nonscalar decl", and a side hashtable to
store the actual value.
I say this because I imagine the number of DECL's which are restrict
qualified, and thus, should have an underlying nonscalar-decl, is very
small, and yet, you've added a field that is there for *all* decl's with
rtl attached to them.
This would also solve your field-decl problem, since you could throw the
bit in the common part.
--Dan
Re: PATCH RFC: Increase support for restrict qualifier
Daniel Berlin <[EMAIL PROTECTED]> writes: > second, how often does this actually set anything useful with restrict > types (I assume the value is not interesting in any other cases)? In functions which use the restrict qualifier, it does something useful pretty often: just about every time the restricted pointer is used other than as a simple *p. The real question, which I don't know the answer to, is how much that helps in common code. (It does make a significant difference in certain key functions at my current job.) > ISTM you'd be better off doing what we do with DECL_VALUE_EXPR, > DECL_DEBUG_EXPR, and DECL_INIT_PRIORITY, which is to use 1 bit to say > whether it has an "underlying nonscalar decl", and a side hashtable to > store the actual value. > > I say this because I imagine the number of DECL's which are restrict > qualified, and thus, should have an underlying nonscalar-decl, is very > small, and yet, you've added a field that is there for *all* decl's with > rtl attached to them. > > This would also solve your field-decl problem, since you could throw the > bit in the common part. Makes sense. It also reduces the cost quite a bit, which might make it a good idea even if the benefit is small, pending a more complete solution. Ian
Re: System header warning exemptions and delta debugging don't mix well
> > Short story: > > To make delta debugging more useful, gcc's STL system headers should > > all compile without warnings at the highest error checking level > > without the use of hardcoded warning suppressions in the compiler > > based on whether the code is in a system header or not (see > > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00049.html for an example > > of such a suppression). > > How bad is it? Can you compile all the headers with -Wsystem-headers > and -W -Wall and see how many problems there are? > This isn't sufficent, as unless the templates are actually getting instansiated then there won't be any warnings produced. Some errors are only produced for very specific headers (for example, bitset will produce an error about unused variables only in the case of bitset<0>, which is valid but I'd imagine never actually used). There appears to be a bug whereby headers in "bits/" in libstdc++ (which is where most of the actual code is) appear uneffected by using Wsystem-headers, so in actual fact the headers are probably already fairly clean. The best way to make, and keep, the headers clean would probably be to make the libstdc++ testsuite run at a higher warning level by default. If you do this now you'll find a lot of tests fail, but the vast majority appear to be from problems in the headers used only in the testsuite. I'd hoped to tackle this, but don't have enough time at the moment. I don't imagine it would be too hard in most cases. Some warnings, for example -Weffc++, as shown in PR14172 currently cause problems with the libstdc++ headers, but fixing them would require pessimising or complicating code.
Re: bad web link on mirrors page
On Thu, 22 Sep 2005, george young wrote: > On the web page: >http://gcc.gnu.org/mirrors.html > > the link: > http://strawberry.resnet.mtu.edu/pub/gcc/ > > fails: "The requested URL /pub/gcc/ was not found on this server" Thanks for the hint! Paul, shall I remove the link from our mirrors page, or is this just a temporary issue? Gerald
Re: g++.dg not having one .exp per directory
Paolo Bonzini wrote: > I have noticed that g++.dg does not have one .exp file per directory, > and I could not figure out how to run, say, a single test case in the > g++.dg/tree-ssa directory. > > Would the patch be acceptable for 4.1? What about 4.2? If not, how do > I achieve the same result? :-) I might be misunderstanding you, but doesn't this do what you're after? make RUNTESTFLAGS="dg.exp=nothrow-1.C" check-g++ Cheers, Ben
Re: g++.dg not having one .exp per directory
On Sep 25, 2005, at 7:58 PM, Ben Elliston wrote: make RUNTESTFLAGS="dg.exp=nothrow-1.C" check-g++ dg.exp=eh\*.C is another one. dg.exp=file1.C,file2.C I think was another spelling.
