Bootstrap failure on Linux/x86-64
On Linux/x86-64 bootstrapping a biarch compiler fails with: cc1: out of memory allocating 22752576 bytes after a total of 142843904 bytes make[3]: *** [insn-recog.o] Error 1 make[3]: Leaving directory `/builds/gcc/misc/gcc' make[2]: *** [all-stage2-gcc] Error 2 Running under debugger, I see: (gdb) r -fpreprocessed insn-recog.i -quiet -dumpbase insn-recog.c -mtune=generic -auxbase-strip insn-recog.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -version -fno-common -o insn-recog.s -dm Starting program: /builds/gcc/misc/prev-gcc/cc1 -fpreprocessed insn-recog.i -quiet -dumpbase insn-recog.c -mtune=generic -auxbase-strip insn-recog.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -version -fno-common -o insn-recog.s -dm GNU C version 4.2.0 20060121 (experimental) (x86_64-suse-linux-gnu) compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 33c06c82ca4a1087acb28cb4b71f71af #0 0x006b86cd in delete_trivially_dead_insns (insns=0x2aaabf79d4c0, nreg=2888) at /cvs/gcc-svn/trunk/gcc/cse.c:7371 #1 0x012fed8e in rest_of_handle_loop_optimize () at /cvs/gcc-svn/trunk/gcc/loop.c:11803 #2 0x00ff84b8 in execute_one_pass (pass=0x16914e0) at /cvs/gcc-svn/trunk/gcc/passes.c:849 #3 0x00ff8577 in execute_pass_list (pass=0x16914e0) at /cvs/gcc-svn/trunk/gcc/passes.c:881 #4 0x00ff8595 in execute_pass_list (pass=0x168fcc0) at /cvs/gcc-svn/trunk/gcc/passes.c:882 #5 0x004f0b99 in tree_rest_of_compilation (fndecl=0x2aaab3e12400) at /cvs/gcc-svn/trunk/gcc/tree-optimize.c:412 #6 0x00425762 in c_expand_body (fndecl=0x2aaab3e12400) at /cvs/gcc-svn/trunk/gcc/c-decl.c:6689 #7 0x010a6ac4 in cgraph_expand_function (node=0x2aaab5766180) at /cvs/gcc-svn/trunk/gcc/cgraphunit.c:1098 #8 0x010a6d52 in cgraph_expand_all_functions () at /cvs/gcc-svn/trunk/gcc/cgraphunit.c:1164 #9 0x010a77ee in cgraph_optimize () at /cvs/gcc-svn/trunk/gcc/cgraphunit.c:1431 #10 0x0042895a in c_write_global_declarations () at /cvs/gcc-svn/trunk/gcc/c-decl.c:7804 #11 0x00f92b12 in compile_file () at /cvs/gcc-svn/trunk/gcc/toplev.c:1003 #12 0x00f94509 in do_compile () at /cvs/gcc-svn/trunk/gcc/toplev.c:1948 #13 0x00f9456d in toplev_main (argc=27, argv=0x7f8afeb8) at /cvs/gcc-svn/trunk/gcc/toplev.c:1980 #14 0x004b84a3 in main (argc=27, argv=0x7f8afeb8) at /cvs/gcc-svn/trunk/gcc/main.c:35 (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x004ea832 in get_use_from_ptr (use=0x2aaac2ca1bc8) at tree-flow-inline.h:578 578 return *(use->use); (gdb) bt #0 0x004ea832 in get_use_from_ptr (use=0x2aaac2ca1bc8) at tree-flow-inline.h:578 #1 0x004ed943 in verify_ssa (check_modified_stmt=1 '\001') at /cvs/gcc-svn/trunk/gcc/tree-ssa.c:734 #2 0x00ff8228 in execute_todo (pass=0x168b6c0, flags=1, use_required=0 '\0') at /cvs/gcc-svn/trunk/gcc/passes.c:783 #3 0x00ff8507 in execute_one_pass (pass=0x168b6c0) [...] (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x00df4f74 in cleanup_barriers () at /cvs/gcc-svn/trunk/gcc/jump.c:113 113 next = NEXT_INSN (insn); (gdb) bt #0 0x00df4f74 in cleanup_barriers () at /cvs/gcc-svn/trunk/gcc/jump.c:113 #1 0x012feda9 in rest_of_handle_loop_optimize () at /cvs/gcc-svn/trunk/gcc/loop.c:11809 #2 0x00ff84b8 in execute_one_pass (pass=0x16914e0) at /cvs/gcc-svn/trunk/gcc/passes.c:849 #3 0x00ff8577 in execute_pass_list (pass=0x16914e0) at /cvs/gcc-svn/trunk/gcc/passes.c:881 #4 0x00ff8595 in execute_pass_list (pass=0x168fcc0) at /cvs/gcc-svn/trunk/gcc/passes.c:882 The memory usage is growing and growing. Seems that we have either a miscompilation of the stage2 compiler and/or some memory leak, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpYRkeA4mf3u.pgp Description: PGP signature
may have found a wrong warning?
Hi,
i just played around a little with wchar_t. I am not sure, but i think
i got a warning that did not make any sense at all. Here's the small
test:
#include
#include
#include
int
main (void)
{
wchar_t a = L'©'; /* The copyright sign */
setlocale (LC_ALL, "");
printf ("char was %lc\n", a);
return 0;
}
if i compile this with my gcc (GCC) 3.3.4 (pre 3.3.5 20040809) i got
the following warning:
warning: character constant too long for its type
well, my linux uses UTF-8 and i know that the copyright sign is a 2byte
multibyte. But if i use it with a wchar_t and the L modifier, i thought
the compiler would change this multibyte to a correct 32bit unicode
value? Well, at least the program works as expected. It prints the
copyright sign.
Best regards
Georg Steffers
pgpzTEmm2hgHV.pgp
Description: PGP signature
ssp check
Hello! The ssp check (gcc_cv_libc_provides_ssp) is glibc centric and the ssp implementation itself assumes that if ssp is provided by libc/ld combo, then the guard is for sure set up in TLS. What would be an acceptable way to provide support for non-glibc/non-TLS? 1. provide 2 configure options, one that omits the above mentioned check and the other that disables ssp in TLS (GUARD_IS_NOT_IN_TLS) the latter being a guard in linux*.h, like -#ifdef TARGET_LIBC_PROVIDES_SSP +#if defined TARGET_LIBC_PROVIDES_SSP && !defined GUARD_IS_NOT_IN_TLS #define TARGET_THREAD_SSP_OFFSET blah #endif 2. replace the features.h grep w/ (or similar) with compiling a dummy test file, get the used ld.so and libc.so from there and do something like (works only for non-cross builds) (nm -D --defined-only ld.so | grep __stack_chk_guard) && (nm -D --defined-only libc.so.x | grep __stack_chk_fail) This would cover the non-glibc version. I have no idea how to check in TLS if __stack_chk_guard is there. Thanks, Peter PS: please CC to me. -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: RELOAD_OTHER bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! DJ Delorie wrote: > This seems to have gotten forgotten: > > >>Date: Wed, 14 Dec 2005 21:12:20 -0500 >>From: DJ Delorie <[EMAIL PROTECTED]> >>CC: gcc@gcc.gnu.org, ian@airs.com > > >>It seems like the very next thing it does is generate and emit the >>reload insns via emit_reload_insns(). >> >>However, I modified my logic to check to see if the other thing we're >>merging with is also an address; if it's not, we stick with >>RELOAD_OTHER. I fiddled with the logic to look for reloads for the >>new RELOAD_FOR_OTHER_ADDRESS too, but I suspect if we find any, >>something may go wrong anyway. > > > http://gcc.gnu.org/ml/gcc/2005-12/msg00377.html > I would be *very* happy to see your patch in. I reported this problem 4 years ago (m68hc11 target) and proposed a patch: http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00812.html I don't say it is best. It is just necessary for m68hc11 and I carry it for 4 years now on www.gnu-m68hc11.org. Stephane -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD0jiKNyQxO2LzKT0RAhNiAJ9Tv+V4FpQSdD/JWHHPg3L3dbTRtgCg3rEG mUsLaeZ49X5baXLs/FjqH8w= =pvnO -END PGP SIGNATURE-
Re: may have found a wrong warning?
On Sat, 21 Jan 2006, Georg Steffers wrote: > if i compile this with my gcc (GCC) 3.3.4 (pre 3.3.5 20040809) i got the 3.3.x is old and no longer maintained, try using 3.4.x or later. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: RTL alias analysis
> One way to avoid this restriction would be to extend RTL alias > analysis to not be strictly type based. In particular, we could > extend it to know that a particular stack slot has a range of alias > sets. And we would then have to know whether a particular pointer > could possibly point to that stack slot. However, in general, I This would not work in general. You can teach RTL AA to properly answer question "can pointer X point to slot Y?" by knowing that slot Y can have two different alias sets, but you need to answer also question "can pointer X point to same place as pointer Y" when both pointers might possibly point to shared slot Z. So if you introduce sharing and you want to do type based AA on pointers, you would have to somehow adjust type aliasing rules so any two types that can point to same place in shared stack slot would be now believed to be conflicting. This is rather nasty I would say. > > Another way to avoid this restriction would be to prevent reordering > of reads and writes across lexical block boundaries when objects are > being shared. This would be another way of preventing the undesirable > reordering of reads and writes. However, in general, I again suspect > that this would yield worse results. It also seems to me that we can prety freely lifht the memory accesses across "block" boundaries already on tree level, so reconstructing some sort of barriers at expansion time is no longer be doable at all. Honza
Re: RTL alias analysis
On Sat, 2006-01-21 at 15:33 +0100, Jan Hubicka wrote: > > One way to avoid this restriction would be to extend RTL alias > > analysis to not be strictly type based. In particular, we could > > extend it to know that a particular stack slot has a range of alias > > sets. And we would then have to know whether a particular pointer > > could possibly point to that stack slot. However, in general, I > > This would not work in general. You can teach RTL AA to properly answer > question "can pointer X point to slot Y?" by knowing that slot Y can > have two different alias sets, but you need to answer also question "can > pointer X point to same place as pointer Y" when both pointers might > possibly point to shared slot Z. So if you introduce sharing and you > want to do type based AA on pointers, you would have to somehow adjust > type aliasing rules so any two types that can point to same place in > shared stack slot would be now believed to be conflicting. This is > rather nasty I would say. Right, which is why, if such a thing was true, you don't do it by modifying the type-based rules directly. You simply have some external way of saying "You think these don't point to the same place, but they really do, trust me". RTL-AA isn't actually as heavily type based as we make it seem. I'd venture, based on experience and the statistics of how effective TBAA is on other compilers that have been published, that TBAA answers roughly 10% of queries that simple disambiguation doesn't resolve (Simple being base + offset and friends). Intraprocedural points-to generally isn't more than 10% either, so this isn't a dig on TBAA :P. Something to keep in mind when thinking of solutions. --Dan
Cross-compiler error
with gcc-3.3.2 i get this error when building a cross-compiler: /home/Owner/src/build/gcc/gcc /xgcc -B/home/Owner/src/build/gcc/gcc/ -B/usr/bin/cross/i386-elf/i386-elf/bin/ -B/usr/bin/cross/i386-elf/i386-elf/lib/ -isystem /usr/bin/cross/i386-elf/i386-elf/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -I. -I. -I../../../gcc- 3.3.2/gcc -I../../../gcc-3.3.2/gcc/. -I../../../gcc-3.3.2/gcc/config -I../../../gcc-3.3.2/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fPIC \ -Dinhibit_libc -c ../../../gcc- 3.3.2/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../../gcc-3.3.2/gcc/crtstuff.c: In function `__do_global_dtors_aux': ../../../gcc-3.3.2/gcc/crtstuff.c:280: warning: passing arg 1 of `__deregister_frame_info' discards qualifiers from pointer target type ../../../gcc-3.3.2/gcc/crtstuff.c: In function `frame_dummy': ../../../gcc-3.3.2/gcc/crtstuff.c:316: warning: passing arg 1 of `__register_frame_info' discards qualifiers from pointer target type /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s: Assembler messages: /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:2: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:4: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:4: Error: junk at end of line, first unrecognized character is `_' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:7: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:9: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:9: Error: junk at end of line, first unrecognized character is `_' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:12: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:14: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:14: Error: junk at end of line, first unrecognized character is `_' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:16: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:18: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:18: Error: junk at end of line, first unrecognized character is `_' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:23: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:23: Error: junk at end of line, first unrecognized character is `_' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:26: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:28: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:28: Error: junk at end of line, first unrecognized character is `p' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:31: Error: unknown pseudo-op: `.local' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:32: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:35: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:35: Error: junk at end of line, first unrecognized character is `_' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:82: Error: unknown pseudo-op: `.local' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:83: Error: junk at end of line, first unrecognized character is `,' /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:85: Warning: .type pseudo-op used outside of .def/.endef ignored. /c/DOCUME~1/Owner/LOCALS~1/Temp/ccCQAi47.s:85: Error: junk at end of line, first unrecognized character is `f' make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/home/Owner/src/build/gcc/gcc' make: *** [all-gcc] Error 2 Please help. /c/ is binded to /cygdrive/c using mount. is this a gcc 3.3.2 bug, should i use 3.4.0 Thanks
Re: Bootstrap failure on Linux/x86-64
I'm still seeing this with current Subversion. Anybody else having the same problem on x86-64? It fails for me on the two systems I tested it on, Andreas Andreas Jaeger <[EMAIL PROTECTED]> writes: > On Linux/x86-64 bootstrapping a biarch compiler fails with: > > cc1: out of memory allocating 22752576 bytes after a total of 142843904 bytes > make[3]: *** [insn-recog.o] Error 1 > make[3]: Leaving directory `/builds/gcc/misc/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > > Running under debugger, I see: > > (gdb) r -fpreprocessed insn-recog.i -quiet -dumpbase insn-recog.c > -mtune=generic -auxbase-strip insn-recog.o -g -O2 -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long > -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute > -Werror -version -fno-common -o insn-recog.s -dm > > Starting program: /builds/gcc/misc/prev-gcc/cc1 -fpreprocessed insn-recog.i > -quiet -dumpbase insn-recog.c -mtune=generic -auxbase-strip insn-recog.o -g > -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition > -Wmissing-format-attribute -Werror -version -fno-common -o insn-recog.s -dm > GNU C version 4.2.0 20060121 (experimental) (x86_64-suse-linux-gnu) > compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux). > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 > Compiler executable checksum: 33c06c82ca4a1087acb28cb4b71f71af > > #0 0x006b86cd in delete_trivially_dead_insns (insns=0x2aaabf79d4c0, > nreg=2888) at /cvs/gcc-svn/trunk/gcc/cse.c:7371 > #1 0x012fed8e in rest_of_handle_loop_optimize () > at /cvs/gcc-svn/trunk/gcc/loop.c:11803 > #2 0x00ff84b8 in execute_one_pass (pass=0x16914e0) > at /cvs/gcc-svn/trunk/gcc/passes.c:849 > #3 0x00ff8577 in execute_pass_list (pass=0x16914e0) > at /cvs/gcc-svn/trunk/gcc/passes.c:881 > #4 0x00ff8595 in execute_pass_list (pass=0x168fcc0) > at /cvs/gcc-svn/trunk/gcc/passes.c:882 > #5 0x004f0b99 in tree_rest_of_compilation (fndecl=0x2aaab3e12400) > at /cvs/gcc-svn/trunk/gcc/tree-optimize.c:412 > #6 0x00425762 in c_expand_body (fndecl=0x2aaab3e12400) > at /cvs/gcc-svn/trunk/gcc/c-decl.c:6689 > #7 0x010a6ac4 in cgraph_expand_function (node=0x2aaab5766180) > at /cvs/gcc-svn/trunk/gcc/cgraphunit.c:1098 > #8 0x010a6d52 in cgraph_expand_all_functions () > at /cvs/gcc-svn/trunk/gcc/cgraphunit.c:1164 > #9 0x010a77ee in cgraph_optimize () > at /cvs/gcc-svn/trunk/gcc/cgraphunit.c:1431 > #10 0x0042895a in c_write_global_declarations () > at /cvs/gcc-svn/trunk/gcc/c-decl.c:7804 > #11 0x00f92b12 in compile_file () > at /cvs/gcc-svn/trunk/gcc/toplev.c:1003 > #12 0x00f94509 in do_compile () at > /cvs/gcc-svn/trunk/gcc/toplev.c:1948 > #13 0x00f9456d in toplev_main (argc=27, argv=0x7f8afeb8) > at /cvs/gcc-svn/trunk/gcc/toplev.c:1980 > #14 0x004b84a3 in main (argc=27, argv=0x7f8afeb8) > at /cvs/gcc-svn/trunk/gcc/main.c:35 > (gdb) c > Continuing. > > Program received signal SIGINT, Interrupt. > 0x004ea832 in get_use_from_ptr (use=0x2aaac2ca1bc8) > at tree-flow-inline.h:578 > 578 return *(use->use); > (gdb) bt > #0 0x004ea832 in get_use_from_ptr (use=0x2aaac2ca1bc8) > at tree-flow-inline.h:578 > #1 0x004ed943 in verify_ssa (check_modified_stmt=1 '\001') > at /cvs/gcc-svn/trunk/gcc/tree-ssa.c:734 > #2 0x00ff8228 in execute_todo (pass=0x168b6c0, flags=1, > use_required=0 '\0') at /cvs/gcc-svn/trunk/gcc/passes.c:783 > #3 0x00ff8507 in execute_one_pass (pass=0x168b6c0) > [...] > (gdb) c > Continuing. > > Program received signal SIGINT, Interrupt. > 0x00df4f74 in cleanup_barriers () at /cvs/gcc-svn/trunk/gcc/jump.c:113 > 113 next = NEXT_INSN (insn); > (gdb) bt > #0 0x00df4f74 in cleanup_barriers () > at /cvs/gcc-svn/trunk/gcc/jump.c:113 > #1 0x012feda9 in rest_of_handle_loop_optimize () > at /cvs/gcc-svn/trunk/gcc/loop.c:11809 > #2 0x00ff84b8 in execute_one_pass (pass=0x16914e0) > at /cvs/gcc-svn/trunk/gcc/passes.c:849 > #3 0x00ff8577 in execute_pass_list (pass=0x16914e0) > at /cvs/gcc-svn/trunk/gcc/passes.c:881 > #4 0x00ff8595 in execute_pass_list (pass=0x168fcc0) > at /cvs/gcc-svn/trunk/gcc/passes.c:882 > > The memory usage is growing and growing. Seems that we have either a > miscompilation of the stage2 compiler and/or some memory leak, > > Andreas Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpxCnGFM6bcd.pgp Description: PGP signature
Re: Bootstrap failure on Linux/x86-64
On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote: I'm still seeing this with current Subversion. Anybody else having the same problem on x86-64? It fails for me on the two systems I tested it on, What reversion is this on? This worked for me on 110050 and 110059. Thanks, Andrew Pinski
Re: Bootstrap failure on Linux/x86-64
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote: > > On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote: > > > > >I'm still seeing this with current Subversion. Anybody else having > >the same problem on x86-64? It fails for me on the two systems I > >tested it on, > > What reversion is this on? > > This worked for me on 110050 and 110059. 110067, right now, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�rnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
gcc-4.2-20060121 is now available
Snapshot gcc-4.2-20060121 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060121/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 110067 You'll find: gcc-4.2-20060121.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060121.tar.bz2 C front end and core compiler gcc-ada-4.2-20060121.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060121.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060121.tar.bz2 C++ front end and runtime gcc-java-4.2-20060121.tar.bz2 Java front end and runtime gcc-objc-4.2-20060121.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060121.tar.bz2The GCC testsuite Diffs from 4.2-20060114 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Bootstrap failure on Linux/x86-64
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote: > > On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote: > > > > >I'm still seeing this with current Subversion. Anybody else having > >the same problem on x86-64? It fails for me on the two systems I > >tested it on, > > What reversion is this on? > > This worked for me on 110050 and 110059. I'll try 110059 now to double check. Perhaps my configure flags are the problem, I use: /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel --enable-checking=misc,tree,gc,rtl,rtlflag,assert --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --with-system-zlib x86_64-suse-linux-gnu --enable-languages=c,ada,c++,fortran,java,objc,treelang Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�rnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Re: Storage for uninitialized objects (PR 24626)
> No, the ISO C standard is clear that the value of an uninitialized
> variable is indeterminate. It may be a trap representation, or it may
> be an unspecified value. In the latter case it must have the correct
> type. But there is no other restriction on it, and the standard
> specifically says (3.17.3) it "imposes no requirements on which value
> is chosen in any instance."
Ok, then I believe that the register selection by reload might be
improved. I see the following assembler code at -O2 for this test
program on hppa-unknow-linux-gnu:
extern int bar (int);
int
foo (void)
{
int x;
bar (x);
return x;
}
stw %r2,-20(%r30)
copy %r3,%r26
bl bar,%r2
stwm %r3,64(%r30)
ldw -84(%r30),%r2
copy %r3,%r28
bv %r0(%r2)
ldwm -64(%r30),%r3
Reload instantiates the uninitialized value of 'x' using register
'r3'. Register 'r3' is a callee saves register on the PA. As a
result, the prologue and epilogue of foo save and restore 'r3'.
Thus, the code isn't as optimal as it might be.
It would be better if uninitialized values were instantiated using
call-clobbered registers. Even better, choosing the destination
register in the "copy" instructions would allow the instructions
to be deleted.
For those that like as much determinism as possible, it would be
better to instantiate uninitialized register values using the value
zero. The cost for this on PA-RISC is the same as using an arbitrary
call-clobbered register.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Bootstrap failure on Linux/x86-64
On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote: On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote: On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote: I'm still seeing this with current Subversion. Anybody else having the same problem on x86-64? It fails for me on the two systems I tested it on, What reversion is this on? This worked for me on 110050 and 110059. I'll try 110059 now to double check. Perhaps my configure flags are the problem, I use: /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel --enable-checking=misc,tree,gc,rtl,rtlflag,assert --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --with-system-zlib x86_64-suse-linux-gnu --enable-languages=c,ada,c++,fortran,java,objc,treelang I just used 110067 and it worked. Maybe it is one of the checking options you are using which is causing it. I just used the default checking. Let me double check with the checking you have. -- Pinski
Re: RTL alias analysis
ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in <[EMAIL PROTECTED]>:
> When dealing with unions, you can take pointers to different fields in
> the unions. If the fields have different types, these pointers can
> have non-conflicting alias sets. Therefore within a single union the
> same memory can be read or written by different pointers. This is
> considered to be invalid--a valid program is required to always access
> the memory within the union in the same type, except if you access the
> memory via the union type itself (this permission being a gcc
> extension).
void test(void)
{
union { int i; double d; } u;
int *ip;
double *dp;
int ii;
double dd;
ip = &u.i;
*ip = 15;
ii = *ip;
dp = &u.d;
*dp = 1.5;
dd = *dp;
printf("ii=%d dd=%f\n", ii, dd);
}
So you're saying this function is not valid?
MfG Kai
Re: Storage for uninitialized objects (PR 24626)
"John David Anglin" <[EMAIL PROTECTED]> writes: > > No, the ISO C standard is clear that the value of an uninitialized > > variable is indeterminate. It may be a trap representation, or it may > > be an unspecified value. In the latter case it must have the correct > > type. But there is no other restriction on it, and the standard > > specifically says (3.17.3) it "imposes no requirements on which value > > is chosen in any instance." > > Ok, then I believe that the register selection by reload might be > improved. I think the place to address this, if indeed it should be addressed, is before reload. If a pseudo-register is used while uninitialized, you can replace the uses with whatever you like. That can be a constant 0 where that fits the instruction, or, if it is a direct assignment from the uninitialized pseudo-register to some other register or memory, you can just remove the assignment. But since correct programs rarely use uninitialized variables, optimizing them is likely to be overkill. Ian
warning: comparison is always true due to limited range of data type
Hello.
There was a discussion about this warning about a year ago, but it
seems to have been forgotten without a resolution.
This warning is issued unconditionally, impossible to disable, hard
to work around, and it depends on integer sizes even when the code
is portable.
I think it should be removed altogether, or at least disabled by
default, or at least possible to disable.
I have macros which generate code like this:
if ((x >= 0 || x >= -0x4000) && x < 0x3FFF) ...
where the type of x is only know to be an integer type.
It correctly checks whether the value lies within the interval
-0x4000..0x3FFF, but generates the mentioned warning if
the type alone is sufficient to determine the answer on the given
architecture. I don't care whether it's true because of the type
or because of the actual value. Please let the warning to away.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Re: warning: comparison is always true due to limited range of data type
> > Hello. > > There was a discussion about this warning about a year ago, but it > seems to have been forgotten without a resolution. > > This warning is issued unconditionally, impossible to disable, hard > to work around, and it depends on integer sizes even when the code > is portable. Well this warning just found a bug in GCC's code where we had an enum and that enum was stored in a bitfield but the bitfield did not span the whole enum so we get this warning. See PR 25886. Thanks, Andrew Pinski
Re: warning: comparison is always true due to limited range of data type
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes: | Hello. | | There was a discussion about this warning about a year ago, but it | seems to have been forgotten without a resolution. | | This warning is issued unconditionally, impossible to disable, hard | to work around, and it depends on integer sizes even when the code | is portable. | | I think it should be removed altogether, or at least disabled by | default, or at least possible to disable. See -Walways-true. -- Gaby
Re: warning: comparison is always true due to limited range of data type
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Well this warning just found a bug in GCC's code where we had an enum and
> that enum was stored in a bitfield but the bitfield did not span the
> whole enum so we get this warning.
Couldn't this be detected when the enum is stored in the bitfield?
> See PR 25886.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886 doesn't seem to be
related to this.
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> See -Walways-true.
gcc-4.1.0-0.20051206r108118 doesn't know this option.
Is it newer or in some unofficial patch?
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Re: warning: comparison is always true due to limited range of data type
> > Andrew Pinski <[EMAIL PROTECTED]> writes: > > > Well this warning just found a bug in GCC's code where we had an enum and > > that enum was stored in a bitfield but the bitfield did not span the > > whole enum so we get this warning. > > Couldn't this be detected when the enum is stored in the bitfield? > > > See PR 25886. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886 doesn't seem to be > related to this. You are wrong, this is the bug which I filed to show that this warning dected the bug. I forgot to say what the warning was but it was comparision always false due to range of the type. -- Pinski
Re: warning: comparison is always true due to limited range of data type
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > See -Walways-true. | | gcc-4.1.0-0.20051206r108118 doesn't know this option. | Is it newer or in some unofficial patch? GCC-4.2.0. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walways_002dtrue-276 -- Gaby
Re: Cross-compiler error
On Jan 21, 2006, at 9:01 AM, Travis Athougies wrote: with gcc-3.3.2 i get this error when building a cross-compiler: You need an i386-elf (your cross target) assembler installed in your path. -eric
RE: insv vs one-bit fields
DJ Delorie wrote: > Why are one-bit bitfields not allowed? I'm trying to support a > BSET/BCLR pair that *only* support single bit fields, for I/O ports, > which are always volatile (and thus you have to use insv, as gcc won't > do a "or #1,port5" if port5 is volatile). ;) Of course, you could always hack around combine to allow it to accept volatiles in a tightly-circumscribed set of conditions that will allow gcc to generate these OR instructions for you. I found that approach worked pretty good for me; YMMV but I could always post a code sample... cheers, DaveK -- Can't think of a witty .sigline today
RE: error found in get_ivts_expr() function.
Uttam Pawar wrote:
> Hi All,
>
> I found following code snippet in file, trunk/gcc/loop-unroll.c
>
>1814 /* Locate in EXPR the expression corresponding to the location
>recorded 1815in IVTS, and return a pointer to the RTX for this
>location. */ 1816
>1817 static rtx *
>1818 get_ivts_expr (rtx expr, struct iv_to_split *ivts)
>1819 {
>1820 unsigned i;
>1821 rtx *ret = &expr;
>1822
>1823 for (i = 0; i < ivts->n_loc; i++)
>1824 ret = &XEXP (*ret, ivts->loc[i]);
>1825
>1826 return ret;
>1827 }
>
> at line 1821, what is the point of taking address of a stack variable?
> and returning it, if the 'condition' in for loop fails. Is this done
> intentionally or is it an error?
The point is that it's only taking that pointer as the start of a linkedlist
chain down which it intends to run. As long as the loop runs at least once,
ret will point to a real rtx somewhere in heap memory. It would be a bug to
call get_ivts_expr if ivts->n_loc was zero, and it certainly wouldn't hurt to
add a gcc_assert() to that effect, but have you actually seen this routine
called with zero n_loc, or is it adequately guarded by the logic of the call
sites?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: RTL alias analysis
Kai Henningsen wrote:
> ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in
> <[EMAIL PROTECTED]>:
>
>> When dealing with unions, you can take pointers to different fields in
>> the unions. If the fields have different types, these pointers can
>> have non-conflicting alias sets. Therefore within a single union the
>> same memory can be read or written by different pointers. This is
>> considered to be invalid--a valid program is required to always access
>> the memory within the union in the same type, except if you access the
>> memory via the union type itself (this permission being a gcc
>> extension).
>
> void test(void)
> {
> union { int i; double d; } u;
> int *ip;
> double *dp;
> int ii;
> double dd;
>
> ip = &u.i;
> *ip = 15;
> ii = *ip;
> dp = &u.d;
> *dp = 1.5;
> dd = *dp;
> printf("ii=%d dd=%f\n", ii, dd);
> }
>
> So you're saying this function is not valid?
>
> MfG Kai
I think he's saying that _this_ one might generate invalid code:
void test(void)
{
union { int i; double d; } u;
int *ip;
double *dp;
int ii;
double dd;
dp = &u.d;
ip = &u.i;
*ip = 15;
ii = *ip;
*dp = 1.5;
dd = *dp;
printf("ii=%d dd=%f\n", ii, dd);
}
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: RTL alias analysis
[EMAIL PROTECTED] (Kai Henningsen) writes:
> ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in <[EMAIL PROTECTED]>:
>
> > When dealing with unions, you can take pointers to different fields in
> > the unions. If the fields have different types, these pointers can
> > have non-conflicting alias sets. Therefore within a single union the
> > same memory can be read or written by different pointers. This is
> > considered to be invalid--a valid program is required to always access
> > the memory within the union in the same type, except if you access the
> > memory via the union type itself (this permission being a gcc
> > extension).
>
> void test(void)
> {
> union { int i; double d; } u;
> int *ip;
> double *dp;
> int ii;
> double dd;
>
> ip = &u.i;
> *ip = 15;
> ii = *ip;
> dp = &u.d;
> *dp = 1.5;
> dd = *dp;
> printf("ii=%d dd=%f\n", ii, dd);
> }
>
> So you're saying this function is not valid?
That function is valid. I expressed myself badly above. What I
should have said is that if you have a pointer to a field in the
union, and you do a read, a valid program must have previously done a
write using a pointer to the same field. A write using a pointer to
one field followed by a read using a pointer to another field is
invalid.
Ian
Re: RTL alias analysis
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I think he's saying that _this_ one might generate invalid code:
>
> void test(void)
> {
> union { int i; double d; } u;
> int *ip;
> double *dp;
> int ii;
> double dd;
>
> dp = &u.d;
> ip = &u.i;
> *ip = 15;
> ii = *ip;
> *dp = 1.5;
> dd = *dp;
> printf("ii=%d dd=%f\n", ii, dd);
> }
That function is valid too.
Here is an example of an invalid function:
void test(void)
{
union { int i; double d; } u;
int *ip;
double *dp;
int ii;
double dd;
dp = &u.d;
ip = &u.i;
*ip = 15;
*dp = 1.5;
ii = *ip;
dd = *dp;
printf("ii=%d dd=%f\n", ii, dd);
}
Ian
floot_log2() - two functions with the same name in GCC.
Looking at gcc/toplev.h and gcc/toplev.c I have found the following
two variants of the same
function once in the header and once in the definition fine.
extern inline int
floor_log2 (unsigned HOST_WIDE_INT x)
{
return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1;
}
and again the same function:
int
floor_log2 (unsigned HOST_WIDE_INT x)
{
int t = 0;
if (x == 0)
return -1;
#ifdef CLZ_HWI
t = HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x);
#else
#endif
return t;
}
At first glace it seems that the .c variants represents hand
optimized C code, which get's never
called. I'm quite convinced that it should be just removed, since
it's never used
due to overschadowing by the .h variant
Re: Request for 48 hours of just regression/bug fixes
Andrew Pinski wrote: > I noticed today that there were three projects which were merged into > the mainline within a 24 hour period yesterday. > > Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin > Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit > Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo > > So I am requesting that we go through a 48 hour period starting Monday > (as the weekends are usually quiet for patch committing) for a stage 3 > type regression only/bug fixes. I'm inclined to agree. Any objections? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: floot_log2() - two functions with the same name in GCC.
OK. Looking closer I have just found that in gcc/toplev.c #if GCC_VERSION < 3004 ... #endif Is missing around the floor_log2() and exact_log2() functions.
Re: floot_log2() - two functions with the same name in GCC.
> > OK. Looking closer I have just found that in gcc/toplev.c > > #if GCC_VERSION < 3004 > ... > #endif > > Is missing around the floor_log2() and exact_log2() functions. You are mssing the fact that the ones in the headers are declared as extern inline. -- Pinski
Re: floot_log2() - two functions with the same name in GCC.
On 2006-01-22, at 04:17, Andrew Pinski wrote: OK. Looking closer I have just found that in gcc/toplev.c #if GCC_VERSION < 3004 ... #endif Is missing around the floor_log2() and exact_log2() functions. You are mssing the fact that the ones in the headers are declared as extern inline. Yes I saw them. However pease look at the if else endif guards in the header. extern inline is just supposed to guarantee that a copy of the function will be spawn out to an .o file when it's seen. Right? The variant in toplev.c will be of course generated as well. And then it's just link order roulette which one of them will be used...
Re: floot_log2() - two functions with the same name in GCC.
> > > On 2006-01-22, at 04:17, Andrew Pinski wrote: > > >> > >> OK. Looking closer I have just found that in gcc/toplev.c > >> > >> #if GCC_VERSION < 3004 > >> ... > >> #endif > >> > >> Is missing around the floor_log2() and exact_log2() functions. > > > > You are mssing the fact that the ones in the headers are declared > > as extern inline. > > Yes I saw them. However pease look at the if else endif guards in the > header. > extern inline is just supposed to guarantee that a copy > of the function will be spawn out to an .o file when it's seen. Right? > The variant in toplev.c will be of course generated as well. And then > it's just link order roulette which one of them will be used... No. This is GCC "extern inline" and not C99 "extern inline". GCC's "extern inline" means inline if you can but if we don't inline, use the external version and don't emit the function in the .o. -- Pinski
Re: floot_log2() - two functions with the same name in GCC.
At first glace it seems that the .c variants represents hand optimized C code, which get's never called. I'm quite convinced that it should be just removed, since it's never used due to overschadowing by the .h variant You need the .c variant for the cases where inlining cannot be done for some reason.
Re: Bootstrap failure on Linux/x86-64
Andrew Pinski <[EMAIL PROTECTED]> writes: > On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote: > >> On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote: >>> >>> On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote: >>> I'm still seeing this with current Subversion. Anybody else having the same problem on x86-64? It fails for me on the two systems I tested it on, >>> >>> What reversion is this on? >>> >>> This worked for me on 110050 and 110059. >> >> I'll try 110059 now to double check. Perhaps my configure flags are >> the >> problem, I use: >> /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel >> --enable-checking=misc,tree,gc,rtl,rtlflag,assert >> --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit >> --enable-shared --with-system-zlib x86_64-suse-linux-gnu >> --enable-languages=c,ada,c++,fortran,java,objc,treelang > > I just used 110067 and it worked. Maybe it is one of the checking > options you are > using which is causing it. I just used the default checking. I now used 110067 with the default checking options - and it worked, so it's the checking options. Kenneth, Zdenek, could you look into this? Please use the same checking options that I have above. > Let me double check with the checking you have. Thanks, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpYd7POOlQYd.pgp Description: PGP signature
