This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Fix for PR58201


>What I can think of is to hide the stale source location when it no
>longer have
>defined meaning:
>Index: cgraphunit.c
>--- cgraphunit.c        (revision 202352)
>+++ cgraphunit.c        (working copy)
>@@ -913,6 +913,7 @@ analyze_functions (void)
>   bitmap_obstack_initialize (NULL);
>+  input_location = UNKNOWN_LOCATION;
>/* Ugly, but the fixup can not happen at a time same body alias is
>      C++ FE is confused about the COMDAT groups being right.  */
>but of course this just leads to:
>jh@gcc10:~/trunk/build7/gcc$ ./xgcc -B ./ -O2
>../../gcc/testsuite/g++.dg/template/cond2.C: In instantiation of 'int
>test(c<(X ?  :  Y)>&) [with int X = 0; int Y = 2]':
>:0:0:   required from here
>../../gcc/testsuite/g++.dg/template/cond2.C:6:28: error: omitted middle
>operand to '?:' operand cannot be mangled
>template<int X, int Y> int test(c<X ? : Y>&); // { dg-error "omitted" }

Actually this kind of change makes a lot of sense to me (cmp clang too): since at that point we do *not* really know the location of the "required from" bit, just plainly admit it. Would it be possible in such cases to have a conditional in the diagnostic machinery and avoid the output of that bit completely when the location is UNKNOWN? I don't think there are existing cases where it's sane to say :0:0 as "required from"!?!

Short term at least, it would seem a good enough solution to me + a comment in testcase too.

Then indeed as you explained in your last message before leaving (enjoy Pisa! All in all I spent there ~10 years!) we should audit, avoid as much as possible such late diagnostic, etc.

What do you think?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]