Re: Signed int overflow behavior in the security context
Paul Schlie wrote: Just as: volatile int* port = (int*)PORT_ADDRESS; int input = *port; supposedly invoking an undefined behavior. is required to be well specified, effectively reading through a pointer an un-initialized object's value, and then assigning that unspecified value to the variable input; as otherwise the language couldn't be utilized to write even the most hardware drivers required of all computer systems. Now, wait just a minute here! Doesn't C's definition of "volatile" specify that things outside the program can cause the value of a volatile variable to become "determinate"? It's an obvious part of what the term means, and Fortran's definition of volatile variables most certainly includes the equivalent provision. Thus, this code is _not_ invoking an undefined behavior if something outside the program is causing *port to become determinate (and if the C standard defines "volatile" in a reasonable way). - Brooks
Does anyone recognize this --enable-checking=all bootstrap failure?
I've been trying to track down an build failure that I was pretty sure came about from some patches I've been trying to merge, but I've now reduced things to a bare unmodified tree and it's still failing. I could have sworn that it wasn't doing that until I started adding things, though, so I'm posting about it here before I make a bug report so y'all can tell me if I did something dumb. Essentially, what's happening is that I've got a build tree configured with --enable-checking=all, and the first time it tries to use xgcc to compile something, it dies with an ICE. Here are the gory details: * Build system: Debian stable, up-to-date, on an Intel P3 machine, running in a VMWare virtual machine. * I updated my build tree to version 121332. * I reverted all changes in the tree by pulling a patch with "svn diff", applying it with "patch -R", and then rerunning "svn diff" to confirm that absolutely no differences from the svn mainline were found. * I created a new empty directory, and ran the following "configure" command in it: ../svn-source/configure --verbose --prefix=/home/brooks/bin-callexpr-c --enable-checking=all --disable-bootstrap --enable-languages=c * Then, I ran make. It died with the following error, in what I believe is the first time it tries to use the newly-created xgcc: --- make[3]: Leaving directory `/home/brooks/gcc-callexpr/build-c/i686-pc-linux-gnu/libgcc' /home/brooks/gcc-callexpr/build-c/./gcc/xgcc -B/home/brooks/gcc-callexpr/build-c/./gcc/ -B/home/brooks/bin-callexpr-c/i686-pc-linux-gnu/bin/ -B/home/brooks/bin-callexpr-c/i686-pc-linux-gnu/lib/ -isystem /home/brooks/bin-callexpr-c/i686-pc-linux-gnu/include -isystem /home/brooks/bin-callexpr-c/i686-pc-linux-gnu/sys-include -O2 -g -O2 -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../svn-source/libgcc -I../../../svn-source/libgcc/. -I../../../svn-source/libgcc/../gcc -I../../../svn-source/libgcc/../include -I../../../svn-source/libgcc/../libdecnumber -I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../svn-source/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../svn-source/libgcc/../gcc/libgcc2.c: In function '__muldi3': ../../../svn-source/libgcc/../gcc/libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12101 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [_muldi3.o] Error 1 make[2]: Leaving directory `/home/brooks/gcc-callexpr/build-c/i686-pc-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/brooks/gcc-callexpr/build-c' make: *** [all] Error 2 --- Any ideas? Is this just me? If this is something reproducable, I'll file a PR in the morning. Thanks much! - Brooks
Re: Interprocedural optimization question
El Mon, Jan 29, 2007 at 02:28:34PM -0500, Daniel Berlin ens deleit� amb les seg�ents paraules: > On 1/29/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote: >> Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33: >> >>> Hi, >>> >>> Does gcc apply inter-procedural optimizations across functions called >> using >>> a function pointer? I guess that gcc performs conservatively assuming >> that >>> the pointer could point everywhere because the pointer is a declared as >> a >>> global variable and could be changed in any place. Is it true? >> >> Yes. >> The callgraph does not include these calls. > > Well, not quite. > > While the callgraph doesn't include them, ipa-pta will come up with a > conservatively correct set for them. > > IN the presence of static function pointers, we will come up with a > completely accurate set for them unless they escape ok, I was wondering the possibility to apply ipa optimizations to a predefined set of functions called by the same pointer. Thanks for the explanation. Salut! -- --- Ramon Bertran Monfort Departament d'Arquitectura de Computadors Telefon (+34) 93 4054033/54055 Universitat Politecnica de Catalunya Fax (+34) 93 4017055Despatx C6-103/C6-221-9 Campus Nord e-mail [EMAIL PROTECTED]C. Jordi Girona 1-3 - 08034 Barcelona --- A hundred times every day, I remind myself that my inner and outer life depends on the labors of other men, living and dead, and that I must exert myself in order to give in the measure as I have received and am still receiving. A. Einstein pgpEiuJyHtk3v.pgp Description: PGP signature
Re: Does anyone recognize this --enable-checking=all bootstrap failure?
On 1/30/07, Brooks Moses <[EMAIL PROTECTED]> wrote: I've been trying to track down an build failure that I was pretty sure came about from some patches I've been trying to merge, but I've now reduced things to a bare unmodified tree and it's still failing. I could have sworn that it wasn't doing that until I started adding things, though, so I'm posting about it here before I make a bug report so y'all can tell me if I did something dumb. Essentially, what's happening is that I've got a build tree configured with --enable-checking=all, and the first time it tries to use xgcc to compile something, it dies with an ICE. Here are the gory details: This is fold-checking tripping over bugs - this is also well-known, just don't use --enable-checking=all. (but =yes) Richard.
Re: Which optimization levels affect gimple?
On 1/29/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: -fdump-tree-all-all will work as will -fdump-rtl-all-all I never added support for -fdump-all-all-all :) Thank you! -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: After GIMPLE...
On 29 Jan 2007 11:38:15 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Paulo J. Matos" <[EMAIL PROTECTED]> writes: > I've been looking into the gcc sources and I'm somewhat confused. > Are gcc/g++ comepletely independent programs or do they share a backend? In the source code, they share a backend. As executables, they are different programs: cc1 and cc1plus. OK, thanks, that was the idea I got from looking at the code. > This question comes from the fact that I was trying to find a point in > the source where I could get the GIMPLE tree and do with it what ever > I wished to, without modifying too many files but it seems that gcc, > g++ and other frontends have different program flows and only share > some data structures and backend sources. So probably I need to > eliminate the backend call in every frontend and after GIMPLE is > created call my own functions which get the GIMPLE tree and then > compile my files against every frontend. Right? I don't see why you would have to modify any code in the frontend. You would modify the middle-end code. Rebuilding the compiler would rebuild cc1, cc1plus, etc. You're right... middle-end code... that's what I need to change, not frontend. I keep forgetting some concepts and vocabulary! Thank you, Paulo Matos Ian -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: GCC 4.1.2 RC1
On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote: > GCC 4.1.2 RC1 is now on ftp://gcc.gnu.org and its mirrors. The > canonical location is: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070128 > > As with all prereleases, the issue of most concern to me is packaging. > Therefore, please test the actual pre-release tarballs, rather than > sources from SVN. Beyond packaging problems, I'm most concerned about > regression from previous 4.1.x releases, since the primary purpose of > 4.1.2 is to provide an upgrade path from previous 4.1.x releases, > incorporating the bug fixes since 4.1.1. > > If you do encounter problems, please file a Bugzilla PR, and add me to > the CC: list for the issue. Please do not send me reports without first > filing a PR, as I am unable to keep track of all the issues if they are > not in the database. > > We'll do either the final GCC 4.1.2 release (if all goes well), or RC2 > (if it doesn't) in about a week. What about PR28516, would it be acceptable for 4.1.2? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Re: GCC 4.1.2 RC1
Hi, On Tuesday 30 January 2007 04:06:36 Mark Mitchell wrote: > GCC 4.1.2 RC1 is now on ftp://gcc.gnu.org and its mirrors. The > canonical location is: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070128 > > As with all prereleases, the issue of most concern to me is packaging. > Therefore, please test the actual pre-release tarballs, rather than > sources from SVN. Beyond packaging problems, I'm most concerned about > regression from previous 4.1.x releases, since the primary purpose of > 4.1.2 is to provide an upgrade path from previous 4.1.x releases, > incorporating the bug fixes since 4.1.1. > > If you do encounter problems, please file a Bugzilla PR, and add me to > the CC: list for the issue. Please do not send me reports without first > filing a PR, as I am unable to keep track of all the issues if they are > not in the database. > > We'll do either the final GCC 4.1.2 release (if all goes well), or RC2 > (if it doesn't) in about a week. Builds fine in the T2 SDE *) for i686: == 10:36:01 =[5]=> Building base/gcc [4.1.2-20070128 7.0-trunk]. -> Compiler Cache Hits while pkg build: 27.78% (794 hits, 2064 misses) == 01/30/07 12:11:16 =[5]=> Finished building package gcc. Target: i686-t2-linux-gnu Configured with: ../configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib --datadir=/usr/share --includedir=/usr/include --infodir=/usr/info --mandir=/usr/man --sysconfdir=/etc --localstatedir=/var --disable-debug --build=i686-t2-linux-gnu --host=i686-t2-linux-gnu --enable-__cxa_atexit --disable-checking --disable-bootstrap --disable-multilib --with-gnu-as --with-gnu-ld --enable-threads=posix --enable-libgcj --enable-languages=c,c++,objc,java,fortran --enable-shared Thread model: posix gcc version 4.1.2 20070129 (prerelease) Yours, *) T2 System Development Environment - http://www.t2-project.org -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
Failure to build libjava on 512MB machine
I can no longer build libjava on a machine with "just" 512MB of main memory (FreeBSD/i386 5.4 in this case). Three weeks ago the build worked on that very machine; did we raise our minimum requirements or is this simply a bug? Gerald echo /sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swing/text/html/parser/*.class > gnu/javax/swing/text/html/parser.list /bin/sh ./libtool --mode=compile /files/pfeifer/OBJ-0129-2308/gcc/gcj -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o gnu/javax/swing/text/html/parser.lo -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list /files/pfeifer/OBJ-0129-2308/gcc/gcj -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list -fPIC -o gnu/javax/swing/text/html/.libs/parser.o jc1: out of memory allocating 4072 bytes after a total of 536273352 bytes gmake[3]: *** [gnu/javax/swing/text/html/parser.lo] Error 1 gmake[3]: Leaving directory `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/files/pfeifer/OBJ-0129-2308' gmake: *** [bootstrap-lean] Error 2
Re: GCC 4.1.2 RC1
On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote: > If you do encounter problems, please file a Bugzilla PR, and add me to > the CC: list for the issue. Please do not send me reports without first > filing a PR, as I am unable to keep track of all the issues if they are > not in the database. It looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675 is fixed in 4.2, because in our autobuild runs we don't see the ICE any more. However, the bugzilla entry doesn't mention a fix for the problem. Paul, have you done something in 4.2 which might be backported to 4.1? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Re: Failure to build libjava on 512MB machine
Gerald Pfeifer writes: > I can no longer build libjava on a machine with "just" 512MB of main > memory (FreeBSD/i386 5.4 in this case). > > Three weeks ago the build worked on that very machine; did we raise > our minimum requirements We just imported a whole new release of the Classpath library, and it's big. But that doesn't explain this bug. > or is this simply a bug? I think so. javax/swing/text/html/parser is quite small: $ /usr/bin/time make javax/swing/text/html/parser.lo 0.53user 0.16system 0:00.74elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+26369minor)pagefaults 0swaps $ ls -lh javax/swing/text/html/.libs/parser.o -rw-r--r-- 1 aph aph 260K Jan 30 11:44 javax/swing/text/html/.libs/parser.o I don't know why it is using so much memory in your case. > Gerald > > echo > /sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swing/text/html/parser/*.class > > gnu/javax/swing/text/html/parser.list > /bin/sh ./libtool --mode=compile /files/pfeifer/OBJ-0129-2308/gcc/gcj > -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ > -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer > -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib > --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o > gnu/javax/swing/text/html/parser.lo > -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes > -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF > gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list > /files/pfeifer/OBJ-0129-2308/gcc/gcj > -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ > -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer > -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib > --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c > -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes > -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF > gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list > -fPIC -o gnu/javax/swing/text/html/.libs/parser.o > jc1: out of memory allocating 4072 bytes after a total of 536273352 bytes > gmake[3]: *** [gnu/javax/swing/text/html/parser.lo] Error 1 > gmake[3]: Leaving directory > `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory > `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[1]: *** [all-target-libjava] Error 2 > gmake[1]: Leaving directory `/files/pfeifer/OBJ-0129-2308' > gmake: *** [bootstrap-lean] Error 2
Interesting build failure on trunk
Hi all, I am getting this when I try to compile gcc trunk: ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function 'read_name_map': ../../libcpp/files.c:1238: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [files.o] Error 1 Did anyone hit this before? Regards, ismail
Re: Signed into overflow behavior in the security context
> Robert wrote: >> Paul Schlie wrote: >> - agreed, and thereby objects having no legitimate trap representation, >> such as most if not all implementations of integers and floating point >> objects on most if not all current target machines, and thereby their >> access does not invoke an undefined behavior. > > First of all, trap representations of COURSE exist for floating-point > objects, I guess you don't know fpt formats (most people don't). - as trap representation within the context of C is a value representation which is not defined to be a member of a type, where if accessed or produced evokes undefined behavior; so admit as to the best of my knowledge all potentially enclosable values for IEEE floats and doubles are defined, it would seem trap representations don't exist in typical fp implementations, as such an implementation would require more bits of encoding than the type itself requires. > But in any case, your reasoning here is once again based on the language > you wish you had, rather than the formal semantic language defined by > the standard, which has no notion of "no legitimate trap representation". > > The standard says an uninitialized variable can have a trap > representation. Therefor it can. - yes that is consistent, one wouldn't want to have to think about reality. > There is no license to reason about how you think code is generated, any > compiled is allowed to generate code AS IF a trap representation were present. - yes, and thereby inconsistent with reality, and thereby wrong. (as may and may not are equivalent possibilities) > I think you often miss this distinction between > > generated code at the implementation level > > as if behavior from the rules in the standard >> >> Just as: >> >> volatile int* port = (int*)PORT_ADDRESS; >> >> int input = *port; supposedly invoking an undefined behavior. >> >> is required to be well specified, effectively reading through a pointer >> an un-initialized object's value, and then assigning that unspecified value >> to the variable input; as otherwise the language couldn't be utilized to >> write even the most hardware drivers required of all computer systems. > > Looks unspecified to me, but in any case reasoning which says > > The standard must say X, since otherwise I could not write "hardware > drivers required of all computer systems", is bogus. There is nothing > that says valid C can be used to write such drivers. - I buy the value is unspecified, the semantics are not.
Re: Failure to build libjava on 512MB machine
Andrew Haley wrote: Gerald Pfeifer writes: > I can no longer build libjava on a machine with "just" 512MB of main > memory (FreeBSD/i386 5.4 in this case). > > Three weeks ago the build worked on that very machine; did we raise > our minimum requirements We just imported a whole new release of the Classpath library, and it's big. But that doesn't explain this bug. You mean 0.93, right? > or is this simply a bug? I think so. javax/swing/text/html/parser is quite small: $ /usr/bin/time make javax/swing/text/html/parser.lo What? No way! I always thought this must be something about 7gb or so. Compiling my canadian cross mingw takes 2h. 40min to 50min is spend for compiling html/parser... I think a linux normal build (static, 32bit) also needs about 2h. A cross host=mingw target=linux took only 50min to my surprise. 0.53user 0.16system 0:00.74elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+26369minor)pagefaults 0swaps $ ls -lh javax/swing/text/html/.libs/parser.o -rw-r--r-- 1 aph aph 260K Jan 30 11:44 javax/swing/text/html/.libs/parser.o I don't know why it is using so much memory in your case. I assume is has something to do with optimization. - I noticed myself that I can't compile some jars on mingw (Waited an hour) while it just took a few minutes on Linux (cross to mingw) - A user of my builds reported also out of memory exceptions with recent gcc builds when optimization is used - someone made a java or libjava bugreport about that Marco > Gerald > > echo /sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swing/text/html/parser/*.class > gnu/javax/swing/text/html/parser.list > /bin/sh ./libtool --mode=compile /files/pfeifer/OBJ-0129-2308/gcc/gcj -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o gnu/javax/swing/text/html/parser.lo -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list > /files/pfeifer/OBJ-0129-2308/gcc/gcj -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list -fPIC -o gnu/javax/swing/text/html/.libs/parser.o > jc1: out of memory allocating 4072 bytes after a total of 536273352 bytes > gmake[3]: *** [gnu/javax/swing/text/html/parser.lo] Error 1 > gmake[3]: Leaving directory `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[1]: *** [all-target-libjava] Error 2 > gmake[1]: Leaving directory `/files/pfeifer/OBJ-0129-2308' > gmake: *** [bootstrap-lean] Error 2
Re: Signed into overflow behavior in the security context
> Paul wrote >> Robert wrote: >>> Paul Schlie wrote: >>> - agreed, and thereby objects having no legitimate trap representation, >>> such as most if not all implementations of integers and floating point >>> objects on most if not all current target machines, and thereby their >>> access does not invoke an undefined behavior. >> >> First of all, trap representations of COURSE exist for floating-point >> objects, I guess you don't know fpt formats (most people don't). > > - as trap representation within the context of C is a value > representation which is not defined to be a member of a type, where if > accessed or produced evokes undefined behavior; so admit as to the best of my > knowledge all potentially enclosable values for IEEE floats and doubles are > defined, it would seem trap representations don't exist in typical fp > implementations, as such an implementation would require more bits of encoding > than the type itself requires. - admittedly, SNaN values may be considered as such; however ints would appear to have no counterpart.
Re: Signed int overflow behavior in the security context
> Paul Jarc wrote: >> Paul Schlie wrote: >> is required to be well specified [...] as otherwise the language >> couldn't be utilized to write even the most hardware drivers >> required of all computer systems. > > In a sense, the language *can't* be used to write most hardware > drivers. Drivers do invoke undefined behavior - that is, the standard > makes no guarantees about their behavior - but the particular platform > they are targeted for makes its own guarantees, so the code is still > useful, e The root of this discussion was based on whether or not GCC's relatively aggressive assumption that an undefined behavior gave it the reasonable and useful right to presume that any expression which may be interpreted as having undefined semantics may be presumed to either mystically never or always occur depending on it's whim, regardless of practical reality. Overall, it would seem there should be a more practical and consistent basis applied.
Who should fix platforms broken by extern inline hack?
Hi all, There are two platforms on which mainline is broken: * bootstrap is broken for i386-netbsd, see PR30058 * the compiler built on i386-mingw32 is unusable, see PR30589 Both regressions were introduced by Geoffrey Keating (http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a "C99 extern inline" patch. Fixincludes were then created for glibc systems. In both cases, I'm ready to debug (I attached the full preprocessed source of minimal examples to both PR) and test patches, but I simply don't know whom I should ping to get bootstrap working again: Geoffrey, who introduced the change that broke so many platforms, or the maintainers for these branches? (it might be worth noting at that point that netbsd doesn't have a maintainer listed) There has been some amount of chatting recently about the development plan for GCC, and I think we can all agree that having broken bootstrap for months on some platform don't help us get more testing :) Thanks for helping me understand the workings of the GCC community, FX
Re: Failure to build libjava on 512MB machine
Marco Trudel writes: > Andrew Haley wrote: > > Gerald Pfeifer writes: > > > I can no longer build libjava on a machine with "just" 512MB of main > > > memory (FreeBSD/i386 5.4 in this case). > > > > > > Three weeks ago the build worked on that very machine; did we raise > > > our minimum requirements > > > > We just imported a whole new release of the Classpath library, and > > it's big. But that doesn't explain this bug. > > You mean 0.93, right? Strictly speaking it's the (former) generics branch from Classpath, but yes. > > > or is this simply a bug? > > > > I think so. javax/swing/text/html/parser is quite small: > > > > $ /usr/bin/time make javax/swing/text/html/parser.lo > > What? No way! I always thought this must be something about 7gb or so. > Compiling my canadian cross mingw takes 2h. 40min to 50min is spend for > compiling html/parser... > I think a linux normal build (static, 32bit) also needs about 2h. A > cross host=mingw target=linux took only 50min to my surprise. > > 0.53user 0.16system 0:00.74elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k > > 0inputs+0outputs (0major+26369minor)pagefaults 0swaps > > > > $ ls -lh javax/swing/text/html/.libs/parser.o > > -rw-r--r-- 1 aph aph 260K Jan 30 11:44 javax/swing/text/html/.libs/parser.o > > > > I don't know why it is using so much memory in your case. > > I assume is has something to do with optimization. I think I was compiling the wrong file. There's gnu/javax/swing/text/html/parser.lo and javax/swing/text/html/partser.lo, which is much larger. Sorry. Anyway, I tried again, this time with the right file, and it took 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k and indeed, it does want a lot of memory - at peak some 550m. It'll be smaller on a 32-bit box, but not much smaller. Andrew.
Re: After GIMPLE...
On 29 Jan 2007 11:38:15 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: I don't see why you would have to modify any code in the frontend. You would modify the middle-end code. Rebuilding the compiler would rebuild cc1, cc1plus, etc. Well, I spent the morning looking at the code and since what I need is only the flow of gcc up until I have the GIMPLE tree, I could add a pass after the pass which generates the gimple tree, in that pass I do what I need with the gimple tree and then call exit(). Would this be a good idea? If yes, then the idea would be to create a pass and add it in passes.c after the line NEXT_PASS (pass_lower_cf); since from what I heard in #gcc, this is where the gimple tree is created, right? Ian -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Signed into overflow behavior in the security context
On Tue, 2007-01-30 at 07:02 -0500, Paul Schlie wrote:
> > There is no license to reason about how you think code is
> generated, any
> > compiled is allowed to generate code AS IF a trap representation
> were present.
>
> - yes, and thereby inconsistent with reality, and thereby wrong.
> (as may and may not are equivalent possibilities)
Now things get really undefined :-) I think there aren't even
sufficiently many GCC users who take the time to analyze their
realities in relation to all of C, object code, CPU, etc.
A difficult job, after all. Where and how can we attribute any
consistency here?
I don't think it is practical to have GCC implement a different
C language that happens to be consistent with a more or less
arbitrary set of expectations that some people share in some
cases but likely don't share in other cases. Do the writers
of GCC know that there is a shared expectation by its many users
that GCC should stop optimizing and provide some arbitrary rules
as to what values there will be, for cases involving C-undefined
variables? (There would be _many_ value combinations to choose
from ...)
John F. Woods, inventor of the nasal demons, says
http://odetocode.com/Blogs/scott/archive/2004/07/29/363.aspx#494
I suggest that the efforts spent in this discussion could be
transferred to a project improving a gcc based tool that finds
sore spots in C programs and gives hints.
If -O -Wextra or splint -strict don't do enough.
int main(void)
{
signed int x;
x = x;
x ^= x;
x = ((int (*)())x)();
return x;
}
Splint 3.1.1 --- 06 Jan 2006
foo.c: (in function main)
foo.c:4:8: Variable x used before definition
An rvalue is used that may not be initialized to a value on some
execution path. (Use -usedef to inhibit warning)
foo.c:5:4: Left operand of ^= is not unsigned value (int): x ^= x
An operand to a bitwise operator is not an unsigned values. This
may have unexpected results depending on the signed
representations. (Use -bitwisesigned to inhibit warning)
gcc -Wextra -O foo.c
foo.c: In function 'main':
foo.c:4: warning: 'x' is used uninitialized in this function
./a.out
Segmentation fault
-- Georg Bauhaus
Re: Signed into overflow behavior in the security context
Paul Schlie wrote: - as trap representation within the context of C is a value representation which is not defined to be a member of a type, where if accessed or produced evokes undefined behavior; so admit as to the best of my knowledge all potentially enclosable values for IEEE floats and doubles are defined, it would seem trap representations don't exist in typical fp implementations, as such an implementation would require more bits of encoding than the type itself requires. You don't think a signalling NaN is a trap value? The existence of such values (which do indeed cause a trap if loaded), is one of the inspirations for the C language and design in this respect.
Re: Signed into overflow behavior in the security context
Paul Schlie wrote: - yes, and thereby inconsistent with reality, and thereby wrong. (as may and may not are equivalent possibilities) The standard is the only reality here. If you cannot deduce semantic behavior from the semantic model of the standard, then you cannot deduce it. You are not allowed to augment the standard with reasoning based on what you think is consistent with the reality of chips and compilers. A test is only valid if it has fully defined behavior according to the standard. An implementation is only invalid if there is a valid test that fails. This does not preclude the possibility of having a given C compiler define behavior in an undefined situation, but I don't see any support for trying to define the effect of referencing uninitialized variables. THe signed overflow situation is indeed different, but if you try to make a general argument that all undefined behavior should be defined in gcc, then you have no hope of any consensual agreement to such a proposal, or even a significant minority agreement.
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On Sun, Jan 28, 2007 at 12:43:36AM +0100, Richard Guenther wrote: > >Can you explain what went through your mind when you picked the > >tree_exp.complexity field for something implemented new... :-( > > Not much... > > http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01117.html > > "... but my brain isn't working anymore." (Did my mailer miss the original message? This thread seems to start with Richard's reply...) Pretty much I couldn't think of anything else reasonable at the time. I figured that when the time *did* come to actually remove that field, we'd think of something. r~
Re: Signed int overflow behavior in the security context
Paul Schlie wrote: The root of this discussion was based on whether or not GCC's relatively aggressive assumption that an undefined behavior gave it the reasonable and useful right to presume that any expression which may be interpreted as having undefined semantics may be presumed to either mystically never or always occur depending on it's whim, regardless of practical reality. Right, that's what the standard says, and what programmers should expect, and what compilers typically do in practice when optimizing at the highest level Overall, it would seem there should be a more practical and consistent basis applied. Use of the passive implies some general consensual agreement to the statement. I know you, Paul, think this is the case, but I don't see even the beginnings of a consensus, and of the C standards committee disagrees with this approach.
Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!
On Tue, Jan 30, 2007 at 08:36:47AM +0100, Paolo Bonzini wrote: > * cp/cp-tree.h (OMP_ATOMIC_CODE): Delete. > (OMP_ATOMIC_DEPENDENT_P): Rewrite. > * cp/pt.c (tsubst_expr): Adjust for new format of dependent OMP_ATOMIC > expressions. > * cp/semantics.c (finish_omp_atomic): Store a whole expression node > in operand 1, and integer_zero_node in operand 0, for dependent > OMP_ATOMIC. Rewrite to make flow easier to understand. Ok. r~
Re: Signed into overflow behavior in the security context
On Tue, Jan 30, 2007 at 10:49:02AM -0500, Robert Dewar wrote: > Paul Schlie wrote: > > >- as trap representation within the context of C is a value > >representation which is not defined to be a member of a type, where if > >accessed or produced evokes undefined behavior; so admit as to the best of > >my knowledge all potentially enclosable values for IEEE floats and doubles > >are defined, it would seem trap representations don't exist in typical fp > >implementations, as such an implementation would require more bits of > >encoding than the type itself requires. > > You don't think a signalling NaN is a trap value? I do. > The existence of > such values (which do indeed cause a trap if loaded), If loaded? This is a very approximate description. For all architectures I use, it is rather "if used as an operand of an arithmetic instruction", but the values can be copied around without ever generating a trap. Even negating or taking the absolute value never traps since those are not considered "arithmetic" instructions. And even then you have to explicitly enable the trap for invalid operation (on systems using IEEE754), otherwise it is simply propagated as a QNaN. I remember that the VAX had separate instructions for moving floats and ints (of the same size) and the only difference between them was that move floating point instruction would trap on the "reserved operand" value (zero exponent and sign bit set). However compilers did not actually use the floating point move instructions (probably for performance reasons). Gabriel
Re: Interesting build failure on trunk
Ismail Dönmez <[EMAIL PROTECTED]> writes: > I am getting this when I try to compile gcc trunk: > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings > -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute > -pedantic -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include > -I../../libcpp/include -c -o > files.o -MT files.o -MMD -MP -MF .deps/files.Po ../../libcpp/files.c > ../../libcpp/files.c: In function 'read_name_map': > ../../libcpp/files.c:1238: internal compiler error: Floating point exception > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. libcpp/files.c:1238 seems to be a call to memcpy. I don't see anyplace a floating point exception might come from. I've certainly never seen anything like that. Ian
Re: Who should fix platforms broken by extern inline hack?
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes: > There are two platforms on which mainline is broken: > * bootstrap is broken for i386-netbsd, see PR30058 > * the compiler built on i386-mingw32 is unusable, see PR30589 > > Both regressions were introduced by Geoffrey Keating > (http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a "C99 > extern inline" patch. Fixincludes were then created for glibc systems. > > In both cases, I'm ready to debug (I attached the full preprocessed > source of minimal examples to both PR) and test patches, but I simply > don't know whom I should ping to get bootstrap working again: > Geoffrey, who introduced the change that broke so many platforms, or > the maintainers for these branches? (it might be worth noting at that > point that netbsd doesn't have a maintainer listed) This is just my opinion. Technically, Geoff is responsible for breaking bootstrap with his patch. As a practical matter, Geoff probably does not have access to those platforms, so while he knows a lot about gcc and has the ability to approve the patches, he won't be able to test them, so you will do better to send your patches to the attention of the appropriate maintainers as well as Geoff. There is in fact a NetBSD maintainer: Jason Thorpe, [EMAIL PROTECTED] (Last I heard, he also works for Apple.) By the way, I've started looking into straightening out what I consider to be the current extern inline mess. Ian
Re: Interesting build failure on trunk
> libcpp/files.c:1238 seems to be a call to memcpy. I don't see > anyplace a floating point exception might come from. I've certainly > never seen anything like that. Division by zero somewhere? -- Eric Botcazou
Re: GCC 4.1.2 RC1
On Tuesday 30 January 2007 11:44, Robert Schwebel wrote: > On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote: > > If you do encounter problems, please file a Bugzilla PR, and add me to > > the CC: list for the issue. Please do not send me reports without first > > filing a PR, as I am unable to keep track of all the issues if they are > > not in the database. > > It looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675 is fixed > in 4.2, because in our autobuild runs we don't see the ICE any more. > However, the bugzilla entry doesn't mention a fix for the problem. Paul, > have you done something in 4.2 which might be backported to 4.1? I never managed to fix it, so I expect it's still latent. I've added my analysis to the PR. Paul
How to get rid of attribute(mode(word))?
Hello, I've grepped through the remaining uses of Unwind_Word in libgcc and the related word_mode uses in gcc and would like to discuss how to go on with these. One target is to identify more places where we can get rid of _Unwind_Word. Other places exist where we definitely need a data type like _Unwind_Word representing a general purpose register. So we have to find a way to define _Unwind_Word without using the mode(word) attribute. Unfortunately all changes in exception handling data structures have the risk of breaking the ABI. The problem is that there might be unwinding code using the old data structures copied or statically linked to binaries. This binary might be executed together with a language library (like libstdc++) containing a personality function expecting the new data structures and vice versa. So at first all data structures used to interface with the personality function must not be changed. And probably there are several other ABI issues I'm currently not aware of. Here is the list of mode(word) related data types together with a few comments on how I think we might handle those: Within gcc: except.c: word_mode is used in init_eh to define the SjLj_Function_Context data structure. I think the data types can be made matching the unwind-sjlj.c definition using a new target macro. sjlj_emit_dispatch_table emits code accessing the data member of the SjLj_Function_Context using UNITS_PER_WORD to step from one element to the next. This has to match the data type used for the "data" member using the target macro mentioned above. c-common.c: handle_mode_attribute: This word_mode use of course goes away with the mode(word) type attribute. Within libgcc: unwind-dw2.h: Here the _Unwind_FrameState structure is defined. This structure seems to be used locally only. The members using _Unwind_Word types look to me as they can safely use unsigned long instead of _Unwind_Word or _Unwind_Ptr for addresses. _Unwind_Word reg; _Unwind_Sword offset; _Unwind_Sword cfa_offset; _Unwind_Word cfa_reg; _Unwind_Sword data_align; _Unwind_Word code_align; _Unwind_Word retaddr_column; unwind-compat.c: Defines wrapper functions for interfacing with libunwind. Here the data type used by libgcc for registers (_Unwind_Word) has to be translated to the data type used by libunwind (which is unsigned long). These functions must know what libgcc unwinding code considers a register type so we are bound to _Unwind_Word I think. unwind-sjlj.c: The data field of SJLJ_Function_Context contains the data array with 4 _Unwind_Word fields. The data type must match what init_eh uses - which is word_mode. See except.c:init_eh above. unwind-generic.h: Defines the _Unwind_Exception structure. This structure is passed to the language personality function which might be defined in a different shared library. So I think it is not safe to change this structure in any way. The _Unwind_GetGR SetGR functions allow the personality function to manipulate registers during unwinding. I think we are bound to something like _Unwind_Word. unwind-dw2.c: Defines _Unwind_Context. Passed to the personality function so the _Unwind_Exception argument applies here as well. _Unwind_Word is also used in uw_install_context_1 to check whether dwarf registers have pointer or register size. execute_stack_op uses an array representing the registers which are object to dwarf operations. Independenly on whether we can further reduce the _Unwind_Word uses we have to provide a data type to libgcc which is appropriate for holding the value of a general purpose register. I think it can be done the same way we do it for the long double stuff. Define a macro in the .h file which is available for IN_LIBGCC2 only. Comments and suggestions are welcome. Bye, -Andreas-
Re: GCC 4.1 Branch Frozen in Preparation for GCC 4.1.2 RC1
On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote: > I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time. > > Therefore, please do not make any checkins to the 4.1 branch after 2PM > PST. Once RC1 is uploaded, the branch will be open only for changes > which have my explicit approval, until the release. > > Remember that the primary criteria for 4.1.2 is that it not contain > regressions from earlier 4.1.x releases. PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a regression from 4.1.1. A patch was posted earlier this month at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have regrettably forgotten to ping this patch (for which I think David's approval was only for the 4.2 branch). In any case, I don't have SVN write access and will need someone else to commit the patch. -- Rask Ingemann Lambertsen
Re: Who should fix platforms broken by extern inline hack?
On 30/01/2007, at 8:48 AM, Ian Lance Taylor wrote: "François-Xavier Coudert" <[EMAIL PROTECTED]> writes: There are two platforms on which mainline is broken: * bootstrap is broken for i386-netbsd, see PR30058 * the compiler built on i386-mingw32 is unusable, see PR30589 Both regressions were introduced by Geoffrey Keating (http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a "C99 extern inline" patch. Fixincludes were then created for glibc systems. In both cases, I'm ready to debug (I attached the full preprocessed source of minimal examples to both PR) and test patches, but I simply don't know whom I should ping to get bootstrap working again: Geoffrey, who introduced the change that broke so many platforms, or the maintainers for these branches? (it might be worth noting at that point that netbsd doesn't have a maintainer listed) This is just my opinion. Technically, Geoff is responsible for breaking bootstrap with his patch. As a practical matter, Geoff probably does not have access to those platforms, so while he knows a lot about gcc and has the ability to approve the patches, he won't be able to test them, so you will do better to send your patches to the attention of the appropriate maintainers as well as Geoff. As it turns out, I do now have access to a NetBSD system, and will look at that problem when I next get time. My understanding from 30589 is that a sufficiently recent version of mingw32 has solved the problem. smime.p7s Description: S/MIME cryptographic signature
Re: Who should fix platforms broken by extern inline hack?
As it turns out, I do now have access to a NetBSD system, and will look at that problem when I next get time. Thanks. When you provid a patch, I will test it. (If someone else ever wants access to a netbsd system, it's worth noting there's one on the GCC compile farm!) My understanding from 30589 is that a sufficiently recent version of mingw32 has solved the problem. The CVS version of mingw32 has the workaround, but most people aren't using the CVS mingw32 (most people aren't using the last released version anyway), so there'll be a need for a fix anyway. FX
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > I am getting this when I try to compile gcc trunk: > > > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -Wmissing-format-attribute -pedantic > > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include > > -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF > > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function > > 'read_name_map': > > ../../libcpp/files.c:1238: internal compiler error: Floating point > > exception Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > libcpp/files.c:1238 seems to be a call to memcpy. I don't see > anyplace a floating point exception might come from. I've certainly > never seen anything like that. FWIW I configure like this: ../configure --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-libssp --disable-nls --enable-ssp --enable-libstdcxx-allocator=new --enable-version-specific-runtime-libs --without-included-gettext --with-system-zlib --prefix=/usr/share/gcc-snapshot --enable-languages=c,c++ And make with : make STAGE1_CFLAGS="-O" BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE" profiledbootstrap Regards, ismail
Re: Interesting build failure on trunk
> make STAGE1_CFLAGS="-O" > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE" > profiledbootstrap Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler. -- Eric Botcazou
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote: > > make STAGE1_CFLAGS="-O" > > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer > > -U_FORTIFY_SOURCE" profiledbootstrap > > Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler. Ok btw bootstrapping compiler is, Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/pisi/gcc-4.2.0-15/work/gcc-4.2-20070102/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0 --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj --disable-libssp --disable-multilib --disable-nls --disable-werror --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new --enable-shared --enable-ssp --enable-threads=posix --enable-version-specific-runtime-libs --without-included-gettext --without-system-libunwind --with-system-zlib Thread model: posix gcc version 4.2.0 20070124 (prerelease) (Pardus Linux) Regards, ismail
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote: > > make STAGE1_CFLAGS="-O" > > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer > > -U_FORTIFY_SOURCE" profiledbootstrap > > Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler. And I am still getting floating point exception even with a bare make. Any way to debug this? Regards, ismail
Re: Interesting build failure on trunk
Ismail Dönmez wrote: On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote: make STAGE1_CFLAGS="-O" BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE" profiledbootstrap Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler. And I am still getting floating point exception even with a bare make. Any way to debug this? Paste the failing gcc invocation from your make output into the shell but add -v so you can see the commands passed to the various compiler components. Then run the failing component in gdb with a command similar to that reported by gcc -v. At least that is the way I would do it. David Daney.
Re: Interesting build failure on trunk
> And I am still getting floating point exception even with a bare make. Any > way to debug this? Not easily unless you already know the innards of the compiler, I'm afraid. -- Eric Botcazou
Re: Failure to build libjava on 512MB machine
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: Andrew> Anyway, I tried again, this time with the right file, and it took Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k Andrew> and indeed, it does want a lot of memory - at peak some 550m. It'll Andrew> be smaller on a 32-bit box, but not much smaller. I suppose with some awful build hacking we could split this .o into multiple parts. I'm fine with the situation as it is, myself, but I will do this if the consensus is that we should. Tom
Re: [PATCH for] Re: gcc-4.0-20070128 is now available
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Gerald Pfeifer <[EMAIL PROTECTED]> writes: > > | On Sun, 28 Jan 2007, Joe Buck wrote: > | > It's probably time to turn off 4.0 snapshots; the last ones will > | > probably be Gaby's prerelease snapshots, and the release should come > | > soon. > | > | That's a good idea. You're right, there is no need to wait until > | the 4.0.4 release itself. > > completely agreed. > > -- Gaby Also, don't forget to remove gcc-4.0 from ~gccadmin/scripts/update_version*
Re: GCC 4.1 Branch Frozen in Preparation for GCC 4.1.2 RC1
Rask Ingemann Lambertsen wrote: > On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote: >> I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time. >> >> Therefore, please do not make any checkins to the 4.1 branch after 2PM >> PST. Once RC1 is uploaded, the branch will be open only for changes >> which have my explicit approval, until the release. >> >> Remember that the primary criteria for 4.1.2 is that it not contain >> regressions from earlier 4.1.x releases. > >PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a > regression from 4.1.1. A patch was posted earlier this month at > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have > regrettably forgotten to ping this patch (for which I think David's approval > was only for the 4.2 branch). In any case, I don't have SVN write access and > will need someone else to commit the patch. Joseph, David, do you have any comments about this patch? The same clearly erroneous code (i.e., the incorrect use of "findstring") does appear on the 4.1 branch. Therefore, my inclination would be to apply the patch. However, I'm not able to effectively test the patch, so I would appreciate your feedback. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1 Branch Frozen in Preparation for GCC 4.1.2 RC1
On Tue, 30 Jan 2007, Mark Mitchell wrote: > >PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a > > regression from 4.1.1. A patch was posted earlier this month at > > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have > > regrettably forgotten to ping this patch (for which I think David's approval > > was only for the 4.2 branch). In any case, I don't have SVN write access and > > will need someone else to commit the patch. > > Joseph, David, do you have any comments about this patch? The same > clearly erroneous code (i.e., the incorrect use of "findstring") does > appear on the 4.1 branch. Therefore, my inclination would be to apply > the patch. However, I'm not able to effectively test the patch, so I > would appreciate your feedback. I think it should be applied to 4.1 and 4.2 branches. (For trunk, the issue is fixed properly, by toplevel libgcc removing the need for findstring in conjunction with E500 long double making -mlong-double-128 a supported option in this case so removing the underlying ICE.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.1.2 RC1
Robert Schwebel wrote: > What about PR28516, would it be acceptable for 4.1.2? There are two issues: (1) it's not marked as a 4.1 regression, let alone a regression from 4.1.x. Did this test case work with older versions of GCC? (2) Richard Earnshaw objected to applying the patch to 4.1 because it requires a newer GAS. Paul's counter that the newer GAS is only needed if your compiler would otherwise crash seems persuasive to me, if true, but I'd certainly want Richard to be comfortable with the change. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.2 RC1
On Wednesday 31 January 2007 01:26, Mark Mitchell wrote: > Robert Schwebel wrote: > > What about PR28516, would it be acceptable for 4.1.2? > > There are two issues: > > (1) it's not marked as a 4.1 regression, let alone a regression from > 4.1.x. Did this test case work with older versions of GCC? 4.1 is the first FSF release to support arm-linux-gnueabi (the bug only effects eabi targets). The bug is preset in 4.0, but apparently noone other than glibc uses nested functions with -fexceptions. Paul
Re: Failure to build libjava on 512MB machine
On Tue, 30 Jan 2007, Andrew Haley wrote: > 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k > > and indeed, it does want a lot of memory - at peak some 550m. It'll > be smaller on a 32-bit box, but not much smaller. Ouch. I can confirm that on a 32-bit box of mine it fails with about 500MB of main memory. On Tue, 30 Jan 2007, Tom Tromey wrote: > I suppose with some awful build hacking we could split this .o into > multiple parts. I'm fine with the situation as it is, myself, but I > will do this if the consensus is that we should. Please, pleeease. This really hurts. No I can no longer build libgcj on my notebook and one or two older (but not that old) testers of mine. Ger ``begging'' ald
Re: Signed into overflow behavior in the security context
Gabriel Paubert wrote: For all architectures I use, it is rather "if used as an operand of an arithmetic instruction", but the values can be copied around without ever generating a trap. Even negating or taking the absolute value never traps since those are not considered "arithmetic" instructions. On some architectures the load causes a trap, and that means for example that you cannot use fpt load/store to move non-fpt stuff. But yes, of course the description is approximate, since the behavior of signalling nan's is unspecifed by the standard! And even then you have to explicitly enable the trap for invalid operation (on systems using IEEE754), otherwise it is simply propagated as a QNaN. That's not guaranteed
Re: GCC 4.1 Branch Frozen in Preparation for GCC 4.1.2 RC1
Joseph S. Myers wrote: > On Tue, 30 Jan 2007, Mark Mitchell wrote: > >>>PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a >>> regression from 4.1.1. A patch was posted earlier this month at >>> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have >>> regrettably forgotten to ping this patch (for which I think David's approval >>> was only for the 4.2 branch). In any case, I don't have SVN write access and >>> will need someone else to commit the patch. >> Joseph, David, do you have any comments about this patch? The same >> clearly erroneous code (i.e., the incorrect use of "findstring") does >> appear on the 4.1 branch. Therefore, my inclination would be to apply >> the patch. However, I'm not able to effectively test the patch, so I >> would appreciate your feedback. > > I think it should be applied to 4.1 and 4.2 branches. (For trunk, the > issue is fixed properly, by toplevel libgcc removing the need for > findstring in conjunction with E500 long double making -mlong-double-128 a > supported option in this case so removing the underlying ICE.) Thanks for the feedback. David mentioned that he's traveling until Friday, and I want to let him comment. So, I've put the PR on the 4.1.2 Status Wiki page, and I will review it before the release. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.2 RC1
Paul Brook wrote: > On Wednesday 31 January 2007 01:26, Mark Mitchell wrote: >> Robert Schwebel wrote: >>> What about PR28516, would it be acceptable for 4.1.2? >> There are two issues: >> >> (1) it's not marked as a 4.1 regression, let alone a regression from >> 4.1.x. Did this test case work with older versions of GCC? > > 4.1 is the first FSF release to support arm-linux-gnueabi (the bug only > effects eabi targets). The bug is preset in 4.0, but apparently noone other > than glibc uses nested functions with -fexceptions. OK; in that case, I don't think this qualifies as a regression from a previous 4.1.x release. But, I'd certainly consider it within the discretion of the ARM maintainers to put this patch on the 4.1 branch after 4.1.2 is out, as it's a simple ARM-only patch. That assumes, of course, that everyone agrees about the GAS issue. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
MIPS Wrong-code regression.
Richard, Sometime between 1/7 and 1/16 on the trunk I started getting wrong code on a bunch of java testcases under mipsel-linux. It looks related to (but not necessarily caused by) this patch: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html For example if we examine the assembler output of the PR9577.java testcase, we see: . . . $LBB2: lw $2,40($fp) sw $2,24($fp) lw $2,24($fp) move$4,$2 .option pic0 jal _ZN4java4lang6ObjectC1Ev nop .option pic2 lw $28,16($fp) $LBE2: move$sp,$fp lw $31,36($sp) lw $fp,32($sp) addiu $sp,$sp,40 j $31 nop The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, even though that symbol is defined in libgcj.so. The assembler and linker conspire to jump to address 0x for this call. It looks like the logic that decides if a symbol is external to the compilation unit is faulty. Any ideas about where it might have gone wrong? I will try to look into it more tomorrow. Thanks, David Daney
Re: MIPS Wrong-code regression.
David Daney <[EMAIL PROTECTED]> writes: > Sometime between 1/7 and 1/16 on the trunk I started getting wrong code > on a bunch of java testcases under mipsel-linux. > > It looks related to (but not necessarily caused by) this patch: > > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html > > For example if we examine the assembler output of the PR9577.java > testcase, we see: > > . > . > . > $LBB2: > lw $2,40($fp) > sw $2,24($fp) > lw $2,24($fp) > move$4,$2 > .option pic0 > jal _ZN4java4lang6ObjectC1Ev > nop > > .option pic2 > lw $28,16($fp) > $LBE2: > move$sp,$fp > lw $31,36($sp) > lw $fp,32($sp) > addiu $sp,$sp,40 > j $31 > nop > > The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, even > though that symbol is defined in libgcj.so. The assembler and linker > conspire to jump to address 0x for this call. > > It looks like the logic that decides if a symbol is external to the > compilation unit is faulty. > > Any ideas about where it might have gone wrong? Not off-hand. I think -mno-shared is using the right interfaces to test for locality. > I will try to look into it more tomorrow. Thanks, let me know how it goes. I won't have any time to do out-of-hours gcc stuff today, but might tomorrow night. Richard
