Re: [RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor
[ Omitting gcc-patches ] On Sun, 30 Sep 2007, Janne Blomqvist wrote: > I think that if indeed metahtml is in such a bad shape as you > describe, moving away from it asap is the right thing to do. But I'm > not convinced that developing a gcc.gnu.org-specific template engine > is the correct answer. That's my concern as well. I certainly would not mind replacing MetaHTML and I very much appreciate if FX or others can help. And I would not mind if this involves a bit of scripting, but it would be good to reuse/share as much from other project as possible and not have this purely GCC- specific unless the scripting is really trivial. > There's plenty of such things available out there that are actively > maintained and developed. E.g. "Template Toolkit" seems rather widely > used, is written in perl (not my favourite language, but...) so it > should work on the current webserver There is one property of our web pages which I'd like to keep if possible, and that is that the pages themselves are simple HTML and the preprocessing only adds style, navigation, footers etc. On Thu, 4 Oct 2007, François-Xavier Coudert wrote: > ping? Gerald, being web pages maintainers, what's your opinion? > > Answering to Janne's comment, I'm certainly not opposed to any > preprocessor/templating system. My own goal is to rewrite the fortran > pages, including the common navigation bar, and I can't use MetaHTML > to do that. Have you been able to get things running with the input from the mail I sent a week or so ago? In the meantime I did a bit of further research, and http://thewml.org, specifically http://thewml.org/docs/backend/wml_p2_mp4h.html may be worth a closer look. It occurs to me that this would allow us to reuse most of the existing infrastructure, and it is still actively maintained. Thoughts? Gerald
Who should top level configure changes be coordinated with?
While digging through the top level configure researching my inhibit_libc changes I realized that there are some non-obvious ways to shoot yourself in the foot. For example, the build-sysroot parameter parsing in gcc-4.3-20071012 has the following code fragment. It looks like specifying --without-build-sysroot will actually set the value of SYSROOT_CFLAGS_FOR_TARGET="--sysroot=no" which is probably not what was wanted. Likewise, --with-build-sysroot sets it to "yes" when no "=" is present, hardly a good default either. AC_ARG_WITH([build-sysroot], [ --with-build-sysroot=SYSROOT use sysroot as the system root during the build], [if test x"$withval" != x ; then SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval" fi], [SYSROOT_CFLAGS_FOR_TARGET=]) AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET) Is it worth changing to something like below? If so, who should these sort of patches be coordinated with? I did not find a maintainer listed for the top level configure. SYSROOT_CFLAGS_FOR_TARGET= AC_ARG_WITH([build-sysroot], AC_HELP_STRING([--with-build-sysroot=SYSROOT], [use sysroot as the system root during the build]), [case $withval in no|"");; yes)AC_MSG_ERROR([--with-build-sysroot= requires a value]);; *)SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval";; esac]) AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET) Steve Kenton
Re: Who should top level configure changes be coordinated with?
On Sun, 2007-10-14 at 18:28 -0500, Steve Kenton wrote: > If so, who should these sort of patches be coordinated with? > I did not find a maintainer listed for the top level configure. build machinery (*.in) Paolo Bonzini [EMAIL PROTECTED] build machinery (*.in) DJ Delorie [EMAIL PROTECTED] build machinery (*.in) Nathanael Nerode[EMAIL PROTECTED] build machinery (*.in) Alexandre Oliva [EMAIL PROTECTED] Cheers, Ben
Re: University coursework & GCC
> I am currently looking for a topic for graduation thesis. I would > like it to be in the area of GCC code generation enhancements, and my > current best choice is providing predication support in selective > scheduling. If you have anything to suggest, I will be very glad to > hear; or maybe your answers will provide helpful directions for other > students who want a GCC-related term/graduation project. Finding a GCC enhancement to implement for your thesis is, I would think, unlikely to meet the academic requirements. On the other hand, I would recommend reading journals from ACM SIGPLAN, the ACM Digital Library, etc., finding an interesting topic in the academic sense and use GCC as a basis for experimenting with that idea. GCC is much better suited to such experimentation than it was 5-10 years ago. Good luck! Ben
Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Hello, On SPARC there is an ABI that is V8+ which allows the linking (and mixing) of V8 ABI but makes uses of features of 64bit UltraSparc CPUs (that were not available in the older 32bit only CPUs). Admittedly looking at the way this works it could be said that Sun had a certain about of forward thinking when they developed their 32bit ABI (this is not true of the 32bit Intel IA32 ABIs that exist). Are there any plans for a plan a new Intel IA32 ABI that is designed solely to run on 64bit capable Intel IA32 CPUs (that support EMT64) ? Userspace would have 32bit memory addressing, but access to more registers, better function call conventions, etc... This would be aimed to replace the existing i386/i686 ABIs on the desktop and would not be looking to maintain backward compatibility directly. My own anecdotal evidence is that I've been using a x86_64 distribution (with dual 64bit and 32bit runtime support) for a few years now and have found performance to be lacking in my two largest footprint applications (my browser and my development IDE totaling 5Gb of footprint between them). I recently converted both these applications from their 64bit versions to 32bit (they are the only 32bit applications running) and the overall interactive performance has improved considerably possibly due to the reduced memory footprint alone, a 4.5 Gb footprint 64bit application is equivalent to a 2 Gb footprint 32bit application in these application domains. Maybe someone knows of a white paper published to find out if the implications and benefit a movement in this direction would mean. Maybe just using the existing 64bit ABI with 32bit void pointers (and long's) is as good a specification as any. RFCs, Darryl
