gnattools folder and GCC snapshots
Hi, IMHO "gnattools" should be added to "ADA_DIRS" in "gcc_release" to generate snapshots properly. Otherwise, people who do not download and install "gcc-ada" tarballs will get a bootstrap error. I no longer use official GCC source snapshots, but I still ran into this issue as I make a copy of the CVS sources containing only files needed by C, C++ and Java and discovered that my bootstrap was broken since the beginning of this week. That is, something like the following (untested) patch: Index: ChangeLog from Ranjit Mathew <[EMAIL PROTECTED]> * gcc_release (ADA_DIRS): Add "gnattools". Index: gcc_release === --- gcc_release 2005-03-01 12:18:06.0 +0530 +++ gcc_release 2005-03-01 12:18:43.0 +0530 @@ -583,5 +583,5 @@ SOURCE_DIRECTORY="" # The directories that should be part of the various language-specific # tar files. These are all relative to the top of the source tree. -ADA_DIRS="gcc/ada libada" +ADA_DIRS="gcc/ada libada gnattools" CPLUSPLUS_DIRS="gcc/cp libstdc++-v3" FORTRAN_DIRS="gcc/f libf2c" Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Java Classes and Non-virtual Destructors
Hi Mark,
After your patch for PR c++/19733, there have been tonnes
of warnings during a libjava build complaining about "class
Foo has virtual functions but non-virtual destructor".
Here's a simple testcase:
-- 8< --
~/tmp > cat y.cpp
extern "Java"
{
class Foo
{
public:
virtual void bar( void);
};
}
~/tmp > mygxx -Wall -fsyntax-only y.cpp
y.cpp:4: warning: 'class Foo' has virtual functions but non-virtual destructor
-- 8< --
If I do add a virtual destructor, I get:
-- 8< --
~/tmp > mygxx -Wall -fsyntax-only y.cpp
y.cpp:7: error: Java class 'Foo' cannot have a destructor
-- 8< --
which is correct, AFAICT.
Therefore, can you please suppress the warning for a "Java"
C++ class?
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Using fold() in frontends
Giovanni Bajo wrote: > > It looks like the general consensus is that we should not use fold() anymore > in the frontends (I consider gimplify part of middle-end already, as it is > mostly language-independent). I know Java people also are trying to remove > usage of fold() since it produces simplifications which are not allowed in > the Java semantics of constant expressions. Not quite correct - *some* folding is still needed in Java: http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#5313 As Mark points out for C++, writing a java_fold() for these ought to be simple and we can avoid calling fold() altogether before semantic analysis has finished. I know Tom would be very happy with this scheme. :-) Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: HEAD regression: All java tests are failing with an ICE when optimized
Andrew Haley wrote: > HEAD, clean build this morning. i686-linux-gnu. > > With the libgcj "make check", there are many identical failures. > > These are of the form > > PR4766.java: In class 'PR4766': > PR4766.java: In method 'PR4766.myfunction()': > PR4766.java:0: internal compiler error: in hash_scan_set, at > postreload-gcse.c:741 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > compiler exited with status 1 > > And the ICE is always in hash_scan_set. > > I do not believe that this is a Java FE bug. > > Has anyone else seen this? First off, I didn't when I ran my regular bootstrap + libjava_check cycle. That's because I use "--disable-checking". Second, it's most likely caused by Nathan's assertifying patch to gcc/p*.c: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00227.html Note that the "#ifdef ENABLE_CHECKING" guard in postreload-gcse.c (around line #741) was *misspelt* before: - #ifdef ENABLE_CHEKCING and was thus never being executed before. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 4.0 RC1 Available
Geoffrey Keating wrote: [...] > which I see you've already committed a patch for, and a large number > of Java failures. > > You can see full test results at [...] > > <http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html> > > for 4.0.0-20050410. It might be helpful to put your "libjava.log" somewhere or if all the Java failures seem similar, to post the error messages around the "FAIL" lines from your libjava.log. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 4.0 RC1 Available
> Exception in thread "main" java.lang.RuntimeException: test failed:5 > <> > FAIL: Array_3 -O3 execution - bytecode->native test This one is expected I think, though not XFAILed (it fails only at -O3). BTW, you keep getting "<>" everywhere - is addr2line from binutils not present somewhere in your default executable search path? Beyond this, the other FAILs seem to be the result of the Java interpreter (gij) getting confused about loading classes. You might try: http://gcc.gnu.org/ml/java/2005-04/msg00075.html but it might or might not help. Sorry for being this vague, but without access to a Darwin machine and any knowledge about that system, I can't shed much light on these FAILs. Ranjit. PS: As Andrew Pinski remarked, I wonder why you don't see these on mainline? Perhaps Tom missed a hunk or two while backporting his patch? -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
"make bootstrap" for cross builds
Hi, I think "make bootstrap" does not make sense for cross builds. We however seem to allow it but fail in a weird way later on (as on mainline). I think this should not be allowed. I discovered this when I mistakenly typed "make bootstrap" out of habit on a cross build. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 4.1: Buildable on GHz machines only?
Per Bothner wrote: > Mark Mitchell wrote: > >>Building libjava takes forever on any platform, relative to the rest of >>the compiler build. [...] > One way to speed up libcgj compilation by quite a bit would be to > compile more than one .java file at a time. For example: >gcj -c java/util/*.java -o java-util.o > This reduces libtool overhead, reduces the duplication in reading > dependencies, and probably reduces link overheads. It can also > produce better code, since intermodule references get trurned into > intramodule references. This just requires Makefile-hacking. [...] > Ideally, there'd be a configure flag to control "chunking". Note that libgcj already supports an "--enable-libgcj-multifile" configuration option that coarsely attempts to do the above. See: http://gcc.gnu.org/ml/java-patches/2003-q3/msg00658.html Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 4.1: Buildable on GHz machines only?
Ranjit Mathew wrote: >>Ideally, there'd be a configure flag to control "chunking". > > > Note that libgcj already supports an "--enable-libgcj-multifile" > configuration option that coarsely attempts to do the above. > > See: > > http://gcc.gnu.org/ml/java-patches/2003-q3/msg00658.html I tried this out by bootstrapping mainline on i686-pc-linux-gnu (RHEL 3AS U4, P4 2.4GHz, 1GB RAM, 512MB Swap) and found *no difference* in the total bootstrap time. :-/ Either this option has bitrotted or something else undoes its effect. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 4.1: Buildable on GHz machines only?
On 05 May 2005 17:01:05 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote: > >>>>> "Rutger" == Rutger Ovidius <[EMAIL PROTECTED]> writes: > > RH> But still largely useless. Who in their right mind is going to > RH> use an 83MB static library when a shared library is available. > > Rutger> Everyone on win32 builds libgcj static, and probably wants to keep it > Rutger> that way if they plan to distribute their apps. > > I thought the reason everybody on win32 built static was that there > was no choice. Is it really preferable? The native libgcj library on Win32 is around 32MB and the JAR is around 8MB (as of 4.0 and judging from Mohan's distribution found in http://www.thisiscool.com/gcc_mingw.htm). If you are building a small and nifty application in Java, it would be unreasonable for you to expect your users to either download the whole Java runtime (either Sun's JRE or GCJ) separately or to have you bundle it with your application. It also doesn't help that the Java runtime is a moving target (in Sun's JRE and more so in GCJ) so you need to keep updating it for new apps or newer versions of existing apps. It keeps bloating at an alarming rate too. It's a similar case for MS .NET. Is it small wonder then that these have not penetrated much outside of enterprises? Even there, you find that many an enterprise software product implemented in Java comes with its own JRE (or even JDK). It's not uncommon to find *many* JREs on the machine of a single enterprise software developer or on a server. Static linking in GCJ and SWT offer a chance to get out of this vicious cycle, though it does lead to (a relatively small) duplication between various such applications. Many a time, it is the only way people are going to even bother trying out your application. One day, Java/GCJ would have stabilised and matured enough for this requirement to go away, but till then it's a crucial intermediate step for platforms like Win32. Ranjit. > I'm sympathetic to folks who want static builds for various reasons. > I wouldn't mind an option to allow libgcj to be built in some reduced > form, either; though it would be up to the folks using this mode to > maintain it. > > Tom > -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Borland software patent restricting GNU compiler development
Florian Weimer wrote: > * Ingrid Marson: > > >>The Borland patent is a patent for standard exception handling >>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL >>&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628, >>016&RS=PN/5,628,016 > > > At least on Linux, GCC implements a different scheme which is > optimized for the more common case of execution without throwing any > exception. Borland's approach doesn't even work without frame > pointers, so it's quite limited. > > Maybe the Windows ABI prescribes the use of Borland's approach? This > could explain the gripes of the WINE developers. Without looking at the patent, I would hazard the guess that it is about Win32 Structured Exception Handling (SEH): http://www.microsoft.com/msj/0197/exception/exception.aspx (The linked-to mail from the GCC mailing list seems to confirm this.) SEH is quite important in Windoze-land. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 3.4.4 RC1
Mark Mitchell wrote: > GCC 3.4.4 RC1 is available here: > > ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/ > > As usual, please test -- by using exactly those tarballs, so that we can > detect packging errors. Put problems into Bugzilla, and Cc: me. At > this point, the only problems that would block the release would be > serious regressions from previous 3.4.x compilers. i686-pc-linux-gnu (c,c++,java) testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00687.html I configured with "--with-arch=pentium4" and it could be the reason for the additional failures I see that (for example) Joe Buck doesn't: http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00682.html I am on Red Hat Enterprise Linux AS 3 Update 4 with: kernel: 2.4.21-27.ELsmp binutils: 2.14.90.0.4-35 glibc: 2.3.2-95.30 all as supplied by the vendor (Red Hat). The CPU is a P4 2.6GHz with HT enabled. Finally, for all the mail/Mail/mailx brouhaha, I posted the results by simply copy-pasting the summary into the Gmail interface for sending mail. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCC 4.1: Buildable on GHz machines only?
Jonathan Wilson wrote: >>Huh? I can cross-compile GCC, its all the packages that require >>native configuration/building > > Is it fesable for people in this sort of situation to build GCC on a fast > machine but with the final host and target both set to whatever the slower > machine is (in this case coldfire) > Does GCC even support that? Yes, this is called a crossed-native build and GCC does support it. I used to use it some time back for building GCJ for Win32: http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html You build a crossed-native compiler in two phases: 1. Build a cross compiler for $TARGET on a fast box. 2. Use the cross compiler to build a crossed-native compiler for $TARGET on the same box. I used to do it for Win32 simply for the reason that building under Linux (on the same box) was *way* faster and less error-prone than under Win32. I was going to suggest this to Peter myself before I saw your message. Ranjit. PS: Surely this must be one of the longest threads in recent times on the GCC list! PPS: I do not see some of the messages, for example, a couple of messages from Robert Dewar that seem to be referenced in other messages. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Bootstrap Times Improvements?
Hi, Between Tuesday and Wednesday (Indian time), something(s) went into mainline that is showing me a dramatic decrease in bootstrap times - a c,c++,java bootstrap on i686-pc-linux-gnu now takes 51m for me compared to 65-66m earlier, which is around 20% of savings over the course of a single day! So who do I thank for it? :-) I am not seeing bootstrap failures as others are, the Java testsuite runs are clean and the ChangeLogs indicate that my tree does have the latest changes... Are others seeing similar savings in bootstrap times too? FYI, I'm using 3.4.4 as a bootstrap compiler, binutils 2.16 (FSF) and configure with --disable-checking and --with-arch=pentium4. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Bootstrap Times Improvements?
On 5/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Ranjit Mathew wrote: > > Hi, > > > > Between Tuesday and Wednesday (Indian time), something(s) > > went into mainline that is showing me a dramatic decrease > > in bootstrap times - a c,c++,java bootstrap on i686-pc-linux-gnu > > now takes 51m for me compared to 65-66m earlier, which is > > around 20% of savings over the course of a single day! So > > who do I thank for it? :-) > > I do not know if it is entirely because of the patch to build libjava > one-directory-at-a-time. If it is, you should thank me :-) for the > patch, and rth for reviewing it very quickly. I suspect as much and so does Tom, so a big THANK YOU from me goes to you! :-) > If you want, you can help by testing the patch for PR17485 against > jacks; since a few days, I cannot get jacks to run (but I think it's my > fault, not the tree's). I'd be glad to. Can you point me to the patch? (Did you give the correct PR number, BTW?) Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Bootstrap Times Improvements?
On 5/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > > If you want, you can help by testing the patch for PR17485 against > jacks; since a few days, I cannot get jacks to run (but I think it's my > fault, not the tree's). FWIW, I tested your patch for PR17845 by doing a clean bootstrap and running the entire libjava testsuite (including Jacks) and found no regressions on i686-pc-linux-gnu. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Bootstrap Times Improvements?
On 5/19/05, Ranjit Mathew <[EMAIL PROTECTED]> wrote: [...] > FWIW, I tested your patch for PR17845 by doing a clean > bootstrap and running the entire libjava testsuite (including > Jacks) and found no regressions on i686-pc-linux-gnu. By "clean", I meant a CVS snapshot with your patch applied and the build directory completely cleaned out before "make bootstrap". Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Compiling GCC with g++: a report
Gabriel Dos Reis wrote: > Hi, > > I spent the week-end trying to get GCC -- mainline -- compilable > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). [...] > > I think this project is beneficial to GCC for several reasons: [...] > > (4) . Tom Tromey's GCJX (gcjx_branch in CVS), the completely rewritten Java front-end that is written in C++. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Google Summer of Code
Jeyasankar Kottalam wrote: > Hi, > > * Are the FSF and GCC interested in mentoring students under Google's Summer > of > Code? > > * What projects would the GCC maintainers like to see done for Google's Summer > of Code? Anything at http://gcc.gnu.org/projects/ ? Or do you have specific > project suggestions? I was a bit confused by this question since I hadn't read Slashdot yet. For the benefit of others, the reference is to: http://code.google.com/summerofcode.html Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Visual C++ style inline asms
Mike Stump wrote: > Any objections to adding Visual C++ style inline asms? Apart from what's been pointed out by RTH, you might also want to read the messages from the previous discussion on this subject initiated by Stan Shebs, if you haven't already: http://gcc.gnu.org/ml/gcc/2004-05/msg00070.html Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Bootstrap Failure (i686-pc-linux-gnu, --with-arch=pentium4)
Hi,
For two consecutive days, I have been unable to
build GCC mainline on i686-pc-linux-gnu:
- 8<
-
stage1/xgcc -Bstage1/ -B/home/ranmath/gcc/i686-pc-linux-gnu/bin/ -c
-O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Werror-DHAVE_CONFIG_H
-I. -Icp -I/home/ranmath/src/gcc/gcc-20050617/gcc
-I/home/ranmath/src/gcc/gcc-20050617/gcc/cp
-I/home/ranmath/src/gcc/gcc-20050617/gcc/../include
-I/home/ranmath/src/gcc/gcc-20050617/gcc/../libcpp/include/home/ranmath/src/gcc/gcc-20050617/gcc/cp/call.c
-o cp/call.o
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c: In function
'ix86_expand_vector_init':
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
error: insn does not satisfy its constraints:
(insn 367 343 378 4
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17047 (set
(reg:QI 138)
(const_int 0 [0x0])) 45 {*movqi_1} (nil)
(expr_list:REG_EQUIV (const_int 0 [0x0])
(nil)))
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
- 8<
-
I build with "--with-arch=pentium4 --disable-checking" and that
might explain why no one has apparently reported it yet. The
full configure invocation is:
- 8<
-
$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
--with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
--with-ld=/home/ranmath/gnu/bin/ld --with-gnu-ld \
--with-arch=pentium4 --with-tune=pentium4 \
--disable-nls --disable-checking --disable-libmudflap \
--disable-debug --enable-threads=posix --enable-__cxa_atexit
- 8<
-
I use FSF GCC 3.4.4 for bootstrapping and FSF binutils
2.16.
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Bootstrap Failure (i686-pc-linux-gnu, --with-arch=pentium4)
On 6/17/05, Volker Reichelt <[EMAIL PROTECTED]> wrote: > > > > For two consecutive days, I have been unable to > > build GCC mainline on i686-pc-linux-gnu: [...] > > I build with "--with-arch=pentium4 --disable-checking" and that > > might explain why no one has apparently reported it yet. > > It has already been reported, it's PR22089 ;-) > http://gcc.gnu.org/PR22089 FWIW, RTH's patch in: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01487.html allows me to complete bootstrap (c,c++,java) as well as run the libjava testsuite successfully. (Except for the "Divide_1" testcase that has started failing recently due to another as-yet-unknown-but-introduced-this-week back-end bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084 ) > Nobody patches reload without causing regressions. > Sometimes even looking hard at the code can cause failures. ;-) :-) http://gcc.gnu.org/wiki/reload seems to indicate something similar. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Error building 4.0.1-RC2
Mark Williams (MWP) wrote: > Thought i should report this... > > Building 4.0.1 RC2, i get this error: > > make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl' Looks like you're trying to build GCC in the source folder itself - this is not supported (yet). Try creating a separate build folder totally outside of the expanded source tree and run configure and then make there. HTH, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Cross compiler
Eric Liu wrote: > > I need a gcc cross compiler under Cygwin. Is there any step-by-step document > on how to make the cross compiler? Any help would be appriciated very much! See: http://billgatliff.com/~bgat/twiki/bin/view/Crossgcc http://gcc.gnu.org/wiki/Cross%20Compiler http://gcc.gnu.org/wiki/Building%20Cross%20Toolchains%20with%20gcc HTH, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: please update the gcj main page
John M. Gabriele wrote: > Please update http://gcc.gnu.org/java/index.html and mention > how much of the Java 1.5 spec that GCJ currently implements. > > When I refer folks to GCJ, the first thing they usually ask is, > "does it support generics?" "autoboxing?" and so on. That info > should be right up on the GCJ front page -- even if GCJ doesn't > support those newer features. *Especially* if GCJ doesn't > support those newer features. GCJ doesn't yet support any of the new 1.5 features. Tom Tromey is developing "gcjx", a complete rewrite of the GCJ compiler front-end, that would support the 1.5 features in addition to being easier to maintain, etc. You can check it out for yourself using the "gcjx-branch" branch of the GCC CVS repository: http://gcc.gnu.org/cvs.html As for your suggestion, I believe the correct place would be "2.8 What features of the Java language are/aren't supported?" in the FAQ: http://gcc.gnu.org/java/faq.html#2_8 in addition to the front-page (if so desired). Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
GCC Summit 2005 Proceedings
Hi, Can someone please upload the individual papers from this year's GCC Summit to: ftp://gcc.gnu.org/pub/gcc/summit/ The big PDF in: http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf is a bit unwieldy to read if one is interested in only reading a few of the papers. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Mark Cuss wrote: > > I'm pretty certain that I'm not the only person who struggles with the "Oh, > that app was built on RH 8 so it won't run on RH 7.3" problems, so I'm > trying to find a solution where I can configure my build system in such a > way that I can distribute a set of libraries with my applications to that it > will run on any distro - at least all of the Red Hats, Fedora Cores, and > RHELs anyways. Perhaps you can just ship a bunch of object files and do the final linking only as a part of your installation process. Of course, since the C++ ABI changed with GCC 3.x, you might want to bundle the C++ libraries, but leave out everything else. It would also mean that end-users have to have binutils, and perhaps make, installed on their machines as a pre-requisite. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: D compiler
Kurt Wall wrote: > On Thu, Jul 28, 2005 at 11:09:17PM -0300, Christian Hartung took 3 lines to > write: > >>When GCC will include a front end for D? >> >>www.digitalmars.com/d > > > Presumably when someone writes one and submits it and signs the > paperwork and agrees to maintain it going forward and... The writing part has already been done to an extent by David Friedman: http://home.earthlink.net/~dvdfrdmn/d/ Perhaps he can tell us if/when he plans to submit it for inclusion in GCC. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
GCJ Interpreter Aborts (2005-08-24 IST)
Hi,
In the last 24 hours, something has gone in which makes
the GCJ interpreter "gij" abort on even simple "Hello World"
classes. For example, the "RuntimeCheck" program in
the Jacks testsuite:
8<
public class RuntimeCheck {
private RuntimeCheck() {}
public static void main(String[] argv) {
System.out.print("1");
}
}
8<
Unfortunately, I didn't have time to debug this properly.
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GCJ Interpreter Aborts (2005-08-24 IST)
On 8/25/05, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > > > In the last 24 hours, something has gone in which makes > > > the GCJ interpreter "gij" abort on even simple "Hello World" > > > classes. For example, the "RuntimeCheck" program in > > > the Jacks testsuite: > > > > I had (probably) the same thing yesterday. Here's a backtrace: > > It was caused by the following patch: > 2005-08-23 J"orn Rennecke <[EMAIL PROTECTED]> > > PR middle-end/23467 > * stor-layout.c (finalize_type_size): Dont override > existing alignment with a smaller alignment from the mode. > > We now have a different layout causing the libjava to fail. Thanks. I can also confirm that backing out this patch and rebuilding GCC resolves the issue as well as other newly introduced libjava testsuite failures. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: 4.2 Project: "@file" support
On 8/25/05, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > FWIW, I should note that GCJ already has support for @file > > style list of input files: > > > > http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html > > > > and has had it for quite some time now. > > DJGPP and Cygwin hosted programs will never see these options, because > the runtime has already expanded them if appropriate. > > Which means your documentation is *wrong* for those platforms; for > them, *any* command line option is legal in @file. Please update your > documentation ;-) GCJ supports them because Sun's javac supports them: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html Sun's javac seems to have the same semantics as that you describe (options, source files, etc.) while GCJ seems to support only source files in "@file" files. So at least on DJGPP/Cygwin, GCJ would appear to be more compatible with Sun's javac than it really is. :-) Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Cross Compiler Unix - Windows
Ivan Novick wrote: > Can you recommend a solution for compiling Windows DLLs on any > variation of UNIX? You can use GCC/MinGW built as a cross-compiler to do this. If you do not mind a shameless plug, read: http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html HTH, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Segmentation Fault building GCC for i686-pc-mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TJ Laurenzo wrote: > I'm getting a segmentation fault in the GCC build from today's CVS > HEAD. I am building the suite for mingw using a cross compiler from > Linux. This setup was working fine prior to updating to the latest > CVS head today. My old sources, which were working correctly, were > from 9/1/2005. In both cases, I had applied patch-rev4.diff from bug > 21766 prior to building. > > If I disable optimizations by removing -O2 arguments and rerunning the > command manually, the file compiles without error. > > Let me know if there is anything else that I can provide to help nail > down this problem. Yes, you can provide a stacktrace and probably debug this yourself. Read http://gcc.gnu.org/wiki/DebuggingGCC first and get the "debugx" and "debug" scripts referred to from there. Change to the folder: `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' and execute once again the command that seemed to fail: i686-pc-mingw32-gcc -DHAVE_CONFIG_H - -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include - -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 - -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include - -c /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c -DDLL_EXPORT -DPIC -o .libs/mark_rts.o If it reproduces, execute the command once again but add "debugx cc1" in the beginning - this will start GDB and you'd be able to debug the actual compiler "cc1". Now enter "run" within GDB and when the fault occurs, use "backtrace" to get a stack trace that might give you/others more information. HTH, Ranjit. > - > make[2]: Entering directory > `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' > /bin/sh ./libtool --mode=compile i686-pc-mingw32-gcc -DHAVE_CONFIG_H > -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include > -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 > -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include > -c -o mark_rts.lo > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c > i686-pc-mingw32-gcc -DHAVE_CONFIG_H > -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include > -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 > -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include > -c /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c > -DDLL_EXPORT -DPIC -o .libs/mark_rts.o > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c: > In function 'GC_approx_sp': > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c:379: > warning: function returns address of local variable > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c: > In function 'GC_add_roots_inner': > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c:175: > internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make[2]: *** [mark_rts.lo] Error 1 > make[2]: Leaving directory > `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' > make: *** [all-target-boehm-gc] Error 2 > - > - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMWrgYb1hx2wRS48RAl6GAJ4/KT8jIu58Z0LmOdFBS+hpjCWrbACfX03I mkhVx1Us3MtDbOy7+JaIJuM= =Byoz -END PGP SIGNATURE-
Re: Windows GUI apps cross-compiled from Linux or Mac OS X?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Lance Taylor wrote: > Chase <[EMAIL PROTECTED]> writes: > > >>Is it possible to use GCC to cross-compile a GUI app for Windows (XP >>specifically) from another platform like Linux or Mac OS X or BeOS? >> >>If so, please either explain in your reply the basic steps required >>to do this or direct me to instructions on how to do so. > > > Questions like this are better directed to [EMAIL PROTECTED] > Thanks. > > Yes, gcc can do this. You will want to build a cross compiler to the > cygwin or mingw target. See cygwin.com and mingw.org for more > information. If you want ready-made scripts and step-by-step instructions for doing this, see: http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPNd1Yb1hx2wRS48RAo3qAJ9FQlenrhIOCOLhG2anIBoj136iQQCeK3wZ QFVQKJD2tBTPGiI0ABob2NQ= =i3Sk -END PGP SIGNATURE-
Minor Tree-SSA Documentation Oddities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Can someone familiar with Tree-SSA please fix the following documentation oddities? In tree-ssa-operands.c, the comment for the function update_stmt_operands() seems to be wrong - it's referring to get_stmt_operands(), which is nowhere to be found. This reference is present inside in the function body as well. I could have done a "s/get_stmt_operands/update_stmt_operands/g" myself, but I was not completely sure of the veracity of the resulting sentences. The "TODOs" and the "CROSSREFs" in this section need to be cleaned up: http://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html Thanks in advance, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDU0WRYb1hx2wRS48RAgXNAJwK1K9/m6rfL+U3XIikRPm22MteRACfXU9X IJT+KmEBPMB4HXMueUtQcZA= =d6gR -END PGP SIGNATURE-
Re: using multiple trees with subversion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni Bajo wrote: > > Probably you're the only one finding disk space expensive. HDs are quite > cheap nowadays. Anyway, I'm sure SVN people would be happy if you help Well, I'm another person who's concerned about growing local copy sizes. As it stands, checking out multiple branches from the current GCC CVS repository *severely* strains the available disc space on my home PC. In my case, I have two hard discs, a CD-ROM drive and a DVD-ROM drive that completely fill out the available IDE channels. (There might be a way to work around this limitation, but I don't know of it yet.) Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVlCYYb1hx2wRS48RAntDAKCfOLR29U1V193NJQbm4AoQ5uZj9QCgiQLl 640Z6Xb1AWdlMn5si6QXhBo= =X0Lf -END PGP SIGNATURE-
Re: A couple more subversion notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnaud Charlet wrote: > > Also, I guess that would mean having 8.5 gigs dedicated > to the GCC rep (without talking about the check outs and builds) on > my machine. I know that disk space is cheap, but I would need to build a > new laptop or reformat my drive in order to achieve that... And still, > having 10gigs less on a laptop's hard drive is quite annoying. 8.5G seems to be the space needed on the server, *not* on your local machine. For example, HEAD seems to take 396M with CVS and 945M with SVN on one of the PCs I tested (comparing "du -sh" output). Note that each of the silly little files like "format", "README.txt", etc. within the ".svn" folder take up 4K each on partition I tested - the "README.txt" files alone take up 6M in the checked-out "trunk" sources. Of course, the biggest savings would perhaps come from not storing the "text-base" copies and letting non-jet-setter hackers have the option of taking the slight penalty of a lag when they do a diff in exchange for a much reduced disc-space requirements. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV1reYb1hx2wRS48RAm38AJ9YAJtxvMJXMoq6U6fmtCSnfwDalwCfR9jL zCcFEosbUdEPD4DUsITtmlI= =BCcx -END PGP SIGNATURE-
Re: A couple more subversion notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnaud Charlet wrote: > > In your world, everyone has an up-to-date version of every tool, > and have e.g. the latest OpenSSH and subversion clients installed > on his machine. In mine, this is clearly far from being the case: > no svn installed, and a 3.x openssh. > > So with this world in mind, this is clearly not 3 minutes that are needed > to get the right set up. > > Same for saying "this will be improved in the next version of svn". > It is assuming that upgrading versions of svn clients for people is a no > cost operation, which is again not the case in practice. You can certainly download the latest and the greatest version of the required software and install it into a private folder, say, "$HOME/wombat". This is not idle speculation, mind you. This is exactly how I personally tested out the SVN repository. The downloading, building and installation of OpenSSL, OpenSSH and SVN (all latest stable versions) took around 15 minutes and an "export PATH=$HOME/wombat/bin:$PATH" later, I was ready to go. This was Linux running on a P4 2.4GHz and your mileage will most likely vary. > And maybe if svn 1.4 will improve such important improvements, it would > be a good idea to wait till svn 1.4 is outt so that people do not have to > upgrade multiple times to get "the expected" behavior. This is a point that I too would like to second. - From what I read on this list, a stable SVN 1.4.x is when a lot of barriers to SVN adoption would be removed. I'm not opposed per se to the shift to SVN, but I sincerely feel that it is a *little* too early. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV35gYb1hx2wRS48RAqyiAJ9QyqUk5Yqg0INpKnq2iWhNV7gJbACgkgn5 aehV7oTVraOGDVdFOseijBI= =Kchz -END PGP SIGNATURE-
Re: A couple more subversion notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni Bajo wrote: [...] >>- time to do an update on mainline/branch > > > When updating, cvs/svn first try to find out what needs to be updated (in > rough > terms) and then start downloading the updates. The latter part (download) is > obviously the same, as they both download compressed delta over the network. > The former part is many times faster in svn, and takes the same time on > branches or mailine (while CVS was much slower in the branch) You'll find out > that, after you type "svn up", it'll start downloading the first file *much > faster* than it used to do with cvs, especially on a branch. I think we ought to remember here that there is a local CVS patch on sources.redhat.com/gcc.gnu.org that makes updates from mainline far faster than on a branch. I think it was written by Ian Lance Taylor. (Search the overseers mailing list for more information.) Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV3/tYb1hx2wRS48RAtEyAJ94bNkI25Du/JK/wgDBUqkEs63s+wCcDf9E k3EGW3djQ9ET1krSEJ0M/Nw= =CRo/ -END PGP SIGNATURE-
GGC Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a few queries on GGC, the GCC garbage collector, and usage of GTY markers in GCC sources. I would be grateful if someone could take some time out to answer these. First off, several fields are marked "skip", though the documents seem to strongly discourage this. For example, see ssa_use_operand_t in tree.h. Second, some of the tree nodes ending in variable-length arrays do not seem to have the appropriate GTY "length" attributes. For example, see struct tree_string's "str" field in tree.h. I guess these are done on purpose, but I can't make out exactly why. :-/ Lastly, on the gcjx-branch, a simple patch to get_output_file_with_visibility() makes it recognise ".hh" and ".cc" C++ source files with GTY markers. My question is, is this sufficient? Do people foresee any problems with this? Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDXQiAYb1hx2wRS48RAqwlAJ984LDJosi5L5IGaU3sg9sGzm5mYwCeKfly zE3y0CWFnWOGQwoTd7p3M7Y= =EJQC -END PGP SIGNATURE-
Re: GGC Questions
On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> >
> > First off, several fields are marked "skip", though the
> > documents seem to strongly discourage this. For example,
> > see ssa_use_operand_t in tree.h.
>
> Was this a question? :-) Skipping is anti-social and decreases the
> flexibility of the software, that said, one can skip any field that
> doesn't need to be walked without any technical problems, as that
> field doesn't need to be walked.
Thanks. Though I didn't frame the question properly (sorry),
I wanted to know why we would want some fields of some
nodes to be skipped. Is it because:
1. we want to reduce time spent in the GC,
2. we know it doesn't matter for PCH, so we do it to
reduce the size of the PCH and its loading time,
3. some other reason?
The problem is that I see the documentation indicate
that this shouldn't be done but I see it being used with
abandon in the actual sources. Hence the query.
Your answer seems to indicate that is something
like #2 because PCH runs before any of these
fields is of any use.
> > Second, some of the tree nodes ending in variable-length
> > arrays do not seem to have the appropriate GTY "length"
> > attributes. For example, see struct tree_string's "str"
> > field in tree.h.
>
> Can be a form of skip. In general, only pointers need to be walked,
> data char [1] is just data and is handled by the size of the object
> as I recall. If you walk the PCH writer, you can watch exactly how
> it does this done if you are curious.
That array ("str") in "tree_string" is of variable length and
its length is indicated by the "length" field. So technically
at least it should be marked with a GTY((length(...)))
marker.
> > Lastly, on the gcjx-branch, a simple patch to
> > get_output_file_with_visibility() makes it recognise
> > ".hh" and ".cc" C++ source files with GTY markers.
> > My question is, is this sufficient? Do people foresee
> > any problems with this?
>
> When tested, it either works, or it doesn't. I'd rather it be tested
> and known to work, then say it looks Ok, and have it turn out to be
> incomplete. For example, the parser knows about a subset of C, if
> those files deviate from this subset too far, they can simply fail to
> work. Usually these failures are of a compile time nature, so it is
> safe to try it out by building the compiler. Better of course to
> actually test that the right thing happens.
Well, the current compiler crashes building
"java/lang/Character.java" where in the debugger I see the
Tree-SSA operands processing code "going bonkers". So
I am trying to figure out if this is because something was
yanked from under its feet by the GC or because there
is some bug in the relevant Tree-SSA code from the time
of the merge or because somehow the GCJX front-end
is not creating the trees properly or something else.
Not being familiar with GGC or Tree-SSA, tracking this
problem has been really frustrating for me. :-(
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: GGC Questions
On 10/26/05, Mike Stump <[EMAIL PROTECTED]> wrote:
>
> > That array ("str") in "tree_string" is of variable length and
> > its length is indicated by the "length" field. So technically
> > at least it should be marked with a GTY((length(...)))
> > marker.
>
> I don't believe it is necessary.
Just to confirm that I understand you properly, it is not
necessary because that variable-length array merely
contains chars, not pointers that the GC might need
to follow. The size of the chunk would anyway be
stored in the metadata for that chunk, so the
GTY((length)) marker can't be for that.
> > Well, the current compiler crashes building
> > "java/lang/Character.java" where in the debugger I see the
> > Tree-SSA operands processing code "going bonkers". So
> > I am trying to figure out if this is because something was
> > yanked from under its feet by the GC or because there
> > is some bug in the relevant Tree-SSA code from the time
> > of the merge or because somehow the GCJX front-end
> > is not creating the trees properly or something else.
>
> Set a breakpoint on creation, and one of use, either, the data
> matches, or it doesn't. If it doesn't set a watch point on the
> changed data, and rerun. Careful to enable the breakpoint only after
> creation, as watch doesn't like unmapped mempory (on darwin anyway).
> You can also tell GC to never collect, and thus `know' if that is the
> issue. Also, you can breakpoint the walker/freer and check if the
> address that can't be freed is. Doing an up from that point tells
> you the context it was in when freed. At times, collect isn't
> allowed, and it might be one of those times. Breaking on freer is
> easier to understand than breaking on a watch point. ggc_free might
> be called on data that isn't totally free, just comment out the
> ggc_free call to fix.
Thanks a lot for your suggestions. I effected modify_stmt()
for the statement and called get_stmt_operands() from
within the debugger and followed the whole thing to find
out that the USEs are indeed calculated correctly. I also
disabled GC (by setting ggc-min-heapsize very high)
and found that the problem still persists.
I have a theory that the problem occurs because GCJX
is sharing the ADDR_EXPR for the Jv_ThrowBadArrayIndex
method across the CALL_EXPRs that call this method
(unlike GCJ on mainline), but I unfortunately ran out of
time before I could test this.
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Cross compile, no grmic/grmiregistry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rui Wang wrote: > Hi all, > > To transform my java RMI code to windows native code, I followed Ranjit > Mathew's tutorial to compile gcc to a cross compiler. > http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html [...] > After successfully runing the cross-compiler shell scripts, then checked > /bin directory, I found mingw32-gcc/g++. There however is no > grmic/grmiregistry. Any ideas what is going on? > > I then tried to compile gcc to a native compile, a error has been thrown out: > collect2: ld returned 1 exit status > make[2]: *** [jv-convert.exe] Error 1 [...] > Am I using the wrong src/bin packages? Any help would be much appreciated! It seems that both on trunk as well as the 4.0 branch, we do not build jv-convert, grmic, etc. if the build is not native. From the file "libjava/Makefile.am" on the 4.0 branch: - - 8< - ## For now, only on native systems. FIXME. if NATIVE bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool endif - - 8< - So this is expected behaviour at the moment. HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcaK/Yb1hx2wRS48RAknqAJ4xLPplk5AE8FfIcTB7wKDeT3FQxgCdG6FJ eYUCAZKwbz5w08rQ2HCJiFo= =8l0s -END PGP SIGNATURE-
Re: Cross compile, no grmic/grmiregistry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TJ Laurenzo wrote: >>- - 8< - >>## For now, only on native systems. FIXME. >>if NATIVE >>bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool >>endif >>- - 8< - >> >>So this is expected behaviour at the moment. > > > This must have changed recently. I remember that when I built the > cross-compiler from mainline last month, all of the tools were > created. Are you talking of a cross-compiler (target != host) or a crossed-native compiler (target==host!=build)? I think Rui was complaining about these tools not being generated in the cross-compiler case while you might have observed these being created in the crossed-native compiler case. I presume "NATIVE" above checks only for "target==host" and therefore your observation. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcgdKYb1hx2wRS48RAtXtAJ41+HWRtYqu3MU1cDsGZ36OI6NVfwCgpYVn 6MpNjdUz6l8kNqAZkXFBGx4= =YNrA -END PGP SIGNATURE-
Re: java broken on Linux/x86-64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jaeger wrote: > Running the testsuite on the trunk, I get lots of failures: > >=== libjava Summary for unix === > > # of expected passes1811 > # of unexpected failures1087 > # of expected failures 6 > # of untested testcases 1097 [...] > This is on Linux/x86-64, Ditto on i686-pc-linux-gnu. Undo this change to fix the problem: Index: gcc/java/ChangeLog from Tom Tromey <[EMAIL PROTECTED]> * parse.y (patch_new_array_init): Don't set length on array. After undoing this change, I'm left with: FAIL: rh174912 compilation from bytecode FAIL: rh174912 -O3 compilation from bytecode FAIL: cxxtest run XPASS: Array_3 execution - bytecode->native test XPASS: Array_3 -O3 execution - bytecode->native test (I don't understand yet why cxxtest run is marked FAILed. It seems to have run just fine. :-/ ) BTW Tom, the Red Hat bugzilla doesn't let me see the bug #174912, even after logging in. It might probably be a better idea to open a PR in GCC's bugzilla describing the problem. That said, the testcase you've included does indeed indicate the problem. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlWRlYb1hx2wRS48RAknrAJ4+rkwjh0+f2bS6Y43RZdF1MPFewQCdHHXw nXr2HsMZ5Br3u6MdIJ2920k= =WsAP -END PGP SIGNATURE-
Re: Any who heard about genmd?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ZengNan wrote: > A tool developed by Indian Institute of Technology Kanpur, which takes > architecture description > represented using Sim-nML as input and generates GCC md as output. I have > been searching for > source code of this tool. Anyone who has the source code, please send me a > copy. I hope you have already seen: http://www.cse.iitk.ac.in/research/mtech1998/984.html and the linked-to paper presenting the thesis. You might want to contact Prof. Sanjeev K. Aggarwal: http://www.cse.iitk.ac.in/users/ska/index.html to find out more about this project and if he has any other students working on enhancing this tool. HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlnRMYb1hx2wRS48RAg7iAJ4rRbkmuFSs/th4ARGgSqCvgv5lLgCbBYog TLT3Qm3eBO8+AyFBy/Vkjxs= =SPIW -END PGP SIGNATURE-
Re: heads up - gcc toplevel bootstrap activated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paolo Bonzini wrote:
> This is just a heads up that GCC has switched so that the toplevel
> coordinates the bootstrapping.
[...]
> Let me know if I broke something.
I used to be able to do:
cd $BUILD_DIR/$TARGET/libjava/testsuite
make -k check
to run only the libjava testsuite.
When I try the same under "stage3-$TARGET/libjava/testsuite"
now, it fails to find the appropriate "gcj". The full error
log is appended at the end of this message.
Thanks,
Ranjit.
- - 8< -
~/src/gcc/build/stage3-i686-pc-linux-gnu/libjava/testsuite > make -k check
make check-DEJAGNU
make[1]: Entering directory `/home/ranmath/src/gcc/build/stage3-i686-pc-linux-gn
u/libjava/testsuite'
srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd /home/ranmath/src/gcc/gcc/libjava/tests
uite && pwd`; export srcdir; \
EXPECT=`if [ -f ../../expect/expect ] ; then echo ../../expect/expect ; else ech
o expect ; fi`; export EXPECT; \
runtest="`if [ -f /home/ranmath/src/gcc/gcc/libjava/../dejagnu/runtest ] ; then
echo /home/ranmath/src/gcc/gcc/libjava/../dejagnu/runtest ; else echo runtest; f
i` INTERPRETER=yes"; \
if /bin/sh -c "$runtest --version" > /dev/null 2>&1; then \
l='libjava'; for tool in $l; do \
$runtest INTERPRETER=yes --tool $tool --srcdir $srcdir ; \
done; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi
WARNING: Couldn't find the global config file.
Test Run By ranmath on Thu Dec 15 14:16:25 2005
Native configuration is i686-pc-linux-gnu
=== libjava tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for targe
t.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/ranmath/src/gcc/gcc/libjava/testsuite/config/default.exp as tool-and
- -target-specific interface file.
Running /home/ranmath/src/gcc/gcc/libjava/testsuite/libjava.cni/cni.exp ...
couldn't execute "gcj": no such file or directory
while executing
"exec gcj -B/home/ranmath/src/gcc/build/stage3-i686-pc-linux-gnu/libjava/testsui
te/../ -v 2>@ stdout"
("eval" body line 1)
invoked from within
"eval exec "$GCJ_UNDER_TEST -B$specdir -v 2>@ stdout""
(procedure "libjava_init" line 41)
invoked from within
"${tool}_init $test_file_name"
(procedure "runtest" line 19)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
"foreach test_name [lsort [find ${dir} *.exp]] {
if { ${test_name} == "" } {
continue
}
# Ignore this one if asked to.
if { ${ignore..."
("foreach" body line 54)
invoked from within
"foreach dir "${test_top_dirs}" {
if { ${dir} != ${srcdir} } {
# Ignore this directory if is a directory to be
# ignored.
if {[info..."
("foreach" body line 121)
invoked from within
"foreach pass $multipass {
# multipass_name is set for `record_test' to use (see framework.exp).
if { [lindex $pass 0] != "" } {
set multipass_..."
("foreach" body line 51)
invoked from within
"foreach current_target $target_list {
verbose "target is $current_target";
set current_target_name $current_target;
set tlist [split $curr..."
(file "/usr/share/dejagnu/runtest.exp" line 1612)
make[1]: *** [check-DEJAGNU] Error 1
make[1]: Leaving directory `/home/ranmath/src/gcc/build/stage3-i686-pc-linux-gnu
/libjava/testsuite'
make: *** [check-am] Error 2
make: Target `check' not remade because of errors.
- - 8< -
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDoS7tYb1hx2wRS48RAnvyAJ9ifrni14WfzWKMHj7W8gh6Cz3GGgCgqzEZ
zE37Vpi2+6vNKmqnPtxkl0M=
=pBvo
-END PGP SIGNATURE-
Re: [PATCH] Do not stage the final build results
) $(RECURSE_FLAGS_TO_PASS) clean-host \
> clean-target
> - @: $(MAKE); $(stage)
>
>
> .PHONY: clean-host
> @@ -1585,7 +1576,6 @@ do-distclean:
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(RECURSE_FLAGS_TO_PASS) distclean-host \
> distclean-target
> - @: $(MAKE); $(stage)
>
>
> .PHONY: distclean-host
> @@ -1688,7 +1678,6 @@ do-maintainer-clean:
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(RECURSE_FLAGS_TO_PASS) maintainer-clean-host \
> maintainer-clean-target
> - @: $(MAKE); $(stage)
>
>
> .PHONY: maintainer-clean-host
> @@ -1944,7 +1933,6 @@ do-check:
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(RECURSE_FLAGS_TO_PASS) check-host check-target
> - @: $(MAKE); $(stage)
>
> # Automated reporting of test results.
>
> @@ -1975,7 +1963,6 @@ install:
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(RECURSE_FLAGS_TO_PASS) installdirs install-host install-target
> - @: $(MAKE); $(stage)
>
> .PHONY: install-host-nogcc
> install-host-nogcc: \
> @@ -36150,7 +36137,6 @@ bootstrap2:
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target
> - @: $(MAKE); $(stage)
>
>
> # Rules to wipe a stage and all the following ones, also used for cleanstrap
> @@ -36432,7 +36418,6 @@ bootstrap:
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target
> - @: $(MAKE); $(stage)
>
>
> # Rules to wipe a stage and all the following ones, also used for cleanstrap
> @@ -36717,7 +36702,6 @@ bootstrap4:
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target
> - @: $(MAKE); $(stage)
>
>
> # Rules to wipe a stage and all the following ones, also used for cleanstrap
> @@ -37197,7 +37181,6 @@ profiledbootstrap:
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(MAKE) $(TARGET_FLAGS_TO_PASS) all-host all-target
> - @: $(MAKE); $(stage)
>
>
> # Rules to wipe a stage and all the following ones, also used for cleanstrap
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDoUr2Yb1hx2wRS48RAlw/AJ9mYnQVFZklcss20qJMksaLO7D88ACdFmX+
0hlfE5j1MmvYLoRxS6EpzDE=
=0dJm
-END PGP SIGNATURE-
Re: GCC mailing list archive search omits results after May 2005
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Per Abrahamsen wrote: > > Actually, I wonder if it really makes sense for the GCC project to > spend part of their limited resources on maintaining their own mail > archives, when specialized free as in FSF services like gmane exist? Yes it does. If nothing else, the archives are used to provide canonical URLs for referring to messages. What might not be clear is the need to run a search engine on the sourceware server, especially if it puts an awful load on the server at times and especially when "foo bar site:gcc.gnu.org" on Google works just fine. However, I have come across (rare) instances where Google does not show any results for such a query even though I can manually dig out such a message and the message was posted quite some time back. My 2p, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoWbXYb1hx2wRS48RArVrAKCY+yJjFI3apeDz7KIZGDlrxViKzQCcCA1e Z5VYvuxO3P63S509N2SVUoE= =93Hm -END PGP SIGNATURE-
Re: A query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harsh Chandra wrote: > > I am new to c programming and had just started learning it . My > friends recommended me to use gcc compilers . but i dont know where > will i get this compiler and how to use this . my operating system is > Windows XP SP2 . please let me know what should i do ? Wrong list - this is a list for discussing development *of* GCC itself, not how to use it or where to obtain it. As for your question, see MinGW: http://www.mingw.org/ If you want a complete UNIX-like environment on Windows (along with GCC), see Cygwin: http://www.cygwin.com/ Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsNVIYb1hx2wRS48RAsH2AJ0VRIF/zwd+QA/NdxD7qQuKIxAS1ACfRcnw UlU0yKcCoj42gN6jOOTbi80= =PrmX -END PGP SIGNATURE-
Slightly OT: Subversion 1.3.0 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is slightly off-topic for this list, but I just noticed that Subversion 1.3.0 is now finally available: http://subversion.tigris.org/servlets/NewsItemView?newsItemID=1417 I wonder if gcc.gnu.org would be moving to this version any time soon. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDu6C3Yb1hx2wRS48RAvlrAKCndV4N41TNUtUrSq5luwqnLxGU1ACfRSfV Lu8VcaKbQTj/voEHi+JR0OA= =DPQo -END PGP SIGNATURE-
Re: Slightly OT: Subversion 1.3.0 Now Available
On 1/4/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > I wonder if gcc.gnu.org would be moving to this > > version any time soon. > > gcc.gnu.org has been running 1.3 development and rc's for many months > now. > > (1.3.0 has been in release candidate mode for about 2 months now :P) Yes, I know that. However, each release candidate has been coming with a notice like this one: http://lolut.utbm.info/pub/subversion-1.3.0/rc7/ so it would seem to make sense to move to 1.3.0 now that it is finally available and request all developers to move to that version. Hence my query. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Time to add new copyright years...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paolo Bonzini wrote: > Just to remember you all that before committing a patch, you now have to > check if the copyright year includes 2006. IANAL, but I think it is sufficient to indicate the year the copyrighted entity was first published and the last year it was revised instead of enumerating all the years it was revised. I personally prefer it too, since otherwise the copyright line becomes a bit too unwieldy. In fact, the US Copyright law seems to need only the first year of publication: http://www.copyright.gov/circs/circ1.html#fnv but I guess we want to be really conservative across countries and their laws on copyright. Sorry, I know this is off-topic for this list but it is somewhat on-topic given that we have to manage this copyright line in every GCC file we edit and the ever-increasing size of these lines becomes a bit irritating. My 2p. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvLUgYb1hx2wRS48RAgO9AJ91MeyLh8+oGk0zDTzNBMxasdaz4ACeNQvN kvNkumid4yypEUcWxVZzurw= =cNJO -END PGP SIGNATURE-
[gcjx] Tree-SSA Operands Processing Problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
While trying to debug a long-standing ICE on the
gcjx branch, I have found out that the root cause
of the problem is with the tree-ssa operands processing
code and it still seems to exist on the mainline
(as of revision 109471), though I have traced the code
path in a debugger and actually observed the problem only
on the gcjx branch.
In mainline, the code path starts from
tree-ssa-operands.c:1906 where we have a *local* variable
VAR whose address is passed on to add_stmt_operand() on
the next line:
- --- 8< ---
1903 /* Add a VUSE for each call-clobbered variable. */
1904 EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, u, bi)
1905 {
1906 tree var = referenced_var (u);
1907 add_stmt_operand (&var, &empty_ann, opf_none |
opf_non_specific);
1908 }
1909
- --- 8< ---
This function then passes this pointer to append_use() at
line 1634, which seems to just store it as-is in BUILD_USES:
- --- 8< ---
1572 static void
1573 add_stmt_operand (tree *var_p, stmt_ann_t s_ann, int flags)
1574 {
[...]
1628 if (is_real_op)
1629 {
1630 /* The variable is a GIMPLE register. Add it to real
operands. */
1631 if (flags & opf_is_def)
1632 append_def (var_p);
1633 else
1634 append_use (var_p);
1635 }
- --- 8< ---
This seems wrong.
I don't know whether this code path is actually ever
taken on mainline or why it hasn't caused any problems
yet, but on the gcjx branch it causes an ICE while
processing the method "of" of the inner class "UnicodeBlock"
of the class "java.lang.Character"
($GCC_SRC_DIR/libjava/java/lang/Character.java). Specifically,
it ICEs while processing the CALL_EXPR corresponding to
the call to _Jv_ThrowBadArrayIndex() thrown if a subscript
is beyond the limits of an array. The problem occurs when
the stack-slot for the VAR variable referred to earlier
is occupied by the NUM local variable of finalize_ssa_vuses()
and is overwritten when this variable is assigned a value in
this function.
Comments?
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDwT2fYb1hx2wRS48RAr8nAJ90iq5wgQpVeG09vihfwN1x1gvsRACfebPH
3ZjNpJLVJNJZTbWpDEKyxiU=
=NBsE
-END PGP SIGNATURE-
Re: [gcjx] Tree-SSA Operands Processing Problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zdenek Dvorak wrote:
>
> this can never happen. Note that is_real_op = is_gimple_reg (var), and
> a call clobbered variable can never satisfy is_gimple_reg. Most likely
> you forget to set TREE_ADDRESSABLE for this variable. Or it gets to
> call_clobbered_vars wrongly.
Oh! That might explain why this hasn't manifested itself
on mainline yet and why even after I put in this workaround
patch:
- 8< ---
Index: tree-ssa-operands.c
===
- --- tree-ssa-operands.c (revision 109471)
+++ tree-ssa-operands.c (working copy)
@@ -1770,8 +1770,10 @@ add_call_read_ops (tree stmt)
/* Add a VUSE for each call-clobbered variable. */
EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, i, bi)
{
- - tree var = referenced_var (i);
- - add_stmt_operand (&var, &empty_ann, opf_none);
+ /* FIXME: Temporary workaround. */
+ tree **var_pp = ggc_alloc (sizeof (tree *));
+ *var_pp = &(referenced_var (i));
+ add_stmt_operand (*var_pp, &empty_ann, opf_none);
}
ro_call_aliased_loads = empty_ann.makes_aliased_loads;
- 8< ---
it still aborts later on (checking is enabled) in
var_ann() in tree-flow-inline.h where the assertion
DECL_P(t) fails - T happens to be an SSA_NAME that
wraps(?) the VAR_DECL for the "SPECIALS" field of
the UnicodeBlock inner class of java.lang.Character.
All the times that this erroneous code path was
taken, the variables were either "SPECIALS" itself
or aliases to it. Thanks a lot. I'll investigate this
when I get some more time.
However, it still remains true that the code path
I referred to is wrong and if, as you say, it can
never be taken, it should just be removed and
replaced with an assertion codifying what you
are saying.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDwc/uYb1hx2wRS48RAiGjAJ9yXv0wlyEf3mTP8uhZWrAssvphBwCggLLM
Ve3PA7Ql4Qm40yUBSvjdNqU=
=w40V
-END PGP SIGNATURE-
Mainline bootstrap failure (revision 110017)
c/gcc/gcc/passes.c:882 #10 0x080c048f in tree_rest_of_compilation (fndecl=0xb7339c00) at /home/ranmath/src/gcc/gcc/gcc/tree-optimize.c:412 #11 0x08057611 in c_expand_body (fndecl=0xb7339c00) - ---Type to continue, or q to quit--- at /home/ranmath/src/gcc/gcc/gcc/c-decl.c:6689 #12 0x0843b9c6 in cgraph_expand_function (node=0xb7182b00) at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:1098 #13 0x0843bb0c in cgraph_expand_all_functions () at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:1164 #14 0x0843c1fc in cgraph_optimize () at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:1431 #15 0x08059820 in c_write_global_declarations () at /home/ranmath/src/gcc/gcc/gcc/c-decl.c:7804 #16 0x083c8e47 in compile_file () at /home/ranmath/src/gcc/gcc/gcc/toplev.c:1003 #17 0x083ca468 in do_compile () at /home/ranmath/src/gcc/gcc/gcc/toplev.c:1948 #18 0x083ca4c8 in toplev_main (argc=43, argv=0xbfffed74) at /home/ranmath/src/gcc/gcc/gcc/toplev.c:1980 #19 0x080ac8ee in main (argc=43, argv=0xbfffed74) at /home/ranmath/src/gcc/gcc/gcc/main.c:35 (gdb) --- 8< ------- Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD0HPtYb1hx2wRS48RAr8cAJ44uth8PiSNorWtQJcs0I0R+DYJEgCfW9I3 0qqty6VAK5mFcG7SJao9NIM= =fn2E -END PGP SIGNATURE-
Re: Unable to access archives on gcc-patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 pranav bhandarkar wrote: > > However the patch that i am looking for is not accessible. the link to > the patch is > > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00826.html Note that you can also use Gmane (news.gmane.org) for accessing archives of many a mailing list. In this particular case, I think the message you're looking for is this: http://article.gmane.org/gmane.comp.gcc.patches/54904 HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1h4qYb1hx2wRS48RAkz8AJ91nTIZIj5Dr3mAKK/+THws+D1sMQCfa+Lf l8G2snSbRkEhy+ESymmC4Y8= =wQK7 -END PGP SIGNATURE-
Re: Patch: Boehm GC 6.6 merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryce McKinlay wrote: > This patch merges the GC 6.6 sources into the libgcj trunk. Two patches [...] This little bit in "boehm-gc/include/private/gcconfig.h" (line 306): - - 8< - > +# else > +#if defined(__i386__) > +# define I386 > --> Not really supported, but at least we recognize it. > +#endif - - 8< - causes a bootstrap failure for me on i686-pc-linux-gnu. Note that the "Not really" bit is not inside a comment. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1xSEYb1hx2wRS48RAlI1AJ9mo12R3N/nB7XhAcxdixECUHKFrACeLdkG WEVT000tFOAJIUc4Fst15fA= =+Ryg -END PGP SIGNATURE-
Re: Toplevel bootstrap patches cause bootstrap breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Edelsohn wrote: > make[4]: Entering directory `/tmp/20060221/prev-gcc' > /tmp/20060221/./prev-gcc/xgcc -B/tmp/20060221/./prev-gcc/ ... -o xgcc > collect2: error trying to exec '/tmp/20060221/./prev-gcc/xgcc': execvp: A > file or directory in the path name does not exist. By the way, I get a similar (but not the same) error in a parallel bootstrap - the execvp failed because "xgcc" didn't have execute permission yet. A serial bubblestrap let me proceed further. (Revision 111359.) Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD+/OeYb1hx2wRS48RAvHRAJ9EDQSNJ/ZZ1uIJYb+7L4PYjsisOQCglSiI VQbkLJGEoHVD6N0/WSd5g1Y= =DzzD -END PGP SIGNATURE-
Re: Successful Build: gcc-4.1-20051230 i686-pc-mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Incognito wrote: > > I started again (deleted the generated files) and configured with "sh > ../gcc-4.1.0/configure --prefix=/home/gcc41 --enable-threads=win32 > --with-ld=/mingw/bin/ld --with-win32-nlsapi=unicode" and fired "make > bootstrap". I think this time make made more than the last time, but ejected > an error again: Before building GCC, you need to ensure that the prefix folder you specify has the C headers. If you're replacing your compiler, the simplest way to achieve this is to say "--prefix=/mingw". Otherwise you need to first extract "mingw-runtime" and "w32api" into (say) "/home/gcc41" before specifying it as the prefix for the new GCC. You can find the latest versions of these packages on the MinGW SF page: http://sourceforge.net/projects/mingw You might also want to extract "binutils" into the same folder before proceeding. On reading the messages in this thread, on a whim I built GCC 4.1.0 for MinGW (C,C++) using the release tarballs. As I noted in PR24382, you need to specify "--with-ld" explicitly as well as use a relative path to the GCC "configure" script (otherwise it fails trying to find "/tmp/gcc-4.1.0/gcc/input.h", even though it's present). Here're the configuration details: - -- 8< -- ~ > gcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc-4.1.0/configure --prefix=/mingw \ - --target=i686-pc-mingw32 --enable-languages=c,c++ --disable-nls \ - --disable-debug --enable-__cxa_atexit --enable-threads=win32 \ - --disable-win32-registry --with-ld=/mingw/bin/ld.exe \ - --with-as=/mingw/bin/as.exe Thread model: win32 gcc version 4.1.0 - -- 8< -- I used "mingw-runtime" version 3.9, "w32api" version 3.6 and "binutils" version 2.16.91-20060119-1, all as available from the MinGW SF project mentioned earlier. I built GCC by invoking "make bootstrap" after configuration. The build environment was MSYS 1.0.11. HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFED8m7Yb1hx2wRS48RAnNhAKCJNFc3gOMsI65ikZ02e3ByIvhEbgCfVO/4 +45uaXnryeFJGxsLUAwHNOs= =DXH5 -END PGP SIGNATURE-
The GCC Wiki and the AddComment Plug-in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I subscribe to the "RecentEdits" RSS feed of the GCC Wiki. Of late, there have been a lot of "AddComment Plug-in" entries in the feed, with no apparent way of finding out which entry in the Wiki the comment refers to, and many filled with bogus comments that are links to online casinos and the like. Can we please have a way of telling which entry a comment refers to or disable the AddComment plug-in altogether? Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKMD6Yb1hx2wRS48RAplIAJ93VyjX6PqhEabtdK8jD8gPbA4dBACggFGs nUhJ44pXxf1CFGG4jSTs7FY= =+gtH -END PGP SIGNATURE-
Re: GCC SC request about ecj
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Tromey wrote: > > In particular we would like to import a copy of the ecj sources into > the GCC source tree, so that we can continue to deliver a complete > compiler system in a single download. > > So, could the SC please discuss the ecj plan and let us know whether > it is acceptable? It would also be helpful to have some idea of how > long the discussion might take. Did the SC get to deliberate on this issue? Was this message: http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html on inclusion of source code from other projects in GCC a direct result of these discussions or a mere coincidence? Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEMhb/Yb1hx2wRS48RAuUIAJ9OoRzBhdt80k0uKP5eQELOZslQRACeJKfU yeVIfT7VJ00VFVmHgbrSz0U= =5n9c -END PGP SIGNATURE-
Re: Toolchain relocation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Murphy wrote: > > I've been having some odd problems with relocation of 4.x toolchains - > i.e. when a toolchain is configured, built and installed with one prefix > but later moved to another location. The binaries appear to be checking > something in the old location before reading from the new path. I might be mistaken, but I think this is intentional behaviour. FWIW, I have faced a different toolchain relocation problem in the GCC 4.1.0 release on MinGW. I configured and built GCC using "--prefix=/mingw" on one machine where "/mingw" maps to "D:\MiscAppz\MinGW" (I used MSYS as the build environment). The compiler built, installed and ran fine on this machine. However, when I moved the binaries to another machine where MinGW was installed in "D:\MinGW", the compiler was not able to find the C runtime headers, even though the folder structure was exactly the same. It was however able to find executables from binutils like as, ld, etc. I worked around this problem temporarily by just specifying the system include path explicitly in the CFLAGS of my programme's build script. There was another curious problem with this GCC, even on the original machine where it was built: when run from within the MSYS environment, everything was hunky-dory but when run from the Windows command prompt, it used to give a "_spawnvp: No such file or directory" error when one tried to compile something. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPzXHYb1hx2wRS48RAgR1AJ4lR9FmGojMA27egIqWwkn6EK/UVwCdFJcj q/oVB2PgULlWz0DEHUZgrQ8= =iUfR -END PGP SIGNATURE-
Re: Toolchain relocation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Murphy wrote: > Ranjit Mathew wrote: >> >> However, when I moved the binaries to another machine >> where MinGW was installed in "D:\MinGW", the compiler was >> not able to find the C runtime headers, even though the >> folder structure was exactly the same. > I think this is due to the compiler believing it was originally > installed at /mingw when in fact it was really installed at > d:\MiscAppz\Mingw so the relocation of the include directory fails > because it can't relate the two. > > I'm still a little confused by this one because it would seem to > indicate that the paths to the binaries and libraries are relocated in a > different manner to the include directories since the relocated compiler > can find as, ld etc with no trouble. GCC looks for an included header file in the following way: http://gcc.gnu.org/onlinedocs/gcc-4.1.0/cpp/Search-Path.html > I know I experience the same problem if I don't configure with > --prefix=:/path/to. If I use mount points or the MSYS style > //path/to then the newly built compiler can't find it's include > directories. I am out of touch with MSYS/MinGW, but I seem to remember that MSYS used to replace UNIX-y paths in the command-line like "/mingw" with their correct mapping as given in /etc/fstab so that applications get to the correct file when they use things like fopen(), etc. which are provided directly by the Windows C runtime (MSVCRT.dll) instead of an abstraction layer as with Cygwin. Note that since the other machine has MinGW in "D:\MinGW" instead of "D:\MiscAppz\MinGW" as on the original machine, even the above should not work for me. >> There was another curious problem with this GCC, even on >> the original machine where it was built: when run from within >> the MSYS environment, everything was hunky-dory but when >> run from the Windows command prompt, it used to give a >> "_spawnvp: No such file or directory" error when one tried >> to compile something. >> > That's interesting. One of my end users reported a similar problem > recently but I've been unable to reproduce this locally under win2kpro. > Was this a win95/98 machine? No, both the machines were running Windows 2000 Professional (SP4a). Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQLU/Yb1hx2wRS48RAp2QAKCbj8EsNvJqM8UnRpzYRV2K9i+4rQCgn2cZ rtMlnsxl6ZpJ3Q48v7HkcHg= =XUUW -END PGP SIGNATURE-
Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, It seems that toolchain relocation, especially for crossed-native builds, seems to be broken in mainline while it used to work for earlier releases. The situation seems particularly bad for Windows (MinGW). I build GCC regularly only on Linux these days but in the distant past I used to build a GCJ for Windows using Linux for building a crossed-native compiler. This process is outlined in: http://rmathew.com/articles/gcj/bldgcj.html Now it does not seem to work as smoothly as it used to. First off, it seems that for MinGW the C runtime headers *must* be in /mingw/include (adjusting for sysroot): http://gcc.gnu.org/ml/java/2006-04/msg00056.html Earlier the compiler used to be able to pick up headers from $PREFIX/$TARGET, but now the $TARGET sub-folder must be renamed to "mingw" and "--with-sysroot=$PREFIX" needs to be specified. However, when the built crossed-native compiler is run on another (Windows) machine, the headers are not found by it and they seem to be picked up if $DIR/mingw is renamed back to $DIR/$TARGET. More seriously, this compiler is not able to find "as" from binutils, even though they are co-located in the same "bin" folder: http://gcc.gnu.org/ml/java/2006-04/msg00057.html This definitely used to work before. There also seem to be regressions in GCJ with the import of GNU Classpath as noted in the message linked to above, but fortunately that is easily overcome with a "--with-gcj=$TARGET-gcj" option. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESQg9Yb1hx2wRS48RAmigAJ0TKr3bz3txfIRWL7za+eLlRu3qNQCeNdKT hlUOQbe37xDihTSzDdN1Clc= =prQu -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai Ruottu wrote: > Because all the MinGW target libs already were produced during the step > 1, it should > sound being "reinventing the wheel" to try to reproduce these during the > step 2 > So one uses the 'make all-gcc', and gets only the "GCC" binaries for the > new host. > That there would be any problems in reproducing the extra libraries will > remain totally > unnoticed... If I understand you correctly, you're saying that the target runtime libraries are already created by the cross-compiler in Phase 1, so I don't need to rebuild them again in Phase 2 along with the crossed-native compiler - I can get by by just building the compiler. I don't know much about the internals of GCC, but what you're saying should be possible though a bit cumbersome. Building everything in Phase 2 (compiler and libraries) just gives a nice bundle that I can then redeploy as I wish (but this is precisely the thing that seems to be broken, on MinGW at least). Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETHRVYb1hx2wRS48RAlCgAJsH3Vr2Ns2DkqXRb/QOzQsrzUaU+ACgiLE0 3IGHUaZ+230w3MP0Q4WfpqQ= =kyo9 -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Murphy wrote:
>
> I'm totally at a loss to explain the problems Ranjit was experiencing in
> this mail then.
>
> http://gcc.gnu.org/ml/gcc/2006-04/msg00247.html
>
> the part where he says " when run from within the MSYS environment,
> everything was hunky-dory but when run from the Windows command prompt,
> it used to give a "_spawnvp: No such file or directory" error when one
> tried to compile something."
The difference is that MSYS automatically adds the "bin"
folder of MinGW to the PATH. On the Windows command prompt,
I was trying to execute "gcc" directly without having its
"bin" folder in the PATH - if I add that folder to the PATH,
things work fine again. In the problematic case, GCC is able
to find "cc1" but not "as":
- --- 8< ---
E:\src\tmp>d:\MiscAppz\MinGW\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.1.0/configure --prefix=/mingw \
- --target=i686-pc-mingw32 --enable-languages=c,c++ \
- --disable-nls --disable-debug --enable-__cxa_atexit \
- --enable-threads=win32 --disable-win32-registry \
- --with-ld=/mingw/bin/ld.exe --with-as=/mingw/bin/as.exe
Thread model: win32
gcc version 4.1.0
d:/miscappz/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/cc1.exe \
- -quiet -v -iprefix d:\miscappz\mingw\bin\../lib/gcc/i686-pc-mingw32/4.1.0/ \
hello.c -quiet -dumpbase hello.c -mtune=pentiumpro -auxbase hello \
- -version -o D:\TEMP/ccWC.s
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "d:/MiscAppz/MinGW/i686-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/include
d:/MiscAppz/MinGW/include
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/include
End of search list.
GNU C version 4.1.0 (i686-pc-mingw32)
compiled by GNU C version 4.1.0.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65462
Compiler executable checksum: ee311961bfecdede449f181caa4cf975
as -o D:\TEMP/ccI5.o D:\TEMP/ccWC.s
gcc: _spawnvp: No such file or directory
- --- 8< ---
(Long lines broken up manually.)
Note that I *had* specified "--with-as", but I was using
UNIX-y paths which are *not* translated by MSYS for shell
scripts (unlike "regular" programmes):
- --- 8< ---
/e/src/tmp > cat hello.c
#include
int main( int argc, char *argv[])
{
if(argc > 1)
printf( "argv[1]: %s\n", argv[1]);
return 0;
}
/e/src/tmp > gcc hello.c
/e/src/tmp > ./a.exe /mingw
argv[1]: d:/MiscAppz/MinGW
/e/src/tmp > cat scr.sh
#!/bin/sh
echo $*
/e/src/tmp > ./scr.sh /mingw
/mingw
- --- 8< ---
Note also that GCC's programme search path does not include
its own location for some reason:
- --- 8< ---
d:/miscappz/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/
d:/miscappz/mingw/bin/../libexec/gcc/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/
/usr/libexec/gcc/i686-pc-mingw32/4.1.0/
/usr/libexec/gcc/i686-pc-mingw32/
/usr/lib/gcc/i686-pc-mingw32/4.1.0/
/usr/lib/gcc/i686-pc-mingw32/
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw
32/bin/i686-pc-mingw32/4.1.0/
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw
32/bin/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
- --- 8< ---
This is the more readable version of the "programs" section
of the output of "D:\MiscAppz\MinGW\bin\gcc -print-search-dirs".
See also PR bootstrap/22259:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
The curious thing is that I could not find the message
in gcc-patches corresponding to CGF's patch and I cannot
find out who defines USE_MINGW_MSYS.
In any case, all this has been overridden in mainline by
a series of patches from Jim Blandy and Mark Mitchell,
though I haven't bootstrapped GCC mainline on MSYS.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFETdPEYb1hx2wRS48RAtDvAJwIFIHe8LQUsFWD8BJ5H4HWlk6i/gCfQbnM
S872RVKUETmoMikS+ymG+30=
=7rQb
-END PGP SIGNATURE-
Re: Windows Unicode and GCC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn wrote: > On Mon, 24 Apr 2006 15:27:07 -0400, Nicolas De Rico wrote: >> I would like to compile files created on Windows and encoded in >> "Unicode" (UTF-8 or UTF-16). Microsoft puts a little header at the >> beginning of files to indicate that they are UTF-16, UTF-8, etc. I >> believe that this header is standard unicode btw, not an extension! > > Are you thinking of the byte order mark (BOM)? If so then this is a quirk > of UTF-16 and is a Windows thing that many apps can't handle correctly ... > UTF-8 should not have any headers at all and GCC should handle them fine. > Try using some text editor to check it really is UTF-8. Windows Notepad still inserts a BOM (0xEF 0xBB 0xBF) at the beginning of files encoded with UTF-8. See: http://www.microsoft.com/globaldev/getwr/steps/wrg_unicode.mspx http://en.wikipedia.org/wiki/Byte_Order_Mark Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETfs0Yb1hx2wRS48RAkvmAKCae/o9vD3doaDKD1VPOSUlSlhRjACdGqv0 nD0cMiSvZLu9TfmIf/BUuIU= =lZaM -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Ridge wrote:
> Ranjit Mathew wrote:
>> In the problematic case, GCC is able to find "cc1" but not "as" ...
> ...
>> Note also that GCC's programme search path does not include
>> its own location for some reason:
> ...
>> d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
>
> This is the directory ("i686-pc-mingw32/bin") where you should install
> the version of as.exe and ld.exe you want that installation of gcc to use.
Thanks for pointing this out - I knew this, but for some reason
it didn't strike me. What's happening is that I am using stock
binutils binaries as distributed by the MinGW project, but
compiling my own GCC binaries. The stock MinGW binutils (and
GCC) are built for the target "mingw32" (an alias for
i386-pc-mingw32) while I was building for the target
"i686-pc-mingw32".
So now I only need to figure out why the cross-compiler
is not picking up headers from $PREFIX/$TARGET while
building a crossed-native compiler, even though it used
to do so in earlier releases.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFETxdXYb1hx2wRS48RAl1mAJ9LGa+iqjfD3Om5WaiAynZd8O7iHACdHDHp
Lf9WkRN3Qi0WYeAMlMjq66M=
=MSnk
-END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ranjit Mathew wrote: > > So now I only need to figure out why the cross-compiler > is not picking up headers from $PREFIX/$TARGET while > building a crossed-native compiler, even though it used > to do so in earlier releases. This is misleading, so I think I should clarify. The problem is that I am building a crossed-native compiler for MinGW from Linux (i.e. build = i686-pc-linux-gnu, host == target = i686-pc-mingw32) using a just-built cross-compiler and the build fails on the stmp-fixinc Makefile target as it cannot find $SYSTEM_HEADER_DIR. After this patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00122.html $SYSTEM_HEADER_DIR is supposed to be "/mingw/include" for a native MinGW target (and since host == target, the build is being considered native). However, in a crossed- native build, I cannot have MinGW headers in this path, so the way I work around this problem is to additionally specify "--with-sysroot=$PREFIX" and extract MinGW headers into "$PREFIX/mingw". This lets the build and installation complete successfully, but when I tar this installation and install it on a Windows machine, GCC fails to find the system headers. The workaround *then* is to rename the "mingw" folder to "$TARGET" (i.e. i686-pc-mingw32) again. Needless to say, this is painful. In earlier releases, I used to be able to just extract the headers to $PREFIX/$TARGET, do the crossed-native build, install the compiler and then bundle this installation up to create a relocatable toolchain. This was the whole point of the article: http://rmathew.com/articles/gcj/bldgcj.html I had written documenting this process. Note that in the follow-up message: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00142.html to the patch mentioned above, Danny Smith mentions that this patch causes no problems if MinGW is actually installed in /mingw. This seems to imply that the only $PREFIX that is properly supported is /mingw and the headers from mingw-runtime should be extracted into /mingw/include. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFET27CYb1hx2wRS48RAna+AJ9NV06yXMi2tZSCppB1er3SXSrbYQCdEgV/ SBX3qobpH4eL3E+LF+ondX4= =XmbU -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Jacobowitz wrote: > On Wed, Apr 26, 2006 at 06:29:46PM +0530, Ranjit Mathew wrote: >> $SYSTEM_HEADER_DIR is supposed to be "/mingw/include" >> for a native MinGW target (and since host == target, the >> build is being considered native). However, in a crossed- >> native build, I cannot have MinGW headers in this path, so >> the way I work around this problem is to additionally specify >> "--with-sysroot=$PREFIX" and extract MinGW headers into >> "$PREFIX/mingw". This lets the build and installation >> complete successfully, but when I tar this installation >> and install it on a Windows machine, GCC fails to find >> the system headers. The workaround *then* is to rename >> the "mingw" folder to "$TARGET" (i.e. i686-pc-mingw32) >> again. Needless to say, this is painful. In earlier >> releases, I used to be able to just extract the headers >> to $PREFIX/$TARGET, do the crossed-native build, install >> the compiler and then bundle this installation up to >> create a relocatable toolchain. This was the whole point >> of the article: > > If you look at HEAD, you'll find a new --with-build-sysroot > option. Does that help? We added it for some very similar > configurations... I found the documentation of the option in: http://gcc.gnu.org/install/configure.html a bit confusing and I had to actually look at Mark's original message: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01579.html to understand this option. That said, I was not able to come up with a description that is short *and* properly conveys the intention of the option. :-( Actually I still don't understand what "libraries whose sysroot lives within the installation prefix" (see Mark's message) means. Why does a library have a sysroot? Is this for doing something like "-rpath"? In any case, I don't readily see how --with-build-sysroot solves the particular problem I'm facing. Perhaps I'm missing something. What I want to be able to do is: 1. Create a folder and extract the C runtime headers and libraries into this folder (whether directly under it, or under $TARGET within it, or under "mingw" within it). 2. Configure and build binutils and GCC for MinGW using a cross-compiler and install them into the folder in #1. 3. Archive the folder and extract it on Windows boxen, possibly under different paths, and have GCC work properly without any changes. As I said, this *used* to be possible once upon a time. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUChgYb1hx2wRS48RAmw9AJ9hwGNKGvH22sZCP90EMtV3dVuITQCfUF0t UvWTg8YVxWoe0vHq45Sp4FY= =G5IW -END PGP SIGNATURE-
Re: Status of SEE and Autovectorization patches?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mircea Namolaru wrote:
>> That certainly does suggest a bug in the SEE patches. They needn't do
>> anything useful on IA32/AMD64, but they should presumably either (a) not
>> cause a bootstrap failure on these architectures, or (b) be disabled on
>> these architectures.
>
> Agree. I will check the bootstrapping on x86. (a) seems preferable but
> if not feasible in a short time frame, it will be (b).
FWIW, while normal bootstrap completes successfully for me
(c,c++,java on i686-pc-linux-gnu), I get a few failures in the
libjava testsuite due to the new SEE code.
The $GCC_SIR_DIR/libjava/testsuite/libjava.lang/TLtest.java
testcase fails to compile at -O3 and results in an ICE for
me:
- -- 8< --
(gdb) r
Starting program: /home/ranmath/src/gcc/build/gcc/jc1 TLtest.java -fhash-synchro
nization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-
inline-functions -quiet -dumpbase TLtest.java -march=pentium4 -auxbase TLtest -O
3 -I/home/ranmath/src/gcc/build/i686-pc-linux-gnu/libjava/libgcj-4.2.0.jar -o /t
mp/cc6b7oji.s
Program received signal SIGSEGV, Segmentation fault.
0x083bc4d0 in hash_descriptor_pre_extension (p=0xbfffcea8)
at /home/ranmath/src/gcc/gcc/gcc/see.c:837
837 rtx set = single_set (extension->se_insn);
(gdb) l
832
833 static hashval_t
834 hash_descriptor_pre_extension (const void *p)
835 {
836 const struct see_pre_extension_expr *extension = p;
837 rtx set = single_set (extension->se_insn);
838 rtx rhs = NULL;
839
840 gcc_assert (set);
841 rhs = SET_SRC (set);
(gdb) p p
$1 = (const void *) 0xbfffcea8
(gdb) p ((struct see_pre_extension_expr *)p)->se_insn
$2 = (rtx) 0x0
(gdb) bt
#0 0x083bc4d0 in hash_descriptor_pre_extension (p=0xbfffcea8)
at /home/ranmath/src/gcc/gcc/gcc/see.c:837
#1 0x083f2e87 in htab_find_slot (htab=0x8542888, element=0xbfffcea8,
insert=INSERT) at /home/ranmath/src/gcc/gcc/libiberty/hashtab.c:657
#2 0x083bcff5 in see_seek_pre_extension_expr (extension=0x0,
type=DEF_EXTENSION) at /home/ranmath/src/gcc/gcc/gcc/see.c:1036
#3 0x083bd0eb in see_set_prop_unmerged_def (slot=0x85ad39c, b=0x85ad2f8)
at /home/ranmath/src/gcc/gcc/gcc/see.c:2280
#4 0x083f25d6 in htab_traverse_noresize (htab=0x85ad318,
callback=0x83bd05a , info=0x85ad2f8)
at /home/ranmath/src/gcc/gcc/libiberty/hashtab.c:729
#5 0x083bcf21 in see_handle_extensions_for_one_ref (stn=0x858b778, data=0x0)
at /home/ranmath/src/gcc/gcc/gcc/see.c:2986
#6 0x083f3660 in splay_tree_foreach_helper (sp=0x85ad2d8, node=0x858b778,
fn=0x83bcd70 , data=0x0)
at /home/ranmath/src/gcc/gcc/libiberty/splay-tree.c:218
#7 0x083bf3b0 in see_main () at /home/ranmath/src/gcc/gcc/gcc/see.c:3021
#8 0x083bfac4 in rest_of_handle_see ()
at /home/ranmath/src/gcc/gcc/gcc/see.c:3754
#9 0x082b4b14 in execute_one_pass (pass=0x849e2e0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:864
#10 0x082b4c44 in execute_pass_list (pass=0x849e2e0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:911
- ---Type to continue, or q to quit---
#11 0x082b4c57 in execute_pass_list (pass=0x849c2a0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:912
#12 0x080972e5 in tree_rest_of_compilation (fndecl=0xb73e5900)
at /home/ranmath/src/gcc/gcc/gcc/tree-optimize.c:418
#13 0x082f1032 in cgraph_expand_function (node=0xb745d080)
at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:1102
#14 0x082f256d in cgraph_assemble_pending_functions ()
at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:354
#15 0x082f222a in cgraph_finalize_function (decl=0xb73e5900, nested=0 '\0')
at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:480
#16 0x08070bd1 in finish_method (fndecl=0xb73e5900)
at /home/ranmath/src/gcc/gcc/gcc/java/decl.c:2147
#17 0x08063468 in java_expand_classes () at parse.y:7678
#18 0x08089b37 in java_parse_file (set_yydebug=0)
at /home/ranmath/src/gcc/gcc/gcc/java/jcf-parse.c:1316
#19 0x08299f05 in toplev_main (argc=17, argv=0xbfffd2a4)
at /home/ranmath/src/gcc/gcc/gcc/toplev.c:999
#20 0x08094a6b in main (argc=Cannot access memory at address 0xc
) at /home/ranmath/src/gcc/gcc/gcc/main.c:35
- -- 8< --
HTH,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEW08MYb1hx2wRS48RApLUAJwIwhtQPemm8Hmb4m6e+Gb5chfP6wCfZplB
QPbZbn9L/h25E26XDGuXffs=
=9iHh
-END PGP SIGNATURE-
[wwwdocs] releases.html v/s develop.html
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Dave Yost points out that a cursory look at the main table in: http://gcc.gnu.org/releases.html (which is linked-to from the main page) gives the impression that 3.4.6 has been our last release. It is very easy to miss the fine-print-like statement above the table that refers the reader to develop.html for the 4.x series and beyond. I agree with him and propose that we either retire releases.html or include information about the 4.x series in that table too. Note that releases.html claims 3.4.6 is the latest in the 3.4 series but the main page says 3.4.5 is the last one (but then the very next line contradicts this line!). This should be rectified - in fact, why don't we just remove the "Previous release series" bit for the 3.4 series? It looks a bit odd to have two "Previous release series" on that page. What do you guys think? Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZr6aYb1hx2wRS48RAkY3AJoDDQwbZyqE5K0UMj8ufUcSW/ddVQCeMd7+ eYYsN+xnzpGC50S7skzWRxQ= =0XJP -END PGP SIGNATURE-
Re: mips: -G0 vs __dso_handle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
DJ Delorie wrote:
> 2006-05-15 DJ Delorie <[EMAIL PROTECTED]>
>
> * crtstuff.c (__dso_handle): Set section from
> TARGET_LBIGCC_SDATA_SECTION if defined.
> * doc/tm.text (TARGET_LIBGCC_SDATA_SECTION): Document.
> * config/mips/mips.h (TARGET_LIBGCC_SDATA_SECTION): Define.
Nitpicking: Two minor typos ("LBIGCC" and "tm.text") here.
> [EMAIL PROTECTED] TARGET_LIBGCC_SDATA_SECTION
[...]
> +access these variables whether it uses small data or not.
> +
> @defmac FORCE_CODE_SECTION_ALIGN
You've missed the "@end defmac" part which is causing
a bootstrap failure.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEaWQyYb1hx2wRS48RAjZgAJwLSJtETjsEU+fIWmlWIrZwKn5RogCfYfKT
78RyVZR8fesXg1LSUWdDU+I=
=kR0U
-END PGP SIGNATURE-
Re: GCC 4.1.1 RC1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Michlmayr wrote: > * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-18 15:33]: >> GCC 4.1.1 RC1 is available from: >> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517 > > Running make check after make gives me: > > | Newly fixed header: ia64/sys/getppdp.h > | > | There were fixinclude test FAILURES You should run "make -k check" instead. See: http://gcc.gnu.org/install/test.html Having said that, I did bootstrap this prerelease tarball successfully on i686-pc-linux-gnu (c,c++,java), but "make -k check" in the toplevel build folder always exited with an error for every sub-folder it traversed into (something about set_ld_library_path_env_vars). I'm sorry I didn't get the time to investigate this further to see if it's a genuine issue with the prerelease tarball or just some SNAFU in my setup. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbfdAYb1hx2wRS48RAuRjAJ9NEshOuXujYoMsALvL2MkX2xtqQwCfVpMZ 9L8hAshHFqCeGgGEOj3gPIE= =gEXN -END PGP SIGNATURE-
Re: mingw32 subtle build failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: > On Wed, May 31, 2006 at 11:37:51PM +0200, FX Coudert wrote: >> And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS? >> (grep is soo sloow on my win32 machine) > > For the record, I don't do Msys. Please don't cc me about msys problems. I think he CC-ed you on the message because you seem to be the one who added the conditional code using USE_MINGW_MSYS to libiberty/pex-win32.c: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00557.html Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfokPYb1hx2wRS48RAjGNAKCq76dq02lwwQo4Q9HQtSt8X6w8XACfXelh dTKwdpfPwCgr10IhbsujkPw= =MKbr -END PGP SIGNATURE-
Re: [wwwdocs] releases.html v/s develop.html
On 6/2/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: Mind to send/commit a patch to complete releases.html with 4.x releases and add a step to releasing.html? (Basically you just need to revert revision 1.26 of that file.) Joe Buck beat me to it and you applied it for him. Thanks to both of you. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/
Objective C++ Bundling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I found out recently that with just the gcc-core and gcc-g++ files, bootstrapping with --enable-languages=c,c++ fails since "gcc/objcp" was being processed without Objective C front-end and runtime files being there in the source tree. I think something like the following patch should be applied to the gcc_release script - I'm not submitting this as a formal patch since I don't know how to use this script and I just use the variables defined by it (JAVA_DIRS, TESTSUITE_DIRS, etc.) to create a reduced snapshot of GCC sources for myself. - -- 8< -- Index: gcc_release === - --- gcc_release 2006-06-05 17:45:51.0 +0530 +++ gcc_release 2006-06-05 17:46:19.0 +0530 @@ -581,5 +581,5 @@ FORTRAN_DIRS="gcc/f libf2c" FORTRAN95_DIRS="gcc/fortran libgfortran" JAVA_DIRS="gcc/java libjava libffi fastjar zlib boehm-gc" - -OBJECTIVEC_DIRS="gcc/objc libobjc" +OBJECTIVEC_DIRS="gcc/objc gcc/objcp libobjc" TESTSUITE_DIRS="gcc/testsuite" - ------ 8< -- Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhCJwYb1hx2wRS48RAh23AJsEX55xF9UEisIniv6ziNKDdNfcOQCggm52 oTB8a8hjV+o/MW3KBZ+oUvA= =mRde -END PGP SIGNATURE-
Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Ridge wrote:
> Ranjit Mathew wrote:
>> Danny, I'm using the same configure flags that you have used for GCC
>> 3.4.5 MinGW release (*except* for --prefix=/mingw, which is something
>> like --prefix=/j/mingw/mgw for me), but the GCC I get is not relocatable
>> at all, while I can put the MinGW GCC 3.4.5 release anywhere on the
>> filesystem and it still works. :-(
>
> The GCC I get from my native MinGW build of the trunk is relocatable:
Curiouser and curiouser!
See the following output that shows what I was talking about
("TEMP" is set to "C:\TEMP", so "/tmp" is mapped to "C:\TEMP"):
- -- 8< --
C:\TEMP\mgw>c:\temp\mgw\mymingw\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc/configure --prefix=/tmp/mgw/mymingw --host=i686-pc-mingw
32 --target=i686-pc-mingw32 --disable-nls --disable-checking --disable-debug --e
nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr
or
Thread model: win32
gcc version 4.2.0 20060606 (experimental)
c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet -v
- -iprefix c:\temp\mgw\mymingw\bin\../lib/gcc/i686-pc-mingw32/4.2.0/ hello.c
-quie
t -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\TEMP/ccuw.s
ignoring nonexistent directory "/tmp/mgw/mymingw/include"
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/i686-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include
C:/TEMP/mgw/mymingw/include
C:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/include
End of search list.
GNU C version 4.2.0 20060606 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.2.0 20060606 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129918
Compiler executable checksum: fa3ae888985b8ab892ffd388ea6c3279
c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mi
ngw32/bin/as.exe -o C:\TEMP/ccOS.o C:\TEMP/ccuw.s
c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/collect2.exe -Bdyn
amic c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../crt2.o -L
c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0 -Lc:/temp/mgw/mymingw/b
in/../lib/gcc -LC:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0 -Lc:/temp/mgw/
mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mingw32/lib -LC
:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mingw32/lib
-Lc:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../.. -LC:/TEMP/m
gw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/../../.. C:\TEMP/ccOS.o -lmingw32 -
lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmi
ngw32 -lgcc -lmoldname -lmingwex -lmsvcrt
C:\TEMP\mgw>move mymingw yourmingw
1 file(s) moved.
C:\TEMP\mgw>c:\temp\mgw\yourmingw\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc/configure --prefix=/tmp/mgw/mymingw --host=i686-pc-mingw
32 --target=i686-pc-mingw32 --disable-nls --disable-checking --disable-debug --e
nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr
or
Thread model: win32
gcc version 4.2.0 20060606 (experimental)
c:/temp/mgw/yourmingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet -
v -iprefix c:\temp\mgw\yourmingw\bin\../lib/gcc/i686-pc-mingw32/4.2.0/ hello.c -
quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\TEMP/ccktaa
aa.s
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/include"
ignoring nonexistent directory "/tmp/mgw/mymingw/include"
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.
0/include"
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/i686-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:/temp/mgw/yourmingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include
End of search list.
GNU C version 4.2.0 20060606 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.2.0 20060606 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129918
Compiler executable checksum: fa3ae888985b8ab892ffd388ea6c3279
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function 'main':
hello.c:5: warning: incompatible implicit declaration of built-in function 'prin
tf'
C:\TEMP\mgw>
- -- 8< --
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT
Cross-compilation and Shared Libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I just noticed that even with "--disable-static --enable-static", a Linux-to-MinGW cross compiler (mainline) still created static libraries for the C++ and Java runtimes. Is this by design or is it a bug? From the point of view of creating executables for embedded platforms, this sort of makes sense but for a "full-fledged" environment like MinGW, it doesn't - yes, it is a bit painful to transfer the executable and all the libraries it depends on to the target machine, but this should not be barred as such. Or is there a more profound reason for this feature? Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEj4uOYb1hx2wRS48RApY/AJ9hXFfYyRRipZW2o29D0GFHd3bxcACfSL/s 8nBAEYP3FvoFFM1EjErEvPc= =Z47d -END PGP SIGNATURE-
Re: Cross-compilation and Shared Libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent wrote: > Ranjit Mathew wrote: > >> I just noticed that even with "--disable-static --enable-static", > > Do you mean --disable-static --enable-shared? Yes, sorry for the silly typo. >> a Linux-to-MinGW cross compiler (mainline) still created static >> libraries for the C++ and Java runtimes. Is this by design or is it >> a bug? From the point of view of creating executables for embedded > > As far as I know, shared libstdc++ for mingw/cygwin has never worked, > you always get static no matter what you do, regardless of > --enable-shared or native/cross. I don't know if this is because of the > archaic version of libtool that's in the tree, or some other reason. It > sure would be nice to get a shared libstdc++ one of these days without > having to resort to hacks like manually linking together all the .o > files in the build tree. I had forgotten about libtool's limitations w.r.t. shared libaries for Windows that TJ Laurenzo had already hit while trying to create a shared libgcj for Windows: http://gcc.gnu.org/ml/java/2005-09/msg9.html Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEj6UJYb1hx2wRS48RAoXyAJ4uTzoPrm+1Ov0h/JHBnPBi3QFezQCfRjxo utyPNuPlYio/vkAn6XvVDNU= =o8Xf -END PGP SIGNATURE-
DLLs for GCC/Windows (Was: Re: Cross-compilation and Shared Libraries)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent wrote: > > As far as I know, shared libstdc++ for mingw/cygwin has never worked, > you always get static no matter what you do, regardless of > --enable-shared or native/cross. I don't know if this is because of the > archaic version of libtool that's in the tree, or some other reason. It > sure would be nice to get a shared libstdc++ one of these days without > having to resort to hacks like manually linking together all the .o > files in the build tree. The libtool in the GCC tree seems to need --enable-win32-dll to build DLLs for Windows runtimes, which it would use only if the library defines AC_PROVIDE_AC_LIBTOOL_WIN32_DLL - I defined: AC_DEFUN([AC_PROVIDE_AC_LIBTOOL_WIN32_DLL],[]) in libstdc++-v3's configure.ac and regenerated configure. libtool also wants ld_shlibs to be set to "yes" and this I achieved by putting "ld_shlibs=yes" under the case label for "mingw*" in ltcf-cxx.sh. With these kludges, GCC tries to build libstdc++ as a DLL, but fails with undefined references to a whole bunch of stuff (crossed-native build on Linux). I'll investigate this issue later. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkEYkYb1hx2wRS48RApEfAJ9yCJPA5Pjk9+FjFQ8Y1nU27l6nHgCfZeKV YX+VfsdJE6ipkZvj8wgew8U= =XrJZ -END PGP SIGNATURE-
Re: RFC: __cxa_atexit for mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danny Smith wrote: > Adding a real __cxa_atexit to mingw runtime is of course also possible, > but I thought I'd attempt the easy options first. When you say "runtime", do you mean libstdc++ or something like libmingwex.a in "mingw-runtime"? If you mean the former, you can add this in for GCC 4.2 and work on a real __cxa_atexit() for GCC 4.3, if you want. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEneajYb1hx2wRS48RAtVKAKCPOIlElw5cVYajj9Ki1LxcRVwgiwCdFEA6 mL/bT1jDUYyTdJp1tQFEfVg= =iXH6 -END PGP SIGNATURE-
Re: [boehms-gc] Some work on ggc-boehm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stump wrote: > On Jul 11, 2006, at 7:18 AM, Laurynas Biveinis wrote: >> I don't know how many yet, as testsuite takes more than 24 hours >> here on Cygwin, 1.8GHz Turion. I can run it much faster inside in >> VMWare on Linux on the same machine. >> Is there any way to speed it up on Cygwin? > > Sure, install Linux. :-) Sorry, couldn't resist. You might be joking but for GCC hacking I've personally found Linux to be *far faster* and more reliable than Cygwin or MSYS on the same machine. Even when building a native toolchain for Windows (MinGW), I prefer building a crossed-native compiler via Linux rather than a native compiler on Windows. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtFZqYb1hx2wRS48RAsP6AJ9xfNq95CuIENmCVDfIO5GOgo1ltACgqsVd UAkchCKhUOj+xyYhBKDFC70= =mNRE -END PGP SIGNATURE-
