| Message ID | 000801cff35d$66786cb0$33694610$@arm.com |
|---|---|
| State | New |
| Headers | show |
On 10/29/14 02:47, Thomas Preud'homme wrote: > It seems more sensible to keep it in this block as the existing > defaulted_int block is for types for which it is not an error to omit the > int type specifier. It's not an error to omit it for complex - but of course means something different. IMHO it would be confusing to set type to integer_type_node when that's definitely wrong. But then setting 'defaulted_int' when that's not the case is also confusing. > ChangeLog unchanged. Ok for trunk? Anyway, I have no further comments on this patch and defer to Jason. nathan
> From: Nathan Sidwell [mailto:nathanmsidwell@gmail.com] On Behalf Of > Nathan Sidwell > > It's not an error to omit it for complex - but of course means something > different. IMHO it would be confusing to set type to integer_type_node > when > that's definitely wrong. But then setting 'defaulted_int' when that's not > the > case is also confusing. Oh in that case the patch is incomplete. Currently a complex alone gives an error at compilation which is why I added -fpermissive to the testcase. The patch don't change this behavior. Best regards, Thomas
On 10/29/14 07:32, Thomas Preud'homme wrote: >> From: Nathan Sidwell [mailto:nathanmsidwell@gmail.com] On Behalf Of > Oh in that case the patch is incomplete. Currently a complex alone gives > an error at compilation which is why I added -fpermissive to the testcase. > The patch don't change this behavior. It's quite probably I'm wrong -- I forgot that you mentioned -fpermissive before. In which case your reasoning is sound. Still deferring to Jason though. nathan
On 10/29/2014 05:47 AM, Thomas Preud'homme wrote: >> From: Nathan Sidwell [mailto:nathan@codesourcery.com] >> Sent: Thursday, October 09, 2014 2:30 PM >> On 10/09/14 09:25, Jason Merrill wrote: >>> I would think we want to handle this up in the existing defaulted_int >> block: >> my thought was to at least put it next to the explicit_int = -1 above. > > It seems more sensible to keep it in this block as the existing > defaulted_int block is for types for which it is not an error to omit the > int type specifier. Since this is a GNU extension, I think we want to be compatible with the C front end, which has > else if (specs->complex_p) > { > specs->typespec_word = cts_double; > pedwarn (specs->locations[cdw_complex], OPT_Wpedantic, > "ISO C does not support plain %<complex%> meaning " > "%<double complex%>"); > } right after the code that parallels the block I mentioned in my earlier mail. Jason
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index d26a432..f382e27 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -9187,6 +9187,7 @@ grokdeclarator (const cp_declarator *declarator, int is_main; explicit_int = -1; + defaulted_int = 1; /* We handle `main' specially here, because 'main () { }' is so common. With no options, it is allowed. With -Wreturn-type, diff --git a/gcc/testsuite/g++.dg/torture/pr63366.C b/gcc/testsuite/g++.dg/torture/pr63366.C new file mode 100644 index 0000000..af59b98 --- /dev/null +++ b/gcc/testsuite/g++.dg/torture/pr63366.C @@ -0,0 +1,11 @@ +// { dg-do run } +// { dg-options "-fpermissive" } +// { dg-prune-output "ISO C\\+\\+ forbids declaration of 'type name' with no type" } + +#include <typeinfo> + +int +main (void) +{ + return typeid (__complex) != typeid (__complex double); +}