https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
Andrew Pinski changed:
What|Removed |Added
Known to fail||
Known to work|
--- Comment #35 from manu at gcc dot gnu dot org 2009-04-18 09:29 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|3792
--- Comment #34 from manu at gcc dot gnu dot org 2009-04-18 09:25 ---
Subject: Bug 36902
Author: manu
Date: Sat Apr 18 09:24:45 2009
New Revision: 146305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146305
Log:
2009-04-18 Manuel López-Ibáñez
PR middle-end/36902
--- Comment #33 from manu at gcc dot gnu dot org 2008-11-18 16:05 ---
(In reply to comment #32)
> (In reply to comment #31)
> > I submitted the patch long ago. We are in regressions-only mode. This is
> > not a
> > regression. Not sure what else you want me to do.
>
> I'm not sure eith
--- Comment #32 from paolo dot carlini at oracle dot com 2008-11-18 15:47
---
(In reply to comment #31)
> I submitted the patch long ago. We are in regressions-only mode. This is not a
> regression. Not sure what else you want me to do.
I'm not sure either ;) Maybe you could just work
--- Comment #31 from manu at gcc dot gnu dot org 2008-11-18 15:43 ---
(In reply to comment #30)
> Thanks Manuel. I'm not sure that this is technically a regression, but in any
> case I consider it a serious problem and really hope we can have a fix for
> 4.4.0.
I submitted the patch lon
--- Comment #30 from paolo dot carlini at oracle dot com 2008-11-18 15:25
---
Thanks Manuel. I'm not sure that this is technically a regression, but in any
case I consider it a serious problem and really hope we can have a fix for
4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #29 from manu at gcc dot gnu dot org 2008-11-18 15:21 ---
There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01117.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #28 from hjl dot tools at gmail dot com 2008-11-18 14:42
---
(In reply to comment #27)
> Isn't this a regression?
>
The warning is new. But the same code won't compile with -Wall while
gcc 4.1 has no problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #27 from paolo dot carlini at oracle dot com 2008-11-18 10:16
---
Isn't this a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #26 from pinskia at gcc dot gnu dot org 2008-11-15 00:07
---
*** Bug 35392 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #25 from pinskia at gcc dot gnu dot org 2008-10-27 00:17
---
*** Bug 37921 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #24 from hjl dot tools at gmail dot com 2008-10-26 22:06
---
*** Bug 37921 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #23 from manu at gcc dot gnu dot org 2008-08-25 10:50 ---
(In reply to comment #22)
> there is currently no good way to detect if a block is dead during the VRP
> pass, as the VRP information is used for *determining* wether or not a block
> is
> dead.
I think in this case
--- Comment #22 from mueller at gcc dot gnu dot org 2008-08-25 07:59
---
there is currently no good way to detect if a block is dead during the VRP
pass, as the VRP information is used for *determining* wether or not a block is
dead.
Is there a general warning-queuing implementation t
--- Comment #21 from manu at gcc dot gnu dot org 2008-08-22 17:54 ---
(In reply to comment #19)
> (In reply to comment #18)
> > I think that if the compiler knows that the code is never executed then, we
> > shouldn't warn.
>
> It does but only later on in the optimization it knows tha
--- Comment #20 from hjl dot tools at gmail dot com 2008-08-22 17:37
---
(In reply to comment #19)
> (In reply to comment #18)
> > I think that if the compiler knows that the code is never executed then, we
> > shouldn't warn.
>
> It does but only later on in the optimization it knows
--- Comment #19 from pinskia at gcc dot gnu dot org 2008-08-22 17:30
---
(In reply to comment #18)
> I think that if the compiler knows that the code is never executed then, we
> shouldn't warn.
It does but only later on in the optimization it knows that the code is dead.
--
http
--- Comment #18 from manu at gcc dot gnu dot org 2008-08-22 17:04 ---
(In reply to comment #1)
> This happens because the warning happens very early in the compiler so it does
> not know that the case5 is not going to be used. I think the warning is
> correct and not really bogus if you
--- Comment #17 from manu at gcc dot gnu dot org 2008-08-22 16:44 ---
The location passed to check_array_ref is correct but the new way to check if
we are in system headers does not work well with the %H hack. This will go away
soon hopefully when everything takes an explicit location.
--- Comment #16 from paolo dot carlini at oracle dot com 2008-08-15 20:36
---
No news, Manuel, still unsuppressed by the pragma
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #15 from manu at gcc dot gnu dot org 2008-08-15 20:18 ---
GCC system_headers should suppress this warning now, doesn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #14 from manu at gcc dot gnu dot org 2008-08-15 20:11 ---
(In reply to comment #13)
> You see, as I feared: this class of warnings coming from the middle-end is
> especially nasty, because cannot be suppressed by any normal means.
What location is being passed to that warnin
--- Comment #13 from paolo dot carlini at oracle dot com 2008-07-23 01:28
---
You see, as I feared: this class of warnings coming from the middle-end is
especially nasty, because cannot be suppressed by any normal means.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-23 01:23
---
(In reply to comment #11)
> Thanks. Actually, I think the experiment would be more meaningful if you could
> put also the equivalent of your main (a calling function, that is) inside the
> header, because in your t
--- Comment #11 from paolo dot carlini at oracle dot com 2008-07-23 01:16
---
Thanks. Actually, I think the experiment would be more meaningful if you could
put also the equivalent of your main (a calling function, that is) inside the
header, because in your testcase the warning is trig
--- Comment #10 from hjl dot tools at gmail dot com 2008-07-23 01:04
---
(In reply to comment #9)
> > I said "It comes from an application." It isn't from system header file.
>
> Yes, and that doesn't answer my question. I asked if the pragma is able to
> suppress a warning triggered b
--- Comment #9 from paolo dot carlini at oracle dot com 2008-07-22 22:53
---
> I said "It comes from an application." It isn't from system header file.
Yes, and that doesn't answer my question. I asked if the pragma is able to
suppress a warning triggered by your kind of snippet, IF, w
--- Comment #8 from hjl dot tools at gmail dot com 2008-07-22 21:42 ---
(In reply to comment #7)
> (In reply to comment #6)
> > It comes from an application.
>
> This doesn't answer my question.
>
I said "It comes from an application." It isn't from system header file.
--
http:/
--- Comment #7 from paolo dot carlini at oracle dot com 2008-07-22 21:32
---
(In reply to comment #6)
> It comes from an application.
This doesn't answer my question.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #6 from hjl dot tools at gmail dot com 2008-07-22 21:30 ---
(In reply to comment #4)
> Out of curiosity: if this kind of code appears in a system header, is #pragma
> GCC system_header able to suppress the warning? Of course I'm asking because
> this is the most annoying feat
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-22 21:29 ---
It is a regression since the same correct code no longer compiles
with "-Werror -Wall" after upgrading from gcc 4.1/4.2 to 4.3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-22 21:26
---
Out of curiosity: if this kind of code appears in a system header, is #pragma
GCC system_header able to suppress the warning? Of course I'm asking because
this is the most annoying feature of PR 36633 (which im
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-22 21:18 ---
> The warning is very fragile: if the buffer in main() is not static then
> there is no failure; is the size is passed as a constant there is no error.
Not really, if you read my comment, you will understand why th
34 matches
Mail list logo
