[patch][RFC] bail out after front-end errors
Hello,
This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnings and errors we generate from the middle-end
and during semantic analysis. But it seems to me that those warnings
are not very meaningful after parse errors (-Wuninitialized after a
parse error??), and errors from the middle end are mostly for exotic
code (involving asm()s and the like). Bailing out after parse errors
is therefore IMHO the right thing to do for the common case.
Thoughts? Comments?
If the consensus is that this patch goes in, I'll also have to do some
work on the test suite, because some warnings and errors disappear.
List attached below. A lot of errors and warnings from g++ disappear.
I suspect this is because they are only issued during gimplification.
That is something I'll have to address before this patch could go in.
Before I spend the effort, I'd like to know if there is consensus on
the general direction proposed here... ;-)
Ciao!
Steven
Index: toplev.c
===
--- toplev.c(revision 185813)
+++ toplev.c(working copy)
@@ -561,9 +561,14 @@ compile_file (void)
/* Compilation is now finished except for writing
what's left of the symbol table output. */
- if (flag_syntax_only || flag_wpa)
+ /* If all we have to do is syntax checking, or if there were parse
+ errors, stop here. */
+ if (flag_syntax_only || seen_error ())
return;
+ if (flag_wpa)
+return;
+
timevar_start (TV_PHASE_GENERATE);
ggc_protect_identifiers = false;
@@ -571,12 +576,6 @@ compile_file (void)
/* This must also call cgraph_finalize_compilation_unit. */
lang_hooks.decls.final_write_globals ();
- if (seen_error ())
-{
- timevar_stop (TV_PHASE_GENERATE);
- return;
-}
-
/* Compilation unit is finalized. When producing non-fat LTO object, we are
basically finished. */
if (in_lto_p || !flag_lto || flag_fat_lto_objects)
New failing tests:
> FAIL: gcc.dg/asm-7.c (test for errors, line 15)
> FAIL: gcc.dg/asm-7.c (test for errors, line 16)
> FAIL: gcc.dg/declspec-10.c (test for warnings, line 19)
> FAIL: gcc.dg/declspec-11.c (test for warnings, line 19)
> FAIL: gcc.dg/declspec-9.c (test for errors, line 20)
> FAIL: gcc.dg/gnu99-static-1.c (test for errors, line 21)
> FAIL: gcc.dg/gnu99-static-1.c (test for errors, line 25)
> FAIL: gcc.dg/pr48552-1.c (test for errors, line 16)
> FAIL: gcc.dg/pr48552-1.c (test for errors, line 40)
> FAIL: gcc.dg/pr48552-1.c (test for errors, line 52)
> FAIL: gcc.dg/pr48552-2.c (test for errors, line 16)
> FAIL: gcc.dg/pr48552-2.c (test for errors, line 40)
> FAIL: gcc.dg/pr48552-2.c (test for errors, line 52)
> FAIL: gcc.dg/redecl-10.c (test for warnings, line 15)
> FAIL: gcc.dg/redecl-10.c (test for warnings, line 29)
> FAIL: gcc.dg/gomp/block-2.c (test for errors, line 14)
> FAIL: gcc.dg/gomp/block-2.c (test for errors, line 16)
> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 9)
> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 10)
> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 11)
> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 15)
> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 16)
> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 17)
> FAIL: gcc.dg/gomp/pr27415.c (test for errors, line 9)
> FAIL: gcc.dg/gomp/pr27415.c (test for errors, line 28)
> FAIL: gcc.dg/gomp/pr27415.c (test for errors, line 37)
> FAIL: c-c++-common/tm/safe-3.c (internal compiler error)
> FAIL: c-c++-common/tm/safe-3.c (test for excess errors)
> FAIL: gcc.dg/tm/pr52141.c (internal compiler error)
> FAIL: gcc.dg/tm/pr52141.c (test for excess errors)
> FAIL: g++.dg/cpp0x/constexpr-ex1.C (test for warnings, line 17)
> FAIL: g++.dg/cpp0x/constexpr-function2.C (test for warnings, line 46)
> FAIL: g++.dg/cpp0x/constexpr-neg1.C (test for warnings, line 5)
> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C (test for warnings, line 15)
> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C not an aggregate (test for
> errors, line 16)
> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C deleted default ctor (test for
> errors, line 17)
> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C deleted assignment op (test for
> errors, line 18)
> FAIL: g++.dg/cpp0x/lambda/lambda-field-names.C no member named i (test for
> errors, line 11)
> FAIL: g++.dg/cpp0x/noexcept15.C (test for errors, line 16)
> FAIL: g++.dg/cpp0x/pr47416.C (test for errors, line 187)
> FAIL: g++.dg/cpp0x/pr47416.C (test for warnings, line 213)
> FAIL: g++.dg/cpp0x/pr47416.C (test for warnings, line 223)
> FAIL: g++.dg/cpp0x/static_assert2.C (test for errors, line 14)
> FAIL: g++.dg/cpp0x/union1.C (test for errors, line 17)
> FAIL: g++.dg/cpp0x/union1.C (test for errors, line 18)
> FAIL: g++.dg/cpp0x/union1.C (test for errors, line 28)
> FAIL:
Re: [patch][RFC] bail out after front-end errors
On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
>>> It would be nice to finally move
>>> the call to cgraph_finalize_compilation_unit to the middle-end ...
>>> (warning, if you try that you run into an issue with the Java frontend ...
>>> :/)
>>
>> Do you remember what issues that causes? I'm running into a great
>> number of issues there already with some varasm fixes (basically just
>> cleanups for the tree-ssa and unit-at-a-time era we're supposed to
>> live in - except Java).
>
> I think it was the
>
> /* Generate hidden aliases for Java. */
> if (candidates)
> {
> build_java_method_aliases (candidates);
> pointer_set_destroy (candidates);
> }
>
> hunk in cp_write_global_declarations that does not work when run
> before cgraph_finalize_compilation_unit
> (I simply tried to move that call out of, and after calling the
> langhook). So the problem materialized when
> building libjava I think.
Hello,
Coming back to this issue... Attached patch is an attempt to resolve
this part of the finalize_compilation_unit problem. Instead of
emitting aliases with assemble_alias after finalize_compilation_unit,
this patch uses cgraph_same_body_alias before it.
Bootstrapped&tested on powerpc64-unknown-linux-gnu.
Richi, Honza, does this make sense?
Ciao!
Steven
cp/
* decl2.c (collect_candidates_for_java_method_aliases): Remove.
(build_java_method_aliases): Rewrite to emit the aliases via the
cgraphunit machinery.
(cp_write_global_declarations): Adjust for abovementioned changes.
Index: cp/decl2.c
===
--- cp/decl2.c (revision 194725)
+++ cp/decl2.c (working copy)
stevenb@stevenb-laptop:~$ cat devel/java_method_aliases.diff
cp/
* decl2.c (collect_candidates_for_java_method_aliases): Remove.
(build_java_method_aliases): Rewrite to emit the aliases via the
cgraphunit machinery.
(cp_write_global_declarations): Adjust for abovementioned changes.
Index: cp/decl2.c
===
--- cp/decl2.c (revision 194725)
+++ cp/decl2.c (working copy)
@@ -3615,79 +3615,53 @@ generate_ctor_and_dtor_functions_for_priority (spl
/* Java requires that we be able to reference a local address for a
method, and not be confused by PLT entries. If hidden aliases are
- supported, collect and return all the functions for which we should
+ supported, emit one for each java function that we've emitted.
emit a hidden alias. */
-static struct pointer_set_t *
-collect_candidates_for_java_method_aliases (void)
+static void
+build_java_method_aliases (void)
{
+#ifdef HAVE_GAS_HIDDEN
struct cgraph_node *node;
- struct pointer_set_t *candidates = NULL;
+ tree fndecl;
+ vec candidates = vNULL;
+ unsigned int ix;
-#ifndef HAVE_GAS_HIDDEN
- return candidates;
-#endif
-
+ /* First collect all candidates. We cannot create the aliases
+ in place, it confuses the FOR_EACH_FUNCTION iterator. */
FOR_EACH_FUNCTION (node)
{
- tree fndecl = node->symbol.decl;
-
+ fndecl = node->symbol.decl;
if (DECL_CONTEXT (fndecl)
&& TYPE_P (DECL_CONTEXT (fndecl))
&& TYPE_FOR_JAVA (DECL_CONTEXT (fndecl))
&& TARGET_USE_LOCAL_THUNK_ALIAS_P (fndecl))
- {
- if (candidates == NULL)
- candidates = pointer_set_create ();
- pointer_set_insert (candidates, fndecl);
- }
+ candidates.safe_push (fndecl);
}
- return candidates;
-}
-
-
-/* Java requires that we be able to reference a local address for a
- method, and not be confused by PLT entries. If hidden aliases are
- supported, emit one for each java function that we've emitted.
- CANDIDATES is the set of FUNCTION_DECLs that were gathered
- by collect_candidates_for_java_method_aliases. */
-
-static void
-build_java_method_aliases (struct pointer_set_t *candidates)
-{
- struct cgraph_node *node;
-
-#ifndef HAVE_GAS_HIDDEN
- return;
-#endif
-
- FOR_EACH_FUNCTION (node)
+ /* Now add the aliases for the candidates collected above.
+ Mangle the name in a predictable way; we need to reference
+ this from a java compiled object file. */
+ FOR_EACH_VEC_ELT (candidates, ix, fndecl)
{
- tree fndecl = node->symbol.decl;
+ tree oid, nid, alias;
+ const char *oname;
+ char *nname;
- if (TREE_ASM_WRITTEN (fndecl)
- && pointer_set_contains (candidates, fndecl))
- {
- /* Mangle the name in a predictable way; we need to reference
-this from a java compiled object file. */
- tree oid, nid, alias;
- const char *oname;
- char *nname;
+ oid = DECL_ASSEMBLER_NAME (fndecl);
+ oname = IDENTIFIER_POINTER (oid);
+ gcc_assert (oname[0] == '_' && oname[1] == 'Z');
Re: [patch][RFC] bail out after front-end errors
On Fri, Dec 28, 2012 at 6:35 PM, Steven Bosscher wrote:
> On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
>> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
It would be nice to finally move
the call to cgraph_finalize_compilation_unit to the middle-end ...
(warning, if you try that you run into an issue with the Java frontend ...
:/)
>>>
>>> Do you remember what issues that causes? I'm running into a great
>>> number of issues there already with some varasm fixes (basically just
>>> cleanups for the tree-ssa and unit-at-a-time era we're supposed to
>>> live in - except Java).
>>
>> I think it was the
>>
>> /* Generate hidden aliases for Java. */
>> if (candidates)
>> {
>> build_java_method_aliases (candidates);
>> pointer_set_destroy (candidates);
>> }
>>
>> hunk in cp_write_global_declarations that does not work when run
>> before cgraph_finalize_compilation_unit
>> (I simply tried to move that call out of, and after calling the
>> langhook). So the problem materialized when
>> building libjava I think.
>
> Hello,
>
> Coming back to this issue... Attached patch is an attempt to resolve
> this part of the finalize_compilation_unit problem. Instead of
> emitting aliases with assemble_alias after finalize_compilation_unit,
> this patch uses cgraph_same_body_alias before it.
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu.
> Richi, Honza, does this make sense?
Looks sensible to me. In theory it should even allow more optimizations
this way ...
Of course it looks like stage1 material.
Thanks,
Richard.
> Ciao!
> Steven
>
> cp/
> * decl2.c (collect_candidates_for_java_method_aliases): Remove.
> (build_java_method_aliases): Rewrite to emit the aliases via the
> cgraphunit machinery.
> (cp_write_global_declarations): Adjust for abovementioned changes.
>
> Index: cp/decl2.c
> ===
> --- cp/decl2.c (revision 194725)
> +++ cp/decl2.c (working copy)
> stevenb@stevenb-laptop:~$ cat devel/java_method_aliases.diff
> cp/
> * decl2.c (collect_candidates_for_java_method_aliases): Remove.
> (build_java_method_aliases): Rewrite to emit the aliases via the
> cgraphunit machinery.
> (cp_write_global_declarations): Adjust for abovementioned changes.
>
> Index: cp/decl2.c
> ===
> --- cp/decl2.c (revision 194725)
> +++ cp/decl2.c (working copy)
> @@ -3615,79 +3615,53 @@ generate_ctor_and_dtor_functions_for_priority (spl
>
> /* Java requires that we be able to reference a local address for a
> method, and not be confused by PLT entries. If hidden aliases are
> - supported, collect and return all the functions for which we should
> + supported, emit one for each java function that we've emitted.
> emit a hidden alias. */
>
> -static struct pointer_set_t *
> -collect_candidates_for_java_method_aliases (void)
> +static void
> +build_java_method_aliases (void)
> {
> +#ifdef HAVE_GAS_HIDDEN
>struct cgraph_node *node;
> - struct pointer_set_t *candidates = NULL;
> + tree fndecl;
> + vec candidates = vNULL;
> + unsigned int ix;
>
> -#ifndef HAVE_GAS_HIDDEN
> - return candidates;
> -#endif
> -
> + /* First collect all candidates. We cannot create the aliases
> + in place, it confuses the FOR_EACH_FUNCTION iterator. */
>FOR_EACH_FUNCTION (node)
> {
> - tree fndecl = node->symbol.decl;
> -
> + fndecl = node->symbol.decl;
>if (DECL_CONTEXT (fndecl)
> && TYPE_P (DECL_CONTEXT (fndecl))
> && TYPE_FOR_JAVA (DECL_CONTEXT (fndecl))
> && TARGET_USE_LOCAL_THUNK_ALIAS_P (fndecl))
> - {
> - if (candidates == NULL)
> - candidates = pointer_set_create ();
> - pointer_set_insert (candidates, fndecl);
> - }
> + candidates.safe_push (fndecl);
> }
>
> - return candidates;
> -}
> -
> -
> -/* Java requires that we be able to reference a local address for a
> - method, and not be confused by PLT entries. If hidden aliases are
> - supported, emit one for each java function that we've emitted.
> - CANDIDATES is the set of FUNCTION_DECLs that were gathered
> - by collect_candidates_for_java_method_aliases. */
> -
> -static void
> -build_java_method_aliases (struct pointer_set_t *candidates)
> -{
> - struct cgraph_node *node;
> -
> -#ifndef HAVE_GAS_HIDDEN
> - return;
> -#endif
> -
> - FOR_EACH_FUNCTION (node)
> + /* Now add the aliases for the candidates collected above.
> + Mangle the name in a predictable way; we need to reference
> + this from a java compiled object file. */
> + FOR_EACH_VEC_ELT (candidates, ix, fndecl)
> {
> - tree fndecl = node->symbol.decl;
> + tree oid, nid, alias;
> + const char *oname;
> + char *nname;
>
> - if (TREE_A
Re: [patch][RFC] bail out after front-end errors
On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote:
> Hello,
>
> This patch is one way to address PR44982. I see no good reason to
> cgraph_finalize_compilation_unit if there were parse errors. As Richi
> already pointed out, GCC traditionally has proceeded after parse
> errors to preserve warnings and errors we generate from the middle-end
> and during semantic analysis. But it seems to me that those warnings
> are not very meaningful after parse errors (-Wuninitialized after a
> parse error??), and errors from the middle end are mostly for exotic
> code (involving asm()s and the like). Bailing out after parse errors
> is therefore IMHO the right thing to do for the common case.
>
> Thoughts? Comments?
Conceptually it makes sense. Did you check whether allowing the
FE too proceed to final_write_globals but stop before
cgraph_finalize_compilation_unit
preserves any errors? I would expect that maybe FE global variable
diagostics are defered until that? It would be nice to finally move
the call to cgraph_finalize_compilation_unit to the middle-end ...
(warning, if you try that you run into an issue with the Java frontend ... :/)
Richard.
> If the consensus is that this patch goes in, I'll also have to do some
> work on the test suite, because some warnings and errors disappear.
> List attached below. A lot of errors and warnings from g++ disappear.
> I suspect this is because they are only issued during gimplification.
> That is something I'll have to address before this patch could go in.
> Before I spend the effort, I'd like to know if there is consensus on
> the general direction proposed here... ;-)
>
> Ciao!
> Steven
>
>
>
> Index: toplev.c
> ===
> --- toplev.c (revision 185813)
> +++ toplev.c (working copy)
> @@ -561,9 +561,14 @@ compile_file (void)
> /* Compilation is now finished except for writing
> what's left of the symbol table output. */
>
> - if (flag_syntax_only || flag_wpa)
> + /* If all we have to do is syntax checking, or if there were parse
> + errors, stop here. */
> + if (flag_syntax_only || seen_error ())
> return;
>
> + if (flag_wpa)
> + return;
> +
> timevar_start (TV_PHASE_GENERATE);
>
> ggc_protect_identifiers = false;
> @@ -571,12 +576,6 @@ compile_file (void)
> /* This must also call cgraph_finalize_compilation_unit. */
> lang_hooks.decls.final_write_globals ();
>
> - if (seen_error ())
> - {
> - timevar_stop (TV_PHASE_GENERATE);
> - return;
> - }
> -
> /* Compilation unit is finalized. When producing non-fat LTO object, we are
> basically finished. */
> if (in_lto_p || !flag_lto || flag_fat_lto_objects)
>
>
> New failing tests:
>> FAIL: gcc.dg/asm-7.c (test for errors, line 15)
>> FAIL: gcc.dg/asm-7.c (test for errors, line 16)
>> FAIL: gcc.dg/declspec-10.c (test for warnings, line 19)
>> FAIL: gcc.dg/declspec-11.c (test for warnings, line 19)
>> FAIL: gcc.dg/declspec-9.c (test for errors, line 20)
>> FAIL: gcc.dg/gnu99-static-1.c (test for errors, line 21)
>> FAIL: gcc.dg/gnu99-static-1.c (test for errors, line 25)
>> FAIL: gcc.dg/pr48552-1.c (test for errors, line 16)
>> FAIL: gcc.dg/pr48552-1.c (test for errors, line 40)
>> FAIL: gcc.dg/pr48552-1.c (test for errors, line 52)
>> FAIL: gcc.dg/pr48552-2.c (test for errors, line 16)
>> FAIL: gcc.dg/pr48552-2.c (test for errors, line 40)
>> FAIL: gcc.dg/pr48552-2.c (test for errors, line 52)
>> FAIL: gcc.dg/redecl-10.c (test for warnings, line 15)
>> FAIL: gcc.dg/redecl-10.c (test for warnings, line 29)
>> FAIL: gcc.dg/gomp/block-2.c (test for errors, line 14)
>> FAIL: gcc.dg/gomp/block-2.c (test for errors, line 16)
>> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 9)
>> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 10)
>> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 11)
>> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 15)
>> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 16)
>> FAIL: gcc.dg/gomp/block-7.c (test for errors, line 17)
>> FAIL: gcc.dg/gomp/pr27415.c (test for errors, line 9)
>> FAIL: gcc.dg/gomp/pr27415.c (test for errors, line 28)
>> FAIL: gcc.dg/gomp/pr27415.c (test for errors, line 37)
>> FAIL: c-c++-common/tm/safe-3.c (internal compiler error)
>> FAIL: c-c++-common/tm/safe-3.c (test for excess errors)
>> FAIL: gcc.dg/tm/pr52141.c (internal compiler error)
>> FAIL: gcc.dg/tm/pr52141.c (test for excess errors)
>> FAIL: g++.dg/cpp0x/constexpr-ex1.C (test for warnings, line 17)
>> FAIL: g++.dg/cpp0x/constexpr-function2.C (test for warnings, line 46)
>> FAIL: g++.dg/cpp0x/constexpr-neg1.C (test for warnings, line 5)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C (test for warnings, line 15)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C not an aggregate (test for
>> errors, line 16)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg.C deleted default ctor (test for
>> errors, line 17)
>> FAIL: g++.dg/cpp0x/lambda/lambda-ctor-neg
Re: [patch][RFC] bail out after front-end errors
Hi, On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote: Hello, This patch is one way to address PR44982. I see no good reason to cgraph_finalize_compilation_unit if there were parse errors. As Richi already pointed out, GCC traditionally has proceeded after parse errors to preserve warnings and errors we generate from the middle-end and during semantic analysis. But it seems to me that those warnings are not very meaningful after parse errors (-Wuninitialized after a parse error??), and errors from the middle end are mostly for exotic code (involving asm()s and the like). Bailing out after parse errors is therefore IMHO the right thing to do for the common case. Thoughts? Comments? Conceptually it makes sense. Did you check whether allowing the FE too proceed to final_write_globals but stop before cgraph_finalize_compilation_unit preserves any errors? I would expect that maybe FE global variable diagostics are defered until that? It would be nice to finally move the call to cgraph_finalize_compilation_unit to the middle-end ... (warning, if you try that you run into an issue with the Java frontend ... :/) I bet it does preserve some errors. I noticed that when I analyzed a bit PR40405, see Comment #3 in particular. Thanks, Paolo.
Re: [patch][RFC] bail out after front-end errors
On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
> This patch is one way to address PR44982.
That's a great idea, I like it. There is only one problem that I know of that
prevents it from going in now. We emit errors/warnings from below finalize and
there is a feature in which we emit all the reasonable error and warning
messages that we can with one compile. There is a certain class of power user
that actually wants to see all the errors or warnings in a given compile, for
them, this is a feature. If you want to move the analysis for those to before
finalize, then I think this is a good way to fix the problem, until then I
think we should fix this in the normal way. The usual way to fix this would be
to find the bit that had the error_mark_node in it, and then do as much as you
can, but, then to bubble up error_mark_node or otherwise end processing.
> I see no good reason to cgraph_finalize_compilation_unit if there were parse
> errors.
It is actually a feature people use, even if you don't have any users or your
user base is too small to have ever met one. I have. The time the feature
allows to be saved, can be measured in days and weeks.
> it seems to me that those warnings are not very meaningful after parse errors
> (-Wuninitialized after a
> parse error??),
But you're wrong.
int f = &sdf;
main() {
int i;
printf("%d", i);
}
is a program that has parse errors and certainly, any and all the errors after
the first line that don't involve f in any meaningful way, are meaningful and
valuable to some people. I understand you don't see the value in them, that's
all right. They aren't valuable or meaningful to you, I get it. But, are you
willing to accept it when I assert that there is a class of people for which
this is a feature, they are meaningful and valuable?
> and errors from the middle end are mostly for exotic
> code (involving asm()s and the like). Bailing out after parse errors
> is therefore IMHO the right thing to do for the common case.
Some are for very exotic things, yes, but not all of them. Actually, I started
reviewing them, none of them seem that exotic to me. Take for example:
int f() { return this->i; } // { dg-error "" "no member named i" }
Really, exotic?
register int y; /* { dg-warning "file-scope declaration of 'y' specifies
'register'" } */
Again, I don't see the value in not giving the warning.
static int f2(void); /* { dg-error "used but never defined" } */
No exactly unheard of.
int x[]; /* { dg-warning "array 'x' assumed to have one element" } */
Gosh, seems reasonable.
hash_unique_table (size_t n, hasher, key_equal,
value_allocator & a):table (n, a)// { dg-error
"is not a direct base" }
This one I can see being nice to get with certain refactoring operations on
large code bases.
static_assert( I % 2 == 1, "I must be an odd number"); // { dg-error "odd
number" }
What, you mean my static_asserts are gonna go away, but we _liked_ them.
case low ... high : return i + 1; // { dg-error "previously" }
case 5 : return i + 2; // { dg-error "duplicate" }
duplicate case statements, awe... What's next?
void Look(W& w) { w.x = 3; } // { dg-error "private within this
context" }
Bye bye access control, I guess it was overrated.
I was going to go through them all, but I have to stop now, my stomach doesn't
feel well. I was only 38% of the way though them. Did you actually review
them, all of them?
What is so very wrong with fixing this in the normal way? I can envision
beefier analysis and code checking that runs very late in the compilation
process in order to get the most accurate analysis out of it. It seems
reasonable to permit that, even in the presence of parse errors, for all the
same reasons we want to see that a case statement was a duplicate, or that
something was never defined.
Re: [patch][RFC] bail out after front-end errors
On Tue, Mar 27, 2012 at 8:59 PM, Mike Stump wrote:
>> and errors from the middle end are mostly for exotic
>> code (involving asm()s and the like). Bailing out after parse errors
>> is therefore IMHO the right thing to do for the common case.
>
> Some are for very exotic things, yes, but not all of them. Actually, I
> started reviewing them, none of them seem that exotic to me. Take for
> example:
>
> int f() { return this->i; } // { dg-error "" "no member named i" }
>
> Really, exotic?
I expect it is not difficult to retain almost all of these C++ errors
by lowering (i.e. gimplifying) in the front end, or by having some
intermediate stage. It certainly wouldn't be acceptable to loose all
those diagnostics, just like that. I'm trying to figure out how to
avoid that! But it seemed prudent to ask what other people think of
this kind of change before spending loads of time on it :-)
Thanks for your comments!
Ciao!
Steven
