[Bug c/89573] -fexcess-precision=standard doesn't work for conversion to integer of multiplication

2019-03-15 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573

--- Comment #8 from Richard Biener  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=24346

[Bug c/89573] -fexcess-precision=standard doesn't work for conversion to integer of multiplication

2019-03-15 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #7 from Richard Biener  ---
(In reply to jos...@codesourcery.com from comment #6)
> On Thu, 14 Mar 2019, rguenther at suse dot de wrote:
> 
> > I see.  This means the different cases in the testcase in question are
> > not equivalent (when excess precision is involved) and thus the
> > expectation that they produce the same value is wrong which means the
> > bug is INVALID?
> 
> Yes.  With, again, the question of whether glibc should be avoiding 
> returning with excess precision from log and other libm functions (where 
> at present it only tries to avoid excess range, and excess precision for 
> fully-determined IEEE functions such as sqrt).

OK, so there's no GCC bug but forcing the glibc result to double "fixes"
the issue.  I'll re-file a glibc bug then.  For reference, the following
works as intended:

#include 
#include 

int main(int argc, char **argv)
{
  double p = 0.00053447623258905705;
  double inv_log_of_base = 1.41668185;

  volatile double lg = log(p);
  int r = lg * inv_log_of_base;
  printf("a: %d\n", r);

  double gr = log(p) * inv_log_of_base;
  printf("b: %g\n", gr);

  double g = log(p);
  int c = g * inv_log_of_base;
  printf("c: %d\n", c);

  return 0;
}

[Bug target/89719] [9 regression] gcc.target/aarch64/spellcheck_[456].c testsuite failures

2019-03-15 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89719

--- Comment #3 from Martin Liška  ---
(In reply to ktkachov from comment #2)
> I'll adjust the tests.

Thanks for it.

[Bug debug/89704] [7/8 Regression] ICE in add_const_value_attribute, at dwarf2out.c:19685

2019-03-15 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89704

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |add_const_value_attribute,  |add_const_value_attribute,
   |at dwarf2out.c:19685|at dwarf2out.c:19685

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug other/89712] [8/9 Regression] Documentation contains unsupported options (-fdump-class-hierarchy and -fdump-translation-unit)

2019-03-15 Thread 7aitsev at pm dot me 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712

--- Comment #6 from Maxim Zaitsev <7aitsev at pm dot me> ---
(In reply to Martin Liška from comment #2)
> @Maxim: I see -fdump-class-hierarchy[-n] mentioned in PDF manual. Where do
> you see -fdump-translation-unit mentioned in GCC 8.x documentation?

My apologies. Only `-fdump-class-hierarchy` was present in the docs, but
`-fdump-translation-unit` doesn't work too since it was replaced. I thought
that the change would be mentioned somewhere in the docs, but it's only my
assumption.

Thanks for quick response and fixing the issue!

[Bug debug/89704] [7/8/9 Regression] ICE in add_const_value_attribute, at dwarf2out.c:19685

2019-03-15 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89704

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 15 08:00:46 2019
New Revision: 269700

URL: https://gcc.gnu.org/viewcvs?rev=269700=gcc=rev
Log:
PR debug/89704
* dwarf2out.c (add_const_value_attribute): Return false for MINUS,
SIGN_EXTEND and ZERO_EXTEND.

* gcc.dg/debug/pr89704.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/pr89704.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

2019-03-15 Thread luoxhu at cn dot ibm.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509

Xiong Hu XS Luo  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #7 from Xiong Hu XS Luo  ---
Hi Richard, trying to figure out the issue recently, but get some questions
need your help. How is the status of the "proposed simple lowering of bitfield
accesses on GIMPLE", please? 
for "less conservative about DECL_BIT_FIELD_REPRESENTATIVE", do you mean we
choose large mode in GIMPLE stage, and make the decision when in target?
Thanks.

PS: As a newbie, can you tell how did you do to "Widening the representative"
:),  I am a bit confused about the best mode and where to process it, sometimes
big mode is better and sometimes smaller mode is better(from Segher's
comments).

<    1   2