Fw: Store scheduling with DFA scheduler
As you noted, when the scheduler decides between stores and adds it always prefers the adds (first at t = 5), due to its critical path heuristic. In Jon's example, stores seem "costly" as one cannot issue a load or store immediately following a store. Perhaps the scheduler could take the (resource-related) "cost" of candidates into consideration (in addition to their latency-related critical path) when making such decisions. Still heuristically speaking, of-course. Ayal.
Re: libjava build times
Richard Henderson writes: > > Now, unless I've done something drastically wrong, it appears as if we > are spending 2/3 of our time in the libtool script. Yes, that's right. That's similar to what my oprofile experiments suggest. Andrew.
Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*
On Fri, 29 Apr 2005, Dimitri Papadopoulos-Orfanos wrote:
> Some links are broken on this page:
> http://gcc.gnu.org/install/specific.html
>
> Specifically:
> i?86-*-sco3.2v5*
> i?86-*-solaris2.10
> x86_64-*-*, amd64-*-*
> all ELF targets
That's even further collateral damage caused by the design changes in
recent versions of GNU makeinfo for strict HTML/XHTML support. :-(
Thanks for the clear report, Dimitri. I just installed the following
change to mainline (which will become GCC 4.1) and will shortly do the
same on the 4.0 branch. Please allow up to 24 hours until this has
propagated to the http://gcc.gnu.org/install/specific.html web page.
I tested this patch by running gcc/doc/install.texi2html and also
verified that the changed links still work when using makeinfo 4.5
Gerald
2005-05-01 Gerald Pfeifer <[EMAIL PROTECTED]>
* doc/install.texi (Specific): Omit dots in the @anchors names
for i?86-*-sco3.2v5*, i?86-*-solaris2.10, and sparc-sun-solaris2.7.
Omit underscores for x86_64-*-* and the "all ELF targets" entry.
Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.350
diff -u -3 -p -r1.350 install.texi
--- doc/install.texi28 Apr 2005 22:53:21 - 1.350
+++ doc/install.texi1 May 2005 13:34:14 -
@@ -2207,9 +2207,9 @@ GNU Compiler Collection on your machine.
@item
@uref{#ix86-x-linux,,i?86-*-linux*}
@item
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
@item
[EMAIL PROTECTED],,i?86-*-solaris2.10}
[EMAIL PROTECTED],,i?86-*-solaris2.10}
@item
@uref{#ix86-x-udk,,i?86-*-udk}
@item
@@ -2267,7 +2267,7 @@ GNU Compiler Collection on your machine.
@item
@uref{#sparc-sun-solaris2,,sparc-sun-solaris2*}
@item
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
@item
@uref{#sparc-x-linux,,sparc-*-linux*}
@item
@@ -2281,7 +2281,7 @@ GNU Compiler Collection on your machine.
@item
@uref{#x-x-vxworks,,*-*-vxworks*}
@item
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
@item
@uref{#xtensa-x-elf,,xtensa-*-elf}
@item
@@ -2296,7 +2296,7 @@ GNU Compiler Collection on your machine.
@itemize
@item
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
@end itemize
@end ifhtml
@@ -2897,7 +2897,7 @@ found on @uref{http://www.bitwizard.nl/s
@html
@end html
[EMAIL PROTECTED] @anchor{ix86-x-sco3.2v5}i?86-*-sco3.2v5*
[EMAIL PROTECTED] @anchor{ix86-x-sco32v5}i?86-*-sco3.2v5*
Use this for the SCO OpenServer Release 5 family of operating systems.
Unlike earlier versions of GCC, the ability to generate COFF with this
@@ -2941,7 +2941,7 @@ GCC, version 2.95.3. It is useful for b
@html
@end html
[EMAIL PROTECTED] @anchor{ix86-x-solaris2.10}i?86-*-solaris2.10
[EMAIL PROTECTED] @anchor{ix86-x-solaris210}i?86-*-solaris2.10
Use this for Solaris 10 or later on x86 and x86-64 systems. This
configuration is supported by GCC 4.0 and later versions only.
@@ -3649,7 +3649,7 @@ or later system, the canonical target tr
@html
@end html
[EMAIL PROTECTED] @anchor{sparc-sun-solaris2.7}sparc-sun-solaris2.7
[EMAIL PROTECTED] @anchor{sparc-sun-solaris27}sparc-sun-solaris2.7
Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8
@@ -3808,7 +3808,7 @@ VxWorks will incorporate this module.)
@html
@end html
[EMAIL PROTECTED] @anchor{x86_64-x-x}x86_64-*-*, amd64-*-*
[EMAIL PROTECTED] @anchor{x86-64-x-x}x86_64-*-*, amd64-*-*
GCC supports the x86-64 architecture implemented by the AMD64 processor
(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and [EMAIL
PROTECTED]
@@ -3921,7 +3921,7 @@ current GCC) is to be found in the GCC t
@html
@end html
[EMAIL PROTECTED] @anchor{elf_targets}all ELF targets (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED] @anchor{elf}all ELF targets (SVR4, Solaris 2, etc.)
C++ support is significantly better on ELF targets if you use the
@uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of
Incomplete instatitiation of virtual registers
I notice, that your last change in function.c forgets virtual
registers in the RTL in some conditions. In older version (the last I used was
20050412),
this has not happend.
In 01.sibling, I have the instruction:
(insn 10 8 12 1 (set (mem/f/i:HI (plus:HI (reg/f:HI 23 virtual-stack-vars)
(const_int -2 [0xfffe])) [0 b+0 S2 A8 ])
(plus:HI (reg/f:HI 23 virtual-stack-vars)
(const_int -6 [0xfffa]))) -1 (nil)
(nil))
In 03.jump, it is replaced with
(insn 10 8 12 1 (set (mem/f/i:HI (plus:HI (reg/f:HI 23 virtual-stack-vars)
(const_int -2 [0xfffe])) [0 b+0 S2 A8 ])
(plus:HI (reg/f:HI 6 VFP)
(const_int -6 [0xfffa]))) 73 {addhi3} (nil)
(nil))
The left virtual-stack-vars causes other problems in the reload pass.
I noticed this in my GCC port, I don't know, if such RTL expressions can
occure in offical versions.
A simple workaround is to rerun the instanication, if anything changes:
Index: function.c
===
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.616
diff -u -p -r1.616 function.c
--- function.c 30 Apr 2005 03:17:53 - 1.616
+++ function.c 1 May 2005 15:11:22 -
@@ -1528,6 +1528,8 @@ instantiate_virtual_regs_in_insn (rtx in
if (recog_memoized (insn) < 0)
fatal_insn_not_found (insn);
}
+ if(any_change)
+instantiate_virtual_regs_in_insn (insn);
}
/* Subroutine of instantiate_decls. Given RTL representing a decl,
mfg Martin Kögler
doubts in gimple code
Hi, In GIMPLE IR, variables that need to live in memory are to be first loaded into temporaries and then used in expressions. The memory here referes here to data area i guess. Because for local variables which reside on stack , this rule does not apply, as an expression like c = a + b ; where a,b are local variabes remain as it is in GIMPLE. while same expression, if a, b are global variabes, becomes : T1 = a ; T2 = b ; c = T1 + T2 ; thereby loading a, b first into temporaries and then using them in expressions. the assignments differ in global and local variables : for a , b global : a = b , become T1 = b ; a = T1 while for a, b local a = b , remains as a = b Also what exactly happens in a = b + c (b,c local) ? -- Regards. Virender
Re: Struggle with FOR_EACH_EDGE
Kazu Hirata wrote: To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a simple dummy function. Kazu, I hope I have time to look in detail at your investigation, however one thing that might be causing a problem is that FOR_EACH_EDGE is an iterator that works for a non-constant VEC. This means there's an extra level of indirection that the optimizer cannot remove, unless it completely inlines the body of the loop (there might be some cases it can do it without inlining, but I suspect not). I wonder if it is worthwhile implementing FOR_EACH_EDGE and FOR_EACH_EDGE_VOLATILE (I want the default, shorter name, to be the constant iterator, so that you have to chose to use the non-constant one). Even with a constant iterator, it might be necessary to help the optimizer by copying the vector length to somewhere local that the optimizer can see cannot be changed by the body of the loop. Hmm, I guess that does mean you need a proper iterator object, rather than the integer index that VEC_iterate employs. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Struggle with FOR_EACH_EDGE
Hello, > >To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a > >simple dummy function. > > Kazu, I hope I have time to look in detail at your investigation, however > one thing that might be causing a problem is that FOR_EACH_EDGE is an > iterator > that works for a non-constant VEC. This means there's an extra level of > indirection that the optimizer cannot remove, unless it completely inlines > the body of the loop (there might be some cases it can do it without > inlining, > but I suspect not). I wonder if it is worthwhile implementing FOR_EACH_EDGE > and FOR_EACH_EDGE_VOLATILE (I want the default, shorter name, to be the > constant iterator, so that you have to chose to use the non-constant one). > > Even with a constant iterator, it might be necessary to help the optimizer > by copying the vector length to somewhere local that the optimizer can see > cannot be changed by the body of the loop. Hmm, I guess that does mean you > need a proper iterator object, rather than the integer index that > VEC_iterate > employs. you can always start the index from number of edges - 1 and iterate to zero. But a proper iterator might be useful anyway. Zdenek
FAIL: ext/stdio_sync_filebuf/wchar_t/12077.cc
Hi, it looks like in mainline this test recently started failing at compile time on some machines. I'm puzzled, unfortunately cannot reproduce the problem and would be grateful is someone could send me (either privately or in public) more information (e.g., an extract from libstdc++.log, at least). Thanks in advance, Paolo.
Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*
On Sun, 1 May 2005, Gerald Pfeifer wrote:
> Thanks for the clear report, Dimitri. I just installed the following
> change to mainline (which will become GCC 4.1) and will shortly do the
> same on the 4.0 branch.
This is the variant of the patch I applied on the 4.0 branch.
Gerald
2005-05-01 Gerald Pfeifer <[EMAIL PROTECTED]>
* doc/install.texi (Specific): Omit dots in the @anchors names
for i?86-*-sco3.2v5* and sparc-sun-solaris2.7.
Omit underscores for x86_64-*-* and the "all ELF targets" entry.
Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.248.4.33
diff -u -3 -p -r1.248.4.33 install.texi
--- doc/install.texi30 Mar 2005 07:42:31 - 1.248.4.33
+++ doc/install.texi1 May 2005 17:56:59 -
@@ -2156,7 +2156,7 @@ GNU Compiler Collection on your machine.
@item
@uref{#ix86-*-linux*,,i?86-*-linux*}
@item
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
@item
@uref{#ix86-*-udk,,i?86-*-udk}
@item
@@ -2218,7 +2218,7 @@ GNU Compiler Collection on your machine.
@item
@uref{#sparc-sun-solaris2*,,sparc-sun-solaris2*}
@item
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
@item
@uref{#sparc-*-linux*,,sparc-*-linux*}
@item
@@ -2232,7 +2232,7 @@ GNU Compiler Collection on your machine.
@item
@uref{#*-*-vxworks*,,*-*-vxworks*}
@item
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
@item
@uref{#xtensa-*-elf,,xtensa-*-elf}
@item
@@ -2247,7 +2247,7 @@ GNU Compiler Collection on your machine.
@itemize
@item
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
@end itemize
@end ifhtml
@@ -2840,7 +2840,7 @@ This will be fixed in future releases of
@html
@end html
[EMAIL PROTECTED] @anchor{ix86-*-sco3.2v5*}i?86-*-sco3.2v5*
[EMAIL PROTECTED] @anchor{ix86-*-sco32v5*}i?86-*-sco3.2v5*
Use this for the SCO OpenServer Release 5 family of operating systems.
Unlike earlier versions of GCC, the ability to generate COFF with this
@@ -3565,7 +3565,7 @@ plain @option{-g}.
@html
@end html
[EMAIL PROTECTED] @anchor{sparc-sun-solaris2.7}sparc-sun-solaris2.7
[EMAIL PROTECTED] @anchor{sparc-sun-solaris27}sparc-sun-solaris2.7
Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8
@@ -3724,7 +3724,7 @@ VxWorks will incorporate this module.)
@html
@end html
[EMAIL PROTECTED] @anchor{x86_64-*-*}x86_64-*-*, amd64-*-*
[EMAIL PROTECTED] @anchor{x86-64-*-*}x86_64-*-*, amd64-*-*
GCC supports the x86-64 architecture implemented by the AMD64 processor
(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
@@ -3837,7 +3837,7 @@ current GCC) is to be found in the GCC t
@html
@end html
[EMAIL PROTECTED] @anchor{elf_targets}all ELF targets (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED] @anchor{elf}all ELF targets (SVR4, Solaris 2, etc.)
C++ support is significantly better on ELF targets if you use the
@uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of
gcc-4.1-20050501 is now available
Snapshot gcc-4.1-20050501 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050501/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-05-01 17:43 UTC You'll find: gcc-4.1-20050501.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050501.tar.bz2 C front end and core compiler gcc-ada-4.1-20050501.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050501.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050501.tar.bz2 C++ front end and runtime gcc-java-4.1-20050501.tar.bz2 Java front end and runtime gcc-objc-4.1-20050501.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050501.tar.bz2The GCC testsuite Diffs from 4.1-20050424 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
possible compiler bug
I have reviewed the gcc web page for reporting bugs and this situation is not covered. I have a program that I have been compiling with the gcc 2.9 and 3.4 series. In the past week I upgraded to gcc 4.0.0 I compiled the program and corrected the warning message about using "unsigned char *" when the function prototype specified "char *" and vice versa. The program files are compiled with the following command line in the make file: gcc -O3 -std=c99 -Wunused-variable -o $@ -lm $(OBJS) There is no compiler output beyond reporting the command line invocation. No warning messages, no compiler errors of any kind. The program has run for many years with no problem. Under gcc 4.0.0, I get a memory access error. If I change the compile command in the make file to: gcc -g -std=c99 -Wunused-variable -o $@ -lm $(OBJS) The program runs with no error. Changing the optimization option to "O" and compiling and the program again runs with no error. Only when I compile with an optimization level of "O2" or "O3" does the program exit with a memory access error. I have attempted to compile with "-g -O3" or "-g -O2" flags and then run under Kdebug. This fails with an error message from Kdebug that gdb failed to load the program. Thus, I am totally unable to debug the program and find the exact problem with the optimization. Thus, there appears to be a fatal error in the "O2" and "O3" levels of optimization in gcc and a definite error in the debug output when the O2 or O3 optimization level is specified. Are these known errors? is the problem with the debug output known? Are there plans to fix this problem? If at all possible, please respond so that I know that you either can do nothing without further information or that you believe you know of these bugs or how to get the necessary information to you to solve these problems. The web page states that you want the compiler command and any compiler output. Unfortunately, there is no compiler output, the program itself simply fails with a memory access error with optimization levels of "O2" or "O3" under gcc 4.0.0 whereas the program functioned normally with these optimization levels under gcc 2.9 series and 3.4 series (3.4.3 being the last I used). One last piece of information: I downloaded the gcc 4.0.0 source and compiled using gcc 3.4.3 - could that be a problem Also, I am running Linux kernal 2.24.20 Pending a solution I will have to drop back to gcc 3.4.3 (hopefully that is still an option for me). Thanks, Terry D. Boldt -- ++ == ** If you are always rushing towards the future, Then you never have any past. Terry Boldt ** As you contemplate the Now, The Now becomes the past. There is no future, There is no past, There is only Now. Unknown ** "A human being is part of the whole called by us the Universe. We experience ourselves, our thoughts and feelings as something separated from the rest --a kind of optical delusion of consciousness. This delusion is a kind of prison for us, restricting us to our personal desires and to affection for a few persons nearest us. Our task must be to free ourselves from this prison by widening our circle of compassion to embrace all living creatures, and the whole of nature in its beauty." Albert Einstein. "We can't solve problems by using the same kind of thinking we used when we created them." --Albert Einstein ** We have the best government money can buy, and it has. Terry Boldt. ** You must decide: Are you a body with a soul or a soul with a body? Terry Boldt ** When you change the way you look at things, the things you look at change. ** Paraphrasing Ben Franklin: Those who sacrifice freedom for safety, have neither. The exact quote: They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin (1706 - 1790), US author, diplomat, inventor, physicist, politician, & printer Historical Review of Pennsylvania, 1759 ** A thought often repeated becomes an act, an act often repeated becomes a habit, a habit often repeated, a character and a settled character molds the very destiny of man. Man is the master of his own destiny. "The Voice of Babaji", Page 236 ** What man thinks, that he becomes Upanishad ** Common sense is so very extr
Re: possible compiler bug
On Sun, May 01, 2005 at 02:16:27PM -0400, Friends wrote: > Only when I compile with an optimization level of "O2" or "O3" does the > program exit with a memory access error. > It may be a bug in GCC and it may also be a bug in your program (some problems like aliasing bugs only are exposed at higher levels of optimization). Without more detailed information it is impossible for us to diagnose your problem. Please report a bug following the instructions in http://gcc.gnu.org/bugs.html. > The web page states that you want the compiler command and any compiler > output. Unfortunately, there is no compiler output, the program itself simply > The best way is to compile your code with -save-temps and give us the .i file so that we can examine it. The bug reporting page has detailed info of what we need to help you with this problem. Diego.
Re: doubts in gimple code
On Sun, May 01, 2005 at 10:45:15PM +0530, Virender Kashyap wrote: > Also what exactly happens in a = b + c (b,c local) ? > That statement is already in GIMPLE form, so it's not changed. What you describe is how the conversion into gimple occurs, have you found a problem with it? I'm not sure whether you are trying to confirm that this is how gimple operates, or you have a problem with it. There is documentation about GIMPLE in the GCC internals manual. Also, -fdump-tree-gimple produces a dump file with the input program in GIMPLE form. Diego.
Re: Struggle with FOR_EACH_EDGE
Hi Nathan, > Kazu, I hope I have time to look in detail at your investigation, however > one thing that might be causing a problem is that FOR_EACH_EDGE is an iterator > that works for a non-constant VEC. This means there's an extra level of > indirection that the optimizer cannot remove, unless it completely inlines > the body of the loop (there might be some cases it can do it without inlining, > but I suspect not). I wonder if it is worthwhile implementing FOR_EACH_EDGE > and FOR_EACH_EDGE_VOLATILE (I want the default, shorter name, to be the > constant iterator, so that you have to chose to use the non-constant one). Yes, the iterator that works for a non-constant VEC adds some overhead. I am wondering if it's OK to tweak FOR_EACH_EDGE like so #define FOR_EACH_EDGE (...)\ if (vec == NULL) \ /* The vector is empty. We don't have anything to do. */ \ e = NULL; \ else \ for (/* usual iterator stuff */) In other words, I am wondering if it's safe to assume that nobody calls VEC_free during edge vector iteration. (I know calling VEC_free sounds crazy, but I want to hear second opinions). If I am allowed to put an "if" like this, the optimizers (or slightly reordered ones) can remove the null check in the loop. Anyway, there seem to be several things going on. 1. FOR_EACH_EDGE itself could be improved (like above). 2. VRP is not really effective in this case because it is run before SRA, meaning it cannot get at as many scalar variables. (Andrew Pinski pointed this out on IRC). 3. VRP does not know that &x->a is nonnull is x is nonnull. (PR21294) I'll start with a low hanging fruit. Kazu Hirata
array type has incomplete element type
Hi,
What's wrong with this ? It is ok in gcc 3 not not ok with gcc4:
#define SERVICE_TYPE(type, val, state) SERVICE_##type = val,
typedef enum service_e {
SERVICE_TYPE(NONE, 0, false)
SERVICE_TYPE(FTP,1, true)
SERVICE_TYPE_MAX
} service_type_t;
Thanks
dave
Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*
On Sun, 1 May 2005, Gerald Pfeifer wrote: > This is the variant of the patch I applied on the 4.0 branch. Sorry, that was a typo: for the 4.0 branch I used exactly the same version as for mainline. This slightly different patch is what I applied on the 3.4 branch. > 2005-05-01 Gerald Pfeifer <[EMAIL PROTECTED]> > > * doc/install.texi (Specific): Omit dots in the @anchors names > for i?86-*-sco3.2v5* and sparc-sun-solaris2.7. > Omit underscores for x86_64-*-* and the "all ELF targets" entry. Gerald
Re: possible compiler bug
Diego Novillo wrote: On Sun, May 01, 2005 at 02:16:27PM -0400, Friends wrote: Only when I compile with an optimization level of "O2" or "O3" does the program exit with a memory access error. It may be a bug in GCC and it may also be a bug in your program (some problems like aliasing bugs only are exposed at higher levels of optimization). Also uninitialized variable problems often show up only with optimization turned on (registers tend to be "more" uninitialized than memory :-)
Re: libjava/3.4.4 problem (SOLVED)
Dixi: >Mark Mitchell dixit: > >>In general, GCC 3.4.3 is working for people > >I've been playing around a lot with the various 3.4.4 snapshots >lately, and got everything to work, except for libjava: With the change in the configuration file, it works now. However, I'm curious about why FreeBSD defines it while NetBSD and OpenBSD do not, and which implications it might have elsewhere. gcj works now, as in "99 Bottles of Beer" compiled from source to bytecode and executed with sunjdk-1.4.2 (native), compiled from source or bytecode to executable. gij does not work because boehm-gc is (still) broken on all OpenBSD/ELF platforms (and, apparently, OpenBSD derivates like MirOS). I'll try with GC disabled now. libjava is a pain in the ass, regarding "writes to build directory during installation time". libtool relinking issues, and the list of headers to be installed. I have worked around these, but it's probably unportable. Also, having its own libltdl is... weird. But I'm really happy with the huge (and I mean it) increase in overall quality between 3.2.3 and 3.4.4 (prerelease). There's still one thing I miss: a list of all flags allowed for a specific compiler/language. For example, I cannot specify -Wformat for Ada, -DPIC for Java, etc. (at the moment, during libstdc++-v3 and libjava build I ignore the user-settable CFLAGS (/etc/mk.conf) and for Ada I remove some via gmake features). I suppose I might be able to dig it out from the source, though. (What I was talking about is an easy to read overview, e.g. a table.) bye, //mirabile -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: libjava build times
Andrew Haley dixit: >Richard Henderson writes: > > > > Now, unless I've done something drastically wrong, it appears as if we > > are spending 2/3 of our time in the libtool script. > >Yes, that's right. That's similar to what my oprofile experiments suggest. Could you please go to http://wiki.mirbsd.de/MirbsdKsh, get the source, compile it and try with it instead of your usual /bin/sh (I suppose GNU bash) again? I'd be interested if that warrants a noticeable speedup. I've done only a few comparisions regarding string handling, and ksh both used less memory and was by times faster. Also, GNU bash started getting MUCH slower at 16 KiB strings, while ksh was linear until 256 KiB strings. Thanks, //mirabile -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: GCC 4.1: Buildable on GHz machines only?
[EMAIL PROTECTED] (Andrew Haley) wrote on 30.04.05 in <[EMAIL PROTECTED]>: > Matt Thomas writes: > > Joe Buck wrote: > > > I think you need to talk to the binutils people. It should be possible > > > to make ar and ld more memory-efficient. > > > > Even though systems maybe demand paged, having super large > > libraries that consume lots of address space can be a problem. > > > > I'd like to libjava be split into multiple shared libraries. In C, > > we have libc, libm, libpthread, etc. In X11, there's X11, Xt, etc. > > So why does java have everything in one shared library? Could the > > swing stuff be moved to its own? Are there other logical > > divisions? > > It might be nice, certainly. However, there are some surprising > dependencies between parts of the Java library, and these would cause > separate shared libraries to depend on each other, negating most of > the advantage of separation. > > We are in the process of rewriting the Java ABI so that sumbol > resolution in libraries is done lazily rather than eagerly. This will > help. Even so, I would prefer to divide libjava -- if it is to be > divided -- on a logical basis rather than simply in order to make > libraries smaller. Surely the other mentioned library divisions (libc, X) were *also* done on a logical basis?! MfG Kai
4.0.0 openbsd
Reporting a successful build on OpenBSD 3.7-BETA: ./config.guess i386-unknown-openbsd3.7 Built with native gcc within OpenBSD: # gcc -v Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) I used GNU make and installed libiconv/texinfo/flex/bison. # gcc4 -v Using built-in specs. Target: i386-unknown-openbsd3.7 Configured with: /usr/gcc-4.0.0/configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-threads --enable-shared --disable-multilib --enable-languages=c,c++ --disable-nls --program-suffix=4 Thread model: posix gcc version 4.0.0
Re: GCC 4.1: Buildable on GHz machines only?
Jason Thorpe <[EMAIL PROTECTED]> wrote: >> I would also like to note that I *myself* requested preprocessed >> source code to >> NetBSD developers at least 6 times in the past 2 years. I am sure >> Andrew Pinski >> did too, a comparable amound of times. These requests, as far as I >> can understand, were never answered. This also helped building up a >> stereotype of >> the average NetBSD developer being "just a GCC whine troll". > > While I have not had much time for a quite a while to work on GCC > myself, I am listed as NetBSD maintainer... you can always drop me a > note directly when this sort of thing happens. Thanks! Are you then going to file in Bugzilla some preprocessed sources that show the 2.95 -> 3.3 slowdown experimented by NetBSD folks? Giovanni Bajo
GCCNews #15 (events of Nov 04) is out.
I have added content to http://gccnews.chatta.us . I tell of my plan for it, and a mailing list summary for last November. I hope to add other months until it is caught up. I welcome your opinions, either on this list or privately. -- rick f. End DRM for brains ! The World has latched itself to you; change shape and watch the fireworks. You are someone's predecessor. http://chalice.us/poe http://gccnews.chatta.us http://chatta.us/resume/ http://chalice.us/leslie
Re: GCCNews #15 (events of Nov 04) is out.
On May 1, 2005, at 10:10 PM, R. D. Flowers wrote: I have added content to http://gccnews.chatta.us . I tell of my plan for it, and a mailing list summary for last November. I hope to add other months until it is caught up. I welcome your opinions, either on this list or privately. VLA is not very large arrays but variable length arrays. Other than that, it looks great. Thanks for doing this. Thanks, Andrew Pinski
re: array type has incomplete element type
[EMAIL PROTECTED] wrote:
What's wrong with this ? It is ok in gcc 3 not not ok with gcc4:
#define SERVICE_TYPE(type, val, state) SERVICE_##type = val,
typedef enum service_e {
SERVICE_TYPE(NONE, 0, false)
SERVICE_TYPE(FTP,1, true)
SERVICE_TYPE_MAX
} service_type_t;
Compiles fine for me with gcc-4.0.0, icc-8.1, and Comeau online.
Re: libjava build times
On Sun, May 01, 2005 at 10:31:05PM +, Thorsten Glaser wrote: > Could you please go to http://wiki.mirbsd.de/MirbsdKsh, get the source, > compile it and try with it instead of your usual /bin/sh (I suppose GNU > bash) again? > > I'd be interested if that warrants a noticeable speedup. No visible change. 2105.44user 1003.09system 49:58.59elapsed 103%CPU (3major+54738718minor) r~
