[Bug libstdc++/45257] New: struct in6_pktinfo is guarded by __USE_GNU macro

[murtadha at ca dot ibm dot com]

The reduced code below used to successfully compile on previous releases of
GCC. I can get this code to compile with GCC 4.1.2, but when I try it with GCC
4.3.4, I get the following error message:
a.c: In function 'main':
a.c:4: error: storage size of 'test' isn't known

Clearly, this is happening because the struct in6_pktinfo is not defined
anywhere before a variable of that type is declared. Looking into the header
file, the struct definition is guarded by a macro __USE_GNU. I have come to
understand that to get this macro defined (thus get the struct defined), one
would define the macro _GNU_SOURCE before including the GCC header files. This
way, types like the in6_pktinfo struct can be defined.
However, this is causing compiler failures for us, and it's not feasible for us
to define this macro (whether on command line, or inside source code) files.
Please take a look and see if this change is unavoidable, and whether there is
a way to reverse it.

Reduced Source Code:
#include 
int main()
{
struct in6_pktinfo test;
}


-- 
   Summary: struct in6_pktinfo is guarded by __USE_GNU macro
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: murtadha at ca dot ibm dot com


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

[Bug c/45620] New: GCC library allows the use of a negative value for 'NAN'

[murtadha at ca dot ibm dot com]

Looking at the source code below, ompiling and linking without any extra
options, one would expect the output of execution to be:
c = nan

And that is correct for GCC on RHEL5 and SLES10, with version 4.1.2. However,
on RHEL6 and SLES11, starting with GCC version 4.3.4, the output is the
following:
c = -nan

Which doesn't make much sense, since you can't really have a negative NAN.
At the same time, when the code is compiled on RHEL5, and ran on RHEL6, the
output still shows a negative NAN. It turns out that only compiling and linking
statically (with -static) allows the results of RHEL5 to be achieved on RHEL6,
and vice versa. This tells us that the libraries are responsible for this
change.

CODE:
/* File name a.c */
int main()
{
double a = 0.0;
double c = -(a/a);
printf("c = %f\n", c);
}

COMPILE:
gcc a.c

RUN:
./a.out

EXPECTED RESULTS: (identical to previous release of GCC)
c = nan

ACTUAL RESULTS: (starting with GCC 4.3.4)
c = -nan


-- 
   Summary: GCC library allows the use of a negative value for 'NAN'
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: murtadha at ca dot ibm dot com


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

[Bug c/45620] GCC library allows the use of a negative value for 'NAN'

[murtadha at ca dot ibm dot com]

--- Comment #2 from murtadha at ca dot ibm dot com  2010-09-09 20:21 ---
How do I open a glibc bug?
Although you say that the sign bit is set, thus you can have a negative NAN.
But it does not make much sense to allow this. A negative not-a-number is not
mathematically sensible. It wasn't the case in previous releases of the
library, so why did it just suddenly change? This change is causing some of our
code to break, so we would like to investigate it more before we are able to
change code to accommodate new changes.


-- 


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