[Bug tree-optimization/89135] [7/8/9 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|internal compiler error: in |[7/8/9 Regression] internal
   |gimple_split_edge, at   |compiler error: in
   |tree-cfg.c:2747 |gimple_split_edge, at
   ||tree-cfg.c:2747
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r246500.  Note, GCC 6 is not supported anymore.
Reduced testcase:
typedef __INTPTR_TYPE__ intptr_t;
intptr_t a, b, c, d;
int foo (void) { return 0; }
int baz (void);

void
bar (void) {
  intptr_t g = (intptr_t) &&h;
  void *i = &&j, *k = &&l;
j:
  if (baz ()) {
intptr_t **n = (intptr_t **) &a;
  l:
b = 0;
for (; b >= 0;)
  goto *k;
  h:
**n = 0;
for (;;) {
  intptr_t *o = &c;
  g = foo ();
  *o = g;
  if (c)
goto *d;
}
  }
  goto *i;
}

[Bug rtl-optimization/89115] compile time and memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 31 08:09:59 2019
New Revision: 268414

URL: https://gcc.gnu.org/viewcvs?rev=268414&root=gcc&view=rev
Log:
2019-01-31  Richard Biener  

PR rtl-optimization/89115
* lra.c (lra_rtx_hash): Properly hash CONST_INT values.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c

[Bug c++/89119] [7/8 Regression] internal compiler error: in tsubst_copy with RANGE_EXPR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||9.0

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||andreast at gcc dot gnu.org,
   ||gp at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
The middle-end transforms sin/cos to cexp which means C99 support is required.
cexp is then eventually expanded as sincos if the target advertises support
via targetm.libc_has_function (function_sincos) or there is an optab handler
(x87 has sincos IIRC).  If sincos isn't available but the target is C99 we
emit a call to cexp() which hopefully has an optimized path when passed
a realpart zero (the glibc libm does).

FreeBSD folks - can you adjust your targets config if appropriate?

[Bug sanitizer/89124] __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 31 08:20:45 2019
New Revision: 268415

URL: https://gcc.gnu.org/viewcvs?rev=268415&root=gcc&view=rev
Log:
PR sanitizer/89124
* ipa-inline.c (sanitize_attrs_match_for_inline_p): Allow inlining
always_inline callees into no_sanitize_address callers.

* c-c++-common/asan/pr89124.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr89124.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0

[Bug sanitizer/89124] __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for GCC9+.

[Bug tree-optimization/89135] [7/8/9 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
I will have a looksee.

[Bug libstdc++/88170] [9 Regression] pretty printer FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/89135] [7/8/9 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747

[gsocshubham at gmail dot com]

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

--- Comment #3 from Shubham Narlawar  ---
I could reproduce the ICE on gcc-8.2 but not on trunk.

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
The issue is that GCC cannot prove finiteness of the loop since inc(i) could
just return i itself.  So I can't see how this optimization would be correct.

Note the loop isn't unswitched but only path-splitting exposes it.

And cddce then rightfully complains:

cannot prove finiteness of loop 2
Marking useful stmt: if (n_7(D) > i_10)

cannot prove finiteness of loop 1
Marking useful stmt: if (n_7(D) > i_16)

[Bug rtl-optimization/89115] compile time and memory hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
  Known to fail|9.0 |

--- Comment #7 from Richard Biener  ---
On trunk compile-time at -O1 should now be reasonable, currently testing
backports.  The DSE issue still exists at -O2+ but compared to the LRA issue
it was "minor".

[Bug other/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS

[drikosev at gmail dot com]

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

--- Comment #3 from Ev Drikos  ---
Created attachment 45573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45573&action=edit
program output & gcc configuration in Yosemite

[Bug other/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS

[drikosev at gmail dot com]

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

--- Comment #4 from Ev Drikos  ---
Created attachment 45574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45574&action=edit
program output & gcc configuration in Sierra

Hello,

Having run this small test in older systems also, Yosemite (10.11) and sierra
(10.12), 
I see that the results vary. I can reproduce the problem in Yosemite, not in
Sierra.

IMHO opinion, this issue depends either on GNU GCC configuration or to some
patch
I've applied in the meantime. My guess is that the reason is likely the
configuration.

Ev. Drikos

[Bug c++/84733] [8/9 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P4  |P3
   Severity|minor   |normal

--- Comment #15 from Paolo Carlini  ---
Given the snippet in Comment #10 this is also an ice-on-valid-code.

[Bug fortran/81651] Enhancement request: have f951 print out fully qualified module file name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
What is a "fully qualified module name"?

[Bug rtl-optimization/89115] compile time and memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 31 10:00:26 2019
New Revision: 268416

URL: https://gcc.gnu.org/viewcvs?rev=268416&root=gcc&view=rev
Log:
2019-01-31  Richard Biener  

Backport from mainline
2019-01-31  Richard Biener  

PR rtl-optimization/89115
* lra.c (lra_rtx_hash): Properly hash CONST_INT values.

2019-01-30  Richard Biener  

PR rtl-optimization/89115
* opts.c (default_options_optimization): Reduce
PARAM_MAX_DSE_ACTIVE_LOCAL_STORES by a factor of 10 at -O1.
Make PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP reduction relative
to the default.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/lra.c
branches/gcc-8-branch/gcc/opts.c

[Bug libbacktrace/89136] New: libbacktrace/elf.c:2941: suspicious assignment

[dcb314 at hotmail dot com]

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

Bug ID: 89136
   Summary: libbacktrace/elf.c:2941: suspicious assignment
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: ian at gcc dot gnu.org
  Target Milestone: ---

libbacktrace/elf.c:2941:30: warning: use of unary operator that may be intended
as compound assignment (+=)

Source code is

 debugaltlink_name_len =+ 1;

maybe 

 ++debugaltlink_name_len;

was intended.

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
svn blame says

267992  vries debugaltlink_name_len =+ 1;

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #19 from nsz at gcc dot gnu.org ---
that code was there for a reason.. now aarch64 fails because it cannot detect
if the flags are supported or not.

so if detection is turned off then on aarch64 "supports trapping" should always
be false and likewise on any target that allows an implementation without
trapping exceptions.

[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE:   |[8 Regression] ICE:
   |Segmentation fault  |Segmentation fault
   |(ovl_first()/location_of()) |(ovl_first()/location_of())

--- Comment #4 from Paolo Carlini  ---
Trunk doesn't ICE anymore.

[Bug go/89123] Too many go test failures on s390x-linux

[rdapp at linux dot ibm.com]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #4 from rdapp at linux dot ibm.com ---
I'm going to have a look.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[ubizjak at gmail dot com]

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

--- Comment #20 from Uroš Bizjak  ---
(In reply to nsz from comment #19)
> that code was there for a reason.. now aarch64 fails because it cannot
> detect if the flags are supported or not.
> 
> so if detection is turned off then on aarch64 "supports trapping" should
> always be false and likewise on any target that allows an implementation
> without trapping exceptions.

Yes. Please return 0 under appropriate ifdef.

[Bug libgomp/89137] New: gcc/omp-low.c:7135: possible read of uninit memory ?

[dcb314 at hotmail dot com]

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

Bug ID: 89137
   Summary: gcc/omp-low.c:7135: possible read of uninit memory ?
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

gcc/omp-low.c:7135:13: warning: variable 'c' is used uninitialized whenever
'if' condition is false [-Wsometimes-uninitialized]

Source code is

  tree c;
  tree lab5 = create_artificial_label (UNKNOWN_LOCATION);
  tree lab6 = create_artificial_label (UNKNOWN_LOCATION);
  lab3 = create_artificial_label (UNKNOWN_LOCATION);
  if (code == OMP_FOR)
c = gimple_omp_for_clauses (ctx->stmt);
  else if (code == OMP_SECTIONS)
c = gimple_omp_sections_clauses (ctx->stmt);
  c = OMP_CLAUSE_DECL (omp_find_clause (c, OMP_CLAUSE__REDUCTEMP_));

Might it be worthwhile to put in extra code for the case where
local variable code isn't one of the expected values ?

Maybe

 else
 assert( 0); /* Shouldn't get here */

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[nsz at gcc dot gnu.org]

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

--- Comment #21 from nsz at gcc dot gnu.org ---
this fix undid the change for bug 78314
do you plan to backport it to gcc 7,8 branches ?

note that in principle on targets where trapping is not supported
the "immediate alternate exception handling" mechanism of ieee 754
can be emulated by save/clear/check/restore status flags around each
fp operation, but i don't think gcc currently supports that
(and it's not very practical unless somebody uses it for debugging
fp issues).

[Bug libgomp/89137] gcc/omp-low.c:7135: possible read of uninit memory ?

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
As this is all in
if (code == OMP_FOR || code == OMP_SECTIONS)
guarded block, that warning is obviously a false positive.
I guess I can just drop the " if (code == OMP_SECTIONS)" to make it happy.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[ubizjak at gmail dot com]

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

--- Comment #22 from Uroš Bizjak  ---
(In reply to nsz from comment #21)
> this fix undid the change for bug 78314
> do you plan to backport it to gcc 7,8 branches ?
> 
> note that in principle on targets where trapping is not supported
> the "immediate alternate exception handling" mechanism of ieee 754
> can be emulated by save/clear/check/restore status flags around each
> fp operation, but i don't think gcc currently supports that
> (and it's not very practical unless somebody uses it for debugging
> fp issues).

IMO, the PR78314 fix was wrong. As is the case with real HW support, there can
be exception flags already set in the status register, and trying to determine
support for traps by enabling and disabling the mask will surely trigger the
trap.

This approach from PR78314 triggers traps on x86 and PowerPC. The former
doesn't use fpu-glibc.h, so it was immune to the PR78314 change.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[ubizjak at gmail dot com]

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

--- Comment #23 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #22)
> (In reply to nsz from comment #21)
> > this fix undid the change for bug 78314
> > do you plan to backport it to gcc 7,8 branches ?

Yes, I'd like to backport the fix to other branches, but only after all issues
are ironed out in the trunk.

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-31
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01780.html

[Bug c++/89138] New: ICE on valid C++11 code: in expand_expr_real_1, at expr.c:9993

[su at cs dot ucdavis.edu]

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

Bug ID: 89138
   Summary: ICE on valid C++11 code: in expand_expr_real_1, at
expr.c:9993
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The test seems to cause all versions since 4.x to crash. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190130 (experimental) [trunk revision 268383] (GCC) 
$ 
$ clang++ -std=c++11 -c tmp.cpp
$ 
$ g++tk -c tmp.cpp
during RTL pass: expand
tmp.cpp: In lambda function:
tmp.cpp:6:22: internal compiler error: in expand_expr_real_1, at expr.c:9993
6 |   [&] { __typeof (b) c; } ();
  |  ^
0xb4094b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:9987
0xb57c2c expand_expr
../../gcc-source-trunk/gcc/expr.h:279
0xb57c2c expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-source-trunk/gcc/expr.c:8484
0xa088c0 expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3790
0xa088c0 expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3850
0xa0c44b expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5886
0xa11e36 execute
../../gcc-source-trunk/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





int a = 1;

void f ()
{
  int b[a];
  [&] { __typeof (b) c; } ();
}

[Bug middle-end/89137] gcc/omp-low.c:7135: possible read of uninit memory ?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
and keep it as comment

[Bug tree-optimization/89135] [7/8/9 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 31 11:51:59 2019
New Revision: 268417

URL: https://gcc.gnu.org/viewcvs?rev=268417&root=gcc&view=rev
Log:
2019-01-31  Richard Biener  

PR tree-optimization/89135
* tree-ssa-phiprop.c (pass_phiprop::execute): Skip blocks
with abnormal preds.

* gcc.dg/torture/pr89135.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr89135.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiprop.c

[Bug tree-optimization/89135] [7/8 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] internal |[7/8 Regression] internal
   |compiler error: in  |compiler error: in
   |gimple_split_edge, at   |gimple_split_edge, at
   |tree-cfg.c:2747 |tree-cfg.c:2747

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug fortran/81651] Enhancement request: have f951 print out fully qualified module file name

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #2)
> What is a "fully qualified module name"?

Error: Module file /full/path/to/module/mymodule.mod is bletchful.

[Bug rtl-optimization/89115] compile time and memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 31 12:05:19 2019
New Revision: 268418

URL: https://gcc.gnu.org/viewcvs?rev=268418&root=gcc&view=rev
Log:
2019-01-31  Richard Biener  

Backport from mainline
2019-01-31  Richard Biener  

PR rtl-optimization/89115
* lra.c (lra_rtx_hash): Properly hash CONST_INT values.

2019-01-30  Richard Biener  

PR rtl-optimization/89115
* opts.c (default_options_optimization): Reduce
PARAM_MAX_DSE_ACTIVE_LOCAL_STORES by a factor of 10 at -O1.
Make PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP reduction relative
to the default.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/lra.c
branches/gcc-7-branch/gcc/opts.c

[Bug rtl-optimization/89115] compile time and memory hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1, 8.2.1
 Resolution|--- |FIXED
  Known to fail|8.2.1   |7.4.0, 8.2.0

--- Comment #10 from Richard Biener  ---
Fixed for GCC 7.5/8.3.

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Thu Jan 31 12:17:32 2019
New Revision: 268419

URL: https://gcc.gnu.org/viewcvs?rev=268419&root=gcc&view=rev
Log:
[libbacktrace] Fix .gnu_debugaltlink build-id check

The 'debugaltlink_name_len =+ 1' bug reported in PR89136 exposes the fact that
the build-id is not verified for the .gnu_debugaltlink.

Fix both problems.

2019-01-31  Tom de Vries  

PR libbacktrace/89136
* elf.c (elf_add): Read build-id if with_buildid_data.  Fix
'debugaltlink_name_len =+ 1'.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/elf.c

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Shouldn't we have a warning for this =+ vs. += case (of course, =- is fine)?

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from Tom de Vries  ---
(In reply to David Binderman from comment #1)
> svn blame says
> 
> 267992  vries debugaltlink_name_len =+ 1;

Thanks for finding and reporting this.

- Tom

[Bug c++/89138] ICE on valid C++11 code: in expand_expr_real_1, at expr.c:9993

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Likely since r152318 when lambda support has been added.
Guess we'd need to capture the VLA array sizes in the lambda.

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #4)
> Shouldn't we have a warning for this =+ vs. += case (of course, =- is fine)?

I found PR45358 - "Diagnostic could be issued for old C style a =+ b and
similar cases"

[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #5 from Tom de Vries  ---
Cross-referencing PR89136 - "libbacktrace/elf.c:2941: suspicious assignment"

[Bug ipa/79966] [9 Regression] run time more than twice slower when using -fipa-cp-clone

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|7.5 |9.0
Summary|[7 Regression] run time |[9 Regression] run time
   |more than twice slower when |more than twice slower when
   |using -fipa-cp-clone|using -fipa-cp-clone

--- Comment #8 from Uroš Bizjak  ---
The testcase fails for every target on trunk (gcc-9):

FAIL: gfortran.dg/pr79966.f90   -O   scan-ipa-dump inline "Inlined
tp_sum/[0-9]+ into runtptests/[0-9]+"

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[jiangning.liu at amperecomputing dot com]

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

Jiangning Liu  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #2 from Jiangning Liu  ---
The original case is only a simple example, and what if GCC can figure out it
is NOT an infinite loop? For example,

std::map BookTable;

BookTable::iterator iter;
BookTable booktable;
for (iter = booktable.begin(); iter!=booktable.end(); ++iter) {
   if (b) {
  b = do_something();
   }
}

Then GCC should be able to figure out this loop is a finite loop due to using
standard C++ STL std::map. The cost of iterating std::map might be high, so
we'd better consider optimize away the empty loop.

[Bug target/88494] [9 Regression] polyhedron 10% mdbx runtime regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||jakub at gcc dot gnu.org,
   ||peter at cordes dot ca
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Bisecting on a different Haswell machine:

r266526: 5.35user 0.00system 0:05.36elapsed 99%CPU
trunk head: 5.80user 0.00system 0:05.81elapsed 99%CPU

output also differs:

   STEP LP  KIN.E   POT.E   TOT.E   DIFFUS PX   PY   PZ   
    -- --- --- ---    
  LENGTH =   25804/  163840
- 1 L   0. -3.0509 -3.0509   0. -0.8E-15 -0.5E-15  0.1E-14
+ 1 L   0. -3.0509 -3.0509   0.  0.3E-15  0.8E-15  0.0E+00

on current trunk verification says it PASSES, past logs indicate it
passed there as well.

r266587: 5.90user 0.00system 0:05.91elapsed 99%CPU

with same output as r266526.

r266557: 5.90user 0.01system 0:05.91elapsed 99%CPU
r266537: 5.33user 0.00system 0:05.33elapsed 100%CPU
r266548: 5.88user 0.01system 0:05.89elapsed 100%CPU 
r266545: 5.34user 0.00system 0:05.34elapsed
r266546: same f951
r266547: same f951

So it is r266548, the fix for PR88189

PR target/88189
* config/i386/i386.c (ix86_expand_sse_movcc): Handle DFmode and
SFmode using sse4_1_blendvs[sd] with TARGET_SSE4_1.  Formatting fixes.
* config/i386/sse.md (sse4_1_blendv): New pattern.

we see extra vblendvpd used for if-conversion in non-vectorized paths
in mforce:

 DO i = 1 , MOLsa
DO nll = MRKr1(i) , MRKr2(i)
   j = LISt(nll)
   xij = X0(1,i) - X0(1,j)
   IF ( xij.GT.+HALf ) xij = xij - PBCx
   IF ( xij.LT.-HALf ) xij = xij + PBCx
   yij = X0(2,i) - X0(2,j)
   IF ( yij.GT.+HALf ) yij = yij - PBCy
   IF ( yij.LT.-HALf ) yij = yij + PBCy
   zij = X0(3,i) - X0(3,j)
   IF ( zij.GT.+HALf ) zij = zij - PBCz
   IF ( zij.LT.-HALf ) zij = zij + PBCz
...

.L241:  .L241:
movslq  liscom_-4(,%rdx,4), %rcxmovslq 
liscom_-4(,%rdx,4), %rcx
leaq(%rcx,%rcx,2), %rax leaq   
(%rcx,%rcx,2), %rax
vsubsd  lcs_+48(,%rax,8), %xmm9, %xmm3| vsubsd 
lcs_+48(,%rax,8), %xmm11, %xmm6
vcomisd %xmm4, %xmm3  | vsubsd 
%xmm13, %xmm6, %xmm5
jbe .L226 |
vcmpltsd%xmm6, %xmm0, %xmm4
vsubsd  %xmm11, %xmm3, %xmm3  |
vblendvpd   %xmm4, %xmm5, %xmm6, %xmm7
.L226:| vsubsd 
lcs_+56(,%rax,8), %xmm10, %xmm5
vcomisd %xmm3, %xmm5  | vaddsd 
%xmm13, %xmm7, %xmm8
jbe .L228 |
vcmpltsd%xmm1, %xmm7, %xmm6
vaddsd  %xmm11, %xmm3, %xmm3  | vsubsd 
%xmm2, %xmm5, %xmm4
.L228:|
vblendvpd   %xmm6, %xmm8, %xmm7, %xmm6
vsubsd  lcs_+56(,%rax,8), %xmm8, %xmm2|
vcmpltsd%xmm5, %xmm0, %xmm7
vcomisd %xmm4, %xmm2  |
vblendvpd   %xmm7, %xmm4, %xmm5, %xmm8
jbe .L230 |
vcmpltsd%xmm1, %xmm8, %xmm4
vsubsd  264(%rsp), %xmm2, %xmm2   | vaddsd 
%xmm2, %xmm8, %xmm5
.L230:|
vblendvpd   %xmm4, %xmm5, %xmm8, %xmm5
vcomisd %xmm2, %xmm5  | vsubsd 
lcs_+64(,%rax,8), %xmm9, %xmm4
jbe .L232 | vsubsd 
%xmm3, %xmm4, %xmm7
vaddsd  264(%rsp), %xmm2, %xmm2   |
vcmpltsd%xmm4, %xmm0, %xmm8
.L232:|
vblendvpd   %xmm8, %xmm7, %xmm4, %xmm4
vsubsd  lcs_+64(,%rax,8), %xmm7, %xmm0| vaddsd 
%xmm3, %xmm4, %xmm7
vcomisd %xmm4, %xmm0  |
vcmpltsd%xmm1, %xmm4, %xmm8
jbe .L234 |
vblendvpd   %xmm8, %xmm7, %xmm4, %xmm4
vsubsd  256(%rsp), %xmm0, %xmm0   | vmulsd 
256(%rsp), %xmm4, %xmm7

[Bug target/88494] [9 Regression] polyhedron 10% mdbx runtime regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Richard Biener  ---
On Skylake it's better (1uop, 1 cycle latency) while on Ryzen even better.
On Bulldozer it also isn't that bad (comparable to Skylake I guess).

So for generic tuning leave it enabled but for Broadwell and earlier tuning
disable it?  Note I didn't actually try benchmarking on Skylake, Ryzen or
Bulldozer.

[Bug target/88494] [9 Regression] polyhedron 10% mdbx runtime regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm not against conditionalizing that expander decision on the tuning, but it
would be nice to have that covered by sufficient benchmarking on various CPUs
(which I don't have good enough setup to do).
So, would we add another DEF_TUNE to x86-tune.def like
X86_TUNE_SCALAR_FLOAT_BLENDV ?

[Bug rtl-optimization/84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
lower-subreg.c doesn't consider this for multiple reasons: 1) it doesn't have
VEC_CONCAT handling, but that could be easily added 2) V2DImode isn't
considered, because its move cost is the same as scalar move cost 3) in
(insn 10 9 11 2 (set (reg:V2DI 90)
(vec_concat:V2DI (reg:DI 92)
(reg:DI 94))) "pr84101.c":9:10 4128 {vec_concatv2di}
 (nil))
(insn 11 10 12 2 (set (reg:TI 87 [ D.1913 ])
(subreg:TI (reg:V2DI 90) 0)) "pr84101.c":9:10 65 {*movti_internal}
 (nil))
(insn 12 11 16 2 (set (reg:TI 88 [  ])
(reg:TI 87 [ D.1913 ])) "pr84101.c":9:10 65 {*movti_internal}
 (nil))
(insn 16 12 17 2 (set (reg/i:TI 0 ax)
(reg:TI 88 [  ])) "pr84101.c":10:1 65 {*movti_internal}
 (nil))
there aren't any reasons to make the pseudos 87 or 88 decomposable, the result
is only used as TImode, not in DImode subregs thereof.
So, right now pseudo 90 ends up in non_decomposable_context (something could be
done about that), but as nothing ends up being in decomposable_context, nothing
is done anyway.

Now, I guess the reason why we should split somewhere this V2DI appart is
mainly the high cost of moving the (2!) integer registers from GPRs to SSE
registers and move the result back, maybe lower-subreg.c would need to treat it
differently based on the costs of VEC_CONCAT with integral operands (though,
x86 rtx_cost claims it is very cheap).

Unfortunately, HARD_REGNO_MODE_OK doesn't allow V2DImode to live in a pair of
GPRs, so the RA can't solve this say through having the vec_concat V2DI pattern
have a =r,r,r alternative.

[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Jan 31 13:53:06 2019
New Revision: 268422

URL: https://gcc.gnu.org/viewcvs?rev=268422&root=gcc&view=rev
Log:
2018-01-31  Bill Schmidt  

PR tree-optimization/89008
* gimple-ssa-strength-reduction.c (slsr_process_mul): Don't
process anything of the form X * 0.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug rtl-optimization/89116] [8/9 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4482

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, this is the same bug as PR85408.  I haven't heard from Honza any comments
on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85408#c2
Honza?

[Bug c++/88988] [8 Regression] ICE: Segmentation fault (in lookup_name_real_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE:   |[8 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |lookup_name_real_1) |lookup_name_real_1)

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

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This has been approved for trunk, are you going to commit it?

[Bug c++/88394] [8/9 Regression] g++ ICE (Segmentation fault) in insert_capture_proxy

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Related to e.g. PR89138 - lambdas and VLAs don't play nicely together right
now.

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
(In reply to Jakub Jelinek from comment #4)
> I really don't like these aarch64 warnings, declare simd is an optimization
> (admittedly with ABI consequences) and warning about this by default is
> weird,
> + it is going to be a pain, any time any declare simd testcase is added
> there is potential "regression" on aarch64.
> Plus it really looks like a bug in this case, there is no mixed type at all,
> the int * argument is uniform, so should be passed as any other pointer, and
> all the others are int and so should use the same vector int type.

I agree backend specific warnings are not ideal but it's unclear whether a
better solution exists beyond just not emitting these warnings at all and
letting the user figure it out.

However the key question is why do testcases which do not specifically test for
a specific warning fail if an extra warning is emitted? That's completely
harmless in most cases.

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Wilco from comment #5)
> I agree backend specific warnings are not ideal but it's unclear whether a
> better solution exists beyond just not emitting these warnings at all and
> letting the user figure it out.

I'd say it belongs to -fopt-info or similar stuff, when one wants to
investigate why something isn't vectorized etc.

> However the key question is why do testcases which do not specifically test
> for a specific warning fail if an extra warning is emitted? That's
> completely harmless in most cases.

That is the standard behavior of most of the testsuites (except for
gcc.c-torture/* which uses -w), and it is a good idea to FAIL for unexpected
warnings.

[Bug tree-optimization/89139] New: GCC emits code for static functions that aren't used by the optimized code

[m...@nieper-wisskirchen.de]

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

Bug ID: 89139
   Summary: GCC emits code for static functions that aren't used
by the optimized code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@nieper-wisskirchen.de
  Target Milestone: ---

Consider the following C module.

**
typedef struct cont
{
void (*f) (struct cont, int a);
} Cont;

int quux (int a);

static void g (Cont c, Cont d, int a)
{
if (quux (a))
  return g (c, d, a + 1);
c.f (d, a * 2); // XXX
}

void bar (struct cont, int a);

static void h (Cont d, int a)
{
if (d.f != bar)
  d.f (d, a);
}

void foo (int a)
{
g ((Cont) { h }, (Cont) { bar }, a);
}
**

I compiled the code with the x86-64 gcc (trunk) version on https://godbolt.org
and I get:

**
h:
cmpq$bar, %rdi
je  .L1
jmp *%rdi
.L1:
ret
foo:
pushq   %rbx
movl%edi, %ebx
jmp .L6
.L8:
addl$1, %ebx
.L6:
movl%ebx, %edi
callquux
testl   %eax, %eax
jne .L8
popq%rbx
ret
**

As one can see, code for the function `h' is emitted but nowhere used.

Interestingly, when I replace `a * 2' in the line marked with XXX by `a', gcc
does not emit code for `h':

**
foo:
pushq   %rbx
movl%edi, %ebx
jmp .L3
.L6:
addl$1, %ebx
.L3:
movl%ebx, %edi
callquux
testl   %eax, %eax
jne .L6
popq%rbx
ret
**

[Bug other/89140] New: libiberty/pex-unix.c fails to compile in aarch64-to-x86_64 cross build

[bneumeier at gmail dot com]

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

Bug ID: 89140
   Summary: libiberty/pex-unix.c fails to compile in
aarch64-to-x86_64 cross build
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bneumeier at gmail dot com
  Target Milestone: ---

Created attachment 45575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45575&action=edit
patch to correct pex-unix.c header file inclusion

In an aarch64-to-x86_64 cross-GCC build scenario, the libiberty configuration
process determines that getrusage is not available but wait4 is. This leads to
a situation where resource.h is not included, but there is a declaration of
type struct rusage.

I was able to get the compile to succeed without issues just by changing the
condition under which resource.h is included, see attached patch.

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #4 from bin.cheng  ---
(In reply to Jakub Jelinek from comment #3)
> This has been approved for trunk, are you going to commit it?

Thanks for reminding, will commit it tomorrow.  I would also need an approval
for 8 branch.

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa
Version|unknown |9.0

--- Comment #1 from Richard Biener  ---
It's likely eliminating the last use too late.

[Bug c++/88752] [8/9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Jan 31 15:03:21 2019
New Revision: 268424

URL: https://gcc.gnu.org/viewcvs?rev=268424&root=gcc&view=rev
Log:
PR c++/88752 - ICE with lambda and constexpr if.

In this testcase, we look for an instantiation of the outer lambda from
within the inner lambda.  enclosing_instantiation_of didn't handle this
properly, as it assumed that any references would be from the same lambda
nesting depth.  Fixed thus.

* cp-tree.h (LAMBDA_EXPR_INSTANTIATED): New.
* pt.c (tsubst_lambda_expr): Set it.
(instantiated_lambda_fn_p): Check it.
(enclosing_instantiation_of): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 31 Jan 2019, amker.cheng at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88932
> 
> bin.cheng  changed:
> 
>What|Removed |Added
> 
>  CC||amker.cheng at gmail dot com
> 
> --- Comment #4 from bin.cheng  ---
> (In reply to Jakub Jelinek from comment #3)
> > This has been approved for trunk, are you going to commit it?
> 
> Thanks for reminding, will commit it tomorrow.  I would also need an approval
> for 8 branch.

It's a regression so there's no need for an extra approval, but still - 
OK.

[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |enclosing_instantiation_of, |enclosing_instantiation_of,
   |at cp/pt.c:13328|at cp/pt.c:13328

--- Comment #6 from Jason Merrill  ---
Fixed on trunk so far.

[Bug preprocessor/89141] New: Documentation of -H ignores effect of include guards

[osemwaro.pedro at ocado dot com]

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

Bug ID: 89141
   Summary: Documentation of -H ignores effect of include guards
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: osemwaro.pedro at ocado dot com
  Target Milestone: ---

Created attachment 45576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45576&action=edit
Four short files with diamond include graph

I have recently been trying to figure out how to construct include graphs from
the GCC preprocessor's output, so that I can give the preprocessor the options
that I would use when compiling my code, to ensure that macros (and comments)
are treated correctly. The documentation of the -H option
(https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-H) led me
to believe that the include stack that it prints would give me the information
that I need. But after carefully examining its output, I realised that it omits
header files that contain include guards, the second time it encounters them.

The attachment demonstrates this. Its four files have the following include
graph:

  +-> d.hpp <-+
  |   | 
b.hpp <-- a.cpp --> c.hpp

and all three .hpp files have include graphs, but GCC prints the following
include stack:

$ g++ -E -H a.cpp 2>&1 1> /dev/null
. b.hpp
.. d.hpp
. c.hpp

I.e. it ignores the fact that c.hpp includes d.hpp.

This treatment of include guards should be described in the documentation (as
should the fact that the include stack is written to standard error). Googling
"gcc include graph" shows that there are a few other people who suggest
constructing include graphs based on -H, so I suspect that I'm not the only
person who has been (or would be) surprised to learn that this leads to
incomplete include graphs.

FWIW, I'm using GCC v. 5.4.0 on Ubuntu 16.04.

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #9 from Vladimir Makarov  ---
  I believe the PR is duplication of PR88850 (see my comments there).  The cost
of register movement in insn 6 is 2.  LRA/reload does not check constraints for
such cost and at the very LRA end (when there is a check for all insn
constraints) the error is reported.

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[avieira at gcc dot gnu.org]

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

--- Comment #10 from avieira at gcc dot gnu.org ---
Hi Vlad,

I don't think it is a duplication. I believe this PR is caused by an issue with
'uses_hard_regs_p' and paradoxical subregs. I proposed a patch in
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00307.html , though it has a
mistake, I forgot to add '|| SUBREG_P (x)' to the 'if (REG_P (x))' line since x
can now be a subreg.  I haven't had much time lately, but I am now running the
last bootstrap, have done arm and aarch64, now doing x86.

I can't reproduce this on GCC 9 but I can on 8 and earlier and the latent bug
is still there on 9. So I believe we should fix it regardless.

Once the bootstrap is done Ill post the fixed patch + testcase (really only
useful for gcc-8) on the mailing list.

Cheers,
Andre

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

--- Comment #12 from nsz at gcc dot gnu.org ---
this got reverted because of bug 88678

and because compile time and runtime support_halting are different.

the compile time value is unconditionally true, which is wrong for
aarch64 and arm:

gcc/fortran/simplify.c:
gfc_expr *
simplify_ieee_support (gfc_expr *expr)
{
  /* We consider that if the IEEE modules are loaded, we have full support
 for flags, halting and rounding, which are the three functions
 (IEEE_SUPPORT_{FLAG,HALTING,ROUNDING}) allowed in constant
 expressions. One day, we will need libgfortran to detect support and
 communicate it back to us, allowing for partial support.  */

  return gfc_get_logical_expr (gfc_default_logical_kind, &expr->where,
   true);
}

i don't know how to change this to false for IEEE_SUPPORT_HALTING
on aarch64 and arm targets, but that would be a possible fix.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson  changed:

   What|Removed |Added

 CC||matmal01 at gcc dot gnu.org

--- Comment #29 from Matthew Malcomson  ---
Hi Jakub,

I've been working on a patch that does very similar to the draft patch posted
above, and I notice a few things I've tried to avoid in it.
I doubt there are any actual bugs, since I don't know if the patterns that
trigger actual faults can occur at the moment.



Using the `address_operand` predicate and 'p' constraint to ensure the address
is a valid address would use the mode SImode of the operand rather than
checking
it's valid for the DImode of the emitted ldrd.

If this happens we generate an ICE in the `adjust_address` call just before
`output_move_double`.

I don't know if such a pattern can actually be generated, but we could use
`arm_legitimate_address_p (DImode, XEXP (operands[1], 0), true)` in the
condition to avoid it just in case.



There's a similar problem to the `address_operand` one above with using the
`arm_count_output_move_double_insns` function.

It's called on the original operands, which means it eventually calls
`output_move_double` with the first two operands (which are in SImode).

This function has some calls to `reg_overlap_mentioned_p`, which depends on the
number of hard registers for a given registers mode.

I've only found cases where the `arm_count_output_move_double_insns` function
returns something other than what it should in cases that only match because of
the `address_operand` problem above.

This could be replaced by a wrapper that generates DImode registers
specifically
for checking this.

---

I think generation of patterns of the form 
(plus:SI (plus:SI (reg) (const_int)) (const_int)) 
which can happen with these peepholes isn't very nice.
I can't find any constraint against these patterns in the canonicalization
rules (maybe there should be?) so I can't say this is an actual problem.


As an example: the following
int __RTL (startwith ("peephole2")) foo_x4 (int *a)
{
(function "foo_x4"
  (insn-chain
(cnote 1 NOTE_INSN_DELETED)
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (cinsn 101 (set (reg:SI r2)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 8)) [0 S4
A64])) "/home/matmal01/test.c":18)
  (cinsn 102 (set (reg:SI r3)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 12)) [0 S4
A32])) "/home/matmal01/test.c":18)
  (cinsn 103 (set (reg:SI r0)
  (plus:SI (reg:SI r2) (reg:SI r3)))
"/home/matmal01/test.c":18)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
  (crtl
(return_rtx 
  (reg/i:SI r0)
) ;; return_rtx
  ) ;; crtl
) ;; function "main"
}

Produces
(insn 104 3 103 2 (parallel [
(set (reg:SI 2 r2)
(mem/c:SI (plus:SI (reg:SI 0 r0)
(const_int 8 [0x8])) [0 S4 S4 A64]))
(set (reg:SI 3 r3)
(mem/c:SI (plus:SI (plus:SI (reg:SI 0 r0)
(const_int 8 [0x8]))
(const_int 4 [0x4])) [0 S4 S4 A32]))
]) -1
 (nil))


Maybe we could use the existing operands, and match with
`rtx_equal_p (..., plus_constant (...))`
so that the plus_constant can take care of adding the constants together.
This is what we do in the load_pair patterns for aarch64.




There are a few other tidy-up points around the define_insn patterns, but
overall I believe they can be merged into one pattern.
The difference between the 'q' and 'r' constraints are using either CORE_REGS
or
GENERAL_REGS, where CORE_REGS allows r13 and GENERAL_REGS doesn't.
I guess this is from a line in infocenter that mentions r12 is strongly
recommended to not be used as the first register for ldrdb, as this is stopped
by requiring both the first and second register to not be r13.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Cihjffga.html

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
(In reply to Tom de Vries from comment #5)
> Thanks for finding and reporting this.

You are welcome. I was testing new clang-8.0.0-rc1
and hadn't compiled gcc with clang for a while.

clang warns for "=+" and it isn't a new warning in clang-8.0.0-rc1.

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #1 from Vladimir Makarov  ---
I cannot reproduce it anymore on today trunk.  Probably some recent RA patch
solved the problem.

[Bug c++/89138] ICE on valid C++11 code: in expand_expr_real_1, at expr.c:9993

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
I guess it may be a duplicate of PR60855 and (or) PR86432.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to nsz from comment #12)
> i don't know how to change this to false for IEEE_SUPPORT_HALTING
> on aarch64 and arm targets, but that would be a possible fix.

--cut here--
Index: libgfortran/config/fpu-glibc.h
===
--- libgfortran/config/fpu-glibc.h  (revision 268424)
+++ libgfortran/config/fpu-glibc.h  (working copy)
@@ -129,6 +129,10 @@
 int
 support_fpu_trap (int flag)
 {
+#if defined(__arm__) || defined(__aarch64__)
+  return 0;
+#endif
+
   return support_fpu_flag (flag);
 }

--cut here--

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
I'll check it on the next trunk snapshot and report back next Monday.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
(In reply to Matthew Malcomson from comment #29)
> I've been working on a patch that does very similar to the draft patch posted
> above, and I notice a few things I've tried to avoid in it.
> I doubt there are any actual bugs, since I don't know if the patterns that
> trigger actual faults can occur at the moment.
> 
> 
> 
> Using the `address_operand` predicate and 'p' constraint to ensure the
> address
> is a valid address would use the mode SImode of the operand rather than
> checking
> it's valid for the DImode of the emitted ldrd.

Sure, but does it really matter?
This is a post reload pattern created by the peephole2s, so nothing that can be
matched out of the blue sky like combiner normally matches.
So, if it didn't pass the conditions in the peephole2s, the patterns wouldn't
be created.
Are there any addresses that pass arm_legitimate_address_p (DImode, x, true)
and fail address_operand (x, SImode)?  From brief skimming I couldn't find
anything.
So, would you be happy if the && arm_legitimate_address_p (DImode, XEXP
(operands[n], 0), true)
condition is added to the insn conditions (after the rtx_equal_p check)?

> There's a similar problem to the `address_operand` one above with using the
> `arm_count_output_move_double_insns` function.
> 
> It's called on the original operands, which means it eventually calls
> `output_move_double` with the first two operands (which are in SImode).
> 
> This function has some calls to `reg_overlap_mentioned_p`, which depends on
> the
> number of hard registers for a given registers mode.
> 
> I've only found cases where the `arm_count_output_move_double_insns` function
> returns something other than what it should in cases that only match because
> of
> the `address_operand` problem above.
> 
> This could be replaced by a wrapper that generates DImode registers
> specifically
> for checking this.

For non-vfp or iwmmxt, the length is always 8, are there cases in the vfp insn
that the length is not 8?

> I think generation of patterns of the form 
> (plus:SI (plus:SI (reg) (const_int)) (const_int)) 
> which can happen with these peepholes isn't very nice.

Why?  I've done that intentionally, so that it is easy to verify it is 4 bytes
appart, otherwise one needs to handle all the different cases where address is
this and that etc.  This whole MEM isn't an operand in the instruction, just
mere RTL.  Combiner doesn't run after peephole2 and if something tries to
canonicalize that some way, it will simply fail to be recognized and it will
not try that canonicalization.

[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Jan 31 17:14:36 2019
New Revision: 268425

URL: https://gcc.gnu.org/viewcvs?rev=268425&root=gcc&view=rev
Log:
2018-01-31  Bill Schmidt  

Backport from mainline
2018-01-31  Bill Schmidt  

PR tree-optimization/89008
* gimple-ssa-strength-reduction.c (slsr_process_mul): Don't
process anything of the form X * 0.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-strength-reduction.c

[Bug tree-optimization/88107] [7/8/9 Regression] ICE in find_outermost_region_in_block, at tree-cfg.c:7157

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45577&action=edit
gcc9-pr88107.patch

Untested fix.

[Bug preprocessor/89142] New: Allow poisoning identifier from the command line

[Simon.Richter at hogyros dot de]

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

Bug ID: 89142
   Summary: Allow poisoning identifier from the command line
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

I'm currently refactoring a program that uses a preprocessor symbol in various
places, and I'd like to generate errors for all uses.

There is no common header file in which I could place a `#pragma gcc poison`
directive, but I can modify the CPPFLAGS globally.

It would be nice to have a way to add poisoned preprocessor symbols from the
command line.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

--- Comment #14 from nsz at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to nsz from comment #12)
> > i don't know how to change this to false for IEEE_SUPPORT_HALTING
> > on aarch64 and arm targets, but that would be a possible fix.
> 
> --cut here--
> Index: libgfortran/config/fpu-glibc.h

that only turns the runtime check into "always false"

but the compile time check is still "always true".

which is still broken.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|nsz at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #15 from nsz at gcc dot gnu.org ---
i unassigned myself as i'm not working on this right now.

[Bug preprocessor/89142] Allow poisoning identifier from the command line

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Jakub Jelinek  ---
Just put it into a new header file and use
-include /whatever/header_with_gcc_poison.h
on the command line.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[matmal01 at gcc dot gnu.org]

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

--- Comment #31 from Matthew Malcomson  ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Matthew Malcomson from comment #29)
> > I've been working on a patch that does very similar to the draft patch 
> > posted
> > above, and I notice a few things I've tried to avoid in it.
> > I doubt there are any actual bugs, since I don't know if the patterns that
> > trigger actual faults can occur at the moment.
> > 
> > 
> > 
> > Using the `address_operand` predicate and 'p' constraint to ensure the
> > address
> > is a valid address would use the mode SImode of the operand rather than
> > checking
> > it's valid for the DImode of the emitted ldrd.
> 
> Sure, but does it really matter?
> This is a post reload pattern created by the peephole2s, so nothing that can
> be matched out of the blue sky like combiner normally matches.
> So, if it didn't pass the conditions in the peephole2s, the patterns
> wouldn't be created.

True -- as I mentioned I don't know if a problematic pattern could actually
occur, so I doubt this is actually a problem.

> Are there any addresses that pass arm_legitimate_address_p (DImode, x, true)
> and fail address_operand (x, SImode)?  From brief skimming I couldn't find
> anything.
> So, would you be happy if the && arm_legitimate_address_p (DImode, XEXP
> (operands[n], 0), true)
> condition is added to the insn conditions (after the rtx_equal_p check)?

That sounds good to me.

> 
> > There's a similar problem to the `address_operand` one above with using the
> > `arm_count_output_move_double_insns` function.
> > 
> > It's called on the original operands, which means it eventually calls
> > `output_move_double` with the first two operands (which are in SImode).
> > 
> > This function has some calls to `reg_overlap_mentioned_p`, which depends on
> > the
> > number of hard registers for a given registers mode.
> > 
> > I've only found cases where the `arm_count_output_move_double_insns` 
> > function
> > returns something other than what it should in cases that only match because
> > of
> > the `address_operand` problem above.
> > 
> > This could be replaced by a wrapper that generates DImode registers
> > specifically
> > for checking this.
> 
> For non-vfp or iwmmxt, the length is always 8, are there cases in the vfp
> insn that the length is not 8?

I believe the length *can* be 4 non-vfp, vfp, or iwmmxt (the case below
produces a single ldrd when compiled with each of them).

int __RTL (startwith ("peephole2")) foo_x4 (int *a)
{
(function "foo_x4"
  (insn-chain
(cnote 1 NOTE_INSN_DELETED)
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (cinsn 101 (set (reg:SI r2)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 8)) [0 S4
A64])) "/home/matmal01/test.c":18)
  (cinsn 102 (set (reg:SI r3)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 12)) [0 S4
A32])) "/home/matmal01/test.c":18)
  (cinsn 103 (set (reg:SI r0)
  (plus:SI (reg:SI r2) (reg:SI r3)))
"/home/matmal01/test.c":18)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
  (crtl
(return_rtx 
  (reg/i:SI r0)
) ;; return_rtx
  ) ;; crtl
) ;; function "main"
}




Something else I've just noticed:
When compiling for vfp or iwmmxt, the ldm2_ define_insn matches the simpler
case below as it comes first in the md order.
That means we get a ldm instruction instead of the ldrd.

int __RTL (startwith ("peephole2")) foo_x5 (int *a)
{
(function "foo_x5"
  (insn-chain
(cnote 1 NOTE_INSN_DELETED)
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (cinsn 101 (set (reg:SI r2)
  (mem/c:SI (reg:SI r0) [0 S4 A64]))
"/home/matmal01/test.c":18)
  (cinsn 102 (set (reg:SI r3)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 4)) [0 S4
A32])) "/home/matmal01/test.c":18)
  (cinsn 103 (set (reg:SI r0)
  (plus:SI (reg:SI r2) (reg:SI r3)))
"/home/matmal01/test.c":18)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
  (crtl
(return_rtx 
  (reg/i:SI r0)
) ;; return_rtx
  ) ;; crtl
) ;; function "main"
}

[Bug preprocessor/89142] Allow poisoning identifier from the command line

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
And with bash, you don't even need a separate file, you can use something like
this:

  -include <(echo '#pragma GCC poison IDENTIFIER')

[Bug c/89122] bad fix-it hint for FLT_MAX when is included

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
Should be fixed by r268426.

[Bug c/89122] bad fix-it hint for FLT_MAX when is included

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jan 31 18:09:29 2019
New Revision: 268426

URL: https://gcc.gnu.org/viewcvs?rev=268426&root=gcc&view=rev
Log:
Fix bogus fix-it for FLT_MAX (PR c/89122)

PR c/89122 reports that we emit a bogus fix-it hint for the case where
the code uses FLT_MAX, but has included  rather than :

x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did you
  mean 'INT_MAX'?
3 | float f = FLT_MAX;
  |   ^~~
  |   INT_MAX

This patch adds some knowledge of  (and ) to
known-headers.cc, fixing the issue:

x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function)
3 | float f = FLT_MAX;
  |   ^~~
x.c:2:1: note: 'FLT_MAX' is defined in header ''; did you forget
  to '#include '?
1 | #include 
  +++ |+#include 
2 |

gcc/c-family/ChangeLog:
PR c/89122
* known-headers.cc (get_stdlib_header_for_name): Add
{FLT|DBL|LDBL}_{MAX|MIN} to "hints" array.

gcc/testsuite/ChangeLog:
PR c/89122
* g++.dg/spellcheck-stdlib.C (test_FLT_MAX): New test.
* gcc.dg/spellcheck-stdlib.c (test_FLT_MAX): New test.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/known-headers.cc
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C
trunk/gcc/testsuite/gcc.dg/spellcheck-stdlib.c

[Bug debug/87295] [8 Regression][early debug] ICE with -ffat-lto-objects -fdebug-types-section -g

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
It seems that this breaks debug-types-sections w/o LTO as well now.
./xgcc -B ./ -O2 -g ~/tramp3d-v44.ii -fdebug-types-section
/aux/hubicka/tramp3d-v4b.cpp:56088:1: internal compiler error: in
build_abbrev_table, at dwarf2out.c:9061
56088 | }
  | ^
0x720707 build_abbrev_table
../../gcc/dwarf2out.c:9061
0xc3dee7 build_abbrev_table
../../gcc/dwarf2out.c:9112
0xc40e7b output_comdat_type_unit
../../gcc/dwarf2out.c:11237
0xc6678d dwarf2out_finish
../../gcc/dwarf2out.c:31496
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I can't reproduce even with r267379 (nor current trunk).  Tried even with
-mtune=skylake-avx512, -mtune=haswell, -mtune=generic, nothing triggers it.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[sje at gcc dot gnu.org]

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

--- Comment #11 from Steve Ellcey  ---
(In reply to Richard Biener from comment #10)
> (In reply to Steve Ellcey from comment #9)

> Looks like that's because of different expected comment characters,
> # vs. // in your file.  The pattern for the comment stuff is
> 
> \[^#/!\]*\[#/!\] DW
> 
> skip until first comment-char (ok), then consume comment (bogus).  Adding
> + might help.  Can you check that?

Yes, that patch fixed the failure I was seeing on aarch64.

[Bug d/88150] Use sections_elf_shared.d on Solaris

[johannespfau at gmail dot com]

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

Johannes Pfau  changed:

   What|Removed |Added

 CC||code at dawg dot eu,
   ||johannespfau at gmail dot com

--- Comment #8 from Johannes Pfau  ---
Regarding the _d_dso_registry issue: Yes, as far as I can see it is a bug that
handleForName dlcloses the handle here. I think what happened is this:

handleForName is used in one place with the comment
// get handle without loading the library
so it is supposed to unload the library there.
But it is also called from handleForAddr which is used to get the DSO handle to
be stored using setDSOForHandle. I think here, it's not really valid to store
the closed handle.

Let's ping the expert here though, I've added Martin Nowak to CC.

[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, perhaps easiest is to revert the PR87414 changes and just error out on
-fasynchronous-unwind-tables with -mindirect-branch=thunk-inline.

The following testcase shows various cases:
void foo (char *);

int
f1 (int (*f) (void))
{
  return f ();
}

int
f2 (int (*f) (void))
{
  foo (0);
  return f ();
}

int
f3 (int (*f) (void))
{
  foo (0);
  return f () + 1;
}

int
f4 (int (*f) (void), int x)
{
  char buf[x];
  foo (buf);
  return f () + 1;
}

__attribute__((optimize ("no-omit-frame-pointer"))) int
f5 (int (*f) (void))
{
  foo (0);
  return f ();
}

The unwind info is incorrect in f3 (the CFA is already %rsp+16 before the call,
so for the mov + ret instruction we need %rsp+24 and then revert), f4 (CFA is
%rbp, so we shouldn't change CFA offset at all).
So, we'd need to figure out if CFA is sp or bp at the instruction (is it call
always?) for which we emit the thunk and only if it is sp, increase offset by
word size and decrease afterwards.
Furthermore, for -fno-dwarf2-cfi-asm, we likely need to search the CFI
instruction array and find where exactly to insert the new CFI, rather than
appending it.  What a mess!

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

[johannespfau at gmail dot com]

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

Johannes Pfau  changed:

   What|Removed |Added

 CC||johannespfau at gmail dot com

--- Comment #7 from Johannes Pfau  ---
> The Minfo_Bracketing assert in sections_elf_shared.d fails now, of
> course, but the file is usable even without linker-provided
> bracketing.  Should this go completely?

I think the assert should go, it doesn't belong there anyway. Minfo_Bracketing
is unused then, AFAICS, so it should be fine to also remove it from
gcc/config.d.

Other changes look fine.

[Bug tree-optimization/89143] New: [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[msebor at gcc dot gnu.org]

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

Bug ID: 89143
   Summary: [9 Regression] comparison of abs(i) against excessive
constant less than UXXX_MAX no longer folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While looking into bug 89127 I noticed that while GCC 8 and prior fold the
comparison to false in the if controlling expression below due to the limited
range of i's type, GCC 9 no longer performs this folding unless the constant is
 UCHAR_MAX and greater.  Same for short and SHRT_MAX + 1.

$ cat u.c && gcc -S -O2 -Wall -Wextra -Wtype-limits
-fdump-tree-optimized=/dev/stdout u.c
void f (signed char i)
{
  if (__builtin_abs (i) > 128)
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)

f (signed char i)
{
  unsigned char _1;

   [local count: 1073741824]:
  _1 = ABSU_EXPR ;
  if (_1 > 128)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug tree-optimization/89143] [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to work||7.3.0, 9.0
  Known to fail||9.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r261681:

gcc/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

PR middle-end/64946
* cfgexpand.c (expand_debug_expr): Hande ABSU_EXPR.
* config/i386/i386.c (ix86_add_stmt_cost): Likewise.
* dojump.c (do_jump): Likewise.
* expr.c (expand_expr_real_2): Check operand type's sign.
* fold-const.c (const_unop): Handle ABSU_EXPR.
(fold_abs_const): Likewise.
* gimple-pretty-print.c (dump_unary_rhs): Likewise.
* gimple-ssa-backprop.c (backprop::process_assign_use): Likesie.
(strip_sign_op_1): Likesise.
* match.pd: Add new pattern to generate ABSU_EXPR.
* optabs-tree.c (optab_for_tree_code): Handle ABSU_EXPR.
* tree-cfg.c (verify_gimple_assign_unary): Likewise.
* tree-eh.c (operation_could_trap_helper_p): Likewise.
* tree-inline.c (estimate_operator_cost): Likewise.
* tree-pretty-print.c (dump_generic_node): Likewise.
* tree-vect-patterns.c (vect_recog_sad_pattern): Likewise.
* tree.def (ABSU_EXPR): New.

[Bug c/89127] missing -Wtype-limits for trivially false expressions

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I see what you mean.  It might perhaps be useful to mention the bigint rule of
thumb in the manual.  At the same time, the warning still doesn't work even
under this restricted interpretation.  For example, in:

  void f (unsigned char i)
  {
if (2 * i > 2 * UCHAR_MAX)
  __builtin_abort ();
  }

the comparison is trivially false due to the limited range of i's type.  GCC
sees that and in EVRP eliminates it, but without issuing the warning (or a
warning).

That said, the distinction is rather subtle between (i * i < 0) being false
because of multiplication's mathematical properties and (2 * i > 2 * UCHAR_MAX)
being false because of i's limited range.  As a user, my expectation is to get
a warning for comparisons that cannot be true, especially in controlling
expressions of conditional and iteration statements.  Whether that's because of
a limited range of the type of the expression or for some other reason is
unimportant.  What matters to me is that the code I wrote is not dead.

Incidentally, besides the warning not working as I expect, the test cases in
comment #0 were partly prompted by the implementation of the warning in
vr-values.c where I had initially assumed some of these expressions might be
handled.  Obviously, they're not because, as the original dump shows, they
never make it anywhere near VRP, but I hadn't taken the time to come up with
test cases that do make it there.  I have now spent some more time trying to
come up with one but so far no luck.  It doesn't even look like anything in the
test suite exercises that code, even with -Wtype-limits enabled by default.

Here are a few other trivial examples where a warning would be helpful (and,
IIUC, should be issued even under the strict interpretation):

  extern unsigned char i;

  if (i >> 31 != 0) __builtin_abort ();
  if (i / 2 > 200) __builtin_abort ();
  if (i & 0x100 != 0) __builtin_abort ();

And here's one where GCC not only doesn't warn, the trunk doesn't even fold it
anymore (GCC 8 does fold it; this is due to pr89143):

  void f (signed char i)
  {
if (__builtin_abs (i) > SCHAR_MAX + 1)
  __builtin_abort ();
  }

[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Florian Weimer  ---
Isn't -fasynchronous-unwind-tables part of the GNU/Linux ABI and enabled by
default?  Without it, asynchronous cancellation does not work.

Can we simplify this if we require frame pointers when using inline thunks?  Or
get rid of inline thunks altogether?

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
"inc" may be pure, but "do_something" isn't, so I don't see how it's valid to
optimize away the loop.

Consider e.g. this implementation in another TU:

int call_count;

int do_something(void)
{
  call_count++;
  return 1;
}

...or somesuch.

(also "b" is global, so presumably there could be another thread touching it,
or observing the changes made by the loop)

[Bug c++/89144] New: GCC emits undefined references when a constexpr initializer_list appears in a template function

[m101010a at gmail dot com]

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

Bug ID: 89144
   Summary: GCC emits undefined references when a constexpr
initializer_list appears in a template function
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
#include 
template  void b() {
constexpr std::initializer_list c{};
}
int main() { b(); }
$ g++ x.cpp
/bin/ld: /tmp/ccqq90fA.o: in function `void b()':
x.cpp:(.text._Z1bIiEvv[_Z1bIiEvv]+0x7): undefined reference to `._0'
collect2: error: ld returned 1 exit status
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

This happens whether or not the initializer list has any elements.  It does not
happen if the list is not constexpr, and does not happen if b is not a
template.  This also happens when using mingw.

[Bug lto/89084] [9 Regression] ICE in get_partitioning_class, at symtab.c:1892

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed (on godbolt with x86_64 trunk, and a regression relative to gcc 8.2)

gcc-bugs@gcc.gnu.org

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> Checking with FreeBSD developers on C99 compliance.

The answer is 'no'.  FreeBSD's C runtime libraries 
(libc+libm) are not fully C99 complaint.  It is a shame,
too.

Unfortunately and I should have remembered, FreeBSD's C runtime
libraries (ie libc+libm) are not C99 compliant.  The problem (for me)
is that function_c99_math_complex indicates that libm includes
a complete set of C99 complex math function, which of course
it doesn't.  Testing with GCC trunk gives

1 default_libc_has_function  (C99 compliant libc+libm)
2 no_c99_libc_has_function   (FreeBSD current setting)

  12
=== gcc Summary ===
# of expected passes134923   134887
# of unexpected failures171  207   <-- This is good.
# of unexpected successes   27   27
# of expected failures  550  550
# of unresolved testcases   14   14
# of unsupported tests   

=== g++ Summary ===
# of expected passes124009   124009
# of unexpected failures41   41
# of expected failures  548  548
# of unsupported tests  5585 5585

=== gfortran Summary ===
# of expected passes4899248993
# of unexpected failures21 <-- This is bad.
# of expected failures  130  130
# of unsupported tests  88   88

'This is bad' occurs because FreeBSD is missing cexpl
and the fallback in libgfortran/intrinsics/c99_functions.c
seems to be broken on FreeBSD if default_libc_has_function
is used.

[Bug lto/89084] [9 Regression] ICE in get_partitioning_class, at symtab.c:1892

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Fails this assertion:

1892  gcc_checking_assert (vnode->definition);

(gdb) p vnode
$3 = 

[Bug tree-optimization/89143] [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-31
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> for Vlad the question
> is just whether r266862 is a real fix or just made it latent.  Given that
> both are IRA costs changes, I assume it is a real fix.

I've checked the generated code difference.  The recent code uses more accurate
register classes and as the result avoid LRA cycling.  So I believe the patch
is a real fix for the PR.  But I think there is still possibility that the 1st
insn scheduler can create a situation when RA (as the old reload) can fail
because of existing constraints in hard register splitting in LRA.  This
problem is less severe every year but still exists and honestly I don't know
when it will be fully solved.

As for this PR, I think it should be closed.