[Bug other/88499] Check for less than zero removed before floating point division causes division by zero (fast-math mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88499 --- Comment #3 from Teodor Petrov --- @Marc Glisse: Would it be possible to give an explanation why this is not a good idea? Link to some kind of a documentation which explains that this behaviour is expected?
[Bug other/88499] Check for less than zero removed before floating point division causes division by zero (fast-math mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88499 --- Comment #1 from Teodor Petrov --- Here are the commands used to reproduce the bug: $ g++ -g -fPIC -Ofast -msse4.2 -std=c++11 -ffunction-sections -fdata-sections -ffast-math -fvisibility=hidden -fexceptions -Wno-c++11-extensions gcc_division.cpp $ ./a.out p=0.000; i=0 Floating point exception (core dumped) If I move the if-else which sets the y0 outside of the loop just after the printf call it works as expected and there is no SIGFPE.
[Bug other/88499] New: Check for less than zero removed before floating point division causes division by zero (fast-math mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88499 Bug ID: 88499 Summary: Check for less than zero removed before floating point division causes division by zero (fast-math mode) Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: fuscated at gmail dot com Target Milestone: --- Created attachment 45237 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45237=edit minimal source to reproduce the problem See the attached file. I've tried 4.8.2 and 8.2.0. on x86-64 Linux. Both failed with SIGFPE.
[Bug c++/70275] New: -w disables all -Werror flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70275
Bug ID: 70275
Summary: -w disables all -Werror flags
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fuscated at gmail dot com
Target Milestone: ---
It happens with all versions I have access to (4.4.7, 4.8.x, 4.9.x, 5.3.0).
To reproduce:
> cat c++noreturn.cpp
int test() {}
int main() {
return 0;
}
> g++-5.3.0 c++noreturn.cpp -Werror=return-type
c++noreturn.cpp: In function ‘int test()’:
c++noreturn.cpp:1:13: error: no return statement in function returning non-void
[-Werror=return-type]
int test() {}
^
cc1plus: some warnings being treated as errors
>
> g++-5.3.0c++noreturn.cpp -Werror=return-type -w
>
And the output of clang:
> clang++ c++noreturn.cpp -Werror=return-type -w
c++noreturn.cpp:1:13: error: control reaches end of non-void function
[-Werror,-Wreturn-type]
int test() {}
^
1 error generated.
For me the behaviour of clang is more predictable and the expected one.
Why we're disabling warnings is another matter. :)
[Bug c++/63619] warning: deleting ‘void*’ is undefined has no -W flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63619 --- Comment #4 from Teodor Petrov fuscated at gmail dot com --- FYI: clang fixed the same issue by adding it to -Wdelete-incomplete
[Bug c++/63619] New: warning: deleting ‘void*’ is undefined has no -W flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63619
Bug ID: 63619
Summary: warning: deleting ‘void*’ is undefined has no -W flag
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fuscated at gmail dot com
Save this snippet in delete_void.cpp
int main() {
void *a=new char[100];
delete [] a;
return 0;
}
$ g++ -fdiagnostics-show-option delete_void.cpp
delete_void.cpp: In function ‘int main()’:
delete_void.cpp:3:12: warning: deleting ‘void*’ is undefined
delete [] a;
^
The compiler poroduces a warning, but doesn't allow the user to turn it into
error and thus such bugs cannot be detected at compile time.
[Bug c++/63619] warning: deleting ‘void*’ is undefined has no -W flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63619 --- Comment #3 from Teodor Petrov fuscated at gmail dot com --- We already use -Werror=delete-incomplete, so it will be easier for us, because it will just work. But if you ask me (as a user) it is best to just change the standard to force these two as errors. I know this will never happen, but I have to murmur about it. BTW: Thanks for looking at this in such a short time :)
[Bug c++/58114] allow turning the warning about deleting a pointer of incomplete type into an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114 --- Comment #4 from Teodor Petrov fuscated at gmail dot com --- @Jonathan Wakely: Do you think the ISO C++ standard people will be willing to change this behaviour for a future standard? I'm asking in order to know if there is any point in starting a conversation with them.
[Bug c++/58114] allow turning the warning about deleting a pointer of incomplete type into an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114 Teodor Petrov fuscated at gmail dot com changed: What|Removed |Added CC||fuscated at gmail dot com --- Comment #1 from Teodor Petrov fuscated at gmail dot com --- This option is very important, because this warning allowed us to fix one serious leak in our application. And to prevent this problem to reappear in the future we want to force this warning to be error, but unfortunately we are not able when building with GCC. All other compilers we use have this feature. And btw in clang the option is named -Wdelete-incomplete, so you can reuse it to minimize the difference between the compilers. BTW: Do someone has an explanation why this is allowed in the standard?
[Bug other/19165] (Natural) language independent error / warning classification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 Teodor Petrov fuscated at gmail dot com changed: What|Removed |Added CC||fuscated at gmail dot com --- Comment #15 from Teodor Petrov fuscated at gmail dot com 2013-01-30 12:13:52 UTC --- I'm speaking as one of Code::Blocks' developers: If you implement this we'll for sure use it, because we have many complaints similar to the one Eclipse's developers have. (After one such complaint I've found this bug, by the way). Some suggestions: Don't pack the line/column info with the file name, if possible. So the proposed diagnostic from this: diagnostic class=error location=/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:10:8 inicializaci#65533;n de un miembro de matriz flexible en un contexto anidado /diagnostic will turn in to this, which will be easier to parse: diagnostic class=error location=/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c line=10 column=8 inicializaci#65533;n de un miembro de matriz flexible en un contexto anidado /diagnostic Also, if it is possible group the notes/instances info with the error/warning messages. This way it will allows us to show the information in a better way.
[Bug other/19165] (Natural) language independent error / warning classification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 --- Comment #17 from Teodor Petrov fuscated at gmail dot com 2013-01-30 20:34:00 UTC --- (In reply to comment #16) If you have some developer power to spare, it may be worthwhile to try to tackle this yourself. Otherwise I am afraid this will never be implemented in GCC. The patch in comment #10 is very rough and outdated, but the idea is simple. Copy diagnostic.c to diagnostic-xml.c and start modifying the output functions to emit XML. Probably, I can spare some time, but I don't have time to spare and be bothered with all the copyright assignments and other bureaucracy related things.
[Bug libstdc++/38238] New: std::tr1::bind fails to compile with pointer to member function
The following example fails to compile:
#include tr1/functional
#include stdio.h
using namespace std::tr1::placeholders;
class player
{
public:
void play(int time) { printf(player::play(%d);\n, time);}
void stop() { printf(player::stop();\n); }
};
int main()
{
player thePlayer;
std::tr1::bind(player::play, thePlayer, _1)(2);
return 0;
}
Here is the output of the compiler:
test_bind.cpp: In function int main():
test_bind.cpp:19: error: no match for call to
(std::tr1::_Bindstd::tr1::_Mem_fnvoid (player::*)(int) ()(player*,
std::tr1::_Placeholder1)) (int)
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1190:
note: candidates are: typename std::tr1::result_of_Functor ()(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args,
std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0)
()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) [with
_Args = int, _Functor = std::tr1::_Mem_fnvoid (player::*)(int), _Bound_args =
player*, std::tr1::_Placeholder1]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201:
note: typename std::tr1::result_ofconst _Functor ()(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args,
std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0)
()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) const
[with _Args = int, _Functor = std::tr1::_Mem_fnvoid (player::*)(int),
_Bound_args = player*, std::tr1::_Placeholder1]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213:
note: typename std::tr1::result_ofvolatile _Functor
()(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args,
std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0)
()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) volatile
[with _Args = int, _Functor = std::tr1::_Mem_fnvoid (player::*)(int),
_Bound_args = player*, std::tr1::_Placeholder1]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226:
note: typename std::tr1::result_ofconst volatile _Functor
()(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args,
std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0)
()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) const
volatile [with _Args = int, _Functor = std::tr1::_Mem_fnvoid
(player::*)(int), _Bound_args = player*, std::tr1::_Placeholder1]
The example compiles fine by replacing tr1::bind with boost::bind.
Best regards,
Teodor Petrov
--
Summary: std::tr1::bind fails to compile with pointer to member
function
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fuscated at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38238
