Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 7:13 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: * In C a const variable which is neither extern nor static is visible outside of the current translation unit. In C++ it is not, without an explicit extern declaration. I'm not sure how best to handle this with -Wc++-compat, since C does not permit initializing an extern const variable. C does permit it; there's a warning, not a pedwarn. Add an option to disable this warning (at least where const is used)? In any case, -Wc++-compat should warn about the difference in behaviour, shouldn't it? I see the current code already handles this somehow: /* It is fine to have 'extern const' when compiling at C and C++ intersection. */ if (!(warn_cxx_compat constp)) warning (0, %qs initialized and declared %extern%, name); BTW, why is this warned about? I believe I'm the author of that code. We had had this debate a couple of years back, when I had more resources to work on GCC. At the time, I was doing an incremental version of the amazing job Ian just accomplished and the CPP component had the construct that declared a variable as const but did not initialize it, and did not contain the `extern' specifier. That in C++ meant that the variable has an internal linkage -- but in C, the variable would have an external linkage. So, to write the code that meant the same thing in C and in C++, an 'extern' specifier is needed. The C people (I bellieve) at the time felt strongly that if not -Wc++-compat it probably should be warned about (because it is not typical C). -- Gaby
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 8:42 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, If one wants to use the same code in C and C++, then it is definitely a spurious warning in my opinion. I do not understand your reasoning. -- Gaby
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 10:19 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: 2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, int i; is not the same as extern int i;. Sorry for my ignorance but I have been reading and searching for the answer and I cannot tell what is the difference between int i = 1 and extern int i = 1 at file-scope in C. Would you or someone else mind to point me out to the answer? Thanks in advance. I suspect you wanted to know the difference between const int i; and extern const int; at file scope. Manuel.
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 10:54 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: 2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: 2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, int i; is not the same as extern int i;. Sorry for my ignorance but I have been reading and searching for the answer and I cannot tell what is the difference between int i = 1 and extern int i = 1 at file-scope in C. I did not say those were different, I said the uninitialized case was different, so extern is implicit if missing is not a general C rule. OK, then. I assumed that we were discussing about the initialized case, which is the origin of this thread. Hence, my suggestion stands: get rid of the warning. I do not follow your reasoning here. BTW, I already the history of the warning. -- Gaby
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 9:39 AM, Ian Lance Taylor i...@google.com wrote:
I've finished my set of patches which fix -Wc++-compat to check for enum
conversions which are valid in C++. Adding those checks forced a lot of
changes in mainline to compile cleanly with -Wc++-compat. I have merged
those changes over to the gcc-in-cxx branch. In the gcc directory
itself, excluding changes to configure and Makefile, the gcc-in-cxx
branch compared to mainline is now
113 files changed, 1558 insertions(+), 1241 deletions(-)
Some of the remaining issues:
* C permits using the ++ and -- operators with a variable of enum type.
C++ does not (unless you explicit declare the operators, which for
purposes of -Wc++-compat I think we can assume to not occur).
* C permits defining a struct/enum/union within a struct/union and then
referring to the inner struct/enum/union outside of the enclosing
struct/union. C++ does not permit this--in C++ it has to be public
and you have to use a scope qualifier.
* C permits struct s { }; typedef int s;. That is, you may reuse a
name as both a struct/enum/union tag and as a type. C++ does not
permit this.
* The C++ frontend warns about while (true); when there is no
whitespace between the ')' and the ';'. The C frontend does not. I'm
not sure how to best handle this. It doesn't make much sense to warn
about this with -Wc++-compat. Should the C frontend warn about this?
Should the C++ frontend not warn about this? Any opinions?
The C frontend should warn about this as well.
* In C an externally visible inline function (i.e., not extern, not
static) is assumed to be accessible outside of the current
translation unit (e.g., vn_nary_op_compute_hash in
gcc/tree-ssa-sccvn.c). In C++ this is not the case. It is also not
the case in C99, so this should be addressed anyhow, somehow, although
it doesn't seem to be a good fit for -Wc++-compat.
Right. Just fix it.
* In C a const variable which is neither extern nor static is
visible outside of the current translation unit. In C++ it is not,
without an explicit extern declaration. I'm not sure how best to
handle this with -Wc++-compat, since C does not permit initializing an
extern const variable.
Does putting an extern const declaration in addition to the const
definition work in C and C++? If so you could warn about a
missing declaration just like we do for missing prototypes.
* The C++ frontend does not support __attribute__ ((unused)) on labels.
The generator programs produce a lot of unused labels. Fixing this in
the C++ frontend may be awkward because C++ syntax permits a
declaration to follow a label, so it may not be clear which one gets
the attribute.
* The C++ frontend emits some warnings on code which is known to be
never executed, which the C frontend does not. This leads to some
warnings compiling code in gcc. I think it is reasonable to fix this
in the C++ frontend.
Or just amend the C frontend to also warn in these cases?
Richard.
Ian
Re: gcc-in-cxx update / multi-targeted gcc
In order to be able to use namespaces in my endeavour to support gcc with multiple targets, I've first done a merge from the gcc-in-cxx branch. For my initial implementation, I choose as configuration --target=m32r-elf --with-extra-target-list='sh64-elf arc-elf32' . I've found some issues with gcc-in-cxx both specific to these targets, and specific to (parts of) compiler passes that are only compiled for a subset of all tagets, which include one or more of the above mentioned three. You can find these in the branch: svn//gcc.gnu.org/svn/gcc/branches/multi-target-4_4-branch So far, I have only made gcc-in-cxx related and a few general checkins there. I haven't got to the stage where I could link the multi-targetted gcc together - it's still missing stuff like target option related variables. However, I have already noticed that you are pushing the target vector in a nonsentical direction: you are using target-specific enums, like enum reg_class . We can't have the target vector refer to these enums, since they are different for each target. Something which I miss in C++ is a way to declare that a function uses an integral type to pass an enum value (in arguments or return value), and then at function definition time only check that the integral type is sufficently large to hold the enum, and then for type checking purposes treat the parameter / return value as if it had been declared as this enum. FWIW, the target vector is more an obstruction than a help to make gcc multi-targeted. macros that change the way an rtl optimization pass work just fine - I then end up with different versions of the rtl optimization pass in different namespaces, which are accessed by pass lists which are initialized by code living in the same name space. My plan (I haven't started implementing this yet) for enum machine_mode is to have each number denote a mode with the same number of bits and mode class on all configured targets on which they denote a usable mode. I'm not sure yet if it will be helpful to diable modes not usable on a target by making them MODE_RANDOM. What are your thoughts on using gcc extensions for gcc-in-cxx ? We can work around the enum issues by liberally sprinkling casts all over the code, but we are really working against the language there. We could try to implement en extension to describe integral types used to pass enums, where the enums only need an unqualified name match. E.g. we could have: typedef int enum_reg_class __attribute__ ((enum (reg_class)); and have that be compatible with mips::enum reg_class for a funtion definition in the mips namespace, with spu::enum reg_class for a function definition in the spu namespace, and with plain enum reg_class anywhere. Another enum problem is enum attr_cpu / enum processor_type in the sh machine description. We need a variable (sh_cpu aka sh_cpu_attr) with this type to be visible inside the attributes generated by genattrtab. Choices to solve these kind of problems would be: - introduce another target header which is guaranteed to be included only after enum definitions from generator files are in effect. - allow the gcc extension of statement expressions to be used in target descriptions, so that a macro could provide an extern declaration of a variable before using its value.
Re: gcc-in-cxx update
On Wed, 29 Apr 2009, Ian Lance Taylor wrote: * The C++ frontend warns about while (true); when there is no whitespace between the ')' and the ';'. The C frontend does not. I'm not sure how to best handle this. It doesn't make much sense to warn about this with -Wc++-compat. Should the C frontend warn about this? Should the C++ frontend not warn about this? Any opinions? I consider this whitespace-sensitive warning very dubious. * In C a const variable which is neither extern nor static is visible outside of the current translation unit. In C++ it is not, without an explicit extern declaration. I'm not sure how best to handle this with -Wc++-compat, since C does not permit initializing an extern const variable. C does permit it; there's a warning, not a pedwarn. Add an option to disable this warning (at least where const is used)? -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 29 Apr 2009, Joern Rennecke wrote: What are your thoughts on using gcc extensions for gcc-in-cxx ? I believe we agreed in a previous discussion to aim for building with the intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including making sure at an appropriate point that it builds with a non-GCC compiler, probably an EDG-based one such as the Intel compiler). Though bearing in mind that PPL doesn't build with GCC before 4.0, the GCC version required for building with GCC might increase (though I think increasing beyond 4.1 would be a bad idea for some time yet). -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update / multi-targeted gcc
Quoting Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Joern Rennecke wrote: What are your thoughts on using gcc extensions for gcc-in-cxx ? I believe we agreed in a previous discussion to aim for building with the intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including making sure at an appropriate point that it builds with a non-GCC compiler, probably an EDG-based one such as the Intel compiler). Though bearing in mind that PPL doesn't build with GCC before 4.0, the GCC version required for building with GCC might increase (though I think increasing beyond 4.1 would be a bad idea for some time yet). I think we should distinguish here between the language we want to support for bootstrapping versus the language we want to be use for builds in general to allow convenient type checking, and to support configurations that are not essential for bootstrapping, like ones with multiple target architectures. When compiling for a single target, we could still use standard enums in the interface even where the enums are target dependent. Although that defeats the purpose of the target vector (it is not interchangeable with any other target vector), it allows you to bootstrap the compiler, and then you can use that compiler to build a multi-targeted gcc which requires the gcc extension. For the generated-enum-in-macro problem, we could use a plain integral type as the variable type and a cast to the enum when reading as a fallback mechanism. But allowing the statement expression for gcc would give better type checking.
Re: gcc-in-cxx update
2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Ian Lance Taylor wrote: * The C++ frontend warns about while (true); when there is no whitespace between the ')' and the ';'. The C frontend does not. I'm not sure how to best handle this. It doesn't make much sense to warn about this with -Wc++-compat. Should the C frontend warn about this? Should the C++ frontend not warn about this? Any opinions? I consider this whitespace-sensitive warning very dubious. So would you like it if it were not sensitive to whitespace? (It could be silenced by while(true) (void)0;) I think the point is more whether the warning itself is useful or not. * In C a const variable which is neither extern nor static is visible outside of the current translation unit. In C++ it is not, without an explicit extern declaration. I'm not sure how best to handle this with -Wc++-compat, since C does not permit initializing an extern const variable. C does permit it; there's a warning, not a pedwarn. Add an option to disable this warning (at least where const is used)? In any case, -Wc++-compat should warn about the difference in behaviour, shouldn't it? I see the current code already handles this somehow: /* It is fine to have 'extern const' when compiling at C and C++ intersection. */ if (!(warn_cxx_compat constp)) warning (0, %qs initialized and declared %extern%, name); BTW, why is this warned about? Cheers, Manuel.
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 29 Apr 2009, Joern Rennecke wrote: Quoting Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Joern Rennecke wrote: What are your thoughts on using gcc extensions for gcc-in-cxx ? I believe we agreed in a previous discussion to aim for building with the intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including making sure at an appropriate point that it builds with a non-GCC compiler, probably an EDG-based one such as the Intel compiler). Though bearing in mind that PPL doesn't build with GCC before 4.0, the GCC version required for building with GCC might increase (though I think increasing beyond 4.1 would be a bad idea for some time yet). I think we should distinguish here between the language we want to support for bootstrapping versus the language we want to be use for builds in general to allow convenient type checking, and to support configurations that are not essential for bootstrapping, like ones with multiple target architectures. The question is not just one for bootstrapping a native compiler but also one of what compiler can be used to build a cross compiler (such as that with multiple targets), which is not bootstrapped in the usual GCC sense. There we presently document GCC 2.95 or later as required (and again I think requiring a version later than 4.1 would be a bad idea). -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 2009-04-29 at 13:21 +, Joseph S. Myers wrote: On Wed, 29 Apr 2009, Joern Rennecke wrote: Quoting Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Joern Rennecke wrote: What are your thoughts on using gcc extensions for gcc-in-cxx ? I believe we agreed in a previous discussion to aim for building with the intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including making sure at an appropriate point that it builds with a non-GCC compiler, probably an EDG-based one such as the Intel compiler). Though bearing in mind that PPL doesn't build with GCC before 4.0, the GCC version required for building with GCC might increase (though I think increasing beyond 4.1 would be a bad idea for some time yet). I think we should distinguish here between the language we want to support for bootstrapping versus the language we want to be use for builds in general to allow convenient type checking, and to support configurations that are not essential for bootstrapping, like ones with multiple target architectures. The question is not just one for bootstrapping a native compiler but also one of what compiler can be used to build a cross compiler (such as that with multiple targets), which is not bootstrapped in the usual GCC sense. There we presently document GCC 2.95 or later as required (and again I think requiring a version later than 4.1 would be a bad idea). GCC (at least, the C port of it) is supposed to be compilable with any ISO C90 compiler; when did this change? Or are you saying that if you are using GCC you need at least 2.95. R.
Re: gcc-in-cxx update
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: 2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Ian Lance Taylor wrote: * The C++ frontend warns about while (true); when there is no whitespace between the ')' and the ';'. The C frontend does not. I'm not sure how to best handle this. It doesn't make much sense to warn about this with -Wc++-compat. Should the C frontend warn about this? Should the C++ frontend not warn about this? Any opinions? I consider this whitespace-sensitive warning very dubious. So would you like it if it were not sensitive to whitespace? (It could be silenced by while(true) (void)0;) I think the point is more whether the warning itself is useful or not. I don't know the rationale for this warning. Is it to do with the C++0x specification that certain loops may be assumed to terminate? I see the current code already handles this somehow: /* It is fine to have 'extern const' when compiling at C and C++ intersection. */ if (!(warn_cxx_compat constp)) warning (0, %qs initialized and declared %extern%, name); BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 29 Apr 2009, Richard Earnshaw wrote: The question is not just one for bootstrapping a native compiler but also one of what compiler can be used to build a cross compiler (such as that with multiple targets), which is not bootstrapped in the usual GCC sense. There we presently document GCC 2.95 or later as required (and again I think requiring a version later than 4.1 would be a bad idea). GCC (at least, the C port of it) is supposed to be compilable with any ISO C90 compiler; when did this change? Or are you saying that if you are using GCC you need at least 2.95. If you are building a non-C front end without bootstrapping you need at least 2.95: To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. (for Ada you need at least 3.4 whether building a cross compiler or bootstrapping and there's a recommendation to use the same version for building a cross compiler). -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update
2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: I don't know the rationale for this warning. Is it to do with the C++0x specification that certain loops may be assumed to terminate? I guess the rationale is that there is little use for while(true) ; so it is probably an unintended mistake. I think in this trivial case we should warn always (in C and C++), whitespace or not (it may come from a strange macro expansion). BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, If one wants to use the same code in C and C++, then it is definitely a spurious warning in my opinion. Cheers, Manuel.
Re: gcc-in-cxx update
Joseph S. Myers wrote:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
* The C++ frontend warns about while (true); when there is no
whitespace between the ')' and the ';'. The C frontend does not. I'm
not sure how to best handle this. It doesn't make much sense to warn
about this with -Wc++-compat. Should the C frontend warn about this?
Should the C++ frontend not warn about this? Any opinions?
I consider this whitespace-sensitive warning very dubious.
So would you like it if it were not sensitive to whitespace?
(It could be silenced by while(true) (void)0;)
I think the point is more whether the warning itself is useful or not.
I don't know the rationale for this warning. Is it to do with the C++0x
specification that certain loops may be assumed to terminate?
I think the rationale is to capture this mistake:
for(...);
{
}
Microsoft's compiler has a similar warning, but stricter: it doesn't
care about whitespace, and the only way to get a warning-free empty loop
is to give it an empty compound statement as the body.
So MSC will warn about this construct, but GCC will not, due to its
whitespace rule:
for(...)
;
Sebastian
Re: gcc-in-cxx update
2009/4/29 Sebastian Redl sebastian.r...@getdesigned.at: So MSC will warn about this construct, but GCC will not, due to its whitespace rule: I think we should just remove the whitespace rule and implement the warning in C. Cheers, Manuel.
Re: gcc-in-cxx update
Richard Guenther richard.guent...@gmail.com writes: * The C++ frontend emits some warnings on code which is known to be never executed, which the C frontend does not. This leads to some warnings compiling code in gcc. I think it is reasonable to fix this in the C++ frontend. Or just amend the C frontend to also warn in these cases? We could do that, but we would have to adjust gcc's code base to avoid the warnings. For example, in insn-modes.c we emit code like this: #define MODE_MASK(m) \ ((m) = HOST_BITS_PER_WIDE_INT) \ ? ~(unsigned HOST_WIDE_INT) 0 \ : ((unsigned HOST_WIDE_INT) 1 (m)) - 1 MODE_MASK (0), /* VOID */ With the current C++ frontend, this issues a warning about a shift larger than the word size. The C frontend sees that the condition is a constant, so it does not issue any warnings about the unexecuted side of the conditional. This is done by manipulating skip_evaluation in c_parser_conditional_expression and testing it in build_binary_op. Ian
Re: gcc-in-cxx update / multi-targeted gcc
Joern Rennecke amyl...@spamcop.net writes: I've found some issues with gcc-in-cxx both specific to these targets, and specific to (parts of) compiler passes that are only compiled for a subset of all tagets, which include one or more of the above mentioned three. I'd be happy to see and approve your patches. Several people have made changes to the gcc-in-cxx branch. Just send them to gcc-patches as usual with [gcc-in-cxx] in the Subject. However, I have already noticed that you are pushing the target vector in a nonsentical direction: you are using target-specific enums, like enum reg_class . We can't have the target vector refer to these enums, since they are different for each target. I'm not sure why you are singling me out. I only added one use of enum reg_class to the target vector; there were already two other uses of enum reg_class, and many uses of enum machine_mode. If we decide that a multi-targeted gcc is a goal we want to support, it's certainly fine with me to change those enums to int and add casts where appropriate. (I'm not personally convinced that a multi-targeted gcc is particularly useful, though I don't object if there is a general desire to support it.) Something which I miss in C++ is a way to declare that a function uses an integral type to pass an enum value (in arguments or return value), and then at function definition time only check that the integral type is sufficently large to hold the enum, and then for type checking purposes treat the parameter / return value as if it had been declared as this enum. FWIW, the target vector is more an obstruction than a help to make gcc multi-targeted. macros that change the way an rtl optimization pass work just fine - I then end up with different versions of the rtl optimization pass in different namespaces, which are accessed by pass lists which are initialized by code living in the same name space. It is perhaps worth noting that the natural way to handle the target vector in C++ is to make a Target class with a set of virtual methods. Then methods like eh_return_filter_mode would use a covariant return type in specific implementations. Where the mode is a parameter it would still have to be changed to int. My plan (I haven't started implementing this yet) for enum machine_mode is to have each number denote a mode with the same number of bits and mode class on all configured targets on which they denote a usable mode. I'm not sure yet if it will be helpful to diable modes not usable on a target by making them MODE_RANDOM. I suspect that would indeed be the best approach for machine_mode in a multi-targeted gcc. What are your thoughts on using gcc extensions for gcc-in-cxx ? We can work around the enum issues by liberally sprinkling casts all over the code, but we are really working against the language there. We could try to implement en extension to describe integral types used to pass enums, where the enums only need an unqualified name match. E.g. we could have: typedef int enum_reg_class __attribute__ ((enum (reg_class)); and have that be compatible with mips::enum reg_class for a funtion definition in the mips namespace, with spu::enum reg_class for a function definition in the spu namespace, and with plain enum reg_class anywhere. I think you need to take a step back. What is a natural way to represent a register class in the machine independent code when writing in C++? I don't think it is to use an enum type. A register class is basically an object which implements methods like bool is_regno_in_class(unsigned int); HARD_REG_SET registers_in_class(); bool equals(Reg_class); bool is_superset_of(Reg_class); bool is_subset_of(Reg_classS); Obviously that is a long way off in gcc. But I don't see any need to add new features to the C++ frontend to support a style of programming which is inappropriate for C++. We can just convert between int and the enum types for now. Another enum problem is enum attr_cpu / enum processor_type in the sh machine description. We need a variable (sh_cpu aka sh_cpu_attr) with this type to be visible inside the attributes generated by genattrtab. Choices to solve these kind of problems would be: - introduce another target header which is guaranteed to be included only after enum definitions from generator files are in effect. - allow the gcc extension of statement expressions to be used in target descriptions, so that a macro could provide an extern declaration of a variable before using its value. A simple approach would be to have a way to say that the enum values for an attribute were already declared. Then instead of listing the values in the define_attr, we would just have a standard mapping from constants of the attribute to the enum names to use. We would have less error checking in the generator programs, but the errors would be caught when the generated code was compiled. Ian
Re: gcc-in-cxx update
Manuel López-Ibáñez lopeziba...@gmail.com writes: 2009/4/29 Sebastian Redl sebastian.r...@getdesigned.at: So MSC will warn about this construct, but GCC will not, due to its whitespace rule: I think we should just remove the whitespace rule and implement the warning in C. Actually it appears that the whitespace rule was already removed from the C++ frontend in PR 36478. So this may be a non-issue for gcc-in-cxx. Ian
Re: gcc-in-cxx update
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, int i; is not the same as extern int i;. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 29 Apr 2009, Ian Lance Taylor wrote: (I'm not personally convinced that a multi-targeted gcc is particularly useful, though I don't object if there is a general desire to support it.) I think the cleanups involved in using the target vector / class more, and other cleanups involved in the natural approach to multi-target GCC of which the target vector is a part, are more useful than the end result (for which compiling large parts of the compiler multiple times is an interesting approach - I'd always thought of the aim as being a multi-target compiler without target-independent files being built more than once). Other clearly worthwhile cleanups in what I thought of as the natural approach include completing the toplevel libgcc transition (so the copies of libgcc built for each target's multilibs get their configuration from configuring the libgcc directory for that target and multilib rather than from the gcc directory if that's configured once, and without including tm.h in target files any more). -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update
2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, int i; is not the same as extern int i;. Sorry for my ignorance but I have been reading and searching for the answer and I cannot tell what is the difference between int i = 1 and extern int i = 1 at file-scope in C. Would you or someone else mind to point me out to the answer? Thanks in advance. Manuel.
Re: gcc-in-cxx update
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: 2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, int i; is not the same as extern int i;. Sorry for my ignorance but I have been reading and searching for the answer and I cannot tell what is the difference between int i = 1 and extern int i = 1 at file-scope in C. I did not say those were different, I said the uninitialized case was different, so extern is implicit if missing is not a general C rule. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-in-cxx update
2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: 2009/4/29 Joseph S. Myers jos...@codesourcery.com: On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: BTW, why is this warned about? I imagine because in C it is not conventional to use extern when defining something, only on a declaration that is not a definition. But may it lead to some confusion or subtle error? It seems overly pedantic to me if it is just a matter of style, because extern is implicit if missing, int i; is not the same as extern int i;. Sorry for my ignorance but I have been reading and searching for the answer and I cannot tell what is the difference between int i = 1 and extern int i = 1 at file-scope in C. I did not say those were different, I said the uninitialized case was different, so extern is implicit if missing is not a general C rule. OK, then. I assumed that we were discussing about the initialized case, which is the origin of this thread. Hence, my suggestion stands: get rid of the warning. Cheers, Manuel.
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 29 Apr 2009, Joseph S. Myers wrote: On Wed, 29 Apr 2009, Richard Earnshaw wrote: If you are building a non-C front end without bootstrapping you need at least 2.95: To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. STRICT_WARN (i.e. -pedantic) was added to all the frontends (except Ada) many years ago. So this comment about use of extensions requiring gcc-2.95 might be obsolete. I suspect you may be able to cross-build all of non-ada GCC with any ISO C compiler right now (I haven't tried it though since I don't have access to an appropriate system.) --Kaveh
Re: gcc-in-cxx update / multi-targeted gcc
Quoting Ian Lance Taylor i...@google.com: I'm not sure why you are singling me out. You seemed to be actively working on the branch, and the c++ enum type checks provide a motivation to make changes. Also, this issue should be considered in general when people change their coding habits in order for the code to be c++ ready. If we decide that a multi-targeted gcc is a goal we want to support, it's certainly fine with me to change those enums to int and add casts where appropriate. OK. This is also the route I have followed so far. (I'm not personally convinced that a multi-targeted gcc is particularly useful, though I don't object if there is a general desire to support it.) As the number of cores integrated into each computing device increases, I think it is only natural that we'll see the emergence of specialized cores. E.g. we already see low power cores for base load/standby, superscalar out-of-order cores for sequential processing, and massively parallel architectures for media processing. Having a single compiler that can generate code for all target architectures in a computing device allows to shift (parts of) functions from one architecture to the other depending the nature of the processing task. This also increases the leverage for profile-based feedback and machine learning. It is perhaps worth noting that the natural way to handle the target vector in C++ is to make a Target class with a set of virtual methods. Yes, but unfortunately that requires ferrying around the this pointer. If we had virtual static member functions, that would be different. And you'd still have to decide on one function signature for each virtual function - having one target return a pointer to an 8 bit enum and another one return a pointer to a 16 bit enum by the same name just won't do. Then methods like eh_return_filter_mode would use a covariant return type in specific implementations. Where the mode is a parameter it would still have to be changed to int. The signature of these virtual functions would have to be defined with a type that is wide enough to fit all target's enums. And you couldn't fix a hook like ira_cover_classes this way. The caller has to know how wide each element is in the of the array the pointer to the first element of which is being returned. I think you need to take a step back. What is a natural way to represent a register class in the machine independent code when writing in C++? I don't think it is to use an enum type. Having all register classes in one enum gives you some things that you don't get with an compiler implementation language class for each register class. E.g. you can easily iterate over all register classes, and have bitmasks which act as sets of register classes. You can use them as indices in lookup tables. A register class is basically an object which implements methods like bool is_regno_in_class(unsigned int); HARD_REG_SET registers_in_class(); bool equals(Reg_class); bool is_superset_of(Reg_class); bool is_subset_of(Reg_classS); Obviously that is a long way off in gcc. Indeed. Expressing this as an actual C++ class would be incompatible with the current goal to be able to build GCC with a C compiler. Another enum problem is enum attr_cpu / enum processor_type in the sh machine description. We need a variable (sh_cpu aka sh_cpu_attr) with this type to be visible inside the attributes generated by genattrtab. Choices to solve these kind of problems would be: - introduce another target header which is guaranteed to be included only after enum definitions from generator files are in effect. - allow the gcc extension of statement expressions to be used in target descriptions, so that a macro could provide an extern declaration of a variable before using its value. A simple approach would be to have a way to say that the enum values for an attribute were already declared. Then instead of listing the values in the define_attr, we would just have a standard mapping from constants of the attribute to the enum names to use. We would have less error checking in the generator programs, but the errors would be caught when the generated code was compiled. I don't see how this would work. Remember, genattrtab needs to know about every value in the enumeration so that it can perform its optimizations. I also don't see how your proposal is simpler than adding another header file. FWIW, the current approach of using two enums in parallel works (awkward as it is) also for C++. It just needed adjustments because the two sets of enum constants are no longer interchangable, and a cast is now required when going from one enum to the other.
Re: gcc-in-cxx update / multi-targeted gcc
Quoting Joseph S. Myers jos...@codesourcery.com: I think the cleanups involved in using the target vector / class more, and other cleanups involved in the natural approach to multi-target GCC of which the target vector is a part, are more useful than the end result (for which compiling large parts of the compiler multiple times is an interesting approach - I'd always thought of the aim as being a multi-target compiler without target-independent files being built more than once). I remembered the reports of GCC getting slower due to the target macros introduced so far (was it some 5% ?). Therefore, tying a multi-targeted gcc to the previous elimination of all non-target-vector target specifics seemed like a bad idea. My approach still allows rtl passes that are present only once - all you have to do is remove it from / not place it in the list of files that are compiled for each target, and change the header files so that the declarations for functions defined in this file are not put in the target namespace. It might well be that slowdown when going all target-vector can be avoided by using different abstractions, or using them in different ways. But that'll be a gargantuous task; I am at more than a hundred target specific files now. Something also to consider is that it is quite common in C++ to compile the same code multiple times. I fact I toyed with the idea to drive the support for multiple targets using templates but I gave up on that because: - It's harder to transform the existing code to be encapsulated into template than to encapsulate it into a namespace. - Mangled names would be more complex, casing debugging nightmares. - It would probably result in ferrying around a this pointer, plus unknown abstraction penalties. - Keeping to a minimal set of one simple C++ feature makes the code easier to understand.
Re: gcc-in-cxx update / multi-targeted gcc
On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote: Something which I miss in C++ is a way to declare that a function uses an integral type to pass an enum value (in arguments or return value), and then at function definition time only check that the integral type is sufficently large to hold the enum, and then for type checking purposes treat the parameter / return value as if it had been declared as this enum. This is exactly N2764, which should be part of C++0x --- at least it seems to be in the draft around p.149. But not part of gcc 4.4. unfortunately. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf http://gcc.gnu.org/projects/cxx0x.html -- Kind regards, Esben
Re: gcc-in-cxx update / multi-targeted gcc
On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote: Something which I miss in C++ is a way to declare that a function uses an integral type to pass an enum value (in arguments or return value), and then at function definition time only check that the integral type is sufficently large to hold the enum, and then for type checking purposes treat the parameter / return value as if it had been declared as this enum. Esben Mose Hansen wrote: This is exactly N2764, which should be part of C++0x --- at least it seems to be in the draft around p.149. But not part of gcc 4.4. unfortunately. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf That is closely related, but it's not quite the same. For a multi-targeted gcc, we'd want generic code to operate on integral types that correspond to enum values defined by the various targets - but these will define these enums differently. If the generic code was in a library, and compilers for the different targets were built separately, then N2764 would work. However, when linking multiple targets together, enums with the same name for different targets are different types, so they can't all be the same type as the type used by the generic code. This is why I would like the generic code to use a separate type which is assignment-compatible with any of these enums if the enums definition is visible.
