Since r110852: Mainline broken for VAX (cc0 target)
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-init.c (gate_handle_loop2): Do not test flag_loop_optimize2. + Test flag_branch_on_count_reg only if HAVE_doloop_end. + * common.opt (floop-optimize2): Removed. + (fmove-loop-invariants): Enabled by default. + vax-linux-uclibc-gcc -c libc/misc/fnmatch/fnmatch.c -o libc/misc/fnmatch/fnmatch.o -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Wnested-externs -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes -Wmissing-declarations -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -fsigned-char -DSTATIC -Os -funit-at-a-time -isystem /tmp/build-temp-vax-linux-uclibc/install/usr/lib/gcc/vax-linux-uclibc/4.2.0/include -DNDEBUG libc/misc/fnmatch/fnmatch_loop.c: In function 'ext_match': libc/misc/fnmatch/fnmatch_loop.c:1193: internal compiler error: in int_mode_for_mode, at stor-layout.c:250 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [libc/misc/fnmatch/fnmatch.o] Error 1 So I'll now try to reduce it to a testcase. Doesn't probably show up on other archs because the VAX MD is quite minimalistic? MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Since r110852: Mainline broken for VAX (cc0 target)
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): Remove handling of flag_loop_optimize2. + * loop-init.c (gate_handle_loop2): Do not test flag_loop_optimize2. + Test flag_branch_on_count_reg only if HAVE_doloop_end. + * common.opt (floop-optimize2): Removed. + (fmove-loop-invariants): Enabled by default. + This is PR 26232. -- Pinski
Re: Since r110852: Mainline broken for VAX (cc0 target)
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. > + * loop-init.c (gate_handle_loop2): Do not test flag_loop_optimize2. > + Test flag_branch_on_count_reg only if HAVE_doloop_end. > + * common.opt (floop-optimize2): Removed. > + (fmove-loop-invariants): Enabled by default. > + > > vax-linux-uclibc-gcc -c libc/misc/fnmatch/fnmatch.c -o > libc/misc/fnmatch/fnmatch.o -include ./include/libc-symbols.h -Wall > -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Wnested-externs > -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 > -Wmissing-prototypes -Wmissing-declarations -fno-stack-protector -fno-builtin > -nostdinc -I./include -I. -fsigned-char -DSTATIC -Os -funit-at-a-time > -isystem > /tmp/build-temp-vax-linux-uclibc/install/usr/lib/gcc/vax-linux-uclibc/4.2.0/include > -DNDEBUG > libc/misc/fnmatch/fnmatch_loop.c: In function 'ext_match': > libc/misc/fnmatch/fnmatch_loop.c:1193: internal compiler error: in > int_mode_for_mode, at stor-layout.c:250 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make: *** [libc/misc/fnmatch/fnmatch.o] Error 1 > > So I'll now try to reduce it to a testcase. Doesn't probably show up > on other archs because the VAX MD is quite minimalistic? this is PR26232 (it shows on all CC0 targets, probably). Zdenek
Re: Since r110852: Mainline broken for VAX (cc0 target)
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]> > >+ > >+ * doc/invoke.texi (-floop-optimize2): Removed. > >+ * toplev.c (process_options): Remove handling of > >flag_loop_optimize2. > >+ * loop-init.c (gate_handle_loop2): Do not test > >flag_loop_optimize2. > >+ Test flag_branch_on_count_reg only if HAVE_doloop_end. > >+ * common.opt (floop-optimize2): Removed. > >+ (fmove-loop-invariants): Enabled by default. > >+ > > This is PR 26232. 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.org/bugzilla/ , which didn't find anything. I don't really feel like wasting your time with doing my homework... MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Since r110852: Mainline broken for VAX (cc0 target)
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.org/bugzilla/ , which didn't find anything. I don't really feel like wasting your time with doing my homework... Well I look at all bug reports that come in so I knew this one was already filed. Other than that searching for int_mode_for_mode will help. Also searching for cc0 can also find it too. -- Pinski
the builtin_function hook
There is a lot of duplicated code in the hooks implementation in the various front ends. I am trying to factor it a little bit. I started with the builtin_function hook. Doing a mostly mechanical work I came up with the attached patch. The patch doesn't touches the C++ front end because it is organised a little differently and would require more work. I don't want to apply this patch right now because I think that it can be made a little better. To do this I need some clarifications: *) Why does a front end needs to know when a new builtin is added? *) If the internal representation used is language independent, can we change the signature of builtin_function to receive just the decl node? The next thing I will try to do is wrap all calls to lang_hooks.builtin_function in a add_builtin_function (in which file should it be?) and move the common code into it. Any comments? Thanks, Rafael builtin.patch Description: Binary data
Re: Since r110852: Mainline broken for VAX (cc0 target)
> > 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 with doing my homework... > > Well I look at all bug reports that come in so I knew this one was > already filed. Other than that searching for int_mode_for_mode will > help. Also searching for cc0 can also find it too. I used to find Zarro Boogs, until I remembered to search for "ALL term_to_search_for". The keyword 'ALL' is kind of important. David Fang
Re: Since r110852: Mainline broken for VAX (cc0 target)
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. I don't > > > really feel like wasting your time with doing my homework... > > > > Well I look at all bug reports that come in so I knew this one was > > already filed. Other than that searching for int_mode_for_mode will > > help. Also searching for cc0 can also find it too. > > I used to find Zarro Boogs, until I remembered to search for > "ALL term_to_search_for". The keyword 'ALL' is kind of important. Apparently it's not obvious, so I recommend always using the bugzilla "Advanced search" and "a Comment [contains the string]" and search for some key item in the ICE message. (That's what I did, using int_mode_for_mode, before filing PR 26232.) brgds, H-P PS. No, I don't know why the simple "some search terms" doesn't work.
Re: Since r110852: Mainline broken for VAX (cc0 target)
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" box of http://gcc.gnu.org/bugzilla/ , which didn't find anything. I don't really feel like wasting your time with doing my homework... Well I look at all bug reports that come in so I knew this one was already filed. That's the key. Although he denies it, I think Pinski has the entire database memorized. David Daney.
Re: "cscope" type functionality
> "Perry" == Perry Smith <[EMAIL PROTECTED]> writes: Perry> gcc/g++ has the -M options to help in creating Makefiles. It struck Perry> me this morning that a similar switch to help in the creation of a Perry> database to use to create a "cscope" type facility would be very Perry> nice. It would be nice if both cpp and gcc/g++ had this ability. Perry> Has/Does anything like this already exist? -- perhaps hidden in one Perry> if the debugging files that can be produced? Historically this idea has met with some resistance. However this seems to have cleared up a bit, so perhaps it is politically possible now. The various debugging dump files aren't the most useful -- sometimes they omit info, I think we don't try to keep the output formats stable, etc. I think it would be more advisable to design something with AST database generation as an explicit goal. Tom
Re: "cscope" type functionality
Tom Tromey <[EMAIL PROTECTED]> writes: [...] | I think it would be more advisable to design something with AST | database generation as an explicit goal. I believe that is a sensible approach, one that I thought a by-product of the "Link Time Optimization" proposal. Such a format will be tremendously useful. -- Gaby
Global declarations before RTL expansion
Dear developers, I am trying to get all global declarations in GIMPLE level just before RTL expansion. I have tried to copy the scope instead of pop_scope() to catch the global declarations in the way c_write_global_declarations() does it but I've failed. It seems the structures are not yet completed at this stage (?). Is there any other way around to get ALL (used, non-used) global variables ? Thank you for your help Arquimedes Canedo
Re: Global declarations before RTL expansion
On Mon, 2006-02-13 at 11:48 +0900, Arquimedes Canedo wrote: > Dear developers, > > I am trying to get all global declarations in GIMPLE level just > before RTL expansion. I have tried to copy the scope instead of > pop_scope() to catch the global declarations in the way > c_write_global_declarations() does it but I've failed. It seems the > structures are not yet completed at this stage (?). cgraph's varpool should have these. Look at ipa-type-escape.c for the varpool_nodes_queue walking code.
Re: Global declarations before RTL expansion
On Feb 13, 2006, at 11:52 AM, Daniel Berlin wrote: cgraph's varpool should have these. Look at ipa-type-escape.c for the varpool_nodes_queue walking code. Thanks for the guidance. I'm using gcc-4.0.2 sources and I could get the global variables by the cgraph_varpool_nodes. This is what I was looking for. Thank you again r-Q
