This is the mail archive of the gcc-patches@gcc.gnu.org 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: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340)


Jakub Jelinek wrote:

>>   namespace { struct A { static int i; }; }
>>   static int foo() { return A::i; }
>>
>> the program is still erroneous, even though the compiler may likely
>> optimize away foo, and the reference to A::i.
> 
> That's true, but the standard explicitly says the diagnostic is not
> required.

It does?  Where?  (I'm not disagreeing, I'm just surprised, and I
couldn't find a pointer.)

> To me it is more important that we don't error on valid programs (especially
> a lot of boost using code is broken), and when all references are optimized
> out, no real harm is done, compiler doesn't make up something unexpected.

We don't want to issue errors about valid programs -- but we do want to
issue diagnostics about invalid programs.  Those can be warnings,
pedwarns, etc.; they don't necessarily have to stop compilation.

> that should be warned about.  If we have some bit which we can really rely
> on to be set reliably for these purposes, then the warning can be precise,
> but TREE_USED is unfortunately not it.

TREE_USED should be accurate.  It should tell us whether or not a thing
was used by the input.  If TREE_USED is not set when it should be, or
set when it shouldn't be, we have a problem.

> template<typename T, typename U> struct C
> {
>   static T ca;
>   static const int value = sizeof (D<U>::foo (ca, 0)) == sizeof (int);
> };

I don't think the standard is not entirely clear.  It says this code is
not evaluated, but I don't see anything that says that this means that
"ca" is not used.  Of course, might well not require that, independent
of what the standard says; I agree that QoI suggests not issuing an
error in this case.

> I'm afraid I don't know the FE enough to further improve this warning
> without breaking valid programs, so the other possibility for me is just to
> back out the original patch and leave this can of worms to you/Jason.

All right; let's revert your original patch, then.  AIUI, that patch
fixed an accepts-invalid problem; that's better than rejects-valid problems.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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