Re: Failure to build libjava on 512MB machine
Gerald Pfeifer wrote: On Tue, 30 Jan 2007, Andrew Haley wrote: 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k and indeed, it does want a lot of memory - at peak some 550m. It'll be smaller on a 32-bit box, but not much smaller. Ouch. I can confirm that on a 32-bit box of mine it fails with about 500MB of main memory. I also only have 500mb on my building box... On Tue, 30 Jan 2007, Tom Tromey wrote: I suppose with some awful build hacking we could split this .o into multiple parts. I'm fine with the situation as it is, myself, but I will do this if the consensus is that we should. Please, pleeease. This really hurts. No I can no longer build libgcj on my notebook and one or two older (but not that old) testers of mine. For me it's fine too... Gerald, what about using a bigger swap partition? Marco
Re: Failure to build libjava on 512MB machine
Anyway, I tried again, this time with the right file, and it took 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k and indeed, it does want a lot of memory - at peak some 550m. It'll be smaller on a 32-bit box, but not much smaller. I want to get rid of TREE_COMPLEXITY! Paolo
Re: debugging capabilities on AIX ?
I wrote: << I'd appreciate feedback on general questions from these observations: Is it generally known/expected that xcoff/stabs debugging capabilities degrade when moving from 3.4 to 4.x ? If yes, how is that considered by AIX GCC developers ? (how serious the issue, is it fixable, are there plans/attempts to move to DWARF2, ...) >> , a number of followups were sent and I wanted to thank participants for the feedback we have received. We are now conducting further experiments and will report further as our understanding of the issues improves. Thanks for your feedback again, With Kind Regards, Olivier
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > I am getting this when I try to compile gcc trunk: > > > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -Wmissing-format-attribute -pedantic > > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include > > -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF > > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function > > 'read_name_map': > > ../../libcpp/files.c:1238: internal compiler error: Floating point > > exception Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > libcpp/files.c:1238 seems to be a call to memcpy. I don't see > anyplace a floating point exception might come from. I've certainly > never seen anything like that. I think this is an hardware error recently got a Bus Error when doing an rm -rf, I hope to change laptop's RAMs soon. I will report back. Thank you for your replies. Regards, ismail
Re: MIPS Wrong-code regression.
David Daney writes: > Richard, > > Sometime between 1/7 and 1/16 on the trunk I started getting wrong code > on a bunch of java testcases under mipsel-linux. > > It looks related to (but not necessarily caused by) this patch: > > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html > > For example if we examine the assembler output of the PR9577.java > testcase, we see: > > . > . > . > $LBB2: > lw $2,40($fp) > sw $2,24($fp) > lw $2,24($fp) > move$4,$2 > .option pic0 > jal _ZN4java4lang6ObjectC1Ev > nop > > .option pic2 > lw $28,16($fp) > $LBE2: > move$sp,$fp > lw $31,36($sp) > lw $fp,32($sp) > addiu $sp,$sp,40 > j $31 > nop > > The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, even > though that symbol is defined in libgcj.so. The assembler and linker > conspire to jump to address 0x for this call. > > It looks like the logic that decides if a symbol is external to the > compilation unit is faulty. > > Any ideas about where it might have gone wrong? Does http://gcc.gnu.org/ml/gcc/2007-01/msg01184.html fix this? Andrew.
Re: Failure to build libjava on 512MB machine
Tom Tromey writes: > > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > Andrew> Anyway, I tried again, this time with the right file, and it took > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > Andrew> and indeed, it does want a lot of memory - at peak some 550m. It'll > Andrew> be smaller on a 32-bit box, but not much smaller. > > I suppose with some awful build hacking we could split this .o into > multiple parts. I'm fine with the situation as it is, myself, but I > will do this if the consensus is that we should. I'd want a bit more information. There's no reason that a 512M box couldn't cope with a 550M process. Sure, it'll be slow, but it should still work, and this is an extreme case. If there is to be a maximum process size during building, we need to make a sane decision about what that size should be. Andrew.
Re: Failure to build libjava on 512MB machine
Gerald Pfeifer writes: > On Tue, 30 Jan 2007, Andrew Haley wrote: > > 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > > 0maxresident)k > > > > and indeed, it does want a lot of memory - at peak some 550m. It'll > > be smaller on a 32-bit box, but not much smaller. > > Ouch. I can confirm that on a 32-bit box of mine it fails with about > 500MB of main memory. Can you tell us a bit more about the config? It really shouldn't be failing to compile this program. Andrew.
Re: Failure to build libjava on 512MB machine
On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote: > > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > Andrew> Anyway, I tried again, this time with the right file, and it took > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > 0maxresident)k > Andrew> and indeed, it does want a lot of memory - at peak some 550m. It'll > Andrew> be smaller on a 32-bit box, but not much smaller. > > I suppose with some awful build hacking we could split this .o into > multiple parts. I'm fine with the situation as it is, myself, but I > will do this if the consensus is that we should. It does look like we are scaring away some people with the long build times and memory hungry build of libjava. I only started building libgcj again recently when I got a 3Ghz/64-bit/dual-core/2GB machine. And even on that box an compile/install/test cycle is not something I want to do more than once or twice a day. Having a 'light' build would be really good. Even if it is just a configure option that creates an unoptimized build. Has someone looked into why gcj takes so much memory/time to compile? And might recent changes in tree-ssa have increased memory and compile time? A frysk build for example is a lot (almost twice) as slow with svn trunk compared with 4.1.1. See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30588 Cheers, Mark
Re: Failure to build libjava on 512MB machine
Le Wed, Jan 31, 2007 at 09:45:04AM +, Andrew Haley écrivait/wrote:
>
> I'd want a bit more information. There's no reason that a 512M box
> couldn't cope with a 550M process. Sure, it'll be slow, but it should
> still work, and this is an extreme case. If there is to be a maximum
> process size during building, we need to make a sane decision about
> what that size should be.
I personnaly am not very favorable to such a limitation (of the maxium
process size during building), because I would suppose that taking such a
decision is a slow process. In the event most people want have such a
limitation explicitly defined I hope it would ber at least some moving
limit, like "the average RAM of most PCs sold last year" and not "512Mb"
(since I am afraid such a limit would stay carved in stone for a long while,
and that a formal agreement on it would take one year to be reached).
After all, I believe that most people who actually compile GCC have a quite
fast & big machine (which I leave purposely undefined here). As an extreme
example, I won't compile GCC on a PDA!
I also acknowledge that I am living in the "first world" and that some
developers have probably much slower machines than I do. But I think that I
don't have the fastest/biggest machine (among developers') neither...
In addition, this 550Mb process size seems to occur only for some languages
(Java probably) of GCC, not all of them.
I am afraid that the GCC community would one day decide something like "no
patch is accepted if the bootstrap procedure of the patched compiler takes
more than X minutes and Y megabytes on reference platform Z" with suitable
(small) values for X and Y and Z. I hope this won't happen.
Maybe we just could put in the documentation -for information only- the
typical time, disk space & memory usage of a typical bootstrap (on a
"typicazl" but specified system), just as a hint to future developers. I
believe that disk usage is already there (but didn't find it quickly).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Failure to build libjava on 512MB machine
Mark Wielaard writes: > On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote: > > > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > > > Andrew> Anyway, I tried again, this time with the right file, and it took > > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata > > 0maxresident)k > > Andrew> and indeed, it does want a lot of memory - at peak some 550m. > > It'll > > Andrew> be smaller on a 32-bit box, but not much smaller. > > > > I suppose with some awful build hacking we could split this .o into > > multiple parts. I'm fine with the situation as it is, myself, but I > > will do this if the consensus is that we should. > > It does look like we are scaring away some people with the long > build times and memory hungry build of libjava. I only started > building libgcj again recently when I got a > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an > compile/install/test cycle is not something I want to do more than > once or twice a day. I'm surprised: the libgcj build takes about 15mis on my box, which is similar to yours. > Having a 'light' build would be really good. Even if it is just a > configure option that creates an unoptimized build. > > Has someone looked into why gcj takes so much memory/time to compile? Yes. Lots of times. It's not entirely to do with gcj: it's mostly time spent in the emiddle-end. gcc, g++, etc do the same. The main difference with gcj is that we're compiling bigger files. One thing that could be improved is the quality of trees geneerated by the gcj front-end, which are unnecessaily verbose, but that would shave a few percentage points of the total time/space. > And might recent changes in tree-ssa have increased memory and compile > time? Yes, I think so. Recent changes to the optimizers do cost compile time and space. I think the authors are aware of that. Andrew.
Re: Failure to build libjava on 512MB machine
Andrew Haley writes: > > > > It does look like we are scaring away some people with the long > > build times and memory hungry build of libjava. I only started > > building libgcj again recently when I got a > > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an > > compile/install/test cycle is not something I want to do more than > > once or twice a day. > > I'm surprised: the libgcj build takes about 15mis on my box, which is > similar to yours. Actually, it used to take that long, but libgcj is a lot bigger these days. I will re-measure. Andrew.
Re: Failure to build libjava on 512MB machine
May I respectfully point out that the gcc make process already has hard-coded hackery to work around the limitations of certain machines, oses, non-GNU makes, linkers, and assembers, etc? (The thing that comes to mind is the 42 item limit for make rules on AIX: see libstdc++-v3/include/Makefile.am. There are no doubt many others.) Adding hacks to the java Makefiles to make parse.o compilable across a large variety of machines/os's seems necessary and essential. If not, the java build and testing base will only go down over time. This seems the opposite of what you want, especially after the big merge to ecj that was just finished. Either this part of libjava can be made optional, or the rule for this object file can be made more complex, or the file can be compiled without optimizations, whatever. There seem to be a variety of approaches that would work. I can understand the interest in wanting to delve deeper into the actual causes of the memory explosion with compiling java/html/parse.o, and the reluctance to add build hacks, but I am somewhat concerned with the response of the java maintainers (and others) that it's OK to require >512MB to bootstrap gcc with java, or that make times "WORKSFORME." best, benjamin
Re: GCC 4.1.2 RC1
On Tue, 2007-01-30 at 17:26 -0800, Mark Mitchell wrote: > Robert Schwebel wrote: > > > What about PR28516, would it be acceptable for 4.1.2? > > There are two issues: > > (1) it's not marked as a 4.1 regression, let alone a regression from > 4.1.x. Did this test case work with older versions of GCC? > > (2) Richard Earnshaw objected to applying the patch to 4.1 because it > requires a newer GAS. Paul's counter that the newer GAS is only needed > if your compiler would otherwise crash seems persuasive to me, if true, > but I'd certainly want Richard to be comfortable with the change. I agree that in this instance it seems reasonable to require the newer GAS version. So objection withdrawn. R.
Re: Failure to build libjava on 512MB machine
On Wed, Jan 31, 2007 at 11:42:12AM +, Andrew Haley wrote: > Andrew Haley writes: > > > > > > It does look like we are scaring away some people with the long > > > build times and memory hungry build of libjava. I only started > > > building libgcj again recently when I got a > > > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an > > > compile/install/test cycle is not something I want to do more than > > > once or twice a day. > > > > I'm surprised: the libgcj build takes about 15mis on my box, which is > > similar to yours. > > Actually, it used to take that long, but libgcj is a lot bigger these > days. I will re-measure. It takes 29 minutes for me on the trunk, with disabled java maintainer mode. Multilib (-m64/-m32) build on 2.66GHz/64-bit/quad-core/2GB machine. Jakub
Re: Failure to build libjava on 512MB machine
Benjamin Kosnik writes: > > I am somewhat concerned with the response of the java maintainers > (and others) that it's OK to require >512MB to bootstrap gcc with > java, or that make times "WORKSFORME." Well, I didn't say that, so I hope you aren't referring to me. But before we do anything we need to know more about the machine on which it failed. Ultimately, it's a question of what we consider to be a reasonable machine on which to build libgcj. I don't know the answer to that. Andrew.
Re: Failure to build libjava on 512MB machine
Wiadomość napisana w dniu 2007-01-31, o godz12:50, przez Andrew Haley: Benjamin Kosnik writes: I am somewhat concerned with the response of the java maintainers (and others) that it's OK to require >512MB to bootstrap gcc with java, or that make times "WORKSFORME." Well, I didn't say that, so I hope you aren't referring to me. But before we do anything we need to know more about the machine on which it failed. Ultimately, it's a question of what we consider to be a reasonable machine on which to build libgcj. I don't know the answer to that. 512MB is *certainly* resonable. It's the most common amount of shipping RAM for in esp. notebooks and it's what usually get's allocated to virtualization solutions.
Re: Failure to build libjava on 512MB machine
Marcin Dalecki wrote: 512MB is *certainly* resonable. It's the most common amount of shipping RAM for in esp. notebooks and it's what usually get's allocated to virtualization solutions. I agree 512M is reasonable (really a compiler taking more than half a gigabyte for any normal sources is a bit wanton). But in any case the memory requirement was only 550M here, not so bad, and should be easily compilable on a 512M machine. Seems like we still don't understand the problem here. The complaint about building libjava taking too long is really a separate issue, the question for this thread is to understand why there was a failure, and as far as I can see we still don't understand that.
Re: After GIMPLE...
Paulo J. Matos wrote on 01/30/07 10:11: Well, I spent the morning looking at the code and since what I need is only the flow of gcc up until I have the GIMPLE tree, I could add a pass after the pass which generates the gimple tree, in that pass I do what I need with the gimple tree and then call exit(). Would this be a good idea? It would probably not be a good idea. Passes are called for each function in the callgraph. If you stop immediately after your pass, you will leave all the other functions unprocessed. What is it that you want to do? If you need dataflow information, you probably also need to have the GIMPLE code in SSA form. If yes, then the idea would be to create a pass and add it in passes.c after the line NEXT_PASS (pass_lower_cf); since from what I heard in #gcc, this is where the gimple tree is created, right? Well, it depends on what you need. If your pass can work in high GIMPLE then you can insert it before that. pass_lower_cf lowers control flow and lexical scopes, but not EH. Perhaps if you describe a little bit what you are trying to do, we can give you a better idea.
Re: After GIMPLE...
On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 01/30/07 10:11: > Well, I spent the morning looking at the code and since what I need is > only the flow of gcc up until I have the GIMPLE tree, I could add a > pass after the pass which generates the gimple tree, in that pass I do > what I need with the gimple tree and then call exit(). Would this be a > good idea? > It would probably not be a good idea. Passes are called for each function in the callgraph. If you stop immediately after your pass, you will leave all the other functions unprocessed. What is it that you want to do? If you need dataflow information, you probably also need to have the GIMPLE code in SSA form. Yes, only after some search I understood that passes are done on a function by function basis which doesn't suit as is. Well, I want to get a tree representation of the source (why gimple? because it's language indep, so if I do it in gimple, I don't need to worry about the language in which the source was written) and analyse it. This analysis is not really specified at the moment. Is part of my PhD and will certainly evolve but it would start with something like telling the users how many variables of which type are defined in the given source code, how many if blocks there are, etc. and then exit. The choice of gimple is two-fold. First you get language independence, that's why I just don't do it in C or C++ directly, or Java or Fortran. The reason why I don't do it in a lower language is because some constructs would be lost with some optimization details. Constructs which might later be useful for my analysis. So, ideally, I would like just the gcc part until the first part of the middleend where you have a 'no optimizations', language independent AST of the source file. The reason why I just don't parse the gimple output of dump is because, as it was said, there's information regarding the source which it's not represented in the dump and which might be useful to me. > If yes, then the idea would be to create a pass and add it in passes.c > after the line > NEXT_PASS (pass_lower_cf); > > since from what I heard in #gcc, this is where the gimple tree is > created, right? > Well, it depends on what you need. If your pass can work in high GIMPLE then you can insert it before that. pass_lower_cf lowers control flow and lexical scopes, but not EH. Perhaps if you describe a little bit what you are trying to do, we can give you a better idea. I've described it above. Any suggestions regarding the best way to taylor gcc to fit my needs? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: MIPS Wrong-code regression.
> "David" == David Daney <[EMAIL PROTECTED]> writes: David> The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, David> even though that symbol is defined in libgcj.so. The assembler and David> linker conspire to jump to address 0x for this call. Could also be the problem reported at the end of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606 Tom
libstdc++: abi_check fails due to lacking long double arithmetic functions
Hi, the gcc 4.1 testsuite currently shows a failure for the libstdc++ abi_check testcase on s390 and s390x and I see this one failing on several other targets as well. On s390x abi_check complains about 22 missing functions in libstdc++.so: FUNC:acosl@@GLIBCXX_3.4.3 FUNC:asinl@@GLIBCXX_3.4.3 FUNC:atan2l@@GLIBCXX_3.4 FUNC:atanl@@GLIBCXX_3.4.3 FUNC:ceill@@GLIBCXX_3.4.3 FUNC:coshl@@GLIBCXX_3.4 FUNC:cosl@@GLIBCXX_3.4 FUNC:expl@@GLIBCXX_3.4 FUNC:floorl@@GLIBCXX_3.4.3 FUNC:fmodl@@GLIBCXX_3.4.3 FUNC:frexpl@@GLIBCXX_3.4.3 FUNC:hypotl@@GLIBCXX_3.4 FUNC:ldexpl@@GLIBCXX_3.4.3 FUNC:log10l@@GLIBCXX_3.4 FUNC:logl@@GLIBCXX_3.4 FUNC:modfl@@GLIBCXX_3.4.3 FUNC:powl@@GLIBCXX_3.4 FUNC:sinhl@@GLIBCXX_3.4 FUNC:sinl@@GLIBCXX_3.4 FUNC:sqrtl@@GLIBCXX_3.4 FUNC:tanhl@@GLIBCXX_3.4 FUNC:tanl@@GLIBCXX_3.4 I think this only happens when building gcc 4.1 on a host with glibc 2.4 installed. abi_check started failing around the time I've upgraded glibc on our gcc daily build. Here is what I found out about it: 1. Works with older glibc: When gcc is built on a machine with glibc 2.3.x no long double arithmetic functions are exported by glibc. The libstdc++ configure script figures that out and libmath/stubs.c generates wrapper functions calling the double versions of these functions. The resulting libstdc++ has the above symbols and abi_check is happy. 2. Works with gcc 4.2 and higher: Jakub made a patch for compatility.cc in libstdc++ providing wrapper functions. These become active when _GLIBCXX_LONG_DOUBLE_COMPAT is defined by configure for targets which have to support long-double-64 AND long-double-128. So we again have these wrapper functions and abi_check succeeds. 3. Doesn't work with gcc 4.1 and glibc 2.4: Since Jakubs patch hasn't been applied to gcc 4.1 branch these symbols are simply lacking. I'm not sure whether thats a serious problem or not. A libstdc++ without the long double functions implies usage of glibc 2.4 so a binary needing such a function then uses the glibc version - right?! So if thats no problem at all I think we should regenerate the gcc 4.1 baseline_symbols.txt for the affected targets in order to make abi_check happy again. Bye, -Andreas-
Re: Failure to build libjava on 512MB machine
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes: Gerald> Ouch. I can confirm that on a 32-bit box of mine it fails with about Gerald> 500MB of main memory. It is interesting that it is the HTML parser that is causing problems. For me, gnu-xml.lo is usually the awful one. Does that one cause problems for you as well? Anyway, I did notice a very large .class file in the HTML parser. So perhaps that is the problem. But I wonder whether this is a GCC regression of some sort. Gerald> Please, pleeease. This really hurts. No I can no longer build libgcj Gerald> on my notebook and one or two older (but not that old) testers of mine. Gerald> Ger ``begging'' ald No need to beg! You've built up so much good will that fixing this barely scratches the surface. Tom
Re: MIPS Wrong-code regression.
Andrew Haley wrote:
David Daney writes:
> Richard,
>
> Sometime between 1/7 and 1/16 on the trunk I started getting wrong code
> on a bunch of java testcases under mipsel-linux.
>
> It looks related to (but not necessarily caused by) this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html
>
> For example if we examine the assembler output of the PR9577.java
> testcase, we see:
>
> .
> .
> .
> $LBB2:
> lw $2,40($fp)
> sw $2,24($fp)
> lw $2,24($fp)
> move$4,$2
> .option pic0
> jal _ZN4java4lang6ObjectC1Ev
> nop
>
> .option pic2
> lw $28,16($fp)
> $LBE2:
> move$sp,$fp
> lw $31,36($sp)
> lw $fp,32($sp)
> addiu $sp,$sp,40
> j $31
> nop
>
> The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, even
> though that symbol is defined in libgcj.so. The assembler and linker
> conspire to jump to address 0x for this call.
>
> It looks like the logic that decides if a symbol is external to the
> compilation unit is faulty.
>
> Any ideas about where it might have gone wrong?
Does http://gcc.gnu.org/ml/gcc/2007-01/msg01184.html fix this?
Unfortunately no. The following output is generated with r121186 +
Andrew.s patched class.c
There are several problems with the generated code for the failing class:
public class PR9577
{
private native void sayHello (String[] s, Object o);
public static void main (String[] args)
{
PR9577 x = new PR9577( );
x.sayHello( null, null);
}
}
Note that this class has an implicit public constructor that does
nothing other than call the super class (java.lang.Object) constructor.
/home/build/gcc-build/gcc/gcj -v
-B/home/build/gcc-build/mipsel-unknown-linux-gnu/libjava/
-B/home/build/gcc-build/gcc/ --encoding=UTF-8
-B/home/build/gcc-build/mipsel-unknown-linux-gnu/libjava/testsuite/../
/home/build/gcc/libjava/testsuite/libjava.cni/PR9577.jar -o j.s -S
Here is the entire generated code for the constructor:
.globl _ZN6PR9577C1Ev
.ent_ZN6PR9577C1Ev
.type _ZN6PR9577C1Ev, @function
_ZN6PR9577C1Ev:
$LFB2:
.frame $fp,40,$31 # vars= 8, regs= 2/0, args= 16,
gp= 8
.mask 0xc000,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-40
$LCFI0:
sw $31,36($sp)
$LCFI1:
sw $fp,32($sp)
$LCFI2:
move$fp,$sp
$LCFI3:
.cprestore 16
sw $4,40($fp)
$LBB2:
lw $2,40($fp)
sw $2,24($fp)
lw $2,24($fp)
move$4,$2
.option pic0
jal _ZN4java4lang6ObjectC1Ev
nop
.option pic2
lw $28,16($fp)
$LBE2:
move$sp,$fp
lw $31,36($sp)
lw $fp,32($sp)
addiu $sp,$sp,40
j $31
nop
.setmacro
.setreorder
$LFE2:
.end_ZN6PR9577C1Ev
Here are the problems I see:
1) The call to _ZN4java4lang6ObjectC1Ev is absolute instead of via the
plt. That function is in a shared library not this compilation unit.
2) It is a public global method. $gp should be initialized, but it is not.
If I compile it with -O3 -mshared I get:
.globl _ZN6PR9577C1Ev
.ent_ZN6PR9577C1Ev
.type _ZN6PR9577C1Ev, @function
_ZN6PR9577C1Ev:
$LFB2:
.frame $sp,32,$31 # vars= 0, regs= 1/0, args= 16,
gp= 8
.mask 0x8000,-8
.fmask 0x,0
.setnoreorder
.cpload $25
.setnomacro
addiu $sp,$sp,-32
$LCFI0:
sw $31,24($sp)
$LCFI1:
.cprestore 16
lw $25,%call16(_ZN4java4lang6ObjectC1Ev)($28)
jalr$25
nop
lw $28,16($sp)
lw $31,24($sp)
j $31
addiu $sp,$sp,32
.setmacro
.setreorder
$LFE2:
.end_ZN6PR9577C1Ev
This time the call to _ZN4java4lang6ObjectC1Ev *is* done via the plt,
but we are using .cpload instead of having gcc generate the individual
instructions and interleaving them with the $sp adjustment as it
normally does.
David Daney
Re: Failure to build libjava on 512MB machine
> "Benjamin" == Benjamin Kosnik <[EMAIL PROTECTED]> writes: Benjamin> but I am Benjamin> somewhat concerned with the response of the java maintainers (and Benjamin> others) that it's OK to require >512MB to bootstrap gcc with java, or Benjamin> that make times "WORKSFORME." My proposal was more that, if it "WORKSFORUS", then I wouldn't bother hacking on the build. Build hacking is unpleasant and I am somewhat motivated to avoid it. Anyhow, I'm testing a patch for this case. And, this will make it a bit simpler to split other objects should it be needed. Tom
Re: After GIMPLE...
Paulo J. Matos wrote on 01/31/07 11:26: So, ideally, I would like just the gcc part until the first part of the middleend where you have a 'no optimizations', language independent AST of the source file. OK, so you probably want to inject your pass right before pass_build_ssa (in init_optimization_passes). All the facilities to traverse the IL and flowgraph described in the Tree SSA section of the internals manual should apply.
gcc-4.2-20070131 is now available
Snapshot gcc-4.2-20070131 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070131/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 121441 You'll find: gcc-4.2-20070131.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070131.tar.bz2 C front end and core compiler gcc-ada-4.2-20070131.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070131.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070131.tar.bz2 C++ front end and runtime gcc-java-4.2-20070131.tar.bz2 Java front end and runtime gcc-objc-4.2-20070131.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070131.tar.bz2The GCC testsuite Diffs from 4.2-20070124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: MIPS Wrong-code regression.
David Daney wrote:
Andrew Haley wrote:
David Daney writes:
> Richard,
> > Sometime between 1/7 and 1/16 on the trunk I started getting
wrong code > on a bunch of java testcases under mipsel-linux.
OK, it was r120621 (The gcj-elipse branch merge) where things started
being broken.
There were some large changes in the java front-end with this commit.
> > It looks related to (but not necessarily caused by) this patch:
> > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html
> > For example if we examine the assembler output of the
PR9577.java > testcase, we see:
> > .
> .
> .
> $LBB2:
> lw $2,40($fp)
> sw $2,24($fp)
> lw $2,24($fp)
> move$4,$2
> .option pic0
> jal _ZN4java4lang6ObjectC1Ev
> nop
> > .option pic2
> lw $28,16($fp)
> $LBE2:
> move$sp,$fp
> lw $31,36($sp)
> lw $fp,32($sp)
> addiu $sp,$sp,40
> j $31
> nop
> > The call to _ZN4java4lang6ObjectC1Ev is being generated as
non-pic, even > though that symbol is defined in libgcj.so. The
assembler and linker > conspire to jump to address 0x for
this call.
> > It looks like the logic that decides if a symbol is external to
the > compilation unit is faulty.
> > Any ideas about where it might have gone wrong?
Does http://gcc.gnu.org/ml/gcc/2007-01/msg01184.html fix this?
Unfortunately no. The following output is generated with r121186 +
Andrew.s patched class.c
There are several problems with the generated code for the failing class:
public class PR9577
{
private native void sayHello (String[] s, Object o);
public static void main (String[] args)
{
PR9577 x = new PR9577( );
x.sayHello( null, null);
}
}
Note that this class has an implicit public constructor that does
nothing other than call the super class (java.lang.Object) constructor.
/home/build/gcc-build/gcc/gcj -v
-B/home/build/gcc-build/mipsel-unknown-linux-gnu/libjava/
-B/home/build/gcc-build/gcc/ --encoding=UTF-8
-B/home/build/gcc-build/mipsel-unknown-linux-gnu/libjava/testsuite/../
/home/build/gcc/libjava/testsuite/libjava.cni/PR9577.jar -o j.s -S
Here is the entire generated code for the constructor:
.globl _ZN6PR9577C1Ev
.ent_ZN6PR9577C1Ev
.type _ZN6PR9577C1Ev, @function
_ZN6PR9577C1Ev:
$LFB2:
.frame $fp,40,$31 # vars= 8, regs= 2/0, args= 16,
gp= 8
.mask 0xc000,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-40
$LCFI0:
sw $31,36($sp)
$LCFI1:
sw $fp,32($sp)
$LCFI2:
move$fp,$sp
$LCFI3:
.cprestore 16
sw $4,40($fp)
$LBB2:
lw $2,40($fp)
sw $2,24($fp)
lw $2,24($fp)
move$4,$2
.option pic0
jal _ZN4java4lang6ObjectC1Ev
nop
.option pic2
lw $28,16($fp)
$LBE2:
move$sp,$fp
lw $31,36($sp)
lw $fp,32($sp)
addiu $sp,$sp,40
j $31
nop
.setmacro
.setreorder
$LFE2:
.end_ZN6PR9577C1Ev
Here are the problems I see:
1) The call to _ZN4java4lang6ObjectC1Ev is absolute instead of via the
plt. That function is in a shared library not this compilation unit.
2) It is a public global method. $gp should be initialized, but it is not.
If I compile it with -O3 -mshared I get:
.globl _ZN6PR9577C1Ev
.ent_ZN6PR9577C1Ev
.type _ZN6PR9577C1Ev, @function
_ZN6PR9577C1Ev:
$LFB2:
.frame $sp,32,$31 # vars= 0, regs= 1/0, args= 16,
gp= 8
.mask 0x8000,-8
.fmask 0x,0
.setnoreorder
.cpload $25
.setnomacro
addiu $sp,$sp,-32
$LCFI0:
sw $31,24($sp)
$LCFI1:
.cprestore 16
lw $25,%call16(_ZN4java4lang6ObjectC1Ev)($28)
jalr$25
nop
lw $28,16($sp)
lw $31,24($sp)
j $31
addiu $sp,$sp,32
.setmacro
.setreorder
$LFE2:
.end_ZN6PR9577C1Ev
This time the call to _ZN4java4lang6ObjectC1Ev *is* done via the plt,
but we are using .cpload instead of having gcc generate the individual
instructions and interleaving them with the $sp adjustment as it
normally does.
David Daney
Re: MIPS Wrong-code regression.
David Daney wrote:
David Daney wrote:
Andrew Haley wrote:
David Daney writes:
> Richard,
> > Sometime between 1/7 and 1/16 on the trunk I started getting
wrong code > on a bunch of java testcases under mipsel-linux.
OK, it was r120621 (The gcj-elipse branch merge) where things started
being broken.
There were some large changes in the java front-end with this commit.
I am testing the attached patch that seems to fix the problem.
Richard, sorry for dragging you into this mess.
David Daney
Index: gcc/java/class.c
===
--- gcc/java/class.c (revision 121441)
+++ gcc/java/class.c (working copy)
@@ -2510,10 +2510,12 @@
tree method_name = DECL_NAME (method_decl);
TREE_PUBLIC (method_decl) = 1;
+
/* Considered external unless it is being compiled into this object
- file. */
- DECL_EXTERNAL (method_decl) = ((is_compiled_class (this_class) != 2)
- || METHOD_NATIVE (method_decl));
+ file, or it was already flagged as external. */
+ if (!DECL_EXTERNAL (method_decl))
+DECL_EXTERNAL (method_decl) = ((is_compiled_class (this_class) != 2)
+ || METHOD_NATIVE (method_decl));
if (ID_INIT_P (method_name))
{
Re: MIPS Wrong-code regression.
Tom Tromey wrote: "David" == David Daney <[EMAIL PROTECTED]> writes: David> The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic, David> even though that symbol is defined in libgcj.so. The assembler and David> linker conspire to jump to address 0x for this call. Could also be the problem reported at the end of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606 Tom I suspect it is the same problem. APH's patch would not have fixed it if it were. David Daney
Arithmetic conversions between two different data types
Hello all, In arithmetic expressions we need to conversion when the operands are of different data types. In gcc 4.1.1 where is this process started? Is this in c-typeck.c, particularly in the function c_common_type ? Thanks in advance, Regards, Shafi.
trunk rev121458 dont bootstrap
Hello
(I don't know if the good mailing list for this is gcc@ or gcc-patches@)
Apparently trunk rev 121458 don't bootstrap on linux debian sid amd64 ie
x86_64-unknown-linux-gnu
I'm getting
make[4]: Leaving directory
`/usr/src/Lang/gcc-trunk/_BootObj2/x86_64-unknown-linux-gnu/libgcc'
/usr/src/Lang/gcc-trunk/_BootObj2/./gcc/xgcc
-B/usr/src/Lang/gcc-trunk/_BootObj2/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -O2
-O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../.././gcc -I/usr/src/Lang/gcc-trunk/libgcc
-I/usr/src/Lang/gcc-trunk/libgcc/. -I/usr/src/Lang/gcc-trunk/libgcc/../gcc
-I/usr/src/Lang/gcc-trunk/libgcc/../include
-I/usr/src/Lang/gcc-trunk/libgcc/../libdecnumber -I../../libdecnumber -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/usr/src/Lang/gcc-trunk/libgcc/../gcc/libgcc2.c \
-fvisibility=hidden -DHIDE_EXPORTS
/usr/src/Lang/gcc-trunk/libgcc/../gcc/libgcc2.c: In function '__multi3':
/usr/src/Lang/gcc-trunk/libgcc/../gcc/libgcc2.c:566: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
configured with
/usr/src/Lang/gcc-trunk/configure --enable-maintainer-mode
--enable-languages=c
Does that seems familiar to anyone?
Regards!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
