Re: 64-Bit Operator Overloading Adventure
On Fri, 11 Jan 2008 09:59:41 -0800, Brian D. McGrew wrote: >We're trying to move to 64-Bit now and this same code that has compiled > for years is barking about operators cannot be overloaded. Please stick to gcc-help, as gcc is the wrong list for such questions. Philipp
Re: How to stop gcc from not calling noinline functions
On Sat, Jan 12, 2008 at 07:20:03AM +0100, Hans-Peter Nilsson wrote: > Or, another attribute. Name? Maybe "always_extern", but I'm > not sure that's as intuitive and obvious as "noinline". I don't > like the perhaps immediately obvious "always_call", because I > think the calls should be deleted if the call-site is dead, just > not for reasons found out from analysis of the called function, > and the name suggests otherwise (alternatively, an implementation > to stop dead-code elimination would be troublesome and useless. :) volatile. That seems to express exactly the right spirit: you can dead-code-eliminate it, but if you don't, call it exactly as the source code suggests. I don't know if the language standards already associate an incompatible meaning to it in this context; if so, just define an attribute with that name.
Re: -Wparentheses lumps too much together
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I'm inclined to approve this if -Wprecedence stays in -Wall, but I'd > like to hear if anybody else has anything to say. The name of the option is rather poor, IMHO. -Wparentheses warns about precedences, so what is the difference to -Wprecedence? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: How to stop gcc from not calling noinline functions
(Yeah, new attributes "impure" and/or "nonconst" would solve this, but only for IPA and there's already the existing option and asm I mentioned. And if you say different files/compilation units, I say LTO.) I think the asm is your best bet. Paolo
Re: -Wparentheses lumps too much together
Andreas Schwab wrote: Ian Lance Taylor <[EMAIL PROTECTED]> writes: I'm inclined to approve this if -Wprecedence stays in -Wall, but I'd like to hear if anybody else has anything to say. The name of the option is rather poor, IMHO. -Wparentheses warns about precedences, so what is the difference to -Wprecedence? -Wparentheses warns in general about things that the GCS prefer to be parenthesized. I would prefer something like int warn_precedence = 2; ... if (warn_precedence == 2) warn_precedence = warn_parentheses; that is, we have -Wparentheses remains as is now, and is enabled by -Wall -Wparentheses -Wno-precedence only warns about things like a = b = c for bool b and non-bool a Paolo
Re: How to stop gcc from not calling noinline functions
On Jan 12, 2008 7:20 AM, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote:
> Also known as "nooo, it's not *inlined*, it's just the call
> being removed because the called function was found to be
> pure/const". :)
>
> This happens when you try to synthesize executable test-cases
> and you need e.g. a call with such-and-such parameters, but the
> called function doesn't do anything; it's the caller you care
> about. You need the call, and can't just leave the called
> function undefined. But such a stub function called in the same
> compilation unit, may surprisingly not be called, *even if you
> declare it __attribute ((__noinline__))*, and when you look at
> *just* the call site, the cause is not just that the call is
> dead as-is. It's a bit confusing until you remember or are
> being told that all functions are analyzed for pure-or-constness
> and the noinline attribute doesn't have say in what happens
> next. The remedy is -fno-ipa-pure-const or sticking a naked
> asm ("") in the stub function. At least, that works for now.
>
> I'm testing the waters for a more well-defined solution. IMHO a
> construct is needed for e.g. such test-cases to stand more of a
> chance to not turn into NOPs with the next smart
> not-inlined-but-you-can't-tell-the-difference optimization.
> There appears to be a use for this in the Linux kernel too
> (kprobe?), and there's a (timing) use case in PR 16922 too. If
> you agree, how should it be done?
>
> Redefine the noinline attribute to also stop gcc from analyzing
> such functions and "keep them called" (my favorite, because as a
> user, you can't really tell the call-removed effect apart from
> being-inlined).
No. ;)
> Or, another attribute. Name? Maybe "always_extern", but I'm
> not sure that's as intuitive and obvious as "noinline". I don't
> like the perhaps immediately obvious "always_call", because I
> think the calls should be deleted if the call-site is dead, just
> not for reasons found out from analysis of the called function,
> and the name suggests otherwise (alternatively, an implementation
> to stop dead-code elimination would be troublesome and useless. :)
>
> Or, just make "noinline" functions that are also "extern" stay
> extern and called.
>
> (Yeah, new attributes "impure" and/or "nonconst" would solve
> this, but only for IPA and there's already the existing option
> and asm I mentioned. And if you say different files/compilation
> units, I say LTO.)
You can apart from the other suggestions also mark the function weak
which will prevent both inlining and pure/const analysis.
Richard.
> brgds, H-P
>
Re: Math library for Alpha Tru64
Adrián Bravo Navarro writes: > I come to you looking for some light ;) We are developing an > application that needs to link statically math.h. I've been looking > for libm.a for Tru64 Alpha with no success at all. System comes > with .so so but i think it's not possible converting .so into .a > Any help is welcome. Two obervations: libm.a is provided by libc, not by gcc. If you need to link statically with libm on a system that deliberately doesn't provide it, you are doing something very wrong. Having said all that, are you absolutely sure there isn't a developer library that contains libm.a that you haven't installed? OS vendors typically put static archives in separate packages. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 11/01/2008, Mark Mitchell wrote:
>
> Exactly so. I think that we have two kinds of pedwarns: those that are
> pedantic in the sense we use for C (like, that there cannot be a naked
> semicolon at the top-level of a file, or that "long long" is not in
> C++98) and those that refer to semantically reasonable constructs that
> we previously accepted, often because they were allowed by cfront or the
> ARM. With flag_permissive, we probably want the latter category to be
> warnings at most; without flag_permissive, we want them to be errors.
I'll start the ball rolling with cp/call.c, cp/class.c and cp/cvt.c
I'll call the latter category isowarns for the purpose of this mail,
they are technically illegal constructs that are errors without
-fpermissive. My suggestion of pedwarn/isowarn given in capitals on
each entry.
call.c:3258 build_conditional_expr PEDWARN
"ISO C++ forbids omitting the middle term of a ?: expression."
GNU extension, currently allowed unless -pedantic.
call.c:3867 build_new_op ISOWARN
"no 'operator++(int)' declared for postfix '++', trying prefix operator instead"
This should not be accepted without -fpermissive
call.c:4352 convert_like_real ISOWARN
pedwarn ("invalid conversion from %qT to %qT", TREE_TYPE (expr), totype);
if (fn)
pedwarn (" initializing argument %P of %qD", argnum, fn);
Not sure about this one ... isowarn I think.
call.c:4953 build_over_call ISOWARN
"passing 'const X' as 'this' argument of 'void X::f()' discards qualifiers"
call.c:6463 joust PEDWARN
"ISO C++ says that these are ambiguous, even though the worst
conversion for the first is better than the worst conversion for the
second:"
GNU extension, currently entirely disallowed by -pedantic, otherwise pedwarn.
I think that's OK.
class.c:2483 finish_struct_anon ISOWARN
""%q+#D invalid; an anonymous struct can only have non-static data members"
"private member %q+#D in anonymous struct"
(and similarly for anonymous unions adn protected members)
Not sure how to trigger this, but I don't think is is intended as a
GNU extension so should require -fpermissive
class.c:3037 check_field_decls ISOWARN
"field 'int S::S' with same name as class"
class.c:5995 resolve_address_of_overloaded_function ISOWARN
"assuming pointer to member %qD (a pointer to member can only be
formed with %<&%E%>)"
class.c:6358 note_name_declared_in_class ISOWARN
"declaration of 'i'
changes meaning of 'i' from ' i'"
cvt.c:382 warn_ref_binding ISOWARN
"initialization of non-const reference type %q#T from rvalue of type %qT"
cvt.c:452 convert_to_reference ISOWARN
"conversion from %qT to %qT discards qualifiers"
cvt.c:656 ocp_convert ISOWARN
"conversion from %q#T to %q#T"
cvt.c:902 convert_to_void ???
"statement cannot resolve address of overloaded function"
Shouldn't this be a hard error? What benefit is there to allowing
this with -fpermissive?
Jon
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 11/01/2008, Mark Mitchell wrote:
> >
> > Exactly so. I think that we have two kinds of pedwarns: those that are
> > pedantic in the sense we use for C (like, that there cannot be a naked
> > semicolon at the top-level of a file, or that "long long" is not in
> > C++98) and those that refer to semantically reasonable constructs that
> > we previously accepted, often because they were allowed by cfront or the
> > ARM. With flag_permissive, we probably want the latter category to be
> > warnings at most; without flag_permissive, we want them to be errors.
>
> I'll start the ball rolling with cp/call.c, cp/class.c and cp/cvt.c
> I'll call the latter category isowarns for the purpose of this mail,
> they are technically illegal constructs that are errors without
> -fpermissive. My suggestion of pedwarn/isowarn given in capitals on
> each entry.
>
Here is an initial patch implementing some of your proposals. I used
pederror as the name of the function. That is, it is an error unless
fpermissive is given.
Let me know your opinion. (Not bootstrapped, not tested, not complete patch).
Cheers,
Manuel.
Index: gcc/diagnostic.c
===
--- gcc/diagnostic.c (revision 131405)
+++ gcc/diagnostic.c (working copy)
@@ -538,15 +538,36 @@ pedwarn (const char *gmsgid, ...)
diagnostic_info diagnostic;
va_list ap;
va_start (ap, gmsgid);
diagnostic_set_info (&diagnostic, gmsgid, &ap, input_location,
+ pedantic_warning_kind ());
+ report_diagnostic (&diagnostic);
+ va_end (ap);
+}
+
+/* A "pedantic" error: issues an error unless -fpermissive was
+ given on the command line, in which case it issues a warning. Use
+ this for things that really should be errors but we want to support legacy code.
+
+ Note that these diagnostics are issued independent of the setting
+ of the -pedantic command-line switch. To get an error enabled
+ only with that switch, write "if (pedantic) pederror (...);" */
+void
+pederror (const char *gmsgid, ...)
+{
+ diagnostic_info diagnostic;
+ va_list ap;
+
+ va_start (ap, gmsgid);
+ diagnostic_set_info (&diagnostic, gmsgid, &ap, input_location,
pedantic_error_kind ());
report_diagnostic (&diagnostic);
va_end (ap);
}
+
/* A hard error: the code is definitely ill-formed, and an object file
will not be produced. */
void
error (const char *gmsgid, ...)
{
Index: gcc/diagnostic.h
===
--- gcc/diagnostic.h (revision 131405)
+++ gcc/diagnostic.h (working copy)
@@ -48,11 +48,12 @@ typedef struct diagnostic_info
diagnostic_t kind;
/* Which OPT_* directly controls this diagnostic. */
int option_index;
} diagnostic_info;
-#define pedantic_error_kind() (flag_pedantic_errors ? DK_ERROR : DK_WARNING)
+#define pedantic_warning_kind() (flag_pedantic_errors ? DK_ERROR : DK_WARNING)
+#define pedantic_error_kind() (flag_permissive ? DK_WARNING : DK_ERROR)
/* Forward declarations. */
typedef struct diagnostic_context diagnostic_context;
typedef void (*diagnostic_starter_fn) (diagnostic_context *,
Index: gcc/toplev.h
===
--- gcc/toplev.h (revision 131405)
+++ gcc/toplev.h (working copy)
@@ -60,10 +60,11 @@ extern void warning0 (const char *, ...)
extern void warning (int, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
extern void error (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
extern void fatal_error (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2)
ATTRIBUTE_NORETURN;
extern void pedwarn (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
+extern void pederror (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
extern void sorry (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
extern void inform (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
extern void verbatim (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
extern void rest_of_decl_compilation (tree, int, int);
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c (revision 131405)
+++ gcc/cp/decl.c (working copy)
@@ -6981,16 +6981,11 @@ compute_array_index_type (tree name, tre
/* Normally, the array-bound will be a constant. */
if (TREE_CODE (size) == INTEGER_CST)
{
/* Check to see if the array bound overflowed. Make that an
error, no matter how generous we're being. */
- int old_flag_pedantic_errors = flag_pedantic_errors;
- int old_pedantic = pedantic;
- pedantic = flag_pedantic_errors = 1;
- constant_expression_warning (size);
- pedantic = old_pedantic;
- flag_pedantic_errors = old_flag_pedantic_errors;
+ constant_expression_error (size);
/* An array must have a positive number of elements. */
if (INT_CST_LT (size, integer_zero_node))
{
if (name)
Index: gcc/cp/call.c
===
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > Here is an initial patch implementing some of your proposals. I used > pederror as the name of the function. That is, it is an error unless > fpermissive is given. Ah, very fast! :-) I was just starting somethign similar, I provisionally used the name permerror, with this comment: /* A conformance error: issues an error unless -fpermissive was given on the command line, in which case it issues a warning. Use this for diagnostics required by the relevant language standard, but which need to be downgradable for non-conformant code. */ void permerror (const char *gmsgid, ...) I don't think the name should involve "ped" or pedantic, since it's not related to -pedantic, the semantics are those described by the -fpermissive docs: -fpermissive Downgrade some diagnostics about nonconformant code from errors to warnings. Thus, using -fpermissive will allow some nonconforming code to compile. These errors should be independent of -pedantic* unless the if (pedantic) check is also present in the code, but that's a special case. Have I understood the intention correctly? I think the name matters, otherwise you will have to write more long mails explaining why the semantics don't match the name :-) (thanks for those mails btw, they helped me a lot) I don't really like the name permerror either though, relaxable_error is accurate but not great either. Thanks for doing this - I agree with your other decisions about what should be a pedward or a pederror/whatever in e.g. lex.c and parser.c Jon
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote: > On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > > > Here is an initial patch implementing some of your proposals. I used > > pederror as the name of the function. That is, it is an error unless > > fpermissive is given. > > These errors should be independent of -pedantic* unless the if > (pedantic) check is also present in the code, but that's a special > case. Have I understood the intention correctly? Actually, I didn't understand that we wanted to separate fpermissive and pedantic-errors completely. (Notice that the internal declaration/definition of fpermissive actually mentions pedantic.) But I agree with you: they should be unrelated. > I don't really like the name permerror either though, relaxable_error > is accurate but not great either. I actually like permerror better than the alternative permissive_error. I think those two are the only ones that make sense. > Thanks for doing this - I agree with your other decisions about what > should be a pedward or a pederror/whatever in e.g. lex.c and parser.c Your information above was very helpful. But I am still not sure about the rest of pedwarns. Cheers, Manuel.
