[Bug tree-optimization/91647] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Martin Sebor from comment #3)
> > I get the following error when running a cross-compiler for
> > x86_64-apple-darwin:
> > 
> > xgcc: error: unrecognized command-line option
> > '-asm_macosx_version_min=10.5'; did you mean '-asm_macosx_version_min='?
> > 
> > Is there a different target I should try or something else I can do to
> > configure it to get around it?
> 
> what was the configuration line?
> you can't expect to build more than cc1/cc1plus, unless you go through the
> process of build a Mach-O 'binptils' - which would be unnecessary here.
> 
> .. (if there's a problem - I can try something on gcc122 later)

../src/configure --prefix=/home/iains/gcc-trunk/darwin
--target=x86_64-apple-darwin10 >conf.txt
make -j16 all-host >b.txt 2>e.txt

built working cc1 & cc1plus for me on gcc122.

[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 07:27:42 2019
New Revision: 275365

URL: https://gcc.gnu.org/viewcvs?rev=275365&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

PR rtl-optimization/36262
* postreload-gcse.c: Include intl.h and gcse.h.
(insert_expr_in_table): Insert at the head of cur_expr->avail_occr
to avoid linear list walk.
(record_last_mem_set_info): Gate off if not computing transparentness.
(get_bb_avail_insn): If transparentness isn't computed give up
early.
(gcse_after_reload_main): Skip compute_transp and extended PRE
if gcse_or_cprop_is_too_expensive says so.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload-gcse.c

[Bug c++/91309] Fails to compile when initializing template argument with immediately-invoked lambda

[beachboy44 at me dot com]

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

--- Comment #1 from beachboy44 at me dot com ---
Possibly related cases that also fail to compile:

template
using F = decltype([]{ return T{0}; });

auto g = [](auto x) {
using G = F;
return G{}();
};

https://godbolt.org/z/tSwWUF


auto f = []{ return 0; };

template
using F = decltype(f);

auto g = [](auto x) {
using G = F;
return G{}();
};

https://godbolt.org/z/w20oxP

[Bug target/59230] __divtf3@@GCC_4.4.0 missing from libgcc_s.so.1

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Created attachment 46808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46808&action=edit
Missing __divtf3@@GCC_4.4.0 on ia64

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Then gen_rtx_REG (mode, REGNO (SUBREG_REG (x))) case I meant only in case some
splitter would be required for proper operation rather than just being an
optimization.  If they are all an optimization, the !paradoxical_subreg_p
guards are probably ok.

[Bug tree-optimization/88415] [7 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/87929] ICE in verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/90006] [7 Regression] gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/88903] [7 Regression] wrong-code with SLP vectorized shift

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug c++/89698] [7 Regression] Run-time error due to optimization of field access after cast at -Os/-O2 and higher

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/88030] ICE in calc_dfs_tree, at dominance.c:458

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Created attachment 46809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46809&action=edit
gcc10-pr91635.patch

If you want full patch from me, here it is, but as I said I can't easily test
it (I don't even have cross-glibc or qemu around to test if the testcase FAILs
or PASSes).
I agree the last splitter is changed just for consistency and it is unlikely it
would hit and for the post-reload splitter it will be hard to come up with
testcases.  I've tried to put all 4 testcases from Zdenek into one.

[Bug middle-end/88448] [9 regression] gnat.dg/opt66.adb etc. FAIL

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug c++/89698] [7 Regression] Run-time error due to optimization of field access after cast at -Os/-O2 and higher

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88415] [7 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/88903] [7 Regression] wrong-code with SLP vectorized shift

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 08:06:24 2019
New Revision: 275366

URL: https://gcc.gnu.org/viewcvs?rev=275366&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-04-09  Richard Sandiford  

* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Always
use gimple_expr_type for load and store calls.  Skip over the
condition argument in a conditional internal function.
Protect use of TREE_INT_CST_LOW.

2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

2019-03-14  Richard Biener  

PR middle-end/89698
* fold-const.c (operand_equal_p): For INDIRECT_REF check
that the access types are similar.

* g++.dg/torture/pr89698.C: New testcase.

2019-01-18  Richard Biener  

PR tree-optimization/88903
* tree-vect-stmts.c (vectorizable_shift): Verify we see all
scalar stmts a SLP shift amount is composed of when detecting
shifts by scalars.

* gcc.dg/vect/pr88903-1.c: New testcase.
* gcc.dg/vect/pr88903-2.c: Likewise.

2018-12-11  Richard Biener  

PR middle-end/88448
PR middle-end/88415
* tree-complex.c (update_complex_assignment): Properly transfer
or clean EH info around gimple_assign_set_rhs_with_ops.

* gcc.dg/gomp/pr88415.c: New testcase.

2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

2018-11-08  Richard Biener  

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

2017-07-25  Eric Botcazou  

* gimple.c (gimple_assign_set_rhs_with_ops): Do not ask gsi_replace
to update EH info here.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr89698.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88415.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr87929.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tsan/pr88030.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/gimple.c
branches/gcc-7-branch/gcc/internal-fn.c
branches/gcc-7-branch/gcc/internal-fn.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c
branches/gcc-7-branch/gcc/tree-complex.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/90006] [7 Regression] gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/87985] Compile-time and memory hog w/ -O1 -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
.

[Bug tree-optimization/88315] SAD and DOT_PROD SLP reductions with initial value != 0 create wrong code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.4.1

--- Comment #5 from Richard Biener  ---
Too much refactoring makes backporting this for GCC 7 too risky.  The function
to patch there would anyone run into this is vect_get_constant_vectors.

So - fixed for GCC 8+.

[Bug tree-optimization/84746] [7 Regression] ICE on valid code at -O2 and -O3: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.5 |8.4

--- Comment #11 from Richard Biener  ---
Not going to touch GCC 7 PRE, the issue is only latent there.

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[tnfchris at gcc dot gnu.org]

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

--- Comment #16 from Tamar Christina  ---
> Do you have a link to those problems?  And no, please don't regress us for no
reason at all, it's really easy to *not* regress this on double-double.

As far as I am aware, the final version of the patch had no regressions for any
target, including PowerPC which I used the GCC compile farm to verify
(https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02567.html)

The patch ended up not getting committed because of questions around whether
integer operations were fast enough on all targets and on the latest reviewer
requesting a major change to the patch.

At this time the patch had gone through 3 completely different implementations
(due to to every time having a different reviewer reviewing it) and so a 4th
rewrite was deemed not productive use of time.

[Bug tree-optimization/83580] [8 Regression] Wrong code caused by vectorization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.5 |8.0
Summary|[7 Regression] Wrong code   |[8 Regression] Wrong code
   |caused by vectorization |caused by vectorization
  Known to fail|6.4.0, 7.2.0|

--- Comment #13 from Richard Biener  ---
Hmm, so I can't make the testcase fail on the GCC 6 or 7 branch or the 6.4 or
7.2 releases, not sure how Martin set those known-to-fail.

Fixed for GCC 8 (but latent).

[Bug c/82186] [7 Regression] ICE (segfault), VLA type with inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail|8.0 |7.4.1

--- Comment #10 from Richard Biener  ---
Too late for backporting IMHO.  Fixed in GCC 8+.

[Bug middle-end/63155] [7 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.5 |8.3

[Bug middle-end/63155] [7 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.4.1

--- Comment #56 from Richard Biener  ---
Not going to backport further, fixed in GCC 8+.

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[kito at gcc dot gnu.org]

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

--- Comment #17 from Kito Cheng  ---
Hi Jakub:

Thanks your patch, I've run with gcc testsuite and no new fails, and I am
ruining more gcc testsuite regression with different arch/abi combination for
that.

I am amazing that seems like RISC-V is first back-end use paradoxical_subreg_p
:P


Hi Jim:
Basically my local patch is almost same as Jakub, so I think you can use
Jakub's  directly if you think that's OK.

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[kretz at kde dot org]

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

--- Comment #5 from Matthias Kretz  ---
> So for #c3 you are essentially asking for a .rodata size optimization.

Comment #1 also does so, no? But yes, this is a .rodata optimization and thus
potentially a visible reduction on cache pressure. Consider a math function for
AVX512 that requires 20 float constants. With the optimization 80 bytes (1 1/4
cache lines) suffice. Without the optimization 1280 bytes (20 cache lines) are
required.

> The problem [...] many define_insns we have non-EVEX variants mixed with EVEX 
> variants [...]

I see. So the implementation is non-trivial for 16 and 32 byte vectors but
should be doable for 64 byte (zmm) vectors?
The instructions where broadcast works seem to be guessable. Quoting Intel
docs:
"
2.6.7 Embedded Broadcast Support in EVEX
EVEX encodes an embedded broadcast functionality that is supported on many
vector instructions with 32-bit (double word or single-precision
floating-point)  and 64-bit data elements, and when the source operand is from
memory. EVEX.b (P[20]) bit is used to enable broadcast on load-op instructions.
When enabled, only one element is loaded from memory and broadcasted to all
other elements instead of loading the full memory size.

The following instruction classes do not support embedded broadcasting:
• Instructions with only one scalar result is written to the vector
destination.
• Instructions with explicit broadcast functionality provided by its opcode.
• Instruction semantic is a pure load or a pure store operation.
"

Starting with AVX, the vbroadcast* instructions could also be used to do the
.rodata size optimization (the performance implication is not obvious to me,
but maybe its the right optimization for -Os in any case?).

The other relevant (missing?) .rodata optimization is to combine vector
constants of different size (and scalars):
auto f(double a) {
return a + 1.2;
}
auto f(double a [[gnu::vector_size(16)]]) {
return a * 1.2;
}
auto f(double a [[gnu::vector_size(32)]]) {
return a * 1.2;
}
auto f(double a [[gnu::vector_size(64)]]) {
return a * 1.2;
}

should produce (again, possibly only on -Os):
f(double):
  vaddsd .LC0(%rip), %xmm0, %xmm0
  ret
f(double __vector(2)):
  vmulpd .LC0(%rip), %xmm0, %xmm0
  ret
f(double __vector(4)):
  vmulpd .LC0(%rip), %ymm0, %ymm0
  ret
f(double __vector(8)):
  vmulpd .LC0(%rip), %zmm0, %zmm0
  ret
.LC0:
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963
  .long 858993459
  .long 1072902963

but instead emits a constant per overload of f. (cf.
https://godbolt.org/z/SDr7jG)

Finally a quote from the Intel ORM (Version 040, 15.9.2):

In Skylake Server microarchitecture, a broadcast instruction with a memory
operand of 32 bits or above is executed on the load ports; it is not executed
on port 5 as other shuffles are. Alternative 2 in the following example shows
how executing the broadcast on the load ports reduces the workload on port 5
and increases performance. Alternative 3 shows how embedded broadcast benefits
from both executing the broadcast on the load ports and micro fusion.

Example 15-13. Broadcast Executed on Load Ports Alternatives

Alternative 1: 32-bit Load and Register Broadcast
loop:
vmovd xmm0, [rax]
vpbroadcastd zmm0, xmm0
vpaddd zmm2, zmm1, zmm0
vpermd zmm2, zmm3, zmm2
inc rax
sub rdx, 0x1
jnz loop

-> Baseline 1x

Alternative 2: Broadcast with a 32-bit Memory Operand
loop:
vpbroadcastd zmm0, [rax]
vpaddd zmm2, zmm1, zmm0
vpermd zmm2, zmm3, zmm2
inc rax
sub rdx, 0x1
jnz loop

-> Speedup: 1.57x

Alternative 3: 32-bit Embedded Broadcast
loop:
vpaddd zmm2, zmm1, [rax]{1to16}
vpermd zmm2, zmm3, zmm2
inc rax
sub rdx, 0x1
jnz loop

-> Speedup: 1.9x

[Bug libstdc++/91655] New: Use of `__in` and `__out` as argument names in c++ headers

[sagebar at web dot de]

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

Bug ID: 91655
   Summary: Use of `__in` and `__out` as argument names in c++
headers
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

After building libstdc++ for a custom toolchain that tries to form a hybrid of
both linux/gnu system headers, as well as headers normally only found on MSVC
(in this case namely: ), I've noticed a problem when it comes to some of
the names used for paramters taken/used by functions exposed in headers created
by libstdc++

Example:
In
[`bits/basic_string.tcc`](https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a00771_source.html),
a function is defined `[...] operator>>(basic_istream<_CharT, _Traits>& __in,
[...])`
As plainly visible, this function takes (and uses) an argument named `__in`.
This causes a collision with a macro defined by MSVC's
[``](https://github.com/dotnet/corert/blob/master/src/Native/inc/unix/sal.h)
header, which is also used by headers such as ``.

I bring up this minor compatibility problem not because it posed too much
problems for me (for my purposes, I simply created a
[patch](https://github.com/GrieferAtWork/KOSmk4/blob/master/kos/misc/patches/libstdc%2B%2B-9.1.0.patch)
file to fix all of those argument names), but because the fix would be so
simple that resolving it could possibly take less time than reading this bug
report.

Of course you are still free to mark this as wont-fix and I would fully
understand the decision to not provide for such compatibility with a
proprietary Windows header.

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
There are quite some .rodata optimizations we don't handle, merging of
different size / mode constants being one of them, ordering by access patterns
another (IMHO size should win here).  I guess in principle post-processing
of the constant pool should be possible at output_constant_pool time
when we add the ability to have multiple labels (with extra offset) per
constant pool entry.  I've once tried some tricks at constant pool entry
creation time (IIRC it was sharing vector constant with scalar constant
entries when they match at the first element).

[Bug libstdc++/91655] Use of `__in` and `__out` as argument names in c++ headers

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to sagebar from comment #0)
> because the fix would be so simple that resolving it could possibly take
> less time than reading this bug report.

Only if we didn't want to bother testing the fix.

Those macros are an abomination. Can you use the PAL_STDCPP_COMPAT macro to
prevent them being defined?

I'm not inclined to change the parameter names in our headers for this, sorry.

[Bug libstdc++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
GCC 4.9.2 has been unsupported for several years.

[Bug libstdc++/91655] Use of `__in` and `__out` as argument names in c++ headers

[sagebar at web dot de]

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

--- Comment #2 from sagebar at web dot de ---
Of course. I understand, am sorry to have bothered you, and totally agree that
those macros are extremely bad (but sadly are being used by programs that I'm
trying to provide compatibility for).
Have a great day, and thanks for the quick reply

[Bug fortran/91648] [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.3

[Bug fortran/91643] [10 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1265

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug fortran/91641] [9/10 Regression] ICE in gfc_conv_is_contiguous_expr, at fortran/trans-intrinsic.c:2857

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug libstdc++/91655] Use of `__in` and `__out` as argument names in c++ headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Jonathan Wakely  ---
Closing then. I think this has to be handled in your custom toolchain, sorry.

[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|new FAILs for   |[10 Regression] new FAILs
   |Warray-bounds-8 and |for Warray-bounds-8 and
   |Wstringop-overflow-3.C  |Wstringop-overflow-3.C

--- Comment #6 from Richard Biener  ---
new FAILs are a regression even if they never passed

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-04
 Blocks||85316
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We have no value-range analysis for floating-point, plus
call-DCE emits an unordered >= while your test is using an ordered compare.

   [local count: 1073741824]:
  y_4 = x_3(D) * x_3(D);
  if (y_4 >= 0.0)
goto ; [26.75%]
  else
goto ; [73.25%]

   [local count: 287225938]:
  if (y_4 u>= 0.0)
goto ; [99.95%]
  else
goto ; [0.05%]

   [local count: 287082327]:
  _7 = .SQRT (y_4);
  goto ; [100.00%]

   [local count: 143611]:
  _10 = __builtin_sqrtf (y_4);

and jump threading doesn't know that if y >= 0.0 is true then
isgreaterequal (y, 0.0) is as well.  OTOH I'm not sure that's
actually true since IIRC isgreaterequal (y, 0.0) will return
true if isunordered (y, 0.0) while for y >= 0.0 the result
is unspecified?

So maybe you simply have to adjust your precondition appropriately
like

  y = x * x;
  if (isless (y, 0.0))
__builtin_unreachable ();
  return std::sqrt (y);

that way it works for me?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-04
 Ever confirmed|0   |1
  Known to fail||8.3.1, 9.2.1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The FE generates an absolutely _huge_ functions (2.2 million lines of .original
dump) for __copy_lvt_statsdatamod_Stats_struc.  It's impossible to tell
if the function generated makes any sense - a smaller example needs to be
looked at but I suspect unnecessary redundancies (aka combinatorical
explosion).

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Paul, you probably know more about this than anybody else.

[Bug tree-optimization/88149] [7 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED

--- Comment #16 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88149] [7 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 10:51:02 2019
New Revision: 275370

URL: https://gcc.gnu.org/viewcvs?rev=275370&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2018-11-23  Richard Biener  

PR tree-optimization/88149
* tree-vect-slp.c (vect_slp_analyze_node_operations): Detect
the case where there are two different def types for the
same operand at different operand position in the same stmt.

* g++.dg/torture/pr88149.C: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr88149.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-slp.c

[Bug fortran/91650] [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/91656] New: [10 Regression] wrong code with -fgcse-after-reload

[zsojka at seznam dot cz]

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

Bug ID: 91656
   Summary: [10 Regression] wrong code with -fgcse-after-reload
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 46810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46810&action=edit
reduced testcase

r275318 is OK, r275369 is BAD

$ riscv64-unknown-linux-gnu-gcc -Og -fgcse-after-reload testcase339.c -static
&& ./a.out 
Aborted
$ riscv64-unknown-linux-gnu-gcc -Og testcase339.c -static && ./a.out
(finishes fine)

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-trunk-275369-checking-yes-rtl-df-extra-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-275369-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/10.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-275369-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190904 (experimental) (GCC)

[Bug tree-optimization/91656] [10 Regression] wrong code with -fgcse-after-reload

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 46811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46811&action=edit
another testcase (needs -O3)

$ riscv64-unknown-linux-gnu-gcc -O3 testcase340.c -static && ./a.out
Aborted
$ riscv64-unknown-linux-gnu-gcc -O3 testcase340.c -static
-fno-gcse-after-reload && ./a.out
(finishes correctly)

r275318 is OK, r275369 is BAD

[Bug target/91615] [10 regression][armeb] ICEs since r274986

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
(In reply to Bernd Edlinger from comment #4)
> Hi Christophe,
> 
> many thanks for your invaluable help.
> 
> I think except this one all regressions are fixed or
> at least understood.
> 
> Unfortunately I have a bit of trouble to reproduce this
> could you please give the exact config options
> and RUNTESTFLAGS, so I can build a cross to debug this?

Sure, nothing fancy; I hoped the options I listed earlier were enough.

Here is what I have at the end of gcc.log:
Executing on host:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-armeb-none-linux-gnueabihf/gcc3/gcc/xgcc
-v(timeout = 300)
spawn -ignore SIGHUP
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-armeb-none-linux-gnueabihf/gcc3/gcc/xgcc
-v
Using built-in specs.
COLLECT_GCC=/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-armeb-none-linux-gnueabihf/gcc3/gcc/xgcc
COLLECT_LTO_WRAPPER=/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/libexec/gcc/armeb-none-linux-gnueabihf/10.0.0/lto-wrapper
Target: armeb-none-linux-gnueabihf
Configured with: /configure --target=armeb-none-linux-gnueabihf
--prefix=/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools
--with-sysroot=/aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-armeb-none-linux-gnueabihf
--disable-nls --disable-libgomp --disable-libmudflap --disable-libcilkrts
--enable-checking --enable-languages=c,c++,fortran --with-float=hard
--enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9
--with-fpu=neon-fp16
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190828 (experimental) [master revision 274985] (GCC) 

and nothing in RUNTESTFLAGS

[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[joey.dumont at gmail dot com]

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

--- Comment #2 from Joey Dumont  ---
How do I pass -save-temps to make? Is there a environment variable that changes
the gcc command options?

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

[lisyarus at gmail dot com]

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

--- Comment #2 from Nikita Lisitsa  ---
If by 'isless(y, 0.0)' you mean 'y < 0.f', then no, it doesn't change anything,
it produces the same 'ucomiss ... call sqrtf' boilerplate. May I have
misunderstood you?

By the way, what about '#pragma GCC optimize ("no-math-errno")'? Is it supposed
to work? Should I issue another bug on that matter?

[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[dragan.mladjeno...@rt-rk.com]

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

--- Comment #3 from Dragan Mladjenovic  ---
You can try manualy rerunning the faulting command after libtool: compile: ...
with  -save-temps.

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46812&action=edit
gcc10-pr91001.patch

Untested fix.

[Bug middle-end/91105] internal compiler error: maximum number of generated reload insns per insn achieved (90)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
Dup.

*** This bug has been marked as a duplicate of bug 91001 ***

[Bug target/91106] internal compiler error: output_operand: invalid use of register 'frame'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Dup.

*** This bug has been marked as a duplicate of bug 91001 ***

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
*** Bug 91105 has been marked as a duplicate of this bug. ***

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
*** Bug 91106 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/81740] [7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 11:56:15 2019
New Revision: 275372

URL: https://gcc.gnu.org/viewcvs?rev=275372&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-03-26  Bin Cheng  

PR tree-optimization/81740
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):
In case of outer loop vectorization, check for backward dependence
at the inner loop if outer loop dependence is reversed.

* gcc.dg/vect/pr81740-1.c: New testcase.
* gcc.dg/vect/pr81740-2.c: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81740-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81740-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-data-refs.c

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---
Created attachment 46813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46813&action=edit
Addon generator_module_hierarchy.f90

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[gs...@t-online.de]

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

--- Comment #5 from G. Steinmetz  ---
Created attachment 46814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46814&action=edit
Addon generator_module_hierarchy_ptr.f90

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[gs...@t-online.de]

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

--- Comment #6 from G. Steinmetz  ---
Created attachment 46815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46815&action=edit
Input "2 2", result test_2_2.f90

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[gs...@t-online.de]

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

--- Comment #7 from G. Steinmetz  ---
Created attachment 46816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46816&action=edit
Input "3 3", result test_3_3.f90


Enclosed are generators to systematically test the facts.
Please find attached two result files, 
e.g. ready to compile test_3_3.f90


$ gfortran generator_module_hierarchy.f90 -o gmh
$
$ echo "3 3" > in
$ ./gmh < in > test_3_3.f90
$
$ time gfortran -c test_3_3.f90
...

[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
Author: wilco
Date: Wed Sep  4 12:42:22 2019
New Revision: 275373

URL: https://gcc.gnu.org/viewcvs?rev=275373&root=gcc&view=rev
Log:
[AArch64] Fix PR81800

PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions.
The previous change for PR81800 didn't fix this: when lrint is disabled
in the backend, the midend will simply use llrint.  This actually makes
things worse since llrint now also ignores FE_INVALID exceptions!
The fix is to disable lrint/llrint on double if the size of a long is
smaller (ie. ilp32).

gcc/
PR target/81800
* gcc/config/aarch64/aarch64.md (lrint): Disable lrint pattern if GPF
operand is larger than a long int.

testsuite/
PR target/81800
* gcc.target/aarch64/no-inline-lrint_3.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/aarch64/aarch64.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug preprocessor/91639] [10 Regression] FAIL: gcc.dg/plugin/location-overflow-test-pr83173.c -fplugin=./location_overflo w_plugin.so scan-file-not # (?!1 [^\r\n]+location-overflow-test-pr83173-1.h"

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-04
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/91652] -march=skylake-avx512 -mno-fma -O2 generates FMA instructions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I don't believe this is a bug.
If you look up the Intel CPU manuals, the FMA CPUID Feature Flag guards the VEX
encoded VF{,N}M{ADD,SUB,ADDSUB}{132,213,231}{S,P}{S,D} instructions, but not
the EVEX encoded ones, those are guarded just by AVX512F or AVX512F and
AVX512VL CPUID Feature Flags.  Thus, -mno-fma shouldn't affect them,
-mno-avx512f should.
And you can use -ffp-contract= to decide if code that isn't already using
explicit fma should be converted to FMA or not if the instructions are
available.

[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

--- Comment #20 from Wilco  ---
Author: wilco
Date: Wed Sep  4 13:06:55 2019
New Revision: 275374

URL: https://gcc.gnu.org/viewcvs?rev=275374&root=gcc&view=rev
Log:
[AArch64] Fix PR81800

PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions.
The previous change for PR81800 didn't fix this: when lrint is disabled
in the backend, the midend will simply use llrint.  This actually makes
things worse since llrint now also ignores FE_INVALID exceptions!
The fix is to disable lrint/llrint on double if the size of a long is
smaller (ie. ilp32).

gcc/
PR target/81800
* gcc/config/aarch64/aarch64.md (lrint): Disable lrint pattern if GPF
operand is larger than a long int.

testsuite/
PR target/81800
* gcc.target/aarch64/no-inline-lrint_3.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/aarch64/aarch64.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/81800] On aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

--- Comment #21 from Wilco  ---
Backported to GCC8 and GCC9 too.

[Bug target/81800] On aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Wilco  ---
Fixed

[Bug c++/91618] template-id required to friend a function template, even for a qualified-id

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
to remind me, bullet 3 that Barry references is:

'if the name of the friend is a qualified-id and a matching function template
is found in the specified class or namespace, the friend declaration refers to
the deduced specialization of that function template (13.9.2.6), otherwise,'

[Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
   Last reconfirmed|2010-02-05 12:53:09 |2019-9-4
   Target Milestone|--- |10.0

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to Tamar Christina from comment #16)
> > Do you have a link to those problems?  And no, please don't regress us for 
> > no
> > reason at all, it's really easy to *not* regress this on double-double.
> 
> As far as I am aware, the final version of the patch had no regressions for
> any target, including PowerPC which I used the GCC compile farm to verify
> (https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02567.html)

That sounds great!

> The patch ended up not getting committed because of questions around whether
> integer operations were fast enough on all targets

But floating point operations are *incorrect* (at least when SNaNs are
enabled).

> and on the latest
> reviewer requesting a major change to the patch.

Hrm.

> At this time the patch had gone through 3 completely different
> implementations (due to to every time having a different reviewer reviewing
> it) and so a 4th rewrite was deemed not productive use of time.

Could you please retry anyway?  Maybe split the patch into smaller chunks,
so it is easier to digest?  (This also helps if anything regresses, to help
pinpoint what caused that).

Thanks!

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[rdapp at linux dot ibm.com]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #7 from rdapp at linux dot ibm.com ---
Created attachment 46817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46817&action=edit
Proposed patch using __tls_get_offset

I drafted a patch that uses __tls_get_offset instead of the internal symbol
following Florian's idea.

Test suite looks similar to before.  Is it OK?


Apart from that patch, however, I noticed that we FAIL in

libphobos.allocations/tls_gc_integration.d
libphobos.thread/tlsgc_sections.d

but I'm not sure yet how serious that is.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[fw at gcc dot gnu.org]

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

--- Comment #8 from Florian Weimer  ---
(In reply to rdapp from comment #7)
> Created attachment 46817 [details]
> Proposed patch using __tls_get_offset
> 
> I drafted a patch that uses __tls_get_offset instead of the internal symbol
> following Florian's idea.
> 
> Test suite looks similar to before.  Is it OK?

Calling functions from inline assembly is always a bit iffy.  For example, your
code lacks clobbers for the vector registers (if present) and the condition
code register.  I don't know if s390/s390x has a red zone, or specific call
frame setup requirements (the psABI is ambiguous regarding the latter for
functions whose arguments all fit into registers, as it is the case here).

I would suggest not to use inline assembly for this purpose.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[rdapp at linux dot ibm.com]

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

--- Comment #9 from rdapp at linux dot ibm.com ---
(In reply to Florian Weimer from comment #8)
> Calling functions from inline assembly is always a bit iffy.  For example,
> your code lacks clobbers for the vector registers (if present) and the
> condition code register.  I don't know if s390/s390x has a red zone, or
> specific call frame setup requirements (the psABI is ambiguous regarding the
> latter for functions whose arguments all fit into registers, as it is the
> case here).
> 
> I would suggest not to use inline assembly for this purpose.

Right about the missing registers.  I was wary about building with an older GCC
but the support only started with GCC9 so this should not be a problem. 
Apparently we can also add vector clobbers with -mno-vx.

I opted for inline assembly to make sure r12 is not changed directly before the
function call. Do you have an idea to guarantee this in another way?

[Bug rtl-optimization/91657] New: [10 regression] many failures after r275365

[seurer at gcc dot gnu.org]

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

Bug ID: 91657
   Summary: [10 regression] many failures after r275365
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

One example:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x3fffb7f80477 in ???
#1  0x10001100 in intrinsic_unpack
at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_unpack.f90:15
#2  0x1b0b in main
at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_unpack.f90:21
FAIL: gfortran.fortran-torture/execute/intrinsic_unpack.f90 execution,  -O3 -g 


FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O3 -g 
FAIL: gcc.dg/tree-prof/20050826-2.c execution,-fprofile-use -D_PROFILE_USE
FAIL: gfortran.dg/boz_15.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/boz_15.f90   -O3 -g  execution test
FAIL: gfortran.dg/char_length_8.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/char_length_8.f90   -O3 -g  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90   -O3 -g  execution test
FAIL: gfortran.dg/intrinsic_unpack_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/list_read_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/list_read_4.f90   -O3 -g  execution test
FAIL: gfortran.dg/lto/bind_c-4 f_lto_bind_c-4_0.o-f_lto_bind_c-4_1.o execute 
-O3 -flto 
FAIL: gfortran.dg/maxlocval_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/maxlocval_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/mvbits_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/mvbits_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/namelist_12.f   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/namelist_12.f   -O3 -g  execution test
FAIL: gfortran.dg/pointer_remapping_5.f08   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/pointer_remapping_5.f08   -O3 -g  execution test
FAIL: gfortran.dg/read_legacy_comma.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/read_legacy_comma.f90   -O3 -g  execution test
FAIL: gfortran.dg/record_marker_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/record_marker_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/reshape-alloc.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/reshape-alloc.f90   -O3 -g  execution test
FAIL: gfortran.dg/shift-alloc.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/shift-alloc.f90   -O3 -g  execution test
FAIL: gfortran.dg/unpack_mask_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/unpack_mask_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/zero_sized_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/zero_sized_3.f90   -O3 -g  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_unpack.f90 execution,  -O3 -g

[Bug c++/66844] [c++-concepts] Requires-expression parameter with void type

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #4 from Andrew Sutton  ---
The parameter list of a requires clause should have the same restrictions as
that of a function's, unless WG21 decides to relax this later. The
concepts-cxx2a branch disallows void parameters, making both examples
ill-formed.

A (void) parameter-list is still permitted and is equivalent to ().

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[fw at gcc dot gnu.org]

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

--- Comment #10 from Florian Weimer  ---
(In reply to rdapp from comment #9)
> I opted for inline assembly to make sure r12 is not changed directly before
> the function call. Do you have an idea to guarantee this in another way?

Wouldn't an out-of-line function in an .S file work?  It's a bit annoying
because makefile changes will be needed, but maybe that's not too bad.

Does D support top-level asm statements?  Then perhaps you could use that to
define an out-of-line function.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

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

--- Comment #11 from Andrew Sutton  ---
Most of the concerns in this issue have been resolved when concept satisfaction
was defined in terms of normalized constraints in all contexts (requirements or
otherwise). In particular. negation makes the constraint atomic, and we don't
recursively normalize atoms. Negation is not a logical operator for the purpose
of subsumption.

Note that the case of overloading with the constraints !(C && C) vs
(!C || !C) is ambiguous since the atomic constraint !(C && C)
doesn't match either  !C and !C (and vice versa).

The concepts-cxx2a branch implements the new semantics.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[andrew.n.sutton at gmail dot com]

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

--- Comment #5 from Andrew Sutton  ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch.

[Bug c++/67148] [concepts] Failed concept check when indirecting through a constrained trait

[andrew.n.sutton at gmail dot com]

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

--- Comment #3 from Andrew Sutton  ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch, which also has a test for this PR.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[andrew.n.sutton at gmail dot com]

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

--- Comment #6 from Andrew Sutton  ---
There's a test for this PR in the concepts-cxx2a branch.

[Bug c++/67178] [concepts] ICE on self-referencing concept

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Fixed in concepts-cxx2a branch. Added a test for this PR.

[Bug c++/67210] [concepts] Error parsing ">>" after a template-id that names a concept

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been resolved at some point. Added a unit test to the
concepts-cxx2a branch.

[Bug c++/67217] [concepts] Constraints are ignored when specializing union templates

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Fixed in concepts-cxx2a. Added a test for this PR.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #10)
> (In reply to rdapp from comment #9)
> > I opted for inline assembly to make sure r12 is not changed directly before
> > the function call. Do you have an idea to guarantee this in another way?
> 
> Wouldn't an out-of-line function in an .S file work?  It's a bit annoying
> because makefile changes will be needed, but maybe that's not too bad.
> 
> Does D support top-level asm statements?  Then perhaps you could use that to
> define an out-of-line function.

.S has the disadvantage that you need to take care about .note.GNU-stack etc.
If D doesn't have toplevel asm, you could use toplevel asm in a C source
perhaps.

[Bug c++/67225] [concepts] Expression constraint with a constrained result turns off access checking

[andrew.n.sutton at gmail dot com]

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

--- Comment #7 from Andrew Sutton  ---
It looks like there was an earlier state where access was being turned
off by one construct or another. All of the examples here fail as they're
supposed to. Added tests to concepts-cxx2a.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Though, looking at libdruntime, it already handles that and has several *.S
files.

[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference!

Here's a small test case copied from the one around line 335 in
g++.dg/warn/Warray-bounds-8.C, and its output with the cross:

  void sink (void*);

  struct B0
  {
char n;
char a[0];// { dg-message "destination object declared
here" }

B0 () { a[0] = 0; }   // { dg-warning "\\\[-Wstringop-overflow" }
  };

  void gb0 (void)
  {
struct B0 b0;
sink (&b0);
  }

$ /build/x86_64-apple-darwin10/gcc-svn/gcc/xgcc -B
/build/x86_64-apple-darwin10/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
In constructor 'B0::B0()',
inlined from 'void gb0()' at t.C:16:13:
t.C:10:16: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   10 |   B0 () { a[0] = 0; }   // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ~^~~

and with a Linux native GCC:

$ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
t.C: In function ‘void gb0()’:
t.C:10:14: warning: array subscript 0 is above array bounds of ‘char [0]’
[-Warray-bounds]
   10 |   B0 () { a[0] = 0; }   // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ~~~^
t.C:8:8: note: while referencing ‘B0::a’
8 |   char a[0];// { dg-message "destination object
declared here" }
  |^


The difference between the two is that with the cross the store is a MEM_REF
that the -Warray-bounds warning doesn't handle:

gb0 ()
{
  struct B0 b0;

   [local count: 1073741824]:
  MEM[(char *)&b0 + 1B] = 0;
  sink (&b0);
  b0 ={v} {CLOBBER};
  return;

}

while with the native GCC the store is an ARRAY_REF that -Warray-bounds does
handle:

gb0 ()
{
  struct B0 b0;

   [local count: 1073741824]:
  b0 ={v} {CLOBBER};
  b0.a[0] = 0;
  sink (&b0);
  b0 ={v} {CLOBBER};
  return;

}

The MEM_REF is introduced during the early sra pass which the native compiler
decides not to run because the B0 ctor doesn't pass the
ipa_sra_preliminary_function_checks: it thinks the function cannot be local. 
This is based on the result of cgraph_node_cannot_be_local_p_1, specifically
the value of node->same_comdat_group which is null with the native GCC and
non-null with darwin:

cgraph_node_cannot_be_local_p_1 (cgraph_node *node, void *)
{
  return !(!node->force_output
   && ((DECL_COMDAT (node->decl)
&& !node->forced_by_abi
&& !node->used_from_object_file_p ()
&& !node->same_comdat_group)
   || !node->externally_visible));
}

I can't say I know why that is but the difference seems gratuitous.

That aside, ideally, both warnings would handle both forms of accesses but as
they don't share code so they improve independently, leading to these kinds of
inconsistencies.  I will look into improving -Warray-bounds to handle the
MEM_REF case as well.

[Bug c++/67319] Short-hand concepts for variadic member functions broken

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been fixed at some point. Add a test for this PR in
concepts-cxx2a.

[Bug c++/67427] [concepts] Subsumption dependence on template parameter ordering

[andrew.n.sutton at gmail dot com]

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

--- Comment #1 from Andrew Sutton  ---
I believe that the ambiguity is correct under the revised semantics of
concepts.

The targets of the parameter mapping in Sentinel differs for the two
declarations of distance because the order of template parameters changes. For
the first declaration, the parameter mapping of the normal form of the requires
expression maps the 2nd template parameter of the concept to the 2nd template
parameter of the function template. For the second declaration, the normal form
of the requires expression maps the 2nd template parameter of the concept to
the 1st template parameter of the function template. Template parameters with
different indexes are not equivalent.

[Bug c++/67654] [concepts] ICE when using concepts in constexpr function

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been fixed at some point. Added a test for this PR in the
concepts-cxx2a branch.

[Bug c++/91658] New: g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

Bug ID: 91658
   Summary: g++: internal compiler error: Killed (program cc1plus)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.chow2 at aecom dot com
  Target Milestone: ---

Created attachment 46818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46818&action=edit
file which cause the compiler to fail with internal error

gcc version 7.4.0 on Ubuntu 18.04.1 fails when it complies a file from MXnet
distribution with the following messages:
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with prepossessed source if appropriate.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

--- Comment #2 from Ivan Chow  ---
Thanks for the info.

I ran this on Ubuntu 18.04 with 16GB RAM configured on a VMware VM and the
maximum memory allowed is 16GB for this VM 

What should I do? 

Thanks for any advices.


-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, September 4, 2019 11:26 AM
To: Chow, Ivan (Aiken)
Subject: [Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D91658&d=DwIFaQ&c=TQzoP61-bYDBLzNd0XmHrw&r=1l2NCl9J2IRlx158OleV8UxhxKZcl07nghTppK8NHRQ&m=xIOYHPfZ-u-WA1Rv1yzNRl-x4iApqZS8WZEXmCdzqMw&s=PvKjvYMWPeh1ZBcDG62Mz-AyKrdic9VIMIbDlRwT2gE&e=
 

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

--- Comment #3 from Ivan Chow  ---
Sorry.  Actually, I can increase the VM memory.   Only the "recommended"
maximum memory is 16GB.

Let me increase the VM memory to 24 GB and see what happen.  But it does have a
maximum memory, which is 64GB.

Thanks.


-Original Message-
From: Chow, Ivan (Aiken) 
Sent: Wednesday, September 4, 2019 11:29 AM
To: 'mpolacek at gcc dot gnu.org'
Subject: RE: [Bug c++/91658] g++: internal compiler error: Killed (program
cc1plus)


Thanks for the info.

I ran this on Ubuntu 18.04 with 16GB RAM configured on a VMware VM and the
maximum memory allowed is 16GB for this VM 

What should I do? 

Thanks for any advices.


-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, September 4, 2019 11:26 AM
To: Chow, Ivan (Aiken)
Subject: [Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D91658&d=DwIFaQ&c=TQzoP61-bYDBLzNd0XmHrw&r=1l2NCl9J2IRlx158OleV8UxhxKZcl07nghTppK8NHRQ&m=xIOYHPfZ-u-WA1Rv1yzNRl-x4iApqZS8WZEXmCdzqMw&s=PvKjvYMWPeh1ZBcDG62Mz-AyKrdic9VIMIbDlRwT2gE&e=
 

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

--- Comment #4 from Ivan Chow  ---
24GB still crashed the compiler

I think the preprocessor cc1plus has a bug in handling some of the templates of
that file...   it shouldn't need that much memory 

I ran command 'top' and can see the memory usage ran out-of-control and then
the compiler crashed.


-Original Message-
From: Chow, Ivan (Aiken) 
Sent: Wednesday, September 4, 2019 11:44 AM
To: 'mpolacek at gcc dot gnu.org'
Subject: RE: [Bug c++/91658] g++: internal compiler error: Killed (program
cc1plus)


Sorry.  Actually, I can increase the VM memory.   Only the "recommended"
maximum memory is 16GB.

Let me increase the VM memory to 24 GB and see what happen.  But it does have a
maximum memory, which is 64GB.

Thanks.


-Original Message-
From: Chow, Ivan (Aiken) 
Sent: Wednesday, September 4, 2019 11:29 AM
To: 'mpolacek at gcc dot gnu.org'
Subject: RE: [Bug c++/91658] g++: internal compiler error: Killed (program
cc1plus)


Thanks for the info.

I ran this on Ubuntu 18.04 with 16GB RAM configured on a VMware VM and the
maximum memory allowed is 16GB for this VM 

What should I do? 

Thanks for any advices.


-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, September 4, 2019 11:26 AM
To: Chow, Ivan (Aiken)
Subject: [Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D91658&d=DwIFaQ&c=TQzoP61-bYDBLzNd0XmHrw&r=1l2NCl9J2IRlx158OleV8UxhxKZcl07nghTppK8NHRQ&m=xIOYHPfZ-u-WA1Rv1yzNRl-x4iApqZS8WZEXmCdzqMw&s=PvKjvYMWPeh1ZBcDG62Mz-AyKrdic9VIMIbDlRwT2gE&e=
 

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #14 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Sep  4 16:25:21 2019
New Revision: 275376

URL: https://gcc.gnu.org/viewcvs?rev=275376&root=gcc&view=rev
Log:
Add warning Wenum-conversion for C and ObjC.

The patch enables warning with Wextra due to PR91593 and warnings with
allmodconfig kernel build. Once these issues are resolved, we could
consider promoting it to Wall.

2019-09-04  Prathamesh Kulkarni  

PR c/78736
* doc/invoke.texi: Document -Wenum-conversion.

c-family
* c.opt (Wenum-conversion): New option.

c/
* c-typeck.c (convert_for_assignment): Handle Wenum-conversion.

testsuite/
* gcc.dg/Wenum-conversion.c: New test-case.

Added:
trunk/gcc/testsuite/gcc.dg/Wenum-conversion.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[joseph at codesourcery dot com]

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

--- Comment #18 from joseph at codesourcery dot com  ---
On Wed, 4 Sep 2019, tnfchris at gcc dot gnu.org wrote:

> As far as I am aware, the final version of the patch had no regressions for 
> any
> target, including PowerPC which I used the GCC compile farm to verify
> (https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02567.html)
> 
> The patch ended up not getting committed because of questions around whether
> integer operations were fast enough on all targets and on the latest reviewer
> requesting a major change to the patch.

It *was* committed (r249005).  Then reverted (r249050).  
 reported "a 
large number of new failures on AIX, including compiler ICEs".  I noted it 
caused ICEs building glibc for powerpc.  Rainer noted Solaris/SPARC was 
affected .  
Other issues were also reported in that thread.

Clearly these problems need to be fixed before it can go back in.

That doesn't mean it needs to cover all cases.  But it needs to avoid 
introducing regressions (whether ICEs or wrong code), and existing cases 
that are expanded inline need to stay expanded inline (whether with the 
old or the new expansion), and the limited subset of cases where it's OK 
to take the address of some such built-in functions with the possibility 
of out-of-line expansion need to stay working in the cases where they 
currently work.

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[tnfchris at gcc dot gnu.org]

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

--- Comment #19 from Tamar Christina  ---
> It *was* committed (r249005).  Then reverted (r249050).  
>  reported "a 
> large number of new failures on AIX, including compiler ICEs".  I noted it 
> caused ICEs building glibc for powerpc.  Rainer noted Solaris/SPARC was 
> affected .  
> Other issues were also reported in that thread.

No it was not. The patch you're linking to is a couple of months older than the
one I had linked to that was problem free.

Yes it was committed and reverted and fixed, but never committed again.

The patch you linked to was form June, the one I linked to is from November.
Two different patches.

[Bug c++/67658] [concepts] invalid code with constrained concepts compiles

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46819&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

[Bug c++/67684] [concepts] friend access not working with constrained function

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Fixed in concepts-cxx2a branch and added a test for the PR.

[Bug c++/67685] ICE on invalid requires expression

[andrew.n.sutton at gmail dot com]

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

--- Comment #3 from Andrew Sutton  ---
Fixed in the concepts-cxx2a branch and added a test for the PR.