Re: Why is the length of *sse_prologue_save_insn 135?
> Hi Jan, Uros,
Hi,
I guess I was just lazy to figure out the size at a time of writting the
pattern.
Length is not used for anything useful at the moment, but fixing it
definitly won't hurt.
Honza
>
> i386.md has
>
> (define_insn "*sse_prologue_save_insn"
> [(set (mem:BLK (plus:DI (match_operand:DI 0 "register_operand" "R")
> (match_operand:DI 4 "const_int_operand" "n")))
> (unspec:BLK [(reg:DI 21)
> (reg:DI 22)
> (reg:DI 23)
> (reg:DI 24)
> (reg:DI 25)
> (reg:DI 26)
> (reg:DI 27)
> (reg:DI 28)] UNSPEC_SSE_PROLOGUE_SAVE))
>(use (match_operand:DI 1 "register_operand" "r"))
>(use (match_operand:DI 2 "const_int_operand" "i"))
>(use (label_ref:DI (match_operand 3 "" "X")))]
> "TARGET_64BIT
>&& INTVAL (operands[4]) + SSE_REGPARM_MAX * 16 - 16 < 128
>&& INTVAL (operands[4]) + INTVAL (operands[2]) * 16 >= -128"
> {
> ...
> }
> [(set_attr "type" "other")
>(set_attr "length_immediate" "0")
>(set_attr "length_address" "0")
>(set_attr "length" "135")
>(set_attr "memory" "store")
>(set_attr "modrm" "0")
>(set_attr "mode" "DI")])
>
> Why is the length 135? I saw
>
> jmp *%rdx # 12*sse_prologue_save_insn [length = 135]
> movaps %xmm7, -15(%rax)
> movaps %xmm6, -31(%rax)
> movaps %xmm5, -47(%rax)
> movaps %xmm4, -63(%rax)
> movaps %xmm3, -79(%rax)
> movaps %xmm2, -95(%rax)
> movaps %xmm1, -111(%rax)
> movaps %xmm0, -127(%rax)
>
> which is 34 bytes.
>
>
> H.J.
Re: GCC Compile Farm News: two new bi-quad core machines available
On Fri, May 23, 2008 at 8:03 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Fri, 23 May 2008, Sebastian Pop wrote: >> AMD Developer Central has generously donated two bi-quad core >> machines with the latest AMD Opteron 8354 "Barcelona B3" processors >> and 16GB of RAM to the GCC Compile Farm >> project for use by free software developers. Hosting is donated >> by http://www.inria.fr/saclay/";>INRIA Saclay. > > This looks good, please go ahead, let's just remove "generously". > > (Not because the donation is not generous, but many other parties > have been doing donations as well, of code, people and infrastructure, > and we want to keep the acknowledgements simple and consistent.) > > Ah, and pleaes make the link to the Wiki an absolute one. We also > have an instance of the web page, but not the Wiki, running on the > www.gnu.org server and there may be further mirrors. Here is what I committed: Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.662 diff -d -u -r1.662 index.html --- index.html 19 May 2008 20:33:11 - 1.662 +++ index.html 24 May 2008 12:43:13 - @@ -45,6 +45,13 @@ +May 22, 2008 +AMD Developer Central has donated two bi-quad core machines with +the latest AMD Opteron 8354 "Barcelona B3" processors and 16GB of RAM +to the http://gcc.gnu.org/wiki/CompileFarm";>GCC Compile Farm +project for use by free software developers. Hosting is donated +by http://www.inria.fr/saclay/";>INRIA Saclay. + May 19, 2008 GCC 4.2.4 has been released. -- Sebastian Pop AMD - GNU Tools
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
On Fri, 18 Apr 2008, Benjamin Kosnik wrote: >> libstdc++-html.20080213 drwxr-sr-x 2 bkoz gcc 258048 Mar 26 >> 06:05 libstdc++-html.20080326 drwxr-sr-x 2 bkoz gcc 237568 Jan >> 18 06:49 libstdc++-html-USERS-20080118 > > These are just the latest doxygen files, ie things that > the "latest-doxgen" symlink finds. > > We really only need what's current (ie, 20080326). (I was keeping some > of the older ones around because sometimes output changes depending on > doxygen version, and I wanted a quick way to check. However, the > 20080328 version is correct.) I see a new version now. Will it be okay to remove drwxr-sr-x 2 bkoz gcc 114688 Feb 13 21:39 libstdc++-html.20080213 drwxr-sr-x 2 bkoz gcc 258048 Mar 26 06:05 libstdc++-html.20080326 and drwxr-sr-x 2 bkoz gcc 237568 Jan 18 06:49 libstdc++-html-USERS-20080118 Do you see any chance to integrate the building of this documentation into the generation of the regular release-specific documentation and perhaps have the documents under those subdirectories instead of having this under libstdc++? That would make things more consistent, but I do not know how hard this will be. Gerald
designated initializers: error or warning for obsolete forms?
Hi,
I've been using designated initializers[1] for structures
for some time, in the form they had been implemented
by the Plan9 C compilers[2], i.e. without a '=' between
designator and initializer, like this:
Point p = {
.y 100,
.x 200
};
In Ansi-C this now is:
Point p = {
.y =100,
.x =200
};
>From Ansi-C's view there are probably
two obsolete forms, one for array designators,
one for designators in struct initializations,
both without the '='.
Apparently the obsolete form for structs is not supported
anymore since SVN rev 89252 [3] (that for array
designators still is):
(initelt): Only permit array_designator without '=', not ".foo",
which is the solution to problem report #16667.
In gcc/c-parser.c this is now coded in c_parser_initelt
within the "if (des_seen==1) / else" block -- the else
block generates the error.
Is there a chance that the old behaviour could be
re-enabled, i.e. the error turned into an `obsolete'
warning again? If yes, perhaps it would make sense to
always print that warning, not only if -pedantic), which
would reduce that code to
}
else
pedwarn ("obsolete use of designated initializer without %<=%>");
I would find it nice if the old form could be supported
again, as I often use that kind of initialization in
embedded software, and it seems to me that it is a bit
more readable than the Ansi-C version.
Thanks,
Michael
[1] http://www.dmk.com/c/init.html
[2] http://plan9.bell-labs.com/sys/doc/comp.html
[3]
http://gcc.gnu.org/viewcvs/trunk/gcc/c-parse.in?r1=89252&r2=89560&pathrev=95557
