Re: [patch] Fix i386-mingw32 build failure
The consensus also seemed to be that it was just an aspect of a larger problem that no good solution had been proposed to solve yet. I am working on a fix that is the same as FX's, but does not pollute the makefile with host triplets. I am not a maintainer, but this was my primary objection to his patch. Paolo
Re: [patch] Fix i386-mingw32 build failure
Can someone with approval privilege over the build system look at this, and OK it? (it's a very simple patch) I must apologize for the delay in handling this. This alternative patch avoids that mingw is hardcoded in the makefiles. FWIW, it is also even smaller, 3 files changed, 19 insertions(+), 12 deletions(-) vs. 1 files changed, 25 insertions(+), 10 deletions(-) :ADDPATCH build: I have only tested it on Linux, can you give it a try? Ok if FX's testing succeeds? Paolo 2005-08-09 Paolo Bonzini <[EMAIL PROTECTED]> * config.build (build_have_sh_scripts): Default to yes, set to no for mingw32. * configure.ac (build_have_sh_scripts): AC_SUBST it. * Makefile.in (stamp-as, stamp-collect-ld, stamp-nm): If build_have_sh_scripts is false, rely on $(LN). * configure: Regenerate. Index: config.build === RCS file: /cvs/gcc/gcc/gcc/config.build,v retrieving revision 1.4 diff -p -u -r1.4 config.build --- config.build25 Jun 2005 01:59:35 - 1.4 +++ config.build9 Aug 2005 07:25:42 - @@ -42,12 +42,17 @@ # # build_exeextSet to the suffix, if the build machine requires # executables to have a file name suffix. +# +# build_have_sh_scripts +# Set to yes or no, depending on whether the built +# compiler can run Bourne shell scripts. # Default settings. build_xm_file= build_xm_defines= build_exeext= build_install_headers_dir=install-headers-tar +build_have_sh_scripts=yes # System-specific settings. case $build in @@ -80,6 +85,7 @@ case $build in i[34567]86-*-mingw32*) build_xm_file=i386/xm-mingw32.h build_exeext=.exe +build_have_sh_scripts=no ;; i[34567]86-pc-msdosdjgpp*) build_xm_file=i386/xm-djgpp.h Index: configure.ac === RCS file: /cvs/gcc/gcc/gcc/configure.ac,v retrieving revision 2.125 diff -p -u -r2.125 configure.ac --- configure.ac29 Jul 2005 19:20:44 - 2.125 +++ configure.ac9 Aug 2005 07:25:43 - @@ -3335,6 +3335,7 @@ AC_SUBST(all_lang_makefiles) AC_SUBST(all_languages) AC_SUBST(all_stagestuff) AC_SUBST(build_exeext) +AC_SUBST(build_have_sh_scripts) AC_SUBST(build_install_headers_dir) AC_SUBST(build_xm_file_list) AC_SUBST(build_xm_include_list) Index: Makefile.in === RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v retrieving revision 1.1535 diff -p -u -r1.1535 Makefile.in --- Makefile.in 6 Aug 2005 13:25:52 - 1.1535 +++ Makefile.in 9 Aug 2005 07:25:43 - @@ -1221,13 +1221,13 @@ cpp$(exeext): gcc.o cppspec.o version.o # (if it is a hard link). stamp-as: $(ORIGINAL_AS_FOR_TARGET) @echo creating as; \ - case "$(ORIGINAL_AS_FOR_TARGET)" in \ - ./as) ;; \ - ../*) \ + case "$(ORIGINAL_AS_FOR_TARGET):@build_have_sh_scripts@" in \ + ./as:*) ;; \ + ../*:* | *:no) \ rm -f as$(exeext); \ echo $(LN) $< as$(exeext); \ $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \ - *) \ + *:yes) \ rm -f as; \ echo '#!$(SHELL)' > as; \ echo 'exec $(ORIGINAL_AS_FOR_TARGET) "$$@"' >> as ; \ @@ -1237,13 +1237,13 @@ stamp-as: $(ORIGINAL_AS_FOR_TARGET) stamp-collect-ld: $(ORIGINAL_LD_FOR_TARGET) @echo creating collect-ld; \ - case "$(ORIGINAL_LD_FOR_TARGET)" in \ - ./collect-ld) ;; \ - ../*) \ + case "$(ORIGINAL_LD_FOR_TARGET):@build_have_sh_scripts@" in \ + ./collect-ld:*) ;; \ + ../*:* | *:no) \ rm -f collect-ld$(exeext); \ echo $(LN) $< collect-ld$(exeext); \ $(LN) $< collect-ld$(exeext) || cp $< collect-ld$(exeext) ;; \ - *) \ + *:yes) \ rm -f collect-ld$(exeext); \ echo '#!$(SHELL)' > collect-ld; \ echo 'exec $(ORIGINAL_LD_FOR_TARGET) "$$@"' >> collect-ld ; \ @@ -1253,13 +1253,13 @@ stamp-collect-ld: $(ORIGINAL_LD_FOR_TARG stamp-nm: $(ORIGINAL_NM_FOR_TARGET) @echo creating nm; \ - case "$(ORIGINAL_NM_FOR_TARGET)" in \ - ./nm) ;; \ - ../*) \ + case "$(ORIGINAL_NM_FOR_TARGET):@build_have_sh_scripts@" in \ + ./nm:*) ;; \ + ../*:* | *:no) \ rm -f nm$(exeext); \ echo $(LN) $< nm$(exeext); \ $(LN) $< nm$(exeext) || cp $< nm$(exeext) ;; \ - *) \ + *:yes) \ rm -f nm$(exeext); \ echo '#!$(SHELL)' > nm; \ echo 'exec $(ORIGINAL_NM_FOR_TARGET) "$$@"' >> nm ; \
[GCC 4.2 Project] Replacements for CSE path following
This pass does simple forward propagation and simplification when an operand of an insn can only come from a single def. The pass has a very good potential of catching simplifications currently done by inter-basic-block CSE (-fcse-follow-jumps and -fcse-skip-blocks) and combine: however, it is much faster than inter-basic-block CSE and runs much earlier than combine. Unlike other attempts to supersede CSE path following, however, I did not write a general optimization framework like GCSE: instead, looking at what kinds of simplifications are only made by CSE, I tried to implement them in a very generic way. Take for example Bug 13724: my fix for it was to make CSE recognize the high word of (zero_extend:DI (reg:SI M)), and simplify it to zero. After committing it, Roger Sayle also tried adding the same to simplify-rtx.c, but it was ineffective. This pass, instead, can use simplify-rtx.c much more effectively than CSE. The patch currently has performance regressions in mesa and in crafty, but overall slightly improves SPEC with a saving of 2-3% in bootstrap and compilation time. Personnel * Paolo Bonzini Delivery Date Stage 1 I actually hoped that the pass itself can go in 4.1, being disabled by default, but it seems unlikely at this point. Benefits Improved compilation time, incentive for moving optimizations from combine.c to simplify-rtx.c. Dependencies * None. Modifications Required The regressions are still to be investigated; but most of the modifications will most likely be in simplify-rtx.c (pouring simplifications in there from combine), or may involve more sophisticated analysis of available expressions in the forward propagation pass.
Re: Old machine cluster for GCC compile/testing
Hi Laurent, Laurent GUERBY wrote: > > So I'm asking for project proposals, that is to say people that think > that their volunteer time to work on these old machine (scripts, > compiling, ... under the limit of minimal external bandwidth use) is of > some significant benefit to some free software project. > I'm proposing to automate gcc's bootstrap & regtest: for each mail sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body' contains a patch against some branch (ie. if it fails to apply to a branch, just drop it and warn the user), enqueue it for validation. The main server can be some script that monitors the availability of cpu ressources and that distributes the patches for validation. The answer can be a mail with just "passed witout regressions", or "patch causes regressions: ". Bandwidth usage: size of incoming mail patch + size of answer + "cvs update -dP" every morning. Sebastian
[GCC 4.2 Project] Section Anchor Optimisations
Summary: This optimisation will allow GCC to access more than one object from the same symbolic address. For example, suppose a section contains two variables x and y, and x and y are close together. The optimisation will create a common anchor point -- let's call it A -- and allow both x and y to be accessed from A. The optimisation will of course be subject to the usual binding rules and will need to be aware of special cases like mergeable constants. At the moment, GCC makes no assumptions about the relative positions of static variables and constants, writing them out in a more-or-less arbitrary order. A major part of the project will therefore be to assign specific positions to objects and to write them out appropriately. The new infrastructure will also allow GCC to reorder objects within a section. Such a reordering might try to reduce the number of anchors or improve cache locality. However, this aspect of the project will be open-ended and isn't going to be part of the initial patch. Full details here: http://gcc.gnu.org/wiki/Section%20Anchor%20Optimisations Richard
Your patch to skip local statics
Hi Jan, Your patch to mainline http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00388.html to defer handling of local statics has caused a regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22583 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045 hindering development. Please could look into it as soon as possible? Thanks, -- Gaby
Re: Old machine cluster for GCC compile/testing
On Tue, 2005-08-09 at 11:02 +0200, Sebastian Pop wrote: > I'm proposing to automate gcc's bootstrap & regtest: for each mail > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body' > contains a patch against some branch (ie. if it fails to apply to a > branch, just drop it and warn the user), enqueue it for validation. > The main server can be some script that monitors the availability of > cpu ressources and that distributes the patches for validation. The > answer can be a mail with just "passed witout regressions", or "patch > causes regressions: ". > > Bandwidth usage: size of incoming mail patch + size of answer + "cvs > update -dP" every morning. Looks good. I think it would be slightly more secure to have people commit the patch with a unique name in some access-controlled CVS (either some subdir of the GCC one or a new local one) than relying on email "From" fields at the cost of minor inconvenience. Also for the cvs update, I assume one of the machine will do an rsync of the whole CVS repository to factor external bandwidth cost and it enables some binary search stuff at no external bandwidth cost. On IRC, I was reminded that some developpers have machine that are less powerfull than the old donated servers or don't have x86 access, so they may use them to test their patch before submission. People in this case, please send me a private email so that I'm able to count the number of developpers that could benefit just from the access to some machine to do GCC work. Laurent
Can empty DWARF location list ranges be deleted?
Hi all, I am encountering a problem with DWARF location lists. Consider the following assembly: _Ltext: main: _LVL0: ;# basic block 0 _LVL1: This generates a DWARF location list entry whose begin and end addresses are identical, due to the empty basic block. Not a great problem on the face of it, but I'm using gcc in an embedded system in which the `main' function is placed at address 0. Thus, the location list entry gets an address range of [0, 0) which denotes the supposed end of the location list. This corrupts the location list, making it impossible to debug optimised code. Would it be difficult to detect empty location list so that they are never emitted? Empty locations lists are meaningless to the debugger, so deleting them wouldn't cause problems, and if they weren't present, the above situation could never occur. thanks, dan. Dan Towner picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG [EMAIL PROTECTED] 07786 702589
Re: Old machine cluster for GCC compile/testing
Laurent GUERBY wrote: > Looks good. I think it would be slightly more secure to have people > commit the patch with a unique name in some access-controlled CVS > (either some subdir of the GCC one or a new local one) than relying on > email "From" fields at the cost of minor inconvenience. > We also can enforce the rules by asking that patches to be signed, but after all, GCC contributors are well educated hackers. > Also for the cvs update, I assume one of the machine will do an > rsync of the whole CVS repository to factor external bandwidth cost > and it enables some binary search stuff at no external bandwidth cost. > okay. > On IRC, I was reminded that some developpers have machine that are less > powerfull than the old donated servers or don't have x86 access, so they > may use them to test their patch before submission. People in this case, > please send me a private email so that I'm able to count the number of > developpers that could benefit just from the access to some machine to > do GCC work. > Indeed, this is another service that can be provided.
Re: Can empty DWARF location list ranges be deleted?
On Tue, 2005-08-09 at 12:28 +0100, Daniel Towner wrote: > Hi all, > > I am encountering a problem with DWARF location lists. Consider the > following assembly: > > _Ltext: > main: > _LVL0: > ;# basic block 0 > _LVL1: > > This generates a DWARF location list entry whose begin and end addresses > are identical, due to the empty basic block. Not a great problem on the > face of it, but I'm using gcc in an embedded system in which the `main' > function is placed at address 0. > Thus, the location list entry gets an > address range of [0, 0) which denotes the supposed end of the location > list. This corrupts the location list, making it impossible to debug > optimised code. > Would it be difficult to detect empty location list so that they are > never emitted? It depends. We already try to elide obviously empty ones when possible. NOTES get in the way sometimes, and we don't try to handle that (see dwarf2out.c:add_var_loc_to_decl) However, even if you did handle that, you couldn't remove all of the empty location lists because the code between them may disappear in machine reorg, linker relaxation, etc.
Re: Old machine cluster for GCC compile/testing
On Tue, 2005-08-09 at 12:54 +0200, Laurent GUERBY wrote: > On Tue, 2005-08-09 at 11:02 +0200, Sebastian Pop wrote: > > I'm proposing to automate gcc's bootstrap & regtest: for each mail > > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body' > > contains a patch against some branch (ie. if it fails to apply to a > > branch, just drop it and warn the user), enqueue it for validation. > > The main server can be some script that monitors the availability of > > cpu ressources and that distributes the patches for validation. The > > answer can be a mail with just "passed witout regressions", or "patch > > causes regressions: ". > > > > Bandwidth usage: size of incoming mail patch + size of answer + "cvs > > update -dP" every morning. > > Looks good. I think it would be slightly more secure to have people > commit the patch with a unique name in some access-controlled CVS > (either some subdir of the GCC one or a new local one) than relying on > email "From" fields at the cost of minor inconvenience. > Why bother? Nobody forges mails to *test patches*. What does it buy you? Let's say you could buffer overflow the patch program with a specially crafted patch. Now you have access to GCC source code (I assume these things are properly segregated from your internal network)! SuSE, for example, has an automatic patch tester that just goes by from address. If i was required to do cvs commits somewhere else to test a patch, I wouldn't bother, and i doubt most people would either, even though you just consider it a "minor inconvenience". It's more inconvenience than the auto-tester is probably worth. > Also for the cvs update, I assume one of the machine will do an > rsync of the whole CVS repository to factor external bandwidth cost > and it enables some binary search stuff at no external bandwidth cost. SVN rsync is very cheap.
Re: Your patch to skip local statics
> > Hi Jan, > > Your patch to mainline > > http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00388.html > > to defer handling of local statics has caused a regression > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22583 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045 > > hindering development. Please could look into it as soon as possible? Sorry for that. I tought these problems was fixed but apparently just one of the dupes was. I will look into it today. Honza > > Thanks, > > -- Gaby
Re: [GCC 4.2 Project] Omega data dependence test
Joe Buck wrote: > Algorithms that are sometimes exponential can still be used if there is > a cutoff mechanism, to abort the algorithm if it exceeds a budget. This > assumes that we can then fall back to an algorithm that might produce > inferior results, but will produce something usable in reasonable time. > Okay, I stand corrected. As a practical implementation we can have a mechanism as push/pop timevar, that would monitor the time and space of an algorithm and that can cancel the computation for failing on a safe approximation. As a first concretization, I was thinking to use threads, but I'm not sure whether this is suitable for GCC.
Re: [patch] Fix i386-mingw32 build failure
On Tue, Aug 09, 2005 at 09:33:19AM +0200, Paolo Bonzini wrote: >>Can someone with approval privilege over the build system look at this, >>and OK it? (it's a very simple patch) > >I must apologize for the delay in handling this. This alternative patch >avoids that mingw is hardcoded in the makefiles. FWIW, it is also even >smaller, > > 3 files changed, 19 insertions(+), 12 deletions(-) > >vs. > > 1 files changed, 25 insertions(+), 10 deletions(-) > >:ADDPATCH build: > >I have only tested it on Linux, can you give it a try? Ok if FX's >testing succeeds? > >2005-08-09 Paolo Bonzini <[EMAIL PROTECTED]> > > * config.build (build_have_sh_scripts): Default to yes, > set to no for mingw32. > * configure.ac (build_have_sh_scripts): AC_SUBST it. > * Makefile.in (stamp-as, stamp-collect-ld, stamp-nm): If > build_have_sh_scripts is false, rely on $(LN). > * configure: Regenerate. This would conflict with my proposed changes to pex-win32.c . It seems like getting '#!' functioning on mingw would be a better solution than relying on $(LN) on mingw. I haven't gotten around to implementing this in libiberty because I've been on vacation but I should have time to do this this week, if it is still desirable. cgf
Re: [GCC 4.2 Project] Omega data dependence test
On Tue, Aug 09, 2005 at 04:59:28PM +0200, Sebastian Pop wrote: > Joe Buck wrote: > > Algorithms that are sometimes exponential can still be used if there is > > a cutoff mechanism, to abort the algorithm if it exceeds a budget. This > > assumes that we can then fall back to an algorithm that might produce > > inferior results, but will produce something usable in reasonable time. > > > > Okay, I stand corrected. As a practical implementation we can have a > mechanism as push/pop timevar, that would monitor the time and space > of an algorithm and that can cancel the computation for failing on a > safe approximation. As a first concretization, I was thinking to use > threads, but I'm not sure whether this is suitable for GCC. The problem with using time as a cutoff is that you then get results that can't be reproduced reliably. Better to count something that is a feature of the algorithm, e.g. number of executions of some inner loop, number of nodes visited, or the like, so that all users get the same results.
Re: [GCC 4.2 Project] Omega data dependence test
[EMAIL PROTECTED] wrote: Okay, I stand corrected. As a practical implementation we can have a mechanism as push/pop timevar, that would monitor the time and space of an algorithm and that can cancel the computation for failing on a safe approximation. As a first concretization, I was thinking to use threads, but I'm not sure whether this is suitable for GCC. No threads in gcc, please.
Enable FTZ/DAZ for SSE?
I have a small testcase to show that enable FTZ/DAZ makes a huge (>160 times faster) difference on SSE floating point code. Icc enables it by defailt for -ON (N>=1). Should gcc do the same? H.J.
Re: [GCC 4.2 Project] Omega data dependence test
On Aug 9, 2005, at 1:59 PM, Daniel Kegel wrote: No threads in gcc, please. Why? If this is only for double checking, why not? -- Pinski
Re: Old machine cluster for GCC compile/testing
On Tue, 2005-08-09 at 08:53 -0400, Daniel Berlin wrote: > > Looks good. I think it would be slightly more secure to have people > > commit the patch with a unique name in some access-controlled CVS > > (either some subdir of the GCC one or a new local one) than relying on > > email "From" fields at the cost of minor inconvenience. > > > > Why bother? > Nobody forges mails to *test patches*. What does it buy you? Full control of an internet connected host, your just have to provide a patch to the gcc Makefile to append some ssh public key in $HOME/.ssh somewhere or compile and run your favourite mini backdoor included in the patch. You can of course run in some jail (usermode linux or whatever) to mitigate this. Laurent
Re: Old machine cluster for GCC compile/testing
On Tue, 2005-08-09 at 20:11 +0200, Laurent GUERBY wrote: > On Tue, 2005-08-09 at 08:53 -0400, Daniel Berlin wrote: > > > Looks good. I think it would be slightly more secure to have people > > > commit the patch with a unique name in some access-controlled CVS > > > (either some subdir of the GCC one or a new local one) than relying on > > > email "From" fields at the cost of minor inconvenience. > > > > > > > Why bother? > > Nobody forges mails to *test patches*. What does it buy you? > > Full control of an internet connected host, > your just have to provide a > patch to the gcc Makefile to append some ssh public key in $HOME/.ssh > somewhere or compile and run your favourite mini backdoor included in > the patch. Yes, well, if someone does that, you blacklist them. You can also simply acl it so that the user can't write anything out of the gcc tree. > > You can of course run in some jail (usermode linux or whatever) to > mitigate this. > > Laurent >
Re: [patch] Fix i386-mingw32 build failure
I have only tested it on Linux, can you give it a try? Ok if FX's testing succeeds? Testing succeeded on i686-mingw32. Configures and builds fine. Can someone review this patch? FX
[ADMINISTRIVIA] email screw up at sourceware.org/gcc.gnu.org/cygwin.com
I just accidentally deleted qmail's outgoing queue on sourceware, thinking that I was actually deleting the queue on a new, improved system which will be coming on line soon. This caused all outgoing email to be deleted. The majority of people affected were spammers but I'm sure that people from all of the active mailing lists were affected as well, although there should be a limited number of those people. This should only affect people who hadn't yet gotten the latest email message as of the time of my screw-up, which was at 8/9/2005 19:16 GMT. So, if you were unlucky enough to have email in the queue prior to that, it's gone now. Email subsequent to that time should still be ok. I don't know of any way to recover the lost email so, if this matters to you, please check the archives of your mailing list to see if you lost anything. I apologize for the inconvenience. That was two stupid mistakes today. I guess I shouldn't be doing any sysadmin stuff right now. Note that I've set the reply-to of this message to the overseers mailing list since I don't think this is an issue which is of general interest to all of the mailing lists that I've cc'ed. cgf
Re: Enable FTZ/DAZ for SSE?
On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> times faster) difference on SSE floating point code. Icc enables it by
> defailt for -ON (N>=1). Should gcc do the same?
This is the flush-denormals-to-zero bit?
See config/{alpha,ia64,sparc}/crtfastmath.c, and how that gets used.
r~
Re: Enable FTZ/DAZ for SSE?
On Tue, Aug 09, 2005 at 01:35:11PM -0700, Richard Henderson wrote:
> On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> > I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> > times faster) difference on SSE floating point code. Icc enables it by
> > defailt for -ON (N>=1). Should gcc do the same?
>
> This is the flush-denormals-to-zero bit?
>
Yes, FTZ stands for flush to zero and DAZ stands for denormals are
zero.
> See config/{alpha,ia64,sparc}/crtfastmath.c, and how that gets used.
>
The one for x86 may be very similar to alpha's crtfastmath.c. It can
be used for fast math on SSE targets.
H.J.
Re: RFH: _inter_-procedure optimizations "CALL_REALLY_USED_REGISTERS"
Steven Bosscher wrote: > In > any case, you should assume that it is a much bigger job than just > modifying the call expander. Ok, I had a closer look at what is happening in present state gcc and I understand that it is indeed a much more complex task than I first thought. One Issue would be also, that it probably would be worth considering which other kind of information (except register clobbering information) on a static leaf function would be worth to be shared with the caller: memory usage of the called function / memory clobbers, information on whether it's a pure function ? Probably once one starts to try to implement kind of a database containing information on all the functions that are already compiled, one might make efforts to support all of the most useful information. Of course there always will be trade-offs concerning compilation time and memory consumption. I still would like to try my very best to look after this, but I'd prefer to start by scanning literature. If anyone could help me out recommending good articles / textbooks dealing with inter-function optimizations. It would be appreciated :-). Yours, Björn
Re: Enable FTZ/DAZ for SSE?
On Tue, Aug 09, 2005 at 02:01:08PM -0700, H. J. Lu wrote:
> On Tue, Aug 09, 2005 at 01:35:11PM -0700, Richard Henderson wrote:
> > On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> > > I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> > > times faster) difference on SSE floating point code. Icc enables it by
> > > defailt for -ON (N>=1). Should gcc do the same?
> >
> > This is the flush-denormals-to-zero bit?
> >
>
> Yes, FTZ stands for flush to zero and DAZ stands for denormals are
> zero.
>
> > See config/{alpha,ia64,sparc}/crtfastmath.c, and how that gets used.
> >
>
> The one for x86 may be very similar to alpha's crtfastmath.c. It can
> be used for fast math on SSE targets.
There is a minor problem. How can I add crtfastmath.o for SSE targets
only? Can I add a new macro, TARGET_EXPAND_MAIN_FUNCTION, to
expand_main_function to generate those instructions directly?
H.J.
Re: Enable FTZ/DAZ for SSE?
H. J. Lu wrote: Yes, FTZ stands for flush to zero and DAZ stands for denormals are zero. seems a bad idea to do this by default. lack of denormals gives fpt rather horrible properties
Re: Enable FTZ/DAZ for SSE?
On Tue, Aug 09, 2005 at 05:45:23PM -0400, Robert Dewar wrote: > H. J. Lu wrote: > > >Yes, FTZ stands for flush to zero and DAZ stands for denormals are > >zero. > > seems a bad idea to do this by default. lack of denormals > gives fpt rather horrible properties Not by default. It should be controlled by an option, like -ffast-math. H.J.
Re: Enable FTZ/DAZ for SSE?
On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote: > There is a minor problem. How can I add crtfastmath.o for SSE targets > only? You don't. You either add code to detect sse, or you make the spec depend on -mfpmath=sse. > Can I add a new macro, TARGET_EXPAND_MAIN_FUNCTION, to > expand_main_function to generate those instructions directly? No. r~
Re: [GCC 4.2 Project] Omega data dependence test
Andrew wrote: >> No threads in gcc, please. > > Why? If this is only for double checking, why not? Sorry, I missed that boehm-gc already uses threads. Ignore me, I'm just a cranky old-school programmer... but still, if there's a way to implement the checker without using threads, that would surely be safer.
Re: [GCC 4.2 Project] Omega data dependence test
On Tue, 9 Aug 2005, Sebastian Pop wrote: Joe Buck wrote: Algorithms that are sometimes exponential can still be used if there is a cutoff mechanism, to abort the algorithm if it exceeds a budget. This assumes that we can then fall back to an algorithm that might produce inferior results, but will produce something usable in reasonable time. Okay, I stand corrected. As a practical implementation we can have a mechanism as push/pop timevar, that would monitor the time and space of an algorithm and that can cancel the computation for failing on a safe approximation. As a first concretization, I was thinking to use threads, but I'm not sure whether this is suitable for GCC. A lot of data dependence related algorithms are exponential in the worst case, and work fine in production compilers, without cutoffs. XLC uses fourier motzkin without any cutoffs, for example (as does intel, i believe) :)
Re: Enable FTZ/DAZ for SSE?
On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote: > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote: > > There is a minor problem. How can I add crtfastmath.o for SSE targets > > only? > > You don't. You either add code to detect sse, or you make the > spec depend on -mfpmath=sse. I will add runtime SSE detection in crtfastmath.o. H.J.
gcc-3.4-20050809 is now available
Snapshot gcc-3.4-20050809 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050809/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050809 You'll find: gcc-3.4-20050809.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050809.tar.bz2 C front end and core compiler gcc-ada-3.4-20050809.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050809.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050809.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050809.tar.bz2 Java front end and runtime gcc-objc-3.4-20050809.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050809.tar.bz2The GCC testsuite Diffs from 3.4-20050802 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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: [GCC 4.2 Project] Replacements for CSE path following
Paolo Bonzini <[EMAIL PROTECTED]> wrote: > This pass does simple forward propagation and simplification when > an operand of an insn can only come from a single def. The pass has a > very good potential of catching simplifications currently done by > inter-basic-block CSE (-fcse-follow-jumps and -fcse-skip-blocks) and > combine: however, it is much faster than inter-basic-block CSE and > runs much earlier than combine. It is not clear whether this patch will make -fcse-follow-jumps / -fcse-skip-blocks obsolete and thus disable/remove them. I think this should be clearly stated. Giovanni Bajo
Re: Old machine cluster for GCC compile/testing
On Tue, 9 Aug 2005, Sebastian Pop wrote: > Laurent GUERBY wrote: > > > > So I'm asking for project proposals, that is to say people that think > > that their volunteer time to work on these old machine (scripts, > > compiling, ... under the limit of minimal external bandwidth use) is of > > some significant benefit to some free software project. > I'm proposing to automate gcc's bootstrap & regtest: for each mail > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body' > contains a patch against some branch (ie. if it fails to apply to a > branch, just drop it and warn the user), enqueue it for validation. And I'd like to add to that proposal, that the target to test should be controllable (default "native), to simplify cross-testing. (Not saying whether it should be possible to specify multiple targets.) Perhaps simplest done by using geoffk's script contrib/regression/btest-gcc.sh, which makes this bit mostly trivial. brgds, H-P
Re: RFH: _inter_-procedure optimizations "CALL_REALLY_USED_REGISTERS"
On Tue, 2005-08-09 at 23:06 +0200, Björn Haase wrote: > Steven Bosscher wrote: > > In > > any case, you should assume that it is a much bigger job than just > > modifying the call expander. > > Ok, I had a closer look at what is happening in present state gcc and I > understand that it is indeed a much more complex task than I first thought. > One Issue would be also, that it probably would be worth considering which > other kind of information (except register clobbering information) on a > static leaf function would be worth to be shared with the caller: > > memory usage of the called function / memory clobbers, information on whether > it's a pure function ? Uh, we produce memory ref/clober info at the tree-ssa level, just not at the RTL level. However, RTL level uses the callgraph info about pure/const functions, which is already extracted through interprocedural analysis (see ipa-pure-const.c)
