Bug#33975: [Bug c++/6905] Suggested g++ warning: changed semantics of conditional expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Sebor  ---
Resolving as Won't Fix due to no progress in 14+ years.  The standard rules are
now well established and so the usefulness of such a warning diminishes with
each passing year.

-- 
You are receiving this mail because:
You reported the bug.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #35 from Martin Sebor  ---
GCC 11 issues a warning when the address of an uninitialized variable is passed
to a function that takes a const pointer but it (still) doesn't warn when the
address escapes.  In both cases, it's possible for the called function to store
a value into the variable but because it's highly unlikely issuing a warning
regardless would be appropriate.  In addition, in cases where the address of
the variable doesn't escape until after the function call its value cannot be
affected even when the address is assigned to a non-const pointer.  The escape
analysis is flow insensitive so it alone cannot be relied on to make the
distinction.  But modifying variables this way is rare so issuing the warning
regardless is likely worthwhile.

$ cat a.c && gcc -O2 -S -Wall a.c
extern void f (const void*);

int g (void)
{
  int i;
  f (&i);   // -Wmaybe-uninitialized
  return i;
}

int h (void)
{
  extern const void *p;

  int i;
  f (0);
  p = &i;
  return i; // missing -Wmaybe-uninitialized
}

a.c: In function ‘int g()’:
a.c:6:5: warning: ‘i’ may be used uninitialized [-Wmaybe-uninitialized]
6 |   f (&i);
  |   ~~^~~~
a.c:1:13: note: by argument 1 of type ‘const void*’ to ‘void f(const void*)’
declared here
1 | extern void f (const void*);
  | ^
a.c:5:7: note: ‘i’ declared here
5 |   int i;
  |   ^

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||scott.d.phillips at intel dot 
com

--- Comment #36 from Martin Sebor  ---
*** Bug 78370 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug target/28314] cpp: x86/powerpc inconsistency for the __linux macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org
  Known to fail||4.1.2, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
This hasn't changed in 10 years.  Should the bug be closed as WONTFIX?

-- 
You are receiving this mail because:
You reported the bug.

[Bug target/28314] cpp: x86/powerpc inconsistency for the __linux macro

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
FWIW, while looking into this bug I couldn't find the topic discussed in the
LSB where I would expect this to be specified.  I did come across a couple of
sites on the web that gather this type of information.  The one below says that
__linux is obsolete, apparently because it doesn't conform to POSIX:

http://sourceforge.net/p/predef/wiki/OperatingSystems/

In XSH section 2.2.2 The Name Space, POSIX specifies that "all identifiers that
begin with an underscore and either an uppercase letter or another underscore
are always reserved for any use by the implementation."  So both __linux__ and
__linux should be fine.

That aside, since the macros are part of the GCC public interface (and they are
relied on by users) I would expect to see them documented in the GCC manual
(along with other OS identification macros such as _AIX).  Since, as Vincent
notes, they aren't, I think a new bug should be raised for that.

-- 
You are receiving this mail because:
You reported the bug.

[Bug target/28314] cpp: x86/powerpc inconsistency for the __linux macro

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I opened bug 69473 to document the macros.

-- 
You are receiving this mail because:
You reported the bug.