[Bug c/54817] New: Warning about extern declarations in C and C++ files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54817 Bug #: 54817 Summary: Warning about extern declarations in C and C++ files. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: eugene.zele...@gmail.com Hi! I think will be good idea if GCC will produce warnings when extern declarations are placed in C/C++ files (not included from other files). Such declarations are definitely belong to headers, so their appearance in source files are indication of bad coding practices. Intel compiler produces such warnings as "warning #1419: external declaration in primary source file". Eugene.
[Bug sanitizer/57884] New: False positive in libgfortran finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57884 Bug ID: 57884 Summary: False positive in libgfortran finalization Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 30497 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30497&action=edit Main file which calls FORTRAN procedure Hi! My application contains some part of FORTRAN code. When I tried to compile it with address sanitizer and then run executable, I got error at the end: ==14628== ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x56732c8c #0 0x5556c854 (/gcc481/lib/libasan.so.0.0.0+0x16854) #1 0x56bf7a20 (/gcc481/lib/libgfortran.so.3.0.0+0xc2a20) ==14628== ABORTING Problematic code is freeing of FORTRAN wrapper for stdin in raw_close(). Strangely, but same operations for stdout and stderr wrappers were performed without problem. All three wrappers are created with same fd_to_stream() function. This problem is observed with GCC 4.8.0 and 4.8.1 built on Red Hat Enterprise Linux 5.5 with 32 and 64 bit executables. But same versions of GCC build on Red Hat Enterprise Linux 6.0 are fine. Example build script: !/bin/csh set echo on set Mode = "-m32" set GCCHome = "/gcc481" $GCCHome/bin/gfortran -std=legacy -g $Mode -fsanitize=address -c zcopy.f -o zcopy.o $GCCHome/bin/gcc -g $Mode -fsanitize=address -c main.c -o main.o $GCCHome/bin/gcc $Mode main.o zcopy.o -lasan -lgfortran -o main.exe GDB backtrace for: #7 0x56bf7a21 in raw_close (s=0x56732c8c <__interceptor_calloc::calloc_memory_for_dlsym+428>) at /gcc481_src/gcc-4.8.1/libgfortran/io/unix.c:416 #8 0x56bf7462 in sclose (s=) at /gcc481_src/gcc-4.8.1/libgfortran/io/unix.h:94 #9 close_unit_1 (u=0x56732ae0 <__interceptor_calloc::calloc_memory_for_dlsym>, locked=locked@entry=1) at /gcc481_src/gcc-4.8.1/libgfortran/io/unit.c:653 #10 0x56bf75da in _gfortrani_close_units () at /gcc481_src/gcc-4.8.1/libgfortran/io/unit.c:716 #11 0x56b48514 in cleanup () at /gcc481_src/gcc-4.8.1/libgfortran/runtime/main.c:250 #12 0x56b45808 in __do_global_dtors_aux () from /home/tammy/gcc481/lib/libgfortran.so.3 #13 0x56c10830 in _fini () from /home/tammy/gcc481/lib/libgfortran.so.3 #14 0x0082580e in _dl_fini () from /lib/ld-linux.so.2 #15 0x00865da9 in exit () from /lib/libc.so.6 #16 0x0084fea4 in __libc_start_main () from /lib/libc.so.6 #17 0x08048561 in _start () Eugene.
[Bug sanitizer/57884] False positive in libgfortran finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57884 --- Comment #1 from Eugene Zelenko --- Created attachment 30498 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30498&action=edit zcopy FORTRAN procedure from BLAS
[Bug sanitizer/57884] False positive in libgfortran finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57884 --- Comment #2 from Eugene Zelenko --- Sorry, forgot to add GCC configuration information in original report: Using built-in specs. COLLECT_GCC=/gcc481/bin/gcc COLLECT_LTO_WRAPPER=/gcc481/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper Target: x86_64-redhat-linux Configured with: /gcc481_src/gcc-4.8.1/configure --prefix=/gcc481 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --with-linker-hash-style=gnu --enable-languages=c,c++,fortran --with-tune=generic --build=x86_64-redhat-linux --disable-nls --with-ld=/binutils/v2.20/bin/ld --with-as=/binutils/v2.20/bin/as Thread model: posix gcc version 4.8.1 (GCC)
[Bug c++/59552] New: Warning when non-trivial type parameter is passed by value but not changed in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59552 Bug ID: 59552 Summary: Warning when non-trivial type parameter is passed by value but not changed in function Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Hi! I think will be good idea to introduce warnings for situations when non-trivial type (of big size or with non-default copy constructor, for example, STL container) parameter is passed by value but not changed in function (only const methods are called), so in this case const reference should be used instead. Eugene.
[Bug c++/59563] New: Warning for void as parameter list in C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59563 Bug ID: 59563 Summary: Warning for void as parameter list in C++ Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Hi! I think will be great to have warning when void is used as function parameter for indication of empty arguments list in C++ code (i. e. not extern "C"). Such coding style have sense in ANSI C, but not C++. Eugene.
[Bug c++/59570] New: Warning for semicolon trailing closing curly brackets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59570 Bug ID: 59570 Summary: Warning for semicolon trailing closing curly brackets Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Hi! I think will be great to have warning when useless semicolon trails closing curly bracket (closing function definition or code block). Same should be done for C. Eugene.
[Bug c++/86706] New: GCC 8.2 ICE in build_base_path, at cp/class.c:294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86706
Bug ID: 86706
Summary: GCC 8.2 ICE in build_base_path, at cp/class.c:294
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene.zelenko at gmail dot com
Target Milestone: ---
Created attachment 44454
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44454&action=edit
Problematic code snippet
I experienced ICE in build_base_path, at cp/class.c:294 with GCC 8.2. 8.1 works
fine on same code.
I tried in-house built 8.2 as well as trunk GCC on Compiler Explorer.
GCC command line and stack trace:
/grid/common/test/gcc-v8.2.0rh65/bin/g++ -std=c++11 -g -m32 GCC82ICE.cc -c -o
GCC82ICE.o
GCC82ICE.cc: In constructor 'ContextCallback::ContextCallback(int,
bool)':
GCC82ICE.cc:31:40: internal compiler error: in build_base_path, at
cp/class.c:294
if ( !first_ || priority < first_->priority_ ) {
^
0x5f1897 build_base_path(tree_code, tree_node*, tree_node*, int, int)
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/class.c:294
0x713a91 build_class_member_access_expr(cp_expr, tree_node*, tree_node*, bool,
int)
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/typeck.c:2477
0x717e3b finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/typeck.c:3000
0x68ecc0 cp_parser_postfix_dot_deref_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:7622
0x69c0d7 cp_parser_postfix_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:7269
0x69d0a1 cp_parser_unary_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:8317
0x67f5e1 cp_parser_cast_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:9085
0x68017d cp_parser_simple_cast_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:27371
0x68017d cp_parser_binary_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:9250
0x6814b4 cp_parser_assignment_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:9481
0x681bd8 cp_parser_expression
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:9650
0x6a46d5 cp_parser_condition
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:11665
0x6894c6 cp_parser_selection_statement
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:11382
0x6894c6 cp_parser_statement
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:10817
0x68a3d0 cp_parser_statement_seq_opt
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:11275
0x68a47f cp_parser_compound_statement
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:11229
0x69f4d5 cp_parser_function_body
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:21799
0x69f4d5 cp_parser_ctor_initializer_opt_and_function_body
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:21836
0x69fcf0 cp_parser_function_definition_after_declarator
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:26865
0x6a09f0 cp_parser_function_definition_from_specifiers_and_declarator
/tmp/gcc-v8.2.0rh65/gcc.source/gcc/cp/parser.c:26781
[Bug c++/71069] New: Extend -Wnonnull-compare to address of reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71069
Bug ID: 71069
Summary: Extend -Wnonnull-compare to address of reference
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene.zelenko at gmail dot com
Target Milestone: ---
I had crash in optimized build because pointer check is skipped in next
situation (null pointer is sneaked into container):
void setData( Data &data ) {
_current_data = &data;
if ( _current_data )
_set_data.insert( _current_data );
}
I think will be good idea to report such situations in -Wnonnull-compare.
[Bug c++/71069] -Waddress didn't catch all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71069 --- Comment #1 from Eugene Zelenko --- Sorry for mistake in original report. -Waddress should report such problems.
[Bug web/71283] New: -Wterminate is not described in "Options to Request or Suppress Warnings"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Bug ID: 71283 Summary: -Wterminate is not described in "Options to Request or Suppress Warnings" Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Target Milestone: --- -Wterminate description is missing in "Options to Request or Suppress Warnings".
[Bug c++/71302] New: -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 Bug ID: 71302 Summary: -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Target Milestone: --- Created attachment 38579 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38579&action=edit Simple test case -Wzero-as-null-pointer-constant incorrectly points to closing bracket instead of actual argument which should take nullptr. Same problem exists in 4.9 and 5.
[Bug c++/80729] New: [GCC 6, 7] -Wuseless-cast doesn't detect casting string literals to (const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80729 Bug ID: 80729 Summary: [GCC 6, 7] -Wuseless-cast doesn't detect casting string literals to (const char*) Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Target Milestone: --- -Wuseless-cast doesn't detect casting string literals to (const char*), like (const char*) "string" I tried GCC 6.3 and 7.1 on C++98/03 code base.
[Bug c++/59793] Warning to suggest making trivial non-virtual method inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59793
--- Comment #2 from Eugene Zelenko ---
Something like that:
class Class
{
private:
int Data;
public:
int GetData() const;
};
int Class::GetData() const {
return Data;
}
[Bug c++/82790] New: [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82790
Bug ID: 82790
Summary: [GCC 5, 6, 7] -Wuseless-cast doesn't detect
unnecessary removal of const
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugene.zelenko at gmail dot com
Target Milestone: ---
[GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const.
For example:
static void Function(const char *Parameter) {
}
static void Caller() {
const char *Variable = "String";
Function( const_cast( Variable ) );
Function( (char *) Variable );
}
[Bug c++/82790] [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82790 --- Comment #2 from Eugene Zelenko --- Just a little bit of background: a lot of legacy C code was converted to C++, so a lot of type casts were necessary to compile it properly. Gradually char * are converted to const char *, so -Wuseless-cast will be helpful for refactoring.
[Bug c++/59792] New: Warning to suggest making non-virtual method const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59792 Bug ID: 59792 Summary: Warning to suggest making non-virtual method const Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Hi! I think will be great to have warning which will suggest to make non-vuirtual method const if doesn't modify object's state and/or call only other const methods. Eugene.
[Bug c++/59793] New: Warning to suggest making trivial non-virtual method inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59793 Bug ID: 59793 Summary: Warning to suggest making trivial non-virtual method inline Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Hi! I think will be great to have warning which will suggest to make trivial non-vuirtual method inline and move to class declaration. Possible criteria of trivial: 1 line of code dealing only with trivial data types (pointer, integer, float, etc). Eugene.
[Bug c++/59570] Warning for semicolon trailing closing curly brackets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59570 Eugene Zelenko changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Eugene Zelenko --- Clang (I just tried 3.4) have such warning (-Wextra-semi).
[Bug c++/64431] "-Wignored-qualifiers" warning gives misleading position in code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64431 Eugene Zelenko changed: What|Removed |Added CC||eugene.zelenko at gmail dot com --- Comment #3 from Eugene Zelenko --- Same problem exists in 4.8.2 and 4.8.3 and probably earlier versions. Will be good idea to fix problem there too. Eugene.
[Bug c/65213] New: Extend -Wmissing-declarations to variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213 Bug ID: 65213 Summary: Extend -Wmissing-declarations to variables Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Will be good idea to -Wmissing-declarations to variables. Global variable should have extern declaration in header file, otherwise variable should be static. Clang detect such situations with -Wmissing-variable-declarations. Same should be done for C++.
[Bug libstdc++/60407] [C++11] call of overloaded ‘isnan’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60407 Eugene Zelenko changed: What|Removed |Added CC||eugene.zelenko at gmail dot com --- Comment #13 from Eugene Zelenko --- Same problem exists in 4.9.2. In my code combining with (later includes os_defines.h then features.h and mathcalls.h) produce same effect.
[Bug c/66918] New: Disable "inline function declared but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918 Bug ID: 66918 Summary: Disable "inline function declared but never defined" warning Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Target Milestone: --- It looks like there is no way to disable this warning (at least in 5.2.0). Part of my code base is built with -Werror, so I usually treat warnings introduced in new versions of GCC as no errors (-Wno-error). "inline function declared but never defined" point to -Werror as way to disable it, but I think will be better to have individual switch.
[Bug c/66918] Disable "inline function declared but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918 --- Comment #2 from Eugene Zelenko --- (In reply to Andrew Pinski from comment #1) > Could you explain why you don't want to have this warning really. This > warning is telling you that the inline function is not defined just like > static functions. I want this warning, but I need individual switch to turn it on/off and forcing it to be warning/error. Just as any other warning.
[Bug c/66918] Disable "inline function declared but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918 --- Comment #4 from Eugene Zelenko --- (In reply to Manuel López-Ibáñez from comment #3) > Does Clang have an option for this? GCC could use the same name. > > (The same warning exists in the C++ FE, thus it should be controlled by the > same option). I tried small example with Clang 3.7 https://gcc.godbolt.org and it looks like it doesn't have such warning (I used -Weverything -std=C++11 and C++14). GCC already has -Wunused-function and it seems reasonable to extend it to inline functions.
[Bug c++/71069] -Waddress didn't catch all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71069 --- Comment #3 from Eugene Zelenko --- (In reply to Andrew Pinski from comment #2) > -fsantize=undefined will catch this at runtime. What is undefined is > passing a NULL to setData. It'll be much better to report such problems during compilation, since run-time paths depends on test cases.
