Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/12/2014 10:32 AM, Chen Gang wrote:
[root@localhost qemu_cc]# cat test.cc
const char n() { return 1; }
const char c = n();
[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O0 -c -o test.o test.cc
[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O2 -c -o test.o test.cc
test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable]
const char c = n();
^
The warning is correct (and new). Please submit bug reports via the
website; see https://gcc.gnu.org/bugs/
Jason
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 12 October 2014 16:32, Chen Gang wrote:
> Hello All:
>
> I found an issue about g++, it is OK for "-Wall -O0", but will report
> -Wunused-variable for "-Wall -O1|2|3|s". The original version (e.g.
> gcc 4.8.3 redhat version) does not report warning for "-Wall -O?".
>
> The related operation:
>
> [root@localhost qemu_cc]# cat test.cc
> const char n() { return 1; }
> const char c = n();
> [root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O0 -c -o test.o test.cc
> [root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O2 -c -o test.o test.cc
> test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable]
>const char c = n();
> ^
This cut down test case seems to have discarded two interesting
things about the original issue
(context: http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01253.html)
(1) the definitions of the const variables are in a header
(2) gcc doesn't warn about const declarations in the same
header which use 'int' rather than 'float' or 'double'
That said, how does g++ know that the variable isn't defined
for the benefit of another translation unit? (Conversely, how
should a library define constants in a header for the benefit
of users of the library in a way that doesn't make g++ complain
if the library using code happens not to use the constant?)
thanks
-- PMM
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/13/14 18:58, Peter Maydell wrote:
> On 12 October 2014 16:32, Chen Gang wrote:
>> Hello All:
>>
>> I found an issue about g++, it is OK for "-Wall -O0", but will report
>> -Wunused-variable for "-Wall -O1|2|3|s". The original version (e.g.
>> gcc 4.8.3 redhat version) does not report warning for "-Wall -O?".
>>
>> The related operation:
>>
>> [root@localhost qemu_cc]# cat test.cc
>> const char n() { return 1; }
>> const char c = n();
>> [root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O0 -c -o test.o test.cc
>> [root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O2 -c -o test.o test.cc
>> test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable]
>>const char c = n();
>> ^
>
> This cut down test case seems to have discarded two interesting
> things about the original issue
> (context: http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01253.html)
> (1) the definitions of the const variables are in a header
> (2) gcc doesn't warn about const declarations in the same
> header which use 'int' rather than 'float' or 'double'
>
> That said, how does g++ know that the variable isn't defined
> for the benefit of another translation unit? (Conversely, how
> should a library define constants in a header for the benefit
> of users of the library in a way that doesn't make g++ complain
> if the library using code happens not to use the constant?)
>
Oh, yes. Originally I got this warning by compiling Qemu. And sorry for
my sample (test.cc) may be not quite precise.
For me, I guess:
- If the constant number is defined in the header file, and never be
used, our g++ need not report warning about [-Wunused-variable].
- But if the constant number is defined in the source file, and never
be used, our g++ need report warning about [-Wunused-variable] (just
like what Jason Merrill said).
Is my guess correct?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/13/14 18:53, Jason Merrill wrote:
> On 10/12/2014 10:32 AM, Chen Gang wrote:
>>[root@localhost qemu_cc]# cat test.cc
>>const char n() { return 1; }
>>const char c = n();
>>[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O0 -c -o test.o
>> test.cc
>>[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O2 -c -o test.o
>> test.cc
>>test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable]
>> const char c = n();
>>^
>
> The warning is correct (and new). Please submit bug reports via the website;
> see https://gcc.gnu.org/bugs/
>
OK, thanks. After finish this consult, I shall report bugs, and shall
try to fix it (I got it from Qemu which in my current focus border).
Hope I can finish within this month.
And one another consult: if the constant variable is defined in header
file, and never be used, need our g++ still report warning about
[-Wunused-variable] too (for me, I guess, not)?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On Mon, Oct 13, 2014 at 09:10:31PM +0800, Chen Gang wrote: > Oh, yes. Originally I got this warning by compiling Qemu. And sorry for > my sample (test.cc) may be not quite precise. > > For me, I guess: > > - If the constant number is defined in the header file, and never be >used, our g++ need not report warning about [-Wunused-variable]. That is nonsense, even if you define such a "constant" in a header file, it still means runtime overhead (the variable needs to be constructed at runtime, const is not the same thing as constexpr). So, IMHO the warning is desirable even if it is in headers, it is something you should reconsider. Making the function constexpr makes the warning of course go away, then there is no runtime overhead associated with it; but you'll need C++11 for that. Jakub
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/13/14 21:31, Jakub Jelinek wrote:
> On Mon, Oct 13, 2014 at 09:10:31PM +0800, Chen Gang wrote:
>> Oh, yes. Originally I got this warning by compiling Qemu. And sorry for
>> my sample (test.cc) may be not quite precise.
>>
>> For me, I guess:
>>
>> - If the constant number is defined in the header file, and never be
>>used, our g++ need not report warning about [-Wunused-variable].
>
> That is nonsense, even if you define such a "constant" in a header file,
> it still means runtime overhead (the variable needs to be constructed at
> runtime, const is not the same thing as constexpr).
> So, IMHO the warning is desirable even if it is in headers, it is something
> you should reconsider. Making the function constexpr makes the warning of
> course go away, then there is no runtime overhead associated with it; but
> you'll need C++11 for that.
>
OK, thank you for your explanation. Excuse me, I am not quite familiar
with C++. I guess your meaning is:
- "char f(){return 1}; const char a = f();", if 'a' is not used, need
report warning (no matter whether it is in header or source file).
- "const float a = 3.1 + 7.0/2;", if 'a' is not used, need nor report
warning (no matter whether it is in header or source file).
- this warning is based on C++11, so old gcc version may not support
this warning, but new gcc (e.g. 5.0), need support it.
Is it correct?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/13/14 21:59, Chen Gang wrote:
>
> On 10/13/14 21:31, Jakub Jelinek wrote:
>> On Mon, Oct 13, 2014 at 09:10:31PM +0800, Chen Gang wrote:
>>> Oh, yes. Originally I got this warning by compiling Qemu. And sorry for
>>> my sample (test.cc) may be not quite precise.
>>>
>>> For me, I guess:
>>>
>>> - If the constant number is defined in the header file, and never be
>>>used, our g++ need not report warning about [-Wunused-variable].
>>
>> That is nonsense, even if you define such a "constant" in a header file,
>> it still means runtime overhead (the variable needs to be constructed at
>> runtime, const is not the same thing as constexpr).
>> So, IMHO the warning is desirable even if it is in headers, it is something
>> you should reconsider. Making the function constexpr makes the warning of
>> course go away, then there is no runtime overhead associated with it; but
>> you'll need C++11 for that.
>>
>
> OK, thank you for your explanation. Excuse me, I am not quite familiar
> with C++. I guess your meaning is:
>
> - "char f(){return 1}; const char a = f();", if 'a' is not used, need
>report warning (no matter whether it is in header or source file).
>
> - "const float a = 3.1 + 7.0/2;", if 'a' is not used, need nor report
Sorry, remove "nor". "If 'a' is not used, need report warning".
>warning (no matter whether it is in header or source file).
>
> - this warning is based on C++11, so old gcc version may not support
>this warning, but new gcc (e.g. 5.0), need support it.
>
> Is it correct?
>
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On Mon, Oct 13, 2014 at 10:01:31PM +0800, Chen Gang wrote: > > Is it correct? This mailing list is for development of GCC, not the right place to learn C++. Please ask either on gcc-help mailing list, or on some C++ user forums. Jakub
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/13/14 22:00, Jakub Jelinek wrote: > On Mon, Oct 13, 2014 at 10:01:31PM +0800, Chen Gang wrote: >>> Is it correct? > > This mailing list is for development of GCC, not the right place to learn > C++. Please ask either on gcc-help mailing list, or on some C++ user > forums. > OK, since I am not quite familiar with C++, can I still report the related bug, and try to fix it? If you worry about it, please help report the bug, and try to fix it. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
warning about const multidimensional array as function parameter
Hi all,
although this is a problem of the C standard, I still
find it annoying that the following code produces warnings
about incompatible pointer types (this has been discussed
before, see below):
extern void test(const double x[2][2]);
void foo(void)
{
double x[2][2];
const double (*y)[2] = x;
test(x);
}
Could we have an option to turn these warnings off?
Or, even better, have these warnings only with '-pedantic'?
I could try to come up with a patch...
This is not allowed because in C the qualifier always
belongs to the element type, and the allowed pointer
conversion rules do not include this case - which I assume
is an oversight of the standards committee.
Converting a pointer to an array to a pointer to a
constant array (i.e. an array with constant element type)
seems to be a perfectly reasonable and safe thing to do.
This is different from the case of converting a pointer
to a pointer, e.g. char** to const char** which is unsafe.
Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143
http://stackoverflow.com/questions/4573349/c-function-const-multidimensional-array-argument-strange-warning
http://gustedt.wordpress.com/2011/02/12/const-and-arrays/
RE: warning about const multidimensional array as function parameter
> Could we have an option to turn these warnings off? This will be controlled by a new option in GCC 5.0. For the details and the answer to your other questions, see https://gcc.gnu.org/wiki/FAQ#constmismatch (If others have comments that are not covered in the FAQ, or believe the answer there could be improved, please update it and provide a link to it.) Thanks, Manuel.
Re: warning about const multidimensional array as function parameter
Manuel López-Ibáñez : Thank you for your quick response. > > Could we have an option to turn these warnings off? > > This will be controlled by a new option in GCC 5.0. > > For the details and the answer to your other questions, see > https://gcc.gnu.org/wiki/FAQ#constmismatch The option '-Wincompatible-pointer-types' would turn of all warnings about incompatible pointers. I want a specific options to turn of the completely pointless warning about converting to pointers to constant arrays, which warns about something which is actually completely safe. Martin > (If others have comments that are not covered in the FAQ, or believe > the answer there could be improved, please update it and provide a > link to it.) > > Thanks, > > Manuel.
Re: warning about const multidimensional array as function parameter
On 14 October 2014 00:01, Martin Uecker wrote: > Manuel López-Ibáñez : > > Thank you for your quick response. > >> > Could we have an option to turn these warnings off? >> >> This will be controlled by a new option in GCC 5.0. >> >> For the details and the answer to your other questions, see >> https://gcc.gnu.org/wiki/FAQ#constmismatch > > The option '-Wincompatible-pointer-types' would turn of all > warnings about incompatible pointers. I want a specific options > to turn of the completely pointless warning about converting > to pointers to constant arrays, which warns about something > which is actually completely safe. It isn't complete safe. http://c-faq.com/ansi/constmismatch.html
Re: warning about const multidimensional array as function parameter
Manuel López-Ibáñez : > > Could we have an option to turn these warnings off? > > This will be controlled by a new option in GCC 5.0. > > For the details and the answer to your other questions, see > https://gcc.gnu.org/wiki/FAQ#constmismatch > > (If others have comments that are not covered in the FAQ, or believe > the answer there could be improved, please update it and provide a > link to it.) The FAQ could be improved by deleting the reference to the C-FAQ which talks about a different thing (converting pointers-to-pointers). Martin > Thanks, > > Manuel.
Re: warning about const multidimensional array as function parameter
Am Tue, 14 Oct 2014 00:05:47 +0100 Jonathan Wakely : > On 14 October 2014 00:01, Martin Uecker wrote: > > Manuel López-Ibáñez : > > > > Thank you for your quick response. > > > >> > Could we have an option to turn these warnings off? > >> > >> This will be controlled by a new option in GCC 5.0. > >> > >> For the details and the answer to your other questions, see > >> https://gcc.gnu.org/wiki/FAQ#constmismatch > > > > The option '-Wincompatible-pointer-types' would turn of all > > warnings about incompatible pointers. I want a specific options > > to turn of the completely pointless warning about converting > > to pointers to constant arrays, which warns about something > > which is actually completely safe. > > It isn't complete safe. http://c-faq.com/ansi/constmismatch.html A pointer to an array is not the same thing as a pointer to a pointer. Converting a pointer to an array to a pointer to a constant array is safe. Converting a pointer to a pointer to a pointer to a pointer to a constant is not (as the CFAQ points out). -- Martin
[debug-early] LTO streaming of on-the-side dwarf data structures
Gentlemen, your feedback would be greatly appreciated! I was investigating why locals were not being early dumped, and realized Michael's patch was skipping decls_for_scope() unless DECL_STRUCT_FUNCTION->gimple_df was set. I assume this was to wait until location information was available. That design caused locals to be dumped LATE, which defeats the whole purpose of this exercise. Since we want the local DECL DIEs to be generated early as well, we'd want the location information to be amended in the second dwarf pass. This got me thinking about deferred_locations, and all these on-the-side data structures that a second dwarf pass would depend on. Unless I'm misunderstanding something, we need a plan... Basically, any early collected data that dwarf2out_finish() and dwarf2out_function_decl() need, would need to be LTO streamed out after early dwarf generation and streamed back before the second dwarf pass. For instance, I see at least the following that need to be streamed in/out: file_table deferred_locations limbo_die_list (and deferred_asm_name) decl_die_table pubname_table pubtype_table We could either stream the hash tables and/or data structures above (and merge them from different compilation units upon stream-in), or we could come up with some way of annotating existing dwarf (to be read/merged back in and annotated). For instance, deferred_locations, decl_die_table, and limbo_die_lists need to associate a DIE with a TREE. We could tag the DIE with an artificial DW_AT_* that has some byte representation of the TREE and recreate the hash at LTO stream-in time. For other data structures (perhaps file_table and pub*_table), perhaps we could come up with yet another way of representing the data in Dwarf. However...I don't know if this is worth the trouble, or if we should just stream the individual hash tables and data structures, and not bother with this dwarf gymnastics. Did anybody have a plan for this? Am I misunderstanding something, or do we need to stream a lot of these on-the-side structures? Aldy
Re: warning about const multidimensional array as function parameter
On 14 October 2014 01:12, Martin Uecker wrote: > Converting a pointer to an array to a pointer to a constant array > is safe. Converting a pointer to a pointer to a pointer to a pointer > to a constant is not (as the CFAQ points out). You are probably right that it is safe. Unfortunately, C considers invalid cases that are safe and that are allowed by C++ (as mentioned in that C FAQ). I updated the FAQ with comments by Joseph Myers taken from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076. I'm not sure how much effort would be to make the C FE of GCC follow the rules of C++ or whether this would conflict with other parts of the standard (that is, rejecting valid C programs). Perhaps the option could be separated into two, one only enabled by -Wpedantic that controls cases that are known to be safe (-Wpedantic-incompatible-pointer-types? -Wincompatible-but-safe?). Still, someone would need to step up and do the work: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps Cheers, Manuel.
Re: warning about const multidimensional array as function parameter
Manuel López-Ibáñez :
> On 14 October 2014 01:12, Martin Uecker wrote:
> > Converting a pointer to an array to a pointer to a constant array
> > is safe. Converting a pointer to a pointer to a pointer to a pointer
> > to a constant is not (as the CFAQ points out).
>
> You are probably right that it is safe. Unfortunately, C considers
> invalid cases that are safe and that are allowed by C++ (as mentioned
> in that C FAQ). I updated the FAQ with comments by Joseph Myers taken
> from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 and
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076.
Thank you. I am not sure about the full C++ semantics, but the
case of passing pointers to const arrays seems fairly straightforward.
I also raised the issue at comp.std.c and proposed a change the
following extension to the pointer conversion rule (6.3.2.3):
"A pointer to an array with non-q-qualified element type may be
converted to a pointer to an array with the q-qualified version
of the type as element type."
Maybe somebody from the committee is reading there...
> I'm not sure how much effort would be to make the C FE of GCC follow
> the rules of C++ or whether this would conflict with other parts of
> the standard (that is, rejecting valid C programs).
I played bit at gcc/c/c-typeck.c and getting rid of the warning
seems simple (see below). But so far I don't fully understand the
code or what I did...
I also haven't figured out how to add a then-required warning about
the case where a pointer-to-constant-array is converted to a
pointer-to-array.
> Perhaps the option could be separated into two, one only enabled by
> -Wpedantic that controls cases that are known to be safe
> (-Wpedantic-incompatible-pointer-types? -Wincompatible-but-safe?).
My preferred solution would be to simple allow the case where it is
safe and warn only when enabled by -Wpedantic.
> Still, someone would need to step up and do the work:
> https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
I will talk a look at this.
Martin
> Cheers,
>
> Manuel.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(Revision 216134)
+++ gcc/c/c-typeck.c(Arbeitskopie)
@@ -1217,6 +1217,7 @@
comp_target_types (location_t location, tree ttl, tree ttr)
{
int val;
+ int val2;
tree mvl = TREE_TYPE (ttl);
tree mvr = TREE_TYPE (ttr);
addr_space_t asl = TYPE_ADDR_SPACE (mvl);
@@ -1228,13 +1229,20 @@
if (!addr_space_superset (asl, asr, &as_common))
return 0;
+ val2 = 1;
+
+ if ((TREE_CODE (mvl) == ARRAY_TYPE) && (TREE_CODE (mvr) == ARRAY_TYPE))
+val2 = comptypes (mvl, mvr);
+
/* Do not lose qualifiers on element types of array types that are
pointer targets by taking their TYPE_MAIN_VARIANT. */
- if (TREE_CODE (mvl) != ARRAY_TYPE)
+
+// if (TREE_CODE (mvl) != ARRAY_TYPE)
mvl = (TYPE_ATOMIC (mvl)
? c_build_qualified_type (TYPE_MAIN_VARIANT (mvl), TYPE_QUAL_ATOMIC)
: TYPE_MAIN_VARIANT (mvl));
- if (TREE_CODE (mvr) != ARRAY_TYPE)
+
+// if (TREE_CODE (mvr) != ARRAY_TYPE)
mvr = (TYPE_ATOMIC (mvr)
? c_build_qualified_type (TYPE_MAIN_VARIANT (mvr), TYPE_QUAL_ATOMIC)
: TYPE_MAIN_VARIANT (mvr));
@@ -1241,6 +1249,10 @@
enum_and_int_p = false;
val = comptypes_check_enum_int (mvl, mvr, &enum_and_int_p);
+ if ((val == 1) && (val2 != 1))
+ pedwarn (location, OPT_Wpedantic, "pointers to array have incompatible
qualifiers");
+
if (val == 2)
pedwarn (location, OPT_Wpedantic, "types are not quite compatible");
About Code coverage Algorithms.
Hi All, Good day for everyone . We benchmarked the code coverage algorithms like a)Optimal Edge Profiling (ftp://ftp.cs.wisc.edu/pub/techreports/1991/TR1031.pdf .) that are adopted by GCC and LLVM b)Dominator Leaf instrumentation(http://users.sdsc.edu/~mtikir/publications/papers/issta02.pdf) and i don't see the practical implementation of this. Goal is to reduce the instrumentation point and when we benchmarked both algorithms .The number of blocks that are required to instrument is less in option-b over option-a. Need some expert insights on this like why the option-b is not widely used over option-a. Thank you ~Umesh
