https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to Jason Merrill from comment #22)
> It could be done specifically for uses in mem-initializers by walking the
> initializer in perform_mem_init to look for any references to members that
> h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2005-05-09 00:52:15 |2014-9-27
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jonathan Wakely changed:
What|Removed |Added
CC||nishant.031 at gmail dot com
--- Commen
--- Comment #19 from bart dot vanassche at gmail dot com 2010-02-25 07:05
---
(In reply to comment #17)
> (In reply to comment #15)
> > Alternatively, the C++ front-end could create an uninitialized variable for
> > each member variable. Initialize those, then, at the very end of the
>
--- Comment #18 from bart dot vanassche at gmail dot com 2010-02-25 07:00
---
(In reply to comment #16)
> (In reply to comment #14)
> > > (In reply to comment #8)
> > > > Incidentally, perhaps we should mark the this parameter as __restrict...
> >
> > I don't see how this would be corr
--- Comment #17 from jason at gcc dot gnu dot org 2010-02-24 20:45 ---
(In reply to comment #15)
> Alternatively, the C++ front-end could create an uninitialized variable for
> each member variable. Initialize those, then, at the very end of the
> constructor, assigned each clone variabl
--- Comment #16 from jason at gcc dot gnu dot org 2010-02-24 20:44 ---
(In reply to comment #14)
> > (In reply to comment #8)
> > > Incidentally, perhaps we should mark the this parameter as __restrict...
>
> I don't see how this would be correct (or useful).
Hmm, I suppose it is possi
--- Comment #15 from manu at gcc dot gnu dot org 2010-02-24 20:30 ---
(In reply to comment #12)
> Is there nothing pointed by this that could be initialized before calling the
> > constructor?
>
> Nothing.
Then for sure someone can write a generic/gimple pass that detects this case
bef
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-02-24 20:22
---
(In reply to comment #11)
> (In reply to comment #8)
> > What else could it be than a pointer? It might be possible to mark it
> > somehow
> > so that the middle end knows to consider the referent uninitialized.
--- Comment #13 from manu at gcc dot gnu dot org 2010-02-24 20:14 ---
(In reply to comment #9)
>
> I'd close this one as WONTFIX or mark it as dup of a "do uninitialized
> variable warnings for memory".
>
Please no, this perhaps could still be implemented in the C++ front-end for
this
--- Comment #12 from jason at gcc dot gnu dot org 2010-02-24 20:12 ---
(In reply to comment #11)
> (In reply to comment #8)
> > What else could it be than a pointer? It might be possible to mark it
> > somehow
> > so that the middle end knows to consider the referent uninitialized.
>
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-24 19:44 ---
(In reply to comment #8)
> What else could it be than a pointer? It might be possible to mark it somehow
> so that the middle end knows to consider the referent uninitialized.
This is because (this) must be allocated
--- Comment #10 from bart dot vanassche at gmail dot com 2010-02-24 19:10
---
(In reply to comment #9)
> I think there is no reasonable way to get reliable uninitialized variable
> warnings for incoming pointed-to memory. The only way we can warn here
> is by inlining the constructor i
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-24 18:04 ---
(In reply to comment #8)
> What else could it be than a pointer? It might be possible to mark it somehow
> so that the middle end knows to consider the referent uninitialized.
>
> Incidentally, perhaps we should ma
--- Comment #8 from jason at gcc dot gnu dot org 2010-02-24 16:43 ---
What else could it be than a pointer? It might be possible to mark it somehow
so that the middle end knows to consider the referent uninitialized.
Incidentally, perhaps we should mark the this parameter as __restrict
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-24 12:59 ---
This usage could be warned in the front-end. Specially because the SSA form
looks like:
S::S() (struct SD.2093 * const thisD.2102)
{
intD.2 D.2131;
# BLOCK 2, starting at line 6
# PRED: ENTRY (fallthru)
[pr198
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-24 12:46 ---
*** Bug 43163 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from manu at gcc dot gnu dot org 2008-07-21 14:30 ---
*** Bug 36866 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from myselfhimself at free dot fr 2007-12-04 21:03 ---
*** Bug 34307 has been marked as a duplicate of this bug. ***
--
myselfhimself at free dot fr changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-02 12:58 ---
*** Bug 26072 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
21:56 ---
This is related to PR 2972 and PR 18016.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Additional Comments From bangerth at dealii dot org 2005-02-07 21:53
---
Confirmed. We should get a warning for this code, but don't:
--
struct S
{
int i, j;
S() : i(j), j(1) {}
};
S s;
---
W.
--
What|Remo
23 matches
Mail list logo
