Re: Failure to build libjava on 512MB machine
Tom Tromey wrote: "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. Aren't you here solving the wrong problem? The problem that is caused by the real problem? If it takes about 30 to 40min to build this html/parser.o and gnu-xml.o needs about 1 or 2 minutes but is - last time I took a look - a lot bigger than the html parser, shouldn't then be investigated why this html parser is such a hard thing? Otherwise there might just come another object after some changes with the same problem... Marco
Fwd: Compiling GCC
I forgot to send to the mailing list that the --disable-multilib from Andrew worked. Thank you all. :) -- Forwarded message -- From: Paulo J. Matos <[EMAIL PROTECTED]> Date: Jan 31, 2007 3:41 PM Subject: Re: Compiling GCC To: Andrew Haley <[EMAIL PROTECTED]> On 1/31/07, Andrew Haley <[EMAIL PROTECTED]> wrote: The problem might be that you don't have the target libs installed for a multilib build. Try --disable-multilib. Done! :) Working now, thank you! Andrew. -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: After GIMPLE...
On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote: 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. What can I do then to stop gcc to further process things? After informing the user there's no more reason on my site to continue. -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Use of INSN_CODE
Hi All, I am using recog_memoized in the machine dependent reorg pass. However, It is causing an ICE because unwittingly a CODE_LABEL is getting passed to it. I understand that CODE_LABEL is in the RTX_EXTRA class and intuitively It is wrong to use INSN_CODE ( which is used in recog_memoized) on CODE_LABEL simply because it is not int the RTX_INSN class. However, the internals only warn against using INSN_CODE on use, clobber, asm_input, addr_vec, addr_diff_vec. There is no mention of other members of the other members of RTX_EXTRA. or shouldnt recog_memoized have an INSN_P check in it ? Am I missing something here ? TIA, Pranav
Re: Use of INSN_CODE
On 2/1/07, Pranav Bhandarkar <[EMAIL PROTECTED]> wrote: However, the internals only warn against using INSN_CODE on use, clobber, asm_input, addr_vec, addr_diff_vec. There is no mention of other members of the other members of RTX_EXTRA. or shouldnt recog_memoized have an INSN_P check in it ? Am I missing something here ? recog* should ice if what it gets passed is not an insn (i.e. !INSN_P). Gr. Steven
Re: MIPS Wrong-code regression.
David Daney writes: > 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. OK. Does your patch work? If it does, I'm going to trace through jc1 to see if I can find the real origin of this regression. TVM, Andrew.
(OffTopic) trouble registering on www.gccsummit.org
Hello All,
Sorry for this off-topic message, but I have some troubles registering on
https://www.gccsummit.org/2007/login.php and my email to
[EMAIL PROTECTED] bounced.
My own email is [EMAIL PROTECTED]
Does anyone know who should I contact about the gccsummit.org web site or
registration system?
Regards, and apologies for this slightly off topic message! I hope someone
in charge of the gccsummit.org site would read it.
--
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: After GIMPLE...
Paulo J. Matos wrote on 02/01/07 04:37: What can I do then to stop gcc to further process things? After informing the user there's no more reason on my site to continue. Stop gracefully or just stop? The latter is easy. The former involves writing code to skip all passes after a certain point, or just don't schedule the passes don't want to run. See init_optimization_passes.
Re: After GIMPLE...
On 2/1/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 02/01/07 04:37: > What can I do then to stop gcc to further process things? After > informing the user there's no more reason on my site to continue. > Stop gracefully or just stop? The latter is easy. The former involves writing code to skip all passes after a certain point, or just don't schedule the passes don't want to run. See init_optimization_passes. Well, I guessed the answer would be something like that... :) I've already started working on it and everything seems ok up until now so I'm on the right track. :) Regards and thanks very much, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Interesting build failure on trunk
On Wednesday 31 January 2007 11:26:38 Ismail Dönmez wrote: > 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 Ok its not, I tried to build on AMD64 3500+ 1GB RAM ( unlike my Centrino laptop, totally different hardware ) and it crashes in the same exact way. now my guess is host compiler is somehow hosed , bad news for gcc 4.2 I guess. Regards, ismail
Re: Interesting build failure on trunk
On 2/1/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: On Wednesday 31 January 2007 11:26:38 Ismail Dönmez wrote: > 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 Ok its not, I tried to build on AMD64 3500+ 1GB RAM ( unlike my Centrino laptop, totally different hardware ) and it crashes in the same exact way. now my guess is host compiler is somehow hosed , bad news for gcc 4.2 I guess. This is probably PR30650 (just don't use profiledbootstrap). Richard.
Re: trunk rev121458 dont bootstrap
On Thu, Feb 01, 2007 at 08:03:36AM +0100, Basile STARYNKEVITCH wrote: > > 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? > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00067.html H.J.
Re: MIPS Wrong-code regression.
Andrew Haley wrote:
David Daney writes:
> 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.
OK. Does your patch work? If it does, I'm going to trace through jc1
to see if I can find the real origin of this regression.
I am testing a new patch that (I think) fixes the real problem. I am
not sure why it regressed as Richard added the code that was being made
to fail last March. The bad code was in class.c when green committed it
over 8 years ago. Several months ago Tromey removed it and then added
it back a few days later.
The problem is that in is_compiled_class() we were erroneously saying
that a candidate class was being emitted to the object file *if* it was
the current_class being parsed. This does not hold because many classes
are parsed that are not emitted so that jc1 can calculate the class
layout and load the symbol tables.
The real fix,I think, is the one I made to is_compiled_class(). I left
the change to layout_class_method() where we don't re-check for
DECL_EXTERNAL if it is already set as a micro-optimization. I tested
both with and without this and obtained correct results, so it is not
really needed.
I also wonder if your previous patch setting DECL_EXTERNAL is still
needed after this has been applied. I didn't check.
I am currently regression testing the attached patch on
x86_64-pc-linux-gnu, and will post it to gcc-patches@ if it passes.
David Daney.
Index: gcc/java/class.c
===
--- gcc/java/class.c (revision 121441)
+++ gcc/java/class.c (working copy)
@@ -2134,10 +2134,6 @@ is_compiled_class (tree class)
return 1;
if (TYPE_ARRAY_P (class))
return 0;
- /* We have to check this explicitly to avoid trying to load a class
- that we're currently parsing. */
- if (class == current_class)
-return 2;
seen_in_zip = (TYPE_JCF (class) && JCF_SEEN_IN_ZIP (TYPE_JCF (class)));
if (CLASS_FROM_CURRENTLY_COMPILED_P (class))
@@ -2147,7 +2143,7 @@ is_compiled_class (tree class)
been loaded already. Load it if necessary. This prevent
build_class_ref () from crashing. */
- if (seen_in_zip && !CLASS_LOADED_P (class))
+ if (seen_in_zip && !CLASS_LOADED_P (class) && (class != current_class))
load_class (class, 1);
/* We return 2 for class seen in ZIP and class from files
@@ -2161,7 +2157,7 @@ is_compiled_class (tree class)
{
if (CLASS_FROM_SOURCE_P (class))
safe_layout_class (class);
- else
+ else if (class != current_class)
load_class (class, 1);
}
return 1;
@@ -2510,10 +2506,12 @@ layout_class_method (tree this_class, tr
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: Failure to build libjava on 512MB machine
> "Marco" == Marco Trudel <[EMAIL PROTECTED]> writes: Marco> If it takes about 30 to 40min to build this html/parser.o and Marco> gnu-xml.o needs about 1 or 2 minutes but is - last time I took a look Marco> - a lot bigger than the html parser, shouldn't then be investigated Marco> why this html parser is such a hard thing? It is just a really big file. If it still takes too much memory to compile, I suppose I, or someone (hint, hint), will look at how to shrink it. Tom
Re: (OffTopic) trouble registering on www.gccsummit.org
On Thu, Feb 01, 2007 at 11:10:52AM +0100, Basile STARYNKEVITCH wrote: > > Hello All, > > Sorry for this off-topic message, but I have some troubles registering on > https://www.gccsummit.org/2007/login.php and my email to > [EMAIL PROTECTED] bounced. > > My own email is [EMAIL PROTECTED] > > Does anyone know who should I contact about the gccsummit.org web site or > registration system? > > Regards, and apologies for this slightly off topic message! I hope someone > in charge of the gccsummit.org site would read it. Mail [EMAIL PROTECTED] Janis
Re: Failure to build libjava on 512MB machine
On Wed, 31 Jan 2007, Andrew Haley wrote:
> Can you tell us a bit more about the config? It really shouldn't be
> failing to compile this program.
The tester where this problem first surfaced as a 32-bit Athlon machine,
with 512MB main memory and 1GB swap. The machine runs FreeBSD 5.4.
I agree with your intuition that even if the machines is swapping heavily,
this amount of virtual memory (1.5GB) should suffice.
However, a bit of investigations makes me believe that, at least in the
default configuration, FreeBSD 5.4 will refuse to allocate more memory to
a single process than the system has main memory.
At least this is what the output of the following quick test program I
hacked indicates:
#include
#include
#include
#define MB 1024*1024
main() {
for(int i=1; i <= 600; i++) {
printf("%dMB ",i); fflush(stdout);
char *p=(char*)malloc(MB);
if( p == NULL ) {
printf("\nCrap!\n");
return 1;
}
}
}
After 512MB, the output I get is
510MB
511MB
512MB
Crap!
while, at the same time, a GCC bootstrap is nicely proceeding on the
same machine. I do not know how many other system may behave similarly,
but at least this explains my (unexpected) bootstrap failures.
Gerald
Re: Failure to build libjava on 512MB machine
> > On Wed, 31 Jan 2007, Andrew Haley wrote: > > Can you tell us a bit more about the config? It really shouldn't be > > failing to compile this program. > > The tester where this problem first surfaced as a 32-bit Athlon machine, > with 512MB main memory and 1GB swap. The machine runs FreeBSD 5.4. > > I agree with your intuition that even if the machines is swapping heavily, > this amount of virtual memory (1.5GB) should suffice. This must be a x86 only issue as I was able to bootstrap yesterday with libjava enabled on powerpc-linux-gnu with only 512MB of memory and 512MB of swap. -- Pinski
Re: Failure to build libjava on 512MB machine
On Thu, 1 Feb 2007, Gerald Pfeifer wrote: > The tester where this problem first surfaced as a 32-bit Athlon machine, > with 512MB main memory and 1GB swap. The machine runs FreeBSD 5.4. > > I agree with your intuition that even if the machines is swapping heavily, > this amount of virtual memory (1.5GB) should suffice. > > However, a bit of investigations makes me believe that, at least in the > default configuration, FreeBSD 5.4 will refuse to allocate more memory to > a single process than the system has main memory. I know managed to track this down: http://plone.org/documentation/faq/freebsd-memory-error By default in FreeBSD 5.X or 4.X the kernel will limit the amount of RAM any one process can use to 512MB (older versions of FreeBSD this was lower). You can tweak this in /boot/loader.conf [...] So, it's not a question of main memory or swap, but a limit in terms of virtual memory per process on this specific tester. I don't know how common such limitations/systems are, so this may be less critical than it originally seemed. Still, this shows that we did have an increase in memory use recently, which may be worth looking into. (And, of course, I'm happily testing Tom's patch as we speak.) Gerald
