[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

2019-05-21 Thread vigerske at math dot hu-berlin.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

--- Comment #32 from Stefan Vigerske  ---
Is there any hope this could actually be improved?
Now, 10 years later, the FENV_ACCESS pragma seems to be implemented, but the
problem here seems to persist.

I run into this with GCC 8.3.0 and code like this:

#pragma STDC FENV_ACCESS ON

#include 
#include 
#include 

#include 

int main()
{
   double op;
   double down;
   double up;
   double near;

   op = atof("0.2");

   fesetround(FE_DOWNWARD);
   down = 1.0 / op;

   fesetround(FE_UPWARD);
   up = 1.0 / op;

   fesetround(FE_TONEAREST);
   near = 1.0 / op;

   printf("1/%.16g: down = %.16g near = %.16g up = %.16g\n", op, down, near,
up);

   assert(down <= 5.0);
   assert(down <= near);
   assert(near <= up);
   assert(5.0 <= up);

   return 0;
}


$ gcc -O3 -lm div.c && ./a.out 
1/0.2: down = 4.999 near = 4.999 up = 4.999
a.out: div.c:32: main: Assertion `5.0 <= up' failed.

Looking at the assembler code, I see that only the first divsd remains and the
other two were optimized away.

The Intel compiler 19.0.0.177 handles this better:
$ icc -O3 div.c -lm && ./a.out 
1/0.2: down = 4.999 near = 5 up = 5

[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib

2018-09-04 Thread vigerske at math dot hu-berlin.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182

Stefan Vigerske  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Stefan Vigerske  ---
Hmm, I think you are right!

With GCC 8.2.0, which I'm using, there still was AC_CHECK_LIB([z], [compress],
[]). The empty [] in the third argument does not seem to have the desired
effect of suppressing the addition of -lz to LIBS. It is still there:
https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure?revision=259610=markup#l12945

With revision 263320 from August 5, the third argument of AC_CHECK_LIB is
nontrivial and then -lz is not appended to LIBS anymore:
https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure?r1=259610=263320

Sorry, I didn't realize this behavior of AC_CHECK_LIBS, but the documentation
also says clearly that augmenting LIBS is only the default behavior if not
overwritten.

Then everything should be fine with the next GCC release.

[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib

2018-09-03 Thread vigerske at math dot hu-berlin.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182

--- Comment #5 from Stefan Vigerske  ---
The AC_CHECK_LIB([z], [compress], []) adds -lz to the LIBS variable in the
Makefile, if successful. This results in calling the libtool that builds
libbacktrace.la with -lz, which then results in having dependency_libs=' -lz'
in libbacktrace.la. The build of libgfortran(.so) picks this up, so that the
systems libz.so ends up as dependency of libgfortran.so.

If libbacktrace itself does not require zlib, then maybe -lz should not end up
in LIBS. I don't know what the preferred way to handle this is. One way is to
save LIBS before calling AC_CHECK_LIB and to restore it again afterwards.
However, the test executable would still need -lz.

[Bug libfortran/87182] New: libbacktrace does not use GCC own zlib

2018-09-01 Thread vigerske at math dot hu-berlin.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182

Bug ID: 87182
   Summary: libbacktrace does not use GCC own zlib
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vigerske at math dot hu-berlin.de
CC: ibuclaw at gdcproject dot org
  Target Milestone: ---

The configure of libbacktrace checks for -lz without considering the build of
zlib in ../../libz (the one that GCC builds). That is, libbacktrace introduces
a dependency on the systems zlib in libgfortran even if --with-system-zlib has
not been set.

It seems that this was introduced with rev 253275:
https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure.ac?r1=253095=253275
Rev 263320 does some cosmetic change
(https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure.ac?r1=256169=263320),
but doesn't fix this issue (imho).

[Bug c++/71274] New: deprecated static const member of struct raises warning without use

2016-05-25 Thread vigerske at math dot hu-berlin.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71274

Bug ID: 71274
   Summary: deprecated static const member of struct raises
warning without use
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vigerske at math dot hu-berlin.de
  Target Milestone: ---

When compiling the code

struct foo
{
   __attribute__ ((deprecated)) static const int a;
};

with GCC 6.1.1 (g++), it raises a deprecated-declaration warning:

dep.cpp:1:8: warning: ‘foo::a’ is deprecated [-Wdeprecated-declarations]
 struct foo
^~~
dep.cpp:3:50: note: declared here
__attribute__ ((deprecated)) static const int a;


This is unexpected to me, as the documentation says that "The deprecated
attribute results in a warning if the variable is used anywhere in the source
file.". But it is not used anywhere.