Re: identifing free() in tree-ssa
* Basile STARYNKEVITCH <[EMAIL PROTECTED]> [070102 22:49]: > Maybe, instead of using built-ins, we could extend the __attribute__ > facility for functions (and expect the libc developers to progressively use > them). Eg > >void free(void*) __attribute((pointer_invalid(1))); > > would mean that argument #1 of function free is pointer which is invalidated > by the function. Or maybe a pragma for that > > Of course, the challenge is then how to have lots of attributes, and not > slow down the compiler... I don't know yet if adding hundreds on definitions > inside gcc/builtin-attrs.def would slow down the compiler. > > IMHO, adding new attributes would permit future library developers to > annotate their header files appropriately. This would be more powerful than > understanding only a given standard symbol like free. Of course, the cost of > attributes is that to use them effectively we depend upon library developers > using them actually in their headers. splint supports this and calls those arguments "only". It has one pitfall, though, which is the realloc function. Realloc can invalidate a pointer or not, and one only knows so when looking at the return value, but I fear this is more than can be dome with simple means. I'm a big fan of such tests on compile time (there are special tools checking, but the more the compiler also does, the better). So if anyone wants to implement something like that (or for example extending checking the non-null attribute to more than rejecting NULL-constants but also variables that are always NULL) and you need testers let me know. Hochachtungsvoll, Bernhard R. Link
Re: Canonical type nodes, or, comptypes considered harmful
* Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]: > This assumes, of course, that we can build an equivalence set for > types. I think that we need to make that work in the middle-end, and > force the front-ends to conform. As someone else mentioned, there are > horrific cases in C like a[] being compatible with both a[5] and a[10] > but a[5] and a[10] not being compatible with each other, and similarly > f() is compatible with f(int) and f(float) but the latter two are not > compatible with each other. Isn't void* and anyothertype* the same case? And how are classes and parent classes made compatible in C++? Is the front end always making a implicit type conversion or are they 'equivalent' in one direction? Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth
Re: Microchip GNU-CC PIC port - script licencing question..
* Dave Korn <[EMAIL PROTECTED]> [060405 16:19]:
> However if Microchip have written their own entirely new linker scripts,
> they hold the copyright and may license them however they please.
Unless they are used to compile the derivative of gcc. If they are they are
most likely "scripts used to control compilation and installation of the
executable" and thus need to be available under GPL-compatible terms.
Hochachtungsvoll,
Bernhard R. Link
Re: RTL alias analysis
* Richard Guenther <[EMAIL PROTECTED]> [060122 14:23]: > [...] The correct solution for converting > a float to an integer (bit-representation) as in the expample is to use > two different memory locations and memcpy (which avoids aliasing > issues by means of using the special rules for access through 'char'). But only in that example. In general memcpy might be optimized to some assignment causing a SIGBUS if gcc thinks it is save but it is not. (like a misaligned pointer to a struct where some member is accessed). Hochachtungsvoll, Bernhard R. Link
Re: -Wuninitialized issues
* Chris Lattner <[EMAIL PROTECTED]> [051102 19:28]:
>
> Jeff Law wrote:
> >> I prefer consistency in warnings, regardless of optimization level.
> >I disagree and I think we have a significant contingency of
> >users that would disagree -- if optimizations allow us to avoid
> >false-positive warnings, then we should use that information to
> >avoid those false positive warnings.
>
> Jeff, I completely agree with you for some class of users (users being
> developers who use GCC but don't hack on GCC itself).
>
> OTOH, there is also a very large class of users (like myself) who have to
> write code that works well across several different compilers. In this
> capacity, having GCC be clever is not a good thing: if GCC is silent where
> a less clever compiler will warn, I will have to fix the warning *anyway*
> and won't know about it until someone else complains (I use GCC as my
> primary development compiler).
Why do you have to do something about a warning that is a clear false
positive?
With code like
if( cond ) {
sav = x;
}
bla;
if( cond )
x = sav;
I'd much prefer a warning about a "may be used uninitialized"
on less clever compiler over the change to lose a "is used unitialized"
warning some future more clever compiler may find if, say, cond is
changed in between. Also placing a unconditional sav=0 before it all
to silence it up I will lose any chance to have this found by valgrind.
> Prior versions of GCC (and most other compilers) assumed that since
> somepredicate is passed the address of X, that it may initialize X, thus
> not emitting a warning at the use site. Newer versions of GCC inline
> somepredicate and then emit a bogus warning: "X" is only assigned to (and
> used) in the case where somepredicate returns true, and GCC loses this
> information (it is probably missing a jump threading opportunity).
While this is surely a regression w.r.t. false positives, I don't see
how this is he result of "more clever", but mostly a side effect of
better inlining that was not followed by making the warning code
better to cope with such inlining.
Hochachtungsvoll,
Bernhard R. Link
Re: Wishlish: GCC option for explicit booleans
* Peter Lupton NCH Swift Sound <[EMAIL PROTECTED]> [051002 05:47]:
> I was hoping was that we could at least have a compile option. So we could
> turn it on if required. I would definitely mandate it in our organization
> at least. I am sure others would too.
I'd looked into getting some boolean checking into the C compiler (I am
personally not that interested in C++), but gcc has this "truthvalues are ints"
quite heavily built in (which is not very suprising, after all the standard says
the are).
Attached is a experimental patch to make the C compiler do boolean checking
by making truthvalues of type bool instead of int and checking for them.
This definitly breaks the standard, as it changed the actual type.
It would be much nicer if there was some kind of "shadow types", that
would be only used for some additional warnings and not for code
generation. That way I think it would still be C standard conform, but
having looked only a very little into the gcc source, I cannot even
guess if it is possible and how much time it would need to implement
that.
While the patch cleary shows my little knowledge of the gcc code, and
switches truthvalue checking on unconditionally (and changes C
semantics, so I really suggest to not use it for anything but type
checking), it found some bugs in code I checked with it. (Which of
course already was written in a way it keeps truthvalues and integers
seperate, such a feature is only sensible if you have such a policy from
the start).
It also has suprisingly few false positives, once one
#define __builtin_expect(a,b) (a)
#define __builtin_constant_p(a) (__builtin_constant_p(a) != 0)
and encapsulates all ctype.h functions...
Hochachtungsvoll,
Bernhard R. Link
Index: gcc/c-common.c
===
RCS file: /cvsroot/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.653
diff -u -r1.653 c-common.c
--- gcc/c-common.c 27 Sep 2005 16:04:06 - 1.653
+++ gcc/c-common.c 2 Oct 2005 12:30:10 -
@@ -2323,6 +2323,10 @@
tree
c_common_truthvalue_conversion (tree expr)
{
+ if (TREE_TYPE (expr) != truthvalue_type_node)
+{
+ warning (0, "Implicit truth value");
+}
switch (TREE_CODE (expr))
{
case EQ_EXPR: case NE_EXPR: case UNEQ_EXPR: case LTGT_EXPR:
Index: gcc/c-decl.c
===
RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.685
diff -u -r1.685 c-decl.c
--- gcc/c-decl.c29 Sep 2005 21:34:24 - 1.685
+++ gcc/c-decl.c2 Oct 2005 12:30:10 -
@@ -2714,10 +2714,11 @@
c_common_nodes_and_builtins ();
- /* In C, comparisons and TRUTH_* expressions have type int. */
- truthvalue_type_node = integer_type_node;
- truthvalue_true_node = integer_one_node;
- truthvalue_false_node = integer_zero_node;
+ truthvalue_type_node = boolean_type_node;
+ /* For this to work, it has to be 0 and 1, which theese are,
+ * but it is a bit ugly that truthvalue is a C frontend speciality */
+ truthvalue_true_node = boolean_true_node;
+ truthvalue_false_node = boolean_false_node;
/* Even in C99, which has a real boolean type. */
pushdecl (build_decl (TYPE_DECL, get_identifier ("_Bool"),
Index: gcc/c-parser.c
===
RCS file: /cvsroot/gcc/gcc/gcc/c-parser.c,v
retrieving revision 2.22
diff -u -r2.22 c-parser.c
--- gcc/c-parser.c 8 Sep 2005 13:09:28 - 2.22
+++ gcc/c-parser.c 2 Oct 2005 12:30:11 -
@@ -4172,7 +4172,7 @@
if (pedantic)
pedwarn ("ISO C forbids omitting the middle term of a ?: expression");
/* Make sure first operand is calculated only once. */
- exp1.value = save_expr (default_conversion (cond.value));
+ exp1.value = save_expr (default_truth_conversion (cond.value));
cond.value = c_objc_common_truthvalue_conversion (exp1.value);
skip_evaluation += cond.value == truthvalue_true_node;
}
@@ -4180,7 +4180,7 @@
{
cond.value
= c_objc_common_truthvalue_conversion
- (default_conversion (cond.value));
+ (default_truth_conversion (cond.value));
skip_evaluation += cond.value == truthvalue_false_node;
exp1 = c_parser_expression_conv (parser);
skip_evaluation += ((cond.value == truthvalue_true_node)
@@ -4425,14 +4425,14 @@
stack[sp].expr
= default_function_array_conversion (stack[sp].expr);
stack[sp].expr.value = c_objc_common_truthvalue_conversion
- (default_conversion (stack[sp].expr.value));
+ (default_truth_conversion (stack[sp].expr.value));
skip_evaluation += stack[sp].expr.value == truthvalue_false_node;
break;
case TRUTH_ORIF_EXPR:
stack[sp].expr
= default_function_array_conversion (stack[sp].expr)
Re: No effect of -fshort-enums..is it a bug
* Andreas Schwab <[EMAIL PROTECTED]> [050921 17:46]: > "Gaurav Gautam, Noida" <[EMAIL PROTECTED]> writes: > > Does -fshort-enum guides the size of enumeration type or the size of > > enumerator constant ? > An enumerator constant is not an object, thus it has no size of its own. > Since the enumerator constants are of type int, not the enum type, > -fshort-enum should not have any effect on their type. I think some warning for this case would be nice. While the value is looks clearly definied, I think almost all cases where this is actually used will be errors. (The same with sizeof(void), which most likely only happens with p=malloc(sizeof(*p)) from macros). Is there already a warning against that (I cannot find any in the info page) or is there any chance to get such a thing implemented? Hochachtungsvoll, Bernhard R. Link
Re: Sine and Cosine Accuracy
* Georg Bauhaus <[EMAIL PROTECTED]> [050530 19:34]: > Programmers write calls to functions named "sin" and "cos" for > reaons of getting a result that is near what the mathematical > model (involving the same names sin and cos) would suggest. > Question is, how and when should GCC enable a programmer to > trigger either library procedures, or procedures built > into the processor. There is no full mathematical trigonometry > inside the processor, and probably not in any T(n) < infty > library function. But there is reason to use either of them > depending on your application. Scott explains. As I stated in my earlier mail, I'm not opposed against some limitation of arguments (2^60 is a large number for me, when it is correctly documented). What I'm arguing against is an argument telling only [0,2\pi] is in any sense of the word 'correct' range for those functions, or in any way sensible range for computations of those. Code like "if( x+y < 2*pi) return sin(x+y); else return(x+y-2*pi);" would really be useable to make me run around screaming, but naming any range smaller than some [-50pi,100pi] "valid" could really make me crazy... Bernhard R. Link
Re: Sine and Cosine Accuracy
* Georg Bauhaus <[EMAIL PROTECTED]> [050529 20:53]: > By "real circle" I mean a thing that is not obfuscated by the useful > but strange ways in which things are redefined by mathematicians; > cf. Halmos for some humor. Sorry, but sin and cos are mathematical functions. If you want to invent some predating functions, given them other names. There might be some use in having computational functions not working in every range (as all computation by computers is somehow limited), but 0..2pi is definitly too limited. As going-to-be mathematican I could not even imagine before this discussion that someone might limit it that much. Breaking things like sin(-x) or sin(x+y) will definitly hurt people, because it is natural to expect this to work. > And yes, I know that all the other stuff mentioned in this thread > explains very well that there exist useful definitions of sine for real > numbers outside "(co)sine related ranges", and that these definitions > are frequently used. What are "(co)sine related ranges", if I may ask? Have you any sane definiton than 'values in a range I personaly like'? Bernhard R. Link
