[Bug c/39731] New: Separate warning classes for maybe-uninitialized and known-uninitialized variables.

[scottwood at freescale dot com]

It would be nice to provide separate -W flags for the "is used uninitialized"
and "may be used uninitialized" variants of -Wuninitialized.  The former is 
always a problem, while the latter is often noise.

See this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070540.html


-- 
   Summary: Separate warning classes for maybe-uninitialized and
known-uninitialized variables.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scottwood at freescale dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731

[Bug middle-end/39731] Separate warning classes for maybe-uninitialized and known-uninitialized variables.

[scottwood at freescale dot com]

--- Comment #2 from scottwood at freescale dot com  2009-04-16 18:30 ---
(In reply to comment #1)
> >The problem is that GCC does not give an error
> 
> It can't give an error for that code as it is only runtime undefined and it
> does not have to be invoked at runtime (i.e. the function is not called).
> 
> -- Pinski
> 

Yes, that was pointed out in the thread -- hence the request simply being a
separation of warning classes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731

[Bug target/69617] PowerPC/e6500: Atomic byte/halfword operations not properly supported

[scottwood at freescale dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69617

Scott wood  changed:

   What|Removed |Added

 CC||scottwood at freescale dot com

--- Comment #1 from Scott wood  ---
Decorated storage (lbdx and such) requires cache-inhibited memory, and the
operations are defined by each SoC rather than by the e6500 core -- this makes
it unusable by GCC.  The non-decorated l[bh]arx/st[bh]cx. could be used,
though.

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[scottwood at freescale dot com]

--- Comment #11 from scottwood at freescale dot com  2008-05-13 21:13 
---
(In reply to comment #4)
> If your code invokes undefined behavior, how is gcc going
> to read your mind?

If GCC can tell that it is undefined behavior, then warning the user is more
useful than silently producing nasal demons, regardless of what might be in the
user's mind.  "The spec allows us to do something stupid" doesn't mean "we
should do something stupid".

> Maybe the programmer meant to enter
> an infinite, so a warning isn't correct.

If it's undefined behavior, then too bad, right?  I have a really hard time
seeing how one would derive such intent from the above code, though -- or
imagining what GCC is doing that made it think that generating the code it does
is a good idea.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124