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.
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?
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
> > 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
>
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 re
> +
> /* 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_sin
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
"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 i
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
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
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
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
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-d
13 matches
Mail list logo
