On 11/01/16 19:15, Bernd Edlinger wrote:
> On 11/01/16 18:11, Jason Merrill wrote:
>> On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
>> <bernd.edlin...@hotmail.de> wrote:
>>> On 11/01/16 16:20, Jason Merrill wrote:
>>>> On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
>>>> I'm not even sure we need a new warning. Can we combine this warning
>>>> with the block that currently follows?
>>>
>>> After 20 years of not having a warning on that,
>>> an implicitly enabled warning would at least break lots of bogus
>>> test cases.
>>
>> Would it, though? Which test cases still break with the current patch?
>>
>
> Less than before, but there are still at least a few of them.
>
> I can make a list and send it tomorrow.
>
FAIL: g++.dg/cpp1y/lambda-generic-udt.C -std=gnu++14 (test for excess
errors)
FAIL: g++.dg/cpp1y/lambda-generic-xudt.C -std=gnu++14 (test for excess
errors)
FAIL: g++.dg/init/new15.C -std=c++11 (test for excess errors)
FAIL: g++.dg/init/new15.C -std=c++14 (test for excess errors)
FAIL: g++.dg/init/new15.C -std=c++98 (test for excess errors)
FAIL: g++.dg/ipa/inline-1.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/ipa/inline-1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ipa/inline-1.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/ipa/inline-2.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/ipa/inline-2.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ipa/inline-2.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tc1/dr20.C -std=c++11 (test for excess errors)
FAIL: g++.dg/tc1/dr20.C -std=c++14 (test for excess errors)
FAIL: g++.dg/tc1/dr20.C -std=c++98 (test for excess errors)
FAIL: g++.dg/tree-ssa/inline-1.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/tree-ssa/inline-1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/tree-ssa/inline-1.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tree-ssa/inline-2.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/tree-ssa/inline-2.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/tree-ssa/inline-2.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/lto/20080908-1 cp_lto_20080908-1_0.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin
FAIL: g++.dg/lto/20080908-1 cp_lto_20080908-1_0.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin
FAIL: g++.dg/lto/20080908-1 cp_lto_20080908-1_0.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: g++.dg/lto/20080908-1 cp_lto_20080908-1_0.o assemble, -O2 -flto
-flto-partition=1to1 -fno-use-linker-plugin
FAIL: g++.dg/lto/20080908-1 cp_lto_20080908-1_0.o assemble, -O2 -flto
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
FAIL: g++.dg/lto/20080908-1 cp_lto_20080908-1_0.o assemble, -O2 -flto
-fuse-linker-plugin
FAIL: g++.dg/lto/pr68811 cp_lto_pr68811_0.o assemble, -O2
FAIL: g++.old-deja/g++.law/except1.C -std=gnu++11 (test for excess errors)
FAIL: g++.old-deja/g++.law/except1.C -std=gnu++14 (test for excess errors)
FAIL: g++.old-deja/g++.law/except1.C -std=gnu++98 (test for excess errors)
FAIL: g++.old-deja/g++.mike/p700.C -std=gnu++11 (test for excess errors)
FAIL: g++.old-deja/g++.mike/p700.C -std=gnu++14 (test for excess errors)
FAIL: g++.old-deja/g++.mike/p700.C -std=gnu++98 (test for excess errors)
FAIL: g++.old-deja/g++.other/builtins10.C -std=c++11 (test for excess
errors)
FAIL: g++.old-deja/g++.other/builtins10.C -std=c++14 (test for excess
errors)
FAIL: g++.old-deja/g++.other/realloc.C -std=c++11 (test for excess errors)
FAIL: g++.old-deja/g++.other/realloc.C -std=c++14 (test for excess errors)
FAIL: g++.old-deja/g++.other/realloc.C -std=c++98 (test for excess errors)
FAIL: g++.old-deja/g++.other/vbase5.C -std=c++11 (test for excess errors)
FAIL: g++.old-deja/g++.other/vbase5.C -std=c++14 (test for excess errors)
FAIL: g++.old-deja/g++.other/vbase5.C -std=c++98 (test for excess errors)
The lto test case does emit the warning when assembling, but
it still produces an executable and even executes it.
Also g++.dg/cpp1y/lambda-generic-udt.C, g++.dg/tc1/dr20.C
and g++.old-deja/g++.other/vbase5.C are execution tests.
So I was wrong to assume these were all compile-only tests.
I think that list should be fixable, if we decide to enable
the warning by default.
>>> Of course in C we have an implicitly enabled warning,
>>> so I would like to at least enable the warning on -Wall, thus
>>> -Wshadow is too weak IMO.
>>
>> Right. The -Wshadow warning is for file-local declarations, so that
>> doesn't apply to your testcase; I was thinking that we should hit the
>> first (currently unconditional) warning.
>>
>>>>> else if ((DECL_EXTERN_C_P (newdecl)
>>>>> && DECL_EXTERN_C_P (olddecl))
>>>>> || compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
>>>>> TYPE_ARG_TYPES (TREE_TYPE
>>>>> (olddecl))))
>>
>> So I was thinking to drop the "else" and the compparms test.
>>
>
> Yes. But then we must somehow avoid:
>
> else
> /* Discard the old built-in function. */
> return NULL_TREE;
>
> It maybe easier, just to copy the warning to the DECL_ANTICIPATED case?
>
>>>>> {
>>>>> /* A near match; override the builtin. */
>>>>>
>>>>> if (TREE_PUBLIC (newdecl))
>>>>> warning_at (DECL_SOURCE_LOCATION (newdecl), 0,
>>>>> "new declaration %q#D ambiguates
>>>>> built-in "
>>>>> "declaration %q#D", newdecl, olddecl);
>>
>> So we would hit this warning. And change the message to remove
>> "ambiguates", since we're removing the compparms.
>>
>>> This started because I wanted to add builtin functions for some
>>> special_function_p names. And I wanted to warn the user if he uses a
>>> name that is recognized by special_function_p, but the parameters
>>> don't match. Now I think we need to teach special_function_p to
>>> distinguish "C" functions from "C++" functions, which it currently
>>> cannot do, because that knowledge is only in the C++ FE.
>>
>> It could look at DECL_ASSEMBLER_NAME rather than DECL_NAME?
>>
>
> Yes. I think previously special_function_p must have used the
> DECL_ASSEMBLER_NAME, at least the comments still mention that.
>
> Also for a "C" function there are target specific naming rules,
> some prepend an underscore, some don't, and more, especially
> W..DOS has special conventions IIRC.
>
> Maybe a language callback would be good to have for this task.
> So that special_function_p can easily check if something is a
> C++ function, then it is immediately clear that it is not a
> special function.
>
>
>
> Bernd.
