Hi,
On Linux/ia32, Linux/Intel64 and Linux/ia64, revision 135884 gave me
[EMAIL PROTECTED] libjava]$
/export/build/gnu/gcc/build-x86_64-linux/./gcc/xgcc -shared-libgcc
-B/export/build/gnu/gcc/build-x86_64-linux/./gcc -nostdinc++
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/
Hans-Peter Nilsson wrote:
PS. No, I don't know why the simple "some search terms" doesn't work.
Probably because simple search only looks at the summary field (and a
few other usually useless fields), and the summary field often doesn't
have the info you are searching for. If you click on th
Andrew Pinski wrote:
On Feb 12, 2006, at 3:33 PM, Jan-Benedict Glaw wrote:
First of all: thanks. You're ultimatively fast.
And now: How do you actually find the PRs? I seem to wrongly use
Bugzilla's search engine. I submitted "int_mode_for_mode" into the
"Enter a bug # or some search terms"
On Sun, 12 Feb 2006, David Fang wrote:
> > > And now: How do you actually find the PRs? I seem to wrongly use
> > > Bugzilla's search engine. I submitted "int_mode_for_mode" into the
> > > "Enter a bug # or some search terms" box of
> > > http://gcc.gnu.org/bugzilla/ , which didn't find anything.
> > And now: How do you actually find the PRs? I seem to wrongly use
> > Bugzilla's search engine. I submitted "int_mode_for_mode" into the
> > "Enter a bug # or some search terms" box of
> > http://gcc.gnu.org/bugzilla/ , which didn't find anything. I don't
> > really feel like wasting your time
On Feb 12, 2006, at 3:33 PM, Jan-Benedict Glaw wrote:
First of all: thanks. You're ultimatively fast.
And now: How do you actually find the PRs? I seem to wrongly use
Bugzilla's search engine. I submitted "int_mode_for_mode" into the
"Enter a bug # or some search terms" box of
http://gcc.gnu.
On Sun, 2006-02-12 15:26:40 -0500, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2006, at 3:21 PM, Jan-Benedict Glaw wrote:
> >Since r110852, GCC (used as cross-compiler) can no longer build uClibc
> >or (parts of) GNU libc:
> >
> >+2006-02-10 Zdenek Dvorak <[EMAIL PROTECTED]>
> >+
> >+
Hello,
> Since r110852, GCC (used as cross-compiler) can no longer build uClibc
> or (parts of) GNU libc:
>
> +2006-02-10 Zdenek Dvorak <[EMAIL PROTECTED]>
> +
> + * doc/invoke.texi (-floop-optimize2): Removed.
> + * toplev.c (process_options): Remove handling of flag_loop_optimize2.
On Feb 12, 2006, at 3:21 PM, Jan-Benedict Glaw wrote:
Hi!
Since r110852, GCC (used as cross-compiler) can no longer build uClibc
or (parts of) GNU libc:
+2006-02-10 Zdenek Dvorak <[EMAIL PROTECTED]>
+
+ * doc/invoke.texi (-floop-optimize2): Removed.
+ * toplev.c (process_options)
Hi!
Since r110852, GCC (used as cross-compiler) can no longer build uClibc
or (parts of) GNU libc:
+2006-02-10 Zdenek Dvorak <[EMAIL PROTECTED]>
+
+ * doc/invoke.texi (-floop-optimize2): Removed.
+ * toplev.c (process_options): Remove handling of flag_loop_optimize2.
+ * loop-i
I think this is either PR 25890 or PR 25905.
It's PR25905, an assertion failure caused by invalid RTL produced by
expand. (PR25890 instead is where combine produces invalid RTL that
fails its own assertion).
Paolo
>
> --ZMT28BdW279F9lxY
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]
> cuni.cz> wrote:
> [...]
> > > This is the SIGN_EXTRACT case of expand_compound_ope
On Sun, 2006-01-22 21:54:47 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> [...]
> > > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this
> > > does ring a
> > > bell?
> >
> > no idea; this
On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
[...]
> > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this
> > does ring a
> > bell?
>
> no idea; this is either completely unrelated, or we randomly clobber memory
> somewhere.
> Could you please
Hello,
> I'm keeping an eye on building GCC for vax-linux /vax-linux-uclibc (only
> some config changes needed for that; I'll submit those once the first libc
> support is committed). Note that this is a cc0 port.
>
> An automated build at 20060120-141501 UTC still showed the ICE in
> udivmodsi4.
Hi!
I'm keeping an eye on building GCC for vax-linux /vax-linux-uclibc (only
some config changes needed for that; I'll submit those once the first libc
support is committed). Note that this is a cc0 port.
An automated build at 20060120-141501 UTC still showed the ICE in
udivmodsi4.c . This was p
Steven Bosscher wrote:
Seems like your forgot the basic-block.h bits in this commit:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00621.html
Gr.
Steven
Sorry. Checked in now.
Hi Joern,
You broke mainline.
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -fno-common -DHAVE_CONFIG_H-I. -I.
-I../../mainline/gcc -I../../mainline/gcc/. -I../../mainline/gcc/../include
-I../../mainline/gcc/../libcpp/include ../../mainline/
18 matches
Mail list logo
