Re: [help-texinfo] Re: small font in gcc online docs
2008/11/3 Karl Berry <[EMAIL PROTECTED]>:
>>> I noticed that in the default Firefox3 configuration on my 1280x1024
> display
>>> your code samples on this page are tiny, and v.hard to read:
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc/Inline.html
>
> I'd like to hear from other people about whether the examples are too
> small in their browsers. They are ok for me (seamonkey, firefox,
> icecat). Distros like to tinker so much with browser defaults ...
The examples look too small in FF 3.0.3 with default settings and 800
x 600 resolution. They look fine on IE 7 with the default settings and
800 x 600 resolution again.
>
>>> I see in the HTML this is the code causing the small font:
>>>
>>> pre.smallexample { font-size:smaller }
>
> I don't know of any way to say "use a slightly smaller font" in
> HTML/CSS. That is, this is what CSS provides, afaik.
>
> The reason that the above css exists at all is because users requested
> that @smallexample (the Texinfo command in question) produce smaller
> output than the regular @example, including in HTML. (Like
> @smalldisplay, @smallformat, @smallisp, and now @smallquotation.)
> Personally I don't have strong feelings about it.
>
>> (I just realized that gcc.gnu.org still uses texinfo 4.8, so if later
>> versions have this changed, I could ask the admins to upgrade.)
>
> Nothing has changed in this regard.
>
> Best,
> karl
>
Parma Polyhedra Library 0.10
It has been released: see http://www.cs.unipr.it/pipermail/ppl-announce/2008/21.html All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: Parma Polyhedra Library 0.10
On Tue, Nov 04, 2008 at 05:37:02PM +0100, Roberto Bagnara wrote: > > It has been released: see > > http://www.cs.unipr.it/pipermail/ppl-announce/2008/21.html > > All the best, > >Roberto > > -- > Prof. Roberto Bagnara > Computer Science Group > Department of Mathematics, University of Parma, Italy > http://www.cs.unipr.it/~bagnara/ > mailto:[EMAIL PROTECTED] > Now that ppl 0.10 is release, what are the plans for merging the cloog-ppl changes into an actual cloog release so that tarballs are available for both? Jack
Re: Parma Polyhedra Library 0.10
Jack Howarth wrote: Now that ppl 0.10 is release, what are the plans for merging the cloog-ppl changes into an actual cloog release so that tarballs are available for both? This is a good question for the CLooG maintainers. Are they on this list? -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
IA64 HP-UX libtool / gcc question about shared libraries
I have a libtool / gcc / libgomp / shared library question. The problem I have is that if I compile a C program with -fopenmp and run it on IA64 HP-UX I get: $ ./x /usr/lib/hpux32/dld.so: Unable to find library 'libgcc_s.so.0'. The problem is that the GNU C compiler links the program against the archive version of libgcc so that the main program does not need the shared libgcc_s.so. But the compiler also links in the shared version of libgomp.so because the IA64 HP-UX linker picks shared libraries over archive ones by default so it links in the shared libgomp.so. The libgomp.so library has a dependency on libgcc_s.so but it doesn't know where to find it because there is no library search path built in to shared libraries. This is because libtool used +nodefaultrpath to stop the HP linker from putting a search path into the shared libraries that it builds. This problem does not occur with C++ or Fortran because those languages link against the shared libgcc instead of the archive one and so libgcc_s.so and a search path for it are in the main object. If I compile and link with '-shared-libgcc -fopenmp', then the program will run correctly. So my question is: should this be fixed in libtool or in GCC. The fix in GCC, as far as I can see would be to use -shared-libgcc when doing links where -fopenmp is used. Or, more drastically, change GCC to always use the shared libgcc on IA64 HP-UX. The IA64 HP-UX system ships without an archive version of libc so forcing it to use a shared libgcc may not be unreasonable. To fix it in libtool I think we would have to stop using +nodefaultrpath when building shared libraries so that there is a search path to use in the shared libraries. This seems simple but I am not sure about all the ramifications of doing this and that makes me a bit nervous. Any opinions or ideas on how (or where) this problem should be fixed? Steve Ellcey [EMAIL PROTECTED]
Re: IA64 HP-UX libtool / gcc question about shared libraries
On Tue, Nov 4, 2008 at 12:56 PM, Steve Ellcey <[EMAIL PROTECTED]> wrote: > To fix it in libtool I think we would have to stop using +nodefaultrpath > when building shared libraries so that there is a search path to use in > the shared libraries. This seems simple but I am not sure about all the > ramifications of doing this and that makes me a bit nervous. > > Any opinions or ideas on how (or where) this problem should be fixed? libtool on AIX inserts a search path into shared libraries, but it often chooses a bloated series of search directories. The search path works but it searches for build directories not present on the install system. David
Re: RFC: A new meta intrinsic header file for x86 intrinsics
On Mon, Nov 03, 2008 at 02:17:40PM -0800, H.J. Lu wrote: > My question is if we should put AVX intrinsics directly in immintrin.h or in > a separate file. If we put AVX and future intrinsics directly in immintrin.h, > immintrin.h may become very large and harder to maintain. Another > choice is to put AVX intrinsics in a separate file, saying avxintrin.h: > > #ifndef _IMMINTRIN_H_INCLUDED > # error "Never use directly; include instead." > #else > AVX intrinsics > #endif /* _IMMINTRIN_H_INCLUDED */ I think a separate header with such an error is better. Note, you can just #endif right after the error and put AVX intrinsics in the file, no need to have everything inside of the #else. Jakub
RFD: reducing inter-procedure stalls w/o IPO
When registers are saved in the prologue, there can be stalls if there are lingering latencies because the values haven't been computed or loaded yet. Likewise, when the epilogue restores registers, there will be stalls if the last one (or one of the last few, depending on latency) is accessed immediately after the call. While Iinterprocedural optimization could in principle address this, you would have to recompile all the libraries to do this, and also somehow include all the lib1funcs into the IPO framework. I wouldn't say that's impossible, but it doesn't seem feasible in the short term, nor for general use even in the medium to long term. If we arrange for the registers to be saved first / restored last to be from a small subset of registers, could the register allocator take into account of this by not allocating values that need to be set with lingering latencies before calls / used immediately after a call to these registers. Of course it does no good to generally avoid these registers if you need any call-saved registers, because one register *has* to be saved first / restored last; if the register allocator fails to use one of the right set, reorg would have to renumber the registers to find something - or otherwise save/restore a register first/last which is not supposed to be in that role.
RE: [help-texinfo] Re: small font in gcc online docs
Hi Karl, Thanks for your reply. > Does @smallexample come out as 8pt or so? It definitely looks > smaller than 10pt on my screen. > > It comes out as whatever your browser tells it to, hopefully depending > on what font size you have set. This is why different users see > different things. The effect should be similar to using > ..., although I expect there are browser(s) and > version(s) which don't implement any of this properly in the first > place. > > As for using @example instead of @smallexample, I suspect some of the > examples would then become too wide for the printed manual. http://gcc.gnu.org/onlinedocs/gcc/Inline.html In the printed manual, is text smaller or the same size as text? I suspect they will be the same, in which case they should both be the same readable size in the HTML version. Definitely each user can change the default browser settings, but I would hope pages would be readable without browser modification. See what it looks like at present for me with default Firefox3: http://img219.imageshack.us/my.php?image=firefox3inlineub4.png > I'm sorry, but I just don't see anything to do here. Every option will > displease someone. Let's see if the manual really does look different. Perhaps GCC could just use the as that works fine? Regards, Jon
RE: [help-texinfo] Re: small font in gcc online docs
In the printed manual, is text smaller or the same size as text? The result of @smallexample is smaller than the result of @example in printed manuals. Definitely each user can change the default browser settings, but I would hope pages would be readable without browser modification. I agree, but all we can do is make the pages as generic as possible. We cannot hope to placate all versions of all browsers. Believe me, if I changed @smallexample back to not use font-size:smaller, there would be plenty of complaints as well. See what it looks like at present for me with default Firefox3: http://img219.imageshack.us/my.php?image=firefox3inlineub4.png I certainly agree that is ridiculously bad. It seems like a bug in firefox3 (not that I have much hope of anything changing). I note that the ... text is smaller than the surrounding text too, so the defaults are apparently set so things are inconsistent to start with. Let's see if the manual really does look different. Perhaps GCC could just use the as that works fine? If @example were used, I believe some examples would overflow the printed pages. If some examples use @example and some examples use @smallexample, the resulting inconsistency looks quite bad as well (in both printed manuals and HTML). I doubt the GCC folks want to research and rewrite their examples to use shorter lines (so @example could be used). Sorry, I am still stuck for any positive action. karl
Call for papers for GCC Research Opportunities Workshop GROW'09 - deadline extension to Nov 21
*** DEADLINE EXTENDED UNTIL NOVEMBER 21, 2008 *** CALL FOR PAPERS 1st International Workshop on GCC Research Opportunities (GROW'09) held in conjunction with the 4th International Conference on High Performance and Embedded Architectures and Compilers (HiPEAC'09) http://www.hipeac.net/conference/ January 25-28, 2009 Paphos, CYPRUS Important dates: Papers due: November 7, 2008 Acceptance notices: December 19, 2008 Workshop date : Half day during January 25-28, 2009 Web site: http://www.doc.ic.ac.uk/~phjk/GROW09/ Topics of interest: GROW focuses on current challenges in research and development of compiler analyses and optimizations based on the free GNU Compiler Collection (GCC). The goal of this workshop is to bring together people from industry and academia that are interested in conducting research based on GCC and enhancing the compiler suite to better support embedded and parallel/multicore systems. The workshop will promote and disseminate compiler research (recent, ongoing or planned) with GCC, as a robust industrial-strength vehicle that supports free and collaborative research. The topics of the workshop include any issue related to innovative compiler analysis and/or optimizations with GCC targeting embedded and parallel/multicore systems, including but not limited to: * Classical compiler analyses, transformations and optimizations * Power-aware analyses and optimizations * Language/Compiler/HW cooperation * Optimizing compilation tools for parallel/multicore systems * Profiling, dynamic analysis, and feedback-directed optimization * Case studies and performance evaluations * Techniques and tools to improve application and compiler quality Submission guidelines: Submitted papers should use the LNCS format and should be 12 pages maximum. Manuscript preparation guidelines can be found at the LNCS specification web site: http://www.springeronline.com/lncs (go to -> For Authors -> Information for LNCS Authors). All papers and abstracts should be submitted in either PDF or PS format to the GROW'09 EasyChair online submission website: http://www.easychair.org/conferences/?conf=grow09 Papers will be refereed by the Program Committee and if accepted, and if the authors wish, will be made available on the workshop web site. Authors of the best papers from the workshop may be invited to revise their submission for the journal Transactions on HiPEAC, if the work is in sufficiently mature form. Organizers: Paul H.J. Kelly, Imperial College of London, UK Sebastian Pop, AMD, USA Program Committee: Albert Cohen, INRIA, France Grigori Fursin, INRIA, France Benedict Gaster, AMD, USA Jan Hubicka, SuSE, Czech Republic Paul H.J. Kelly, Imperial College of London, UK Ondrej Lhotak, University of Waterloo, Canada Hans-Peter Nilsson, AXIS, Sweden Diego Novillo, Google, Canada Sebastian Pop, AMD, USA Ian Lance Taylor, Google, USA Kenneth Zadeck, NaturalBridge, USA Ayal Zaks, IBM, Israel
Re: Call for papers for GCC Research Opportunities Workshop GROW'09 - deadline extension to Nov 21
On Tue, Nov 4, 2008 at 7:27 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote: > *** DEADLINE EXTENDED UNTIL NOVEMBER 21, 2008 *** ... > Papers due: November 7, 2008 Well, papers are now due by November 21, 2008. Sorry for the typo. Sebastian
Re: Parma Polyhedra Library 0.10
On Tue, Nov 4, 2008 at 11:45 AM, Roberto Bagnara <[EMAIL PROTECTED]> wrote: > Jack Howarth wrote: >> >> Now that ppl 0.10 is release, what are the plans for merging >> the cloog-ppl changes into an actual cloog release so that tarballs are >> available for both? > > This is a good question for the CLooG maintainers. > Are they on this list? I'm the one responsible to close the cloog-ppl "branch" and get that code merged in CLooG. Sebastian
