Mirrors
I am working on a project that easily and automatically uses Mirrors and segmented downloading. Basically, it is an XML file for storing the many links for a file (FTP, HTTP, P2P - BitTorrent especially). As you can imagine, this is very useful for accelerated downloading with download managers & balancing load between servers. It is being added to FlashGot, a Firefox extension, (which can pass URLs on to many other downlod managers) & GetRight (another download manager) now, but I would like for more people to hear about it. Some people who run kernel.org are interested too. Here's a link & some examples: http://home.comcast.net/~albryan/metalink/ I'd be interested in any comments you have. thanks, ant
Re: [C, C++] fundamental type object representation
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | Ian Lance Taylor writes: > | > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | > Does GCC support any target where the object representation of a > | > fundamental type T (e.g. int, float, double, pointers) whose all bits > | > are zero does not hold value (T)0? > | > | Surprisingly, the answer seems to be yes. > ... > | For the C4X target, a > | single precision floating point zero is apparently represented as > | 0x8000 (for double precision there is another 32 zero bits). > ... > | In other words, the floating point zero is only generated correctly > | when gcc is forced to output the initializer for some other reason. > ... > | Given that doesn't work, it is probably reasonably safe to assume gcc > | is always going to generate all zero bits for a fundamental types > | initialized to zero. > > OK, thanks. I was rewriting part of valarray and I saw I made that > assumption, and since it is bug chasing time I thought I should make > sure my use of memset() isn't going to bomb out. - If of any help, the c4x's float format is: [exp:8|sign:1|fract:23] where the exponent is encoded in 2's complement form thereby: (float)0 :: [0|0|0] :: 1.0*2^0 :: 1.0 and further defined that an exponent of -128 regardless of the value of it's sign and fraction fields is interpreted as 0.0, thereby: (int)0.0 :: (int)X*2^-128 :: may = (int)[-128|0|0] :: -2,147,483,648 So if it's defined that non otherwise initialized static data fields are initialized to all zero's, then correspondingly such floats will be interpreted as being initialized to 1.0 as far as the c4x is concerned; which may or may not be ok, but possibly reasonable if simply known to the the case?
Re: [C, C++] fundamental type object representation
Paul Schlie <[EMAIL PROTECTED]> writes: [...] | > OK, thanks. I was rewriting part of valarray and I saw I made that | > assumption, and since it is bug chasing time I thought I should make | > sure my use of memset() isn't going to bomb out. | | - If of any help, the c4x's float format is: [exp:8|sign:1|fract:23] | where the exponent is encoded in 2's complement form thereby: | | (float)0 :: [0|0|0] :: 1.0*2^0 :: 1.0 | | and further defined that an exponent of -128 regardless of the value | of it's sign and fraction fields is interpreted as 0.0, thereby: | | (int)0.0 :: (int)X*2^-128 :: may = (int)[-128|0|0] :: -2,147,483,648 | | So if it's defined that non otherwise initialized static data fields | are initialized to all zero's, then correspondingly such floats will be | interpreted as being initialized to 1.0 as far as the c4x is concerned; | which may or may not be ok, but possibly reasonable if simply known to | the the case? That may probably be OK -- I haven't heard of a C4X user doing instensive computations with valarray. But I guess I'll stick to the explicit loop and avoid having to revisit the valarray mess again. However, Ian and you have intrigued me; do you have a (preferably online) reference to C4X model? Thanks, -- Gaby
Implicit Type Conversions Warning
I used to use the CodeWarrior compiler on Mac OS 9 and X and then switched to the GCC compiler. One set of warnings that I sorely miss is that of implicit type conversions. GCC does offer a ³-Wconversion² warning, but this warns against type conversions between types in a function prototype vs. types that would be used if the prototype is missing. This is clearly a warning for historical purposes before C++ required function prototypes (and for C one can use Wstrict-prototypes, Wmissing-prototypes and Wmissing-declarations). What I desire is a warning for implicit type conversions between the passed parameter and the function prototype for that parameter. The current ³-Wconversion² implicit parameter types for missing function prototypes warning is irrelevant if one requires function prototypes (as C++ does or as one can catch from the ³C² warnings just mentioned). The ³-Wconversion² also warns against signed constant to unsigned variable conversion (assignment). This is incomplete. What I desire is a warning for implicit type conversions in an assignment and would apply to assignment from a variable or expression, not just from a constant. Though there are many ways one can categorize implicit type conversions, the following are useful and would apply to both function arguments vs. function prototype parameters and to assignments: - Signed/Unsigned conversions. These are from a signed type to an unsigned type and vice versa. Unspecified types, such as ³int², are treated by their implied signed type (³char² is treated as signed or unsigned based on the machine unless funsigned-char or fsigned-char is specified). - Shortened conversions. These are from a larger type to a shorter type. For example, from ³long² to ³short² or from ³double² to ³float² or from ³float² to ³int². The size of an ³int² is based on the machine. Since ³signed/unsigned conversions² is a separate warning, this ³shortened conversions² warning would not warn about signed/unsigned conversions that did not go from a larger type to a shorter type. So, ³short² to ³unsigned short² or ³short² to ³unsigned long² would not generate a warning from ³shortened conversions² (but would for ³signed/unsigned conversions² if that warning was enabled). - Any conversion. This would add lengthened and equivalent conversions to those above. For example, from ³short² to ³long² or from ³int² to ³long² (even if ³int² is the size of a ³long² on the machine). This category also catches conversions from ³char² to ³signed char² or ³unsigned char² or vice versa since ³char² is machine-dependent. However, ³int² and ³signed int², etc., are not considered to have any implicit conversion possibility since the language definition requires these to be exactly equivalent (so no warning is generated when missing a ³signed² except for the ³char² case). The primary way to avoid these warnings is to use typecasts, when necessary, for parameters in function calls and for expressions or constants in assignments. This forces the programmer to explicitly declare that they know what they are doing that type conversions are occurring and are intended. With proper planning, most typecasts are avoided as parameters and variables are designed with consistent types initially, but when mismatches occur, they are at least made explicitly clear. These warnings have caught many potential problems in the past. I didn¹t see this sort of enhancement request mentioned in the archives so that¹s why I¹m adding this now. Does anyone know why implicit type conversion warnings aren¹t in GCC already? Since CodeWarrior had them, I would assume that they aren¹t that difficult to implement. Thanks, Richard Falk
Re: Implicit Type Conversions Warning
I just found the following thread that addresses part of my enhancement request: http://gcc.gnu.org/ml/gcc/2004-06/msg01270.html This at least partially addresses the ³shortened conversions² part of my request. Sorry I didn¹t see that earlier. It sounds like this is an old request that has never been officially implemented.
Re: weakref and static
On Dec 1, 2005, [EMAIL PROTECTED] (Geoffrey Keating) wrote:
> The 'weakref' attribute is defined in terms of aliases. Now,
> if the user writes
> void foo(void) { }
> void bar(void) __attribute__((alias ("foo")));
> then that causes 'bar' to be defined. Other translation units can use
> 'bar'. If 'weakref' is to define an alias, it should behave the same
> way.
weakref does not define an alias. It defines a weakref. It happens
to use some of GCC's aliasing machinery under the covers, but that's
all. It's not an alias like non-weakref aliases, anyway.
> The easiest solution to this is to require that weakrefs must be
> 'static', because the name that they define is not visible outside
> this translation unit.
While this is true, not all properties of static names hold for
weakrefs. If the name they refer to is not itself static, none of the
local-binding analysis properties will apply correctly if the wekaref
is marked as static. I felt it was safer to keep it extern.
> * doc/extend.texi (Function Attributes): Mention that an alias
> attribute creates a definition for the thing it's attached to.
Except for weakrefs, that may introduce a local (weakref) definition,
if the assembler supports .weakref, or no definition whatsoever, if it
does not.
> Change the documentation for weakref to say that the thing
> it's attached to must be static.
Err... The above is a bit misleading, in that it at first appeared to
be referring to the target of the weakref, not to the weakref itself.
The weakref may alias to something that is static or not (the whole
point is being able to refer to symbols in other translation units
with weak and non-weak semantics). The weakref itself could be static
or extern, and both possibilities could be argued for and match
certain uses. Since attribute alias has traditionally required the
extern keyword, I figured it would make sense to keep it as such, but
if you prefer to change that and adjust all cases in which the use of
static might cause problems, that's certainly fine with me. I don't
see that you're taking care of such cases, though.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: weakref and static
On Sun, Dec 11, 2005 at 06:46:39PM -0200, Alexandre Oliva wrote: > Err... The above is a bit misleading, in that it at first appeared to > be referring to the target of the weakref, not to the weakref itself. > The weakref may alias to something that is static or not (the whole > point is being able to refer to symbols in other translation units > with weak and non-weak semantics). The weakref itself could be static > or extern, and both possibilities could be argued for and match > certain uses. Since attribute alias has traditionally required the > extern keyword, I figured it would make sense to keep it as such, but > if you prefer to change that and adjust all cases in which the use of > static might cause problems, that's certainly fine with me. I don't > see that you're taking care of such cases, though. Yeah, as shown on the s390 bootstrap failure, I suspect there will be many such corner cases lurking around on various targets. I prefer weakrefs to be extern too. Jakub
Re: [C, C++] fundamental type object representation
Gabriel Dos Reis wrote > Paul Schlie writes: > [...] > | > OK, thanks. I was rewriting part of valarray and I saw I made that > | > assumption, and since it is bug chasing time I thought I should make > | > sure my use of memset() isn't going to bomb out. > | > | - If of any help, the c4x's float format is: [exp:8|sign:1|fract:23] > | where the exponent is encoded in 2's complement form thereby: > | > | (float)0 :: [0|0|0] :: 1.0*2^0 :: 1.0 > | > | and further defined that an exponent of -128 regardless of the value > | of it's sign and fraction fields is interpreted as 0.0, thereby: > | > | (int)0.0 :: (int)X*2^-128 :: may = (int)[-128|0|0] :: -2,147,483,648 > | > | So if it's defined that non otherwise initialized static data fields > | are initialized to all zero's, then correspondingly such floats will be > | interpreted as being initialized to 1.0 as far as the c4x is concerned; > | which may or may not be ok, but possibly reasonable if simply known to > | the the case? > > That may probably be OK -- I haven't heard of a C4X user doing > instensive computations with valarray. But I guess I'll stick to the > explicit loop and avoid having to revisit the valarray mess again. > > However, Ian and you have intrigued me; do you have a (preferably > online) reference to C4X model? - General TI DSP Docs: http://focus.ti.com/dsp/docs/dspsupporttechdocs.tsp?sectionId=3&tabId=409&t echDoc=6&familyId=497&documentCategoryId=6 - c4x User Guide: http://focus.ti.com/lit/ug/spru063c/spru063c.pdf
Re: Installing libgcj consumes huge amounts of memory
On Sun, 4 Dec 2005, Mark Wielaard wrote: >> 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]> >> >> * lib/split-for-gcj.sh: Cut list to 3 package levels deep. > I reversed this (patch attached) and now my build with ulimit -v45 > passes. But the total virtual memory usage didn't drop that much. It was > around 454MB top usage, to 438MB top usage. Build time increased with > several minutes. Maybe this was just the tipping point for your setup? Is it possible that the last Classpath imports caused this to break for me (and others), since we added some new modules? I gave your patch a try on two of my test boxes, and indeed just reverting that one change didn't unbreak the build for me. (I saw, and appreciate, HJ's GNU make patches, but these may take a long time to appear in any official release.) Is there any other way to address the problem during installation? Perhaps by splitting the package set into two partitions and processing these separately or something along these lines? Gerald
Re: default cflags to compile
On 8 Dec 2005, Nuno Lopes gibbered uncontrollably: > I need to generate a gcc binary that will always enable the > -fabi-version=1, because I have a library built with gcc 3.3 and I > need to link with it, but I would like to use gcc 4. The libstdc++ ABI broke between these releases, so unless your library doesn't use libstdc++ at all (somewhat unlikely), there is little point to this.q > Is there a simple way to do this (a configure option,..) ? or do I > need to patch the gcc/c-cppbuiltin.c file to always define > _GXX_ABI_VERSION as 102? The latter, as far as I know. -- `Don't confuse the shark with the remoras.' --- Rob Landley
RFC: REG_LABEL not sufficient, cbranchM4 causes ambiguity
For once, the documentation seems to be most accurate; more
accurate than random comments in the code, of which some
contradicts other code:
@item REG_LABEL
This insn uses @var{op}, a @code{code_label} or a @code{note} of type
@code{NOTE_INSN_DELETED_LABEL}, but is not a
@code{jump_insn}, or it is a @code{jump_insn} that required the label to
be held in a register. The presence of this note allows jump
optimization to be aware that @var{op} is, in fact, being used, and flow
optimization to build an accurate flow graph.
However, for a cbranchsi4, the pattern can look like this:
(define_insn_and_split "cbranch4"
[(set (pc)
(if_then_else
(match_operator
0 "comparison_operator"
[(match_operand:BWDQ 1 "nonimmediate_operand" "")
(match_operand:BWDQ 2 "general_operand" "")])
(label_ref (match_operand 3 "" ""))
(pc)))]
...)
Causing for example in (from gfortran.dg/g77/pr9258.f and with
local CRIS-cc0-removal-changes):
(jump_insn 54 53 56 6 (set (pc)
(if_then_else (eq (reg/v/f:SI 25 [ m.1 ])
(label_ref:SI 0))
(label_ref 33)
(pc))) 1 {cbranchsi4} (nil)
(expr_list:REG_BR_PROB (const_int 1900 [0x76c])
(nil)))
Note *two* labels. One is a jump target, the other is an
operand. So, a JUMP_P can have multiple label references *some
of which are not jump targets*. This causes ambiguity with the
documented (and mostly real) use of REG_LABEL, and of course the
code assumes there are no non-jump-target REG_LABELs in JUMP_P:s.
I could of course "fix" this by disallowing REG_LABELs in
operand 2 in the pattern above, but that'd be like cheating,
giving in to a lame restriction in GCC and proving a
cbranchM4-representation to be lacking by definition with better
expressibility with cc0. Can't do that.
I propose (and will try to) solve this by splitting REG_LABELs
into two types, REG_LABEL_TARGET and REG_LABEL_OPERAND:
Only JUMP_P:s will have REG_LABEL_TARGET notes; those notes
marks its jump targets (perhaps can be only one). As a special
case, the JUMP_LABEL field in a JUMP_P is a short-cut and will
be handled as a first REG_LABEL_TARGET note. It is invalid to
have both JUMP_TARGET being NULL and REG_LABEL_TARGET notes in a
(JUMP_P) insn. A tablejump/casesi will have its JUMP_LABEL set
to the corresponding ADDR_VEC (there can be another
label-ref-target there, in case you think there'll only ever be
the JUMP_TARGET field and no REG_LABEL_TARGET notes).
A JUMP_P using a register for ordinary branches (like on sh64)
will have its JUMP_LABEL pointing to the label loaded in that
register (if it can be identified; it seems it usually can). To
make this work, REG_LABEL_TARGET notes (and the JUMP_LABEL) are
sticky; not removed before each jump pass if the JUMP_P no
longer refer to the label in its body.
Any insn can have REG_LABEL_OPERAND, which marks non-target use,
e.g. &&label operands and branch-target register loads in
non-jumps and the non-jump cbranchM4 (label-ref:SI 0) operand
above. (IIRC the 0 is actually due to the failure I saw.)
REG_LABEL_OPERANDs are regenerated for each jump pass.
A JUMP_P can have REG_LABEL_OPERANDs only for stuff in a
if_then_else condition; everything else is considered a
jump-target.
Or at least that's the definition I currently think (and hope)
will work.
Thoughts?
brgds, H-P
How can I get access to tree representation
I started exploring code base of cc1plus, and now I have little question - how I can get access to tree representation of program (I should do it after gcc/cp/parser.c:cp_parser_translation unit(...), isnt it?) If I wasnt mistaken, RTL began build only if parser says that syntax OK? -- Best regards, Alexander mailto:[EMAIL PROTECTED]
