Re: GCC 4.4.0 Status Report (2008-11-01)
On Sat, Nov 1, 2008 at 10:28 PM, Jack Howarth <[EMAIL PROTECTED]> wrote: > What are the rules for porting patches back from the graphite > branch that fix ICEs when -fgraphite is used to compile code? > There doesn't seem to have been much movement of patches out of > the graphite branch lately. Patches that touch graphite code only should be ok. For other patches it depends. Richard.
Re: About the "Build status for GCC 4.3" page
Hi Dennis, On Tue, 2 Sep 2008, Dennis Clarke wrote: > I noticed that the "Build status for GCC" page has no link > at all for 4.3.x and it would be nice to add that there please. > > http://gcc.gnu.org/buildstat.html thanks for catching this; I just committed the patch included at the end of this message to address this. > Also, could we get a few results for 4.3.2 on the 4.3.x status > page such that package builders ( like myself ) can get a feel > for how others are doing ? > > http://gcc.gnu.org/gcc-4.3/buildstat.html Looking at the current status of that page, this information has been completed now thanks to the nice contributions of Tom. > Is there a way perhaps to update this page automagically? Maybe even > a web based submission form with a a backend MySQL database ? I am > thinking that we could drum up something to make the test results > more readily available. I would be supportive of such an approach. Let's hear what Tom based on his experience in the last months suggests. > Sorry for being a nag. Not at all, thanks for the valuable input! Gerald Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/buildstat.html,v retrieving revision 1.15 retrieving revision 1.17 diff -u -3 -p -r1.15 -r1.17 --- buildstat.html 21 Oct 2006 02:54:29 - 1.15 +++ buildstat.html 2 Nov 2008 19:25:54 - 1.17 @@ -10,6 +10,7 @@ These pages summarize build reports for GCC. +GCC 4.3.x GCC 4.2.x GCC 4.1.x GCC 4.0.x
Re: small font in gcc online docs
On Tue, 21 Oct 2008, Jonathan Grant wrote:
> 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 see in the HTML this is the code causing the small font:
>
> pre.smallexample { font-size:smaller }
>
> Would you consider just using regular sized text?
>
> The CSS for inline doesn't have this problem, so you could
> even display it that way?
Thanks for reporting this, Jonathan. We are using a tool called texinfo
(makeinfo) to generate those pages on gcc.gnu.org, using the default
settings there, so let me redirect this to the texinfo mailing list.
(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.)
Gerald
Patch for Re: out of date docs? (alpha/64bit vs. 32bit vs. cross)
On Mon, 20 Oct 2008, Ian Lance Taylor wrote:
>> http://gcc.gnu.org/install/specific.html#alpha-dec-osf
>>
>> "Note that since the Alpha is a 64-bit architecture, cross-compilers from
>> 32-bit machines will not generate code as efficient as that generated when
>> the compiler is running on a 64-bit machine because many optimizations that
>> depend on being able to represent a word on the target in an integral value
>> on the host cannot be performed. Building cross-compilers on the Alpha for
>> 32-bit machines has only been tested in a few cases and may not work
>> properly. "
>>
>> This is false lately, eh?
>> Can it be amended to note what versions it was possibly true for and what
>> versions it is definitely false for?
>> In particular, I /assume/ it is false for any version that uses gmp.
> I believe that this is false these days. I believe that it has been
> false since a cross-compiler to the alpha required a 64-bit
> HOST_WIDE_INT, which was in gcc 3.4.
Does this mean you (or Rainer) would approve the following documentation
update? ;-)
Gerald
2008-11-02 Gerald Pfeifer <[EMAIL PROTECTED]>
* doc/install.texi (alpha*-dec-osf*): Remove note on 32-bit
hosted cross-compilers generating less efficient code.
Index: doc/install.texi
===
--- doc/install.texi(revision 141527)
+++ doc/install.texi(working copy)
@@ -2746,14 +2746,6 @@
new version of DEC Unix, you should rebuild GCC to pick up the new version
stamp.
-Note that since the Alpha is a 64-bit architecture, cross-compilers from
-32-bit machines will not generate code as efficient as that generated
-when the compiler is running on a 64-bit machine because many
-optimizations that depend on being able to represent a word on the
-target in an integral value on the host cannot be performed. Building
-cross-compilers on the Alpha for 32-bit machines has only been tested in
-a few cases and may not work properly.
-
@samp{make compare} may fail on old versions of DEC Unix unless you add
@option{-save-temps} to @code{BOOT_CFLAGS}. On these systems, the name
of the assembler input file is stored in the object file, and that makes
Re: small font in gcc online docs
[ [EMAIL PROTECTED] -> [EMAIL PROTECTED] ]
On Sun, 2 Nov 2008, Gerald Pfeifer wrote:
> On Tue, 21 Oct 2008, Jonathan Grant wrote:
>> 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 see in the HTML this is the code causing the small font:
>>
>> pre.smallexample { font-size:smaller }
>>
>> Would you consider just using regular sized text?
>>
>> The CSS for inline doesn't have this problem, so you could
>> even display it that way?
>
> Thanks for reporting this, Jonathan. We are using a tool called texinfo
> (makeinfo) to generate those pages on gcc.gnu.org, using the default
> settings there, so let me redirect this to the texinfo mailing list.
>
>
> (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.)
Re: new mirror
Hi Adriaticus, On Mon, 27 Oct 2008, Adriaticus wrote: > welcome > I would like to create mirror gcc > http://mirror.adriaticus.org/pub/gcc/ > ftp://mirror.adriaticus.org/pub/gcc/ just go ahead! Once the mirror is up and running a patch against http://gcc.gnu.org/mirrors.html to add an new entry for your site would be great. (I can also take care of that, but experience shows it's better if the mirror operator writes this up.) Thanks, Gerald
Re: [help-texinfo] Re: small font in gcc online docs
>> 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 ...
>> 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
Re: bootstrap4 vs. compare?
> though that is probably inadequate. Especially because Makefile.in is automatically generated. :-) > It's not the default goal that matters, but if bootstrap4 is a goal at all. > Or if compare3 is a goal. I have a (correct) patch which I'll apply in a day or two. Thanks, Paolo
using gcc's lexer/parser (was: Re: 'recording' program execution.)
ok, wrt the below, I was giving it some thought, and was wondering how usable the gcc lexer/parser combo was by itself, how 'pluggable' it was - my hope was that I could take the lexer/parser and instead of making an executable out of the incoming code, I could transform the code in place, ie: add extra code of my own choosing that I would then compile with gcc. How feasible would that be? Where's a good place to start? Thanks, Ed On Fri, Oct 31, 2008 at 11:24 AM, Edward Peschko <[EMAIL PROTECTED]> wrote: > Richard, > > Thanks for the info... I'll try it out - I'm assuming that what you > get out of this is very similar to what you get out of dtrace when you > instrument a pid on entry and return.. Having a full trace is very > helpful in tracking things down. > > I'd like to go further in c code even than what I have right now, > something I really can't do without a 'true' solution.. > > In perl, I've implemented reverse watch points - such that you give > the environment a certain data sequence/ascii string, and it monitors > all assignments and prints out the point in the code where they were > done, the variable that was set, and the values it was set to. > > It does this by parsing the code for assignments, and then comparing > the variable to the value(s) given by the user. > > I suppose I could do the same thing with my hack that does tracing, by > realizing that an assignment is occuring, keeping track of the > variable types of the code that I'm instrumenting, and defining a > different macro for each type of assignment, but I'm coming awful > close to writing a parser for c/c++ at that point and I don't think > the structure I've built would support it.. > > Which is too bad, because that is doubly helpful (above and beyond a > simple trace) for programs that you do not know. > > You see the behavior of the program in the form of strings being > output, but don't know the structure, etc. so you poke and prod it by > setting the reverse watchpoint to a string you know is going to be > output, run it, get the variable name you should be looking at, and > trace the stack back to the point where you are interested... > > How easy this would be to do even with the support of gcc/g++ is > questionable, but it would be a killer function for debugging > programs. With reverse tracepoints, I can typically get to perl > problems 10 times faster than I can without them, especially with more > complicated structures with huge object hierarchies.. > > Ed > > > > On Fri, Oct 31, 2008 at 3:57 AM, Richard Guenther > <[EMAIL PROTECTED]> wrote: >> On Fri, Oct 31, 2008 at 10:18 AM, wuxi <[EMAIL PROTECTED]> wrote: >>> [EMAIL PROTECTED] wrote: have a look at the flag -finstrument-functions for gcc. >>> >>> as far as I know, this could only record at function entry and return ? >>> >>> but sometimes recording all the "trace" of how program behaves is useful for >>> debugging purpose. >>> >>> further, using a binary instrumentation tool like PIN could only record the >>> low level instruction trace >> >> I would suggest to do the instrumentation in the frontends as there >> you still know >> the original statement boundaries. Note that the original program text may >> be >> not readily available there, so you might need to hack libcpp as well. >> >> Richard. >> >
