--- Comment #18 from manu at gcc dot gnu dot org 2008-08-23 15:59 ---
(In reply to comment #0)
Compiling the following with -Wunreachable-code -D_GLIBCXX_DEBUG
--
#include vector
int main()
{
std::vectorint::iterator a;
}
--
--- Comment #19 from manu at gcc dot gnu dot org 2008-08-23 16:01 ---
(In reply to comment #4)
Here is a minimal code example:
#include new
int* get_ptr(void* ptr)
{
return new(ptr) int();
}
I can reproduce this, though.
--
--- Comment #20 from manu at gcc dot gnu dot org 2008-08-23 16:13 ---
For testcase in comment #4 I get 2 warnings now:
home/manuel/test2/src/gcc/testsuite/g++.dg/warn/pr31246-2.C: In function int*
get_ptr(void*):
/home/manuel/test2/src/gcc/testsuite/g++.dg/warn/pr31246-2.C:8:
--- Comment #21 from manu at gcc dot gnu dot org 2008-08-23 16:21 ---
If gimple stmts do not have the equivalent of DECL_ARTIFICIAL, then the C++
front-end should use gimple_set_no_warning(stmt) when generating such
constructs. So, anyone knows where this comes from?
--
--- Comment #22 from manu at gcc dot gnu dot org 2008-08-23 17:24 ---
In addition, __cxa_call_unexpected should probably have both TREE_NO_WARNING
and DECL_ARTIFICIAL set but this is orthogonal because at the point of the
warning we should not be testing that.
--
--- Comment #23 from paolo dot carlini at oracle dot com 2008-08-23 18:43
---
To be clear, there are no #pragma GCC system_header at all in the entire
libsupc++ directory. I hope we don't have to begin...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-19 13:56 ---
(In reply to comment #8)
I agree with you Paolo. The front-end should make sure that its
artefacts don't adversily affect diagnostics we emit.
I agree to some extend. The reason why the try/catch is there is
--- Comment #10 from gdr at cs dot tamu dot edu 2007-03-19 15:19 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| And I think that we should not warn about generated code. No matter if it is
| generated by
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-19 22:31
---
(In reply to comment #10)
I fully agree.
I am not agreeing fully, This warning is only because we can prove something
is pure/const/cannot throw and that only comes because of simple optimization.
What about
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #10)
|
| I fully agree.
|
| I am not agreeing fully,
Well, you've got a problem.
[...]
| What about this case:
There is a distinction betwen user code and compiler-generated codes.
Warning about
--- Comment #12 from gdr at cs dot tamu dot edu 2007-03-19 22:45 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #10)
|
| I fully agree.
|
| I am not agreeing fully,
Well,
--- Comment #13 from manu at gcc dot gnu dot org 2007-03-19 23:13 ---
Andrew, as you say, -Wunreachable-code is not enabled by -Wall. The user has to
give it explicitly. And in your testcases the code is not reachable. So in that
case, it could be argued whether the warning is warranted
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-19 23:18
---
But the user can see the code, it is what is produced by what the C++ standard
says is produced, now you could say the user has no control over fixing it, it
is also true with the template case. Both cases are
--- Comment #15 from manu at gcc dot gnu dot org 2007-03-19 23:35 ---
Andrew, you have Paolo and Gabriel expressing that the warning should not be
emitted because the code is generated. Then you close as wontfix. Sometimes I
don't understand you at all.
--
--- Comment #16 from gdr at cs dot tamu dot edu 2007-03-19 23:40 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| But the user can see the code,
Andrew --
When you don't understand an issue, please
--- Comment #17 from pcarlini at suse dot de 2007-03-19 23:43 ---
WONTFIX is simply ridicolous.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2007-03-17 20:48 ---
And I'm recategorizing as C++: either (as I strongly believe) a very general
diagnostic issue, or maybe a duplicate of C++/30500: certainly there is nothing
we can do on the library side to fix the implementation of
--- Comment #7 from gdr at cs dot tamu dot edu 2007-03-17 23:35 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Note, however, that, as far as I can see, such try/catch are *not* in the
| library code proper,
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 05:38 ---
I agree with you Paolo. The front-end should make sure that its
artefacts don't adversily affect diagnostics we emit.
I agree to some extend. The reason why the try/catch is there is because of
what the C++
19 matches
Mail list logo
