[Bug tree-optimization/92452] [10 Regression] ICE in vrp_prop::check_array_ref at tree-vrp.c:4153

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 12 08:21:40 2019
New Revision: 278080

URL: https://gcc.gnu.org/viewcvs?rev=278080&root=gcc&view=rev
Log:
PR tree-optimization/92452
* tree-vrp.c (vrp_prop::check_array_ref): If TRUNC_DIV_EXPR folds
into NULL_TREE, set up_bound to NULL_TREE instead of computing
MINUS_EXPR on it.

* c-c++-common/pr92452.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr92452.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug testsuite/92464] [10 regression] r278033 breaks gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-12
 Ever confirmed|0   |1

--- Comment #1 from Kewen Lin  ---
Before the regressed commit, the cost view looks like:
  0x13135eb0 ic[i_35] 2 times vector_stmt costs 2 in prologue
  0x13135eb0 ic[i_35] 1 times vector_stmt costs 1 in prologue
  0x13135eb0 ic[i_35] 1 times vector_load costs 1 in body
  0x13135eb0 ic[i_35] 1 times vec_perm costs 3 in body
  0x13135eb0 _5 1 times vector_store costs 1 in body
  .c:21:3: note:  not using a fully-masked loop.
  cost model: prologue peel iters set to vf/2.
  cost model: epilogue peel iters set to vf/2 because peeling for alignment is
unknown.
  0x13135eb0  1 times cond_branch_taken costs 3 in prologue
  0x13135eb0  1 times cond_branch_not_taken costs 1 in prologue
  0x13135eb0  1 times cond_branch_taken costs 3 in epilogue
  0x13135eb0  1 times cond_branch_not_taken costs 1 in epilogue
  0x13135eb0 ic[i_35] 2 times scalar_load costs 2 in prologue
  0x13135eb0 ic[i_35] 2 times scalar_load costs 2 in epilogue
  0x13135eb0 _5 2 times scalar_store costs 2 in prologue
  0x13135eb0 _5 2 times scalar_store costs 2 in epilogue
  .c:21:3: note:  Cost model analysis:
Vector inside of loop cost: 5
Vector prologue cost: 11
Vector epilogue cost: 8
Scalar iteration cost: 2
Scalar outside cost: 0
Vector outside cost: 19
prologue iterations: 2
epilogue iterations: 2
Calculated minimum iters for profitability: 19

With the commit, the cost view is changed to:
  0x13135eb0 ic[i_35] 2 times vector_stmt costs 2 in prologue
  0x13135eb0 ic[i_35] 1 times vector_stmt costs 1 in prologue
  0x13135eb0 ic[i_35] 1 times vector_load costs 2 in body
  0x13135eb0 ic[i_35] 1 times vec_perm costs 3 in body
  0x13135eb0 _5 1 times vector_store costs 1 in body
  .c:21:3: note:  not using a fully-masked loop.
  cost model: prologue peel iters set to vf/2.
  cost model: epilogue peel iters set to vf/2 because peeling for alignment is
unknown.
  0x13135eb0  1 times cond_branch_taken costs 3 in prologue
  0x13135eb0  1 times cond_branch_not_taken costs 1 in prologue
  0x13135eb0  1 times cond_branch_taken costs 3 in epilogue
  0x13135eb0  1 times cond_branch_not_taken costs 1 in epilogue
  0x13135eb0 ic[i_35] 2 times scalar_load costs 4 in prologue
  0x13135eb0 ic[i_35] 2 times scalar_load costs 4 in epilogue
  0x13135eb0 _5 2 times scalar_store costs 2 in prologue
  0x13135eb0 _5 2 times scalar_store costs 2 in epilogue
  .c:21:3: note:  Cost model analysis:
Vector inside of loop cost: 6
Vector prologue cost: 13
Vector epilogue cost: 10
Scalar iteration cost: 3
Scalar outside cost: 0
Vector outside cost: 23
prologue iterations: 2
epilogue iterations: 2
Calculated minimum iters for profitability: 12

The cost changes are expected, scalar and vector load cost more. It leads the
profitable min iter count become small.

I ran both before- and after-executable with 10 invocations at 10 times,
the evaluated time are very close, both average time are 65.23s. It means the
cost adjustment doesn't make this case worse.

One fix idea is to adjust the test case iteration count to 11 lower than the
current profitable min iters count.

[Bug target/92449] [10 Regression] ICE in extract_insn, at recog.c:2311

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 12 08:22:29 2019
New Revision: 278081

URL: https://gcc.gnu.org/viewcvs?rev=278081&root=gcc&view=rev
Log:
PR target/92449
* tree-complex.c (expand_complex_multiplication): If !HONOR_NANS,
don't emit UNORDERED_EXPR guarded libcall.  Formatting fixes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-complex.c

[Bug tree-optimization/92452] [10 Regression] ICE in vrp_prop::check_array_ref at tree-vrp.c:4153

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.

[Bug fortran/92470] New: CFI_address wrongly assumes that lower bounds are at zero – invalid for pointers + allocatables

[burnus at gcc dot gnu.org]

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

Bug ID: 92470
   Summary: CFI_address wrongly assumes that lower bounds are at
zero – invalid for pointers + allocatables
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Mentioned at https://gcc.gnu.org/ml/fortran/2019-11/msg00060.html
refers to
https://github.com/j3-fortran/fortran_proposals/issues/57#issuecomment-552680503
(the two Fortran codes in this comment are identical).

The problem is the handling of the lower bound and CFI_address.

Passing a Fortran array to bind(C), one has for the bounds (F2018, 18.5.3, para
3):

"For a C descriptor of an array pointer or allocatable array, the value of the
lower_bound member of each element of the dim member of the descriptor is
determined by argument association, allocation, or pointer association.
For a C descriptor of a nonallocatable nonpointer object, the value of the
lower_bound member of each element of the dim member of the descriptor is
zero."

Hence, for allocate(A(-2:5)) - A's lower bound has also in C the value -2.
Thus, when calling
   CFI_address(dv, lb);
with lb = -2, the result should be the original unmodified "data" pointer.

The problem is that CFI_address assumes that the lower bound is 0;
libgfortran/runtime/ISO_Fortran_binding.c has:
   base_addr = base_addr + (CFI_index_t)(subscripts[i] * dv->dim[i].sm);

Expected: Either add a case separation (e.g. based on the type) or
unconditionally honour the lower bound value.

[Bug fortran/92470] CFI_address wrongly assumes that lower bounds are at zero – invalid for pointers + allocatables

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Created attachment 47215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47215&action=edit
Lightly tested patch

[Bug tree-optimization/92461] [10 Regression] ICE: verify_ssa failed (error: excess use operand for statement)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-12
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug tree-optimization/92460] [10 Regression] ICE: verify_ssa failed (error: definition in block 13 does not dominate use in block 22)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Indeed -fno-strict-aliasing might be a workaround (apart from the atomicity
issue).  Also using a character type for the access (uint8_t is _not_ a
character type) would make the alias issue go away.

[Bug testsuite/92464] [10 regression] r278033 breaks gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/92465] [10 regression] r278034 breaks gcc.dg/pr47763.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|other   |target
   Target Milestone|--- |10.0

[Bug fortran/83118] [7/8/9/10 Regression] Bad intrinsic assignment of class(*) array component of derived type

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #23 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #21)
> > Created attachment 46216 [details]
> > Patch for the remaining problems.
> I have the patch in my working tree without any problem.

(In reply to paul.richard.tho...@gmail.com from comment #22)
> I'll get lined up to fix this tomorrow night.

Any update? That was 2019-05-19.

Does this patch by chance also fix the issue reported at
https://gcc.gnu.org/ml/fortran/2019-11/msg00061.html ?

[Bug target/92469] [9/10 Regression] ICE: output_operand: invalid use of register 'frame'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug ipa/92471] New: [ICE] segmentation fault in ipa-profile.c ipa_get_cs_argument_count (args=0x0)

[hliu at amperecomputing dot com]

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

Bug ID: 92471
   Summary: [ICE] segmentation fault in ipa-profile.c
ipa_get_cs_argument_count (args=0x0)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hliu at amperecomputing dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

GCC failed to compile spec2017 523.xalancbmk_r. The command line and stacks are
as following:

(gdb) r -quiet -dumpbase AIXPlatformUtils.o -mabi=lp64 -mlittle-endian
-march=armv8-a+crypto+crc -auxbase AIXPlatformUtils -Ofast -version -fno-openmp
-fno-openacc -fno-pie -fltrans-output-list=/tmp/ccuzr3NS.ltrans.out -fwpa
@/tmp/ccbPq0RT
...
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 10.0.0 2019 (experimental)
(aarch64-unknown-linux-gnu)
compiled by GNU C version 10.0.0 2019 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
...
Program received signal SIGSEGV, Segmentation fault.
0x0071bd54 in ipa_get_cs_argument_count (args=0x0) at
../../gcc/gcc/ipa-prop.h:681
681   return vec_safe_length (args->jump_functions);
(gdb) bt
#0  0x0071bd54 in ipa_get_cs_argument_count (args=0x0) at
../../gcc/gcc/ipa-prop.h:681
#1  ipa_profile () at ../../gcc/gcc/ipa-profile.c:607
#2  (anonymous namespace)::pass_ipa_profile::execute (this=) at
../../gcc/gcc/ipa-profile.c:755
#3  0x0084a224 in execute_one_pass (pass=pass@entry=0x1be2e00) at
../../gcc/gcc/passes.c:2494
#4  0x0084ba28 in execute_ipa_pass_list (pass=0x1be2e00) at
../../gcc/gcc/passes.c:2921
#5  0x0043b0f4 in do_whole_program_analysis () at
../../gcc/gcc/context.h:48
#6  lto_main () at ../../gcc/gcc/lto/lto.c:642
#7  0x0091d568 in compile_file () at ../../gcc/gcc/toplev.c:459
#8  0x0040f630 in do_compile () at ../../gcc/gcc/toplev.c:2284
#9  toplev::main (this=this@entry=0xedd8, argc=,
argc@entry=17, argv=, argv@entry=0xef38) at
../../gcc/gcc/toplev.c:2419
#10 0x0041143c in main (argc=17, argv=0xef38) at
../../gcc/gcc/main.c:39
(gdb) p args
$1 = (ipa_edge_args *) 0x0

[Bug ipa/92471] [ICE] lto1 segmentation fault: ipa-profile.c ipa_get_cs_argument_count (args=0x0)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-12
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can see the same, lemme bisect that.

[Bug tree-optimization/90200] [graphite] ICE: Segmentation fault (in apply_schedule_on_deps)

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
I cannot reproduce ti w/ gfortran-10.0.0-alpha20191110 snapshot and isl 0.22.

[Bug c++/92441] [10 regression] ICE: in strip_typedefs, at cp/tree.c:1681

[h2+bugs at fsfe dot org]

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

--- Comment #2 from Hannes Hauswedell  ---
(In reply to Martin Liška from comment #1)
> Can you please provide full command line of the GCC?

g++10 -std=c++17 -fconcepts dna4_test.ii

This triggers the ICE as mentioned in the original report. For The resulting
binary to link correctly, gtest has to be added as a static library.

The full invocation that generates the intermediate code is this:

cd /home/hannes/devel/seqan3-build/release10/alphabet/nucleotide &&
/usr/local/bin/ccache /usr/local/bin/g++10  -DSEQAN3_HAS_BZIP2=1
-DSEQAN3_HAS_ZLIB=1
-I/home/hannes/devel/seqan3-build/release10/vendor/googletest/googletest/include
-I/home/hannes/devel/seqan3/test/include -I/home/hannes/devel/seqan3/include
-isystem /home/hannes/devel/seqan3/submodules/sdsl-lite/include -isystem
/home/hannes/devel/seqan3/submodules/range-v3/include -isystem
/home/hannes/devel/seqan3/submodules/cereal/include 
-ftemplate-backtrace-limit=0 -fdiagnostics-color=always -std=c++17 -fconcepts
-save-temps -O3 -DNDEBUG   -pedantic -Wall -Wextra -Werror
-DNO_WARN_X86_INTRINSICS -pthread -o CMakeFiles/dna4_test.dir/dna4_test.cpp.o
-c /home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/dna4_test.cpp



> And please paste output of when '-v' is added.

Using built-in specs.
COLLECT_GCC=g++10
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc10/gcc/x86_64-portbld-freebsd12.0/10.0.0/lto-wrapper
Target: x86_64-portbld-freebsd12.0
Configured with:
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20191103/configure
--enable-multilib --with-build-config=bootstrap-debug --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc10
--libexecdir=/usr/local/libexec/gcc10 --program-suffix=10
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc10/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc10 --build=x86_64-portbld-freebsd12.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191103 (experimental) (FreeBSD Ports Collection) 
COLLECT_GCC_OPTIONS='-std=c++17' '-fconcepts' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc10/gcc/x86_64-portbld-freebsd12.0/10.0.0/cc1plus
-fpreprocessed /tmp/dna4_test.ii -quiet -dumpbase dna4_test.ii -mtune=generic
-march=x86-64 -auxbase dna4_test -std=c++17 -version -fconcepts -o
/tmp//ccmJ4Que.s
GNU C++17 (FreeBSD Ports Collection) version 10.0.0 20191103 (experimental)
(x86_64-portbld-freebsd12.0)
compiled by GNU C version 10.0.0 20191103 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++17 (FreeBSD Ports Collection) version 10.0.0 20191103 (experimental)
(x86_64-portbld-freebsd12.0)
compiled by GNU C version 10.0.0 20191103 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e7b6ef0d246e27cc0ec9ebf3a0ce4fdc
In file included from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/concepts.hpp:30,
 from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/range/concepts.hpp:28,
 from /home/hannes/devel/seqan3/include/seqan3/std/ranges:28,
 from
/home/hannes/devel/seqan3/include/seqan3/core/concept/core_language.hpp:19,
 from
/home/hannes/devel/seqan3/include/seqan3/alphabet/concept.hpp:17,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/../alphabet_constexpr_test_template.hpp:10,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/dna4_test.cpp:8:
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/access.hpp:222:76:
internal compiler error: in strip_typedefs, at cp/tree.c:1681
  222 | is_swappable_with,
iter_reference_t>::value>
  |
   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Created attachment 47216
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47216&action=edit
asm diff

-O2 -mfma -mtune=znver2 -fdbg-cnt=ivopts_loop:66:67 -fno-schedule-insns
-mno-stv -fno-tree-slsr

assembler diff attached, - is "working", + is "failing".  Can't see the obvious
error...

[Bug ipa/92471] [ICE] lto1 segmentation fault: ipa-profile.c ipa_get_cs_argument_count (args=0x0)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I can reproduce that for -O2 -flto=16 -march=znver2 with PGO.

[Bug c/92472] New: enhancement: 5 * constify some parameters

[dcb314 at hotmail dot com]

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

Bug ID: 92472
   Summary: enhancement: 5 * constify some parameters
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

1.

For this message from static analyser cppcheck:

trunk/gcc/alloc-pool.h:63:39: style: Parameter 'total' can be declared with
const [constParameter]

This patch seems to fix the problem.

Index: gcc/alloc-pool.h
===
--- gcc/alloc-pool.h(revision 278050)
+++ gcc/alloc-pool.h(working copy)
@@ -60,7 +60,7 @@

   /* Dump usage coupled to LOC location, where TOTAL is sum of all rows.  */
   inline void
-  dump (mem_location *loc, mem_usage &total) const
+  dump (mem_location *loc, const mem_usage &total) const
   {
 char *location_string = loc->to_string ();

2.

Message:

trunk/gcc/bitmap.h:240:39: style: Parameter 'total' can be declared with const
[constParameter]

Patch:

Index: gcc/bitmap.h
===
--- gcc/bitmap.h(revision 278050)
+++ gcc/bitmap.h(working copy)
@@ -237,7 +237,7 @@

   /* Dump usage coupled to LOC location, where TOTAL is sum of all rows.  */
   inline void
-  dump (mem_location *loc, mem_usage &total) const
+  dump (mem_location *loc, const mem_usage &total) const
   {
 char *location_string = loc->to_string ();

3.

Message:

trunk/gcc/mem-stats.h:206:39: style: Parameter 'total' can be declared with
const [constParameter]
trunk/gcc/mem-stats.h:73:24: style: Parameter 'other' can be declared with
const [constParameter]

Patch:

Index: gcc/mem-stats.h
===
--- gcc/mem-stats.h (revision 278050)
+++ gcc/mem-stats.h (working copy)
@@ -70,7 +70,7 @@

   /* Return true if the memory location is equal to OTHER.  */
   int
-  equal (mem_location &other)
+  equal (const mem_location &other)
   {
 return m_filename == other.m_filename && m_function == other.m_function
   && m_line == other.m_line;
@@ -203,7 +203,7 @@

   /* Dump usage coupled to LOC location, where TOTAL is sum of all rows.  */
   inline void
-  dump (mem_location *loc, mem_usage &total) const
+  dump (mem_location *loc, const mem_usage &total) const
   {
 char *location_string = loc->to_string ();


4.

Message:

trunk/gcc/sese.h:48:23: style: Parameter 's' can be declared with const
[constParameter]
trunk/gcc/sese.h:56:22: style: Parameter 's' can be declared with const
[constParameter]

Patch:

Index: gcc/sese.h
===
--- gcc/sese.h  (revision 278050)
+++ gcc/sese.h  (working copy)
@@ -45,7 +45,7 @@
 /* Get the entry of an sese S.  */

 static inline basic_block
-get_entry_bb (sese_l &s)
+get_entry_bb (const sese_l &s)
 {
   return s.entry->dest;
 }
@@ -53,7 +53,7 @@
 /* Get the exit of an sese S.  */

 static inline basic_block
-get_exit_bb (sese_l &s)
+get_exit_bb (const sese_l &s)
 {
   return s.exit->src;
 }

5.

Message:

trunk/libstdc++-v3/include/parallel/multiway_merge.h:121:40: style: Parameter
'__bi2' can be declared with const [constParameter]
trunk/libstdc++-v3/include/parallel/multiway_merge.h:191:42: style: Parameter
'__bi2' can be declared with const [constParameter]

Patch:

Index: libstdc++-v3/include/parallel/multiway_merge.h
===
--- libstdc++-v3/include/parallel/multiway_merge.h  (revision 278050)
+++ libstdc++-v3/include/parallel/multiway_merge.h  (working copy)
@@ -118,7 +118,7 @@
*  @return @c true if less. */
   friend bool
   operator<(_GuardedIterator<_RAIter, _Compare>& __bi1,
-   _GuardedIterator<_RAIter, _Compare>& __bi2)
+   _GuardedIterator<_RAIter, const _Compare>& __bi2)
   {
if (__bi1._M_current == __bi1._M_end)   // __bi1 is sup
  return __bi2._M_current == __bi2._M_end;  // __bi2 is not sup
@@ -188,7 +188,7 @@
*  @return @c true if less. */
   friend bool
   operator<(_UnguardedIterator<_RAIter, _Compare>& __bi1,
-   _UnguardedIterator<_RAIter, _Compare>& __bi2)
+   _UnguardedIterator<_RAIter, const _Compare>& __bi2)
   {
// Normal compare.
return (__bi1.__comp)(*__bi1, *__bi2);

All patches seemed to bootstrap ok.

[Bug target/92473] New: test pr92324-2.c fails on arm and aarch64

[clyon at gcc dot gnu.org]

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

Bug ID: 92473
   Summary: test pr92324-2.c fails on arm and aarch64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The test pr92324-2.c introduced at r277958 fails on arm and aarch64:
FAIL: gcc.dg/vect/pr92324-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr92324-2.c execution test

I'm attaching the end of the execution traces dumped by qemu, not sure how
helpful they are.

[Bug target/92473] test pr92324-2.c fails on arm and aarch64

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Created attachment 47218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47218&action=edit
Execution trace for arm

[Bug target/92473] test pr92324-2.c fails on arm and aarch64

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 47217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47217&action=edit
Execution trace for aarch64

[Bug sanitizer/92474] New: Sanitizer breaks tail-recursion optimization

[Hi-Angel at yandex dot ru]

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

Bug ID: 92474
   Summary: Sanitizer breaks tail-recursion optimization
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

When `-fsanitize=address` applied, tail-call optimization does not kick in.

I made a testcase below. Simplest way to demonstrate it would be to try to run
executable built from the testcase with and without the option: it either
crashes or not. But since it's an arguable demonstration (because how does one
know if non-crashing version didn't simply did not consume enough stack), I
demonstrate it with a different approach: I grep the assembly for `callq
foo()`, and while the case with optimization applied has just one call to it,
the case where it wasn't applied has 2 of them.

# Steps to reproduce (in terms of terminal commands):

$ cat test.cpp
struct MyStruct {
unsigned  n_recurses;
};

MyStruct foo(MyStruct m) {
return (m.n_recurses == 0)? m : foo(MyStruct{m.n_recurses - 1});
}

int main() {
foo(MyStruct{99});
}
$ g++ test.cpp -o a -O3 -g
$ objdump -d a | grep -E "callq.*foo"
1029:   e8 12 01 00 00  callq  1140 <_Z3foo8MyStruct>
$ g++ test.cpp -o a -O3 -g -fsanitize=address
$ objdump -d a | grep -E "callq.*foo"

## Expected:

One line with the call:
1089:   e8 32 01 00 00  callq  11c0 <_Z3foo8MyStruct>

## Actual:

Two lines with the call:
1089:   e8 32 01 00 00  callq  11c0 <_Z3foo8MyStruct>
1293:   e8 28 ff ff ff  callq  11c0 <_Z3foo8MyStruct>

[Bug ipa/92471] [ICE] lto1 segmentation fault: ipa-profile.c ipa_get_cs_argument_count (args=0x0)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|NEW |ASSIGNED
  Known to work||9.2.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92454
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |10.0
  Known to fail||10.0

--- Comment #3 from Martin Liška  ---
Started same as PR92454 with r278016.

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Yeah, I think on x86_64-linux it works by pure accident.
The type used on the C side is:
typedef struct CFI_cdesc_t
 {
void *base_addr;
size_t elem_len;
int version;
CFI_rank_t rank;
CFI_attribute_t attribute;
CFI_type_t type;
CFI_dim_t dim[];
 }
CFI_cdesc_t;

where void * and size_t are 64-bit on LP64 and 32-bit on ILP32,
CFI_rank_t/CFI_attribute_t are 8-bit and CFI_type_t is 16-bit, while for
integer(c_int), allocatable, intent(out) :: dat(..)
select rank (dat)
  rank (0)
  allocate( dat )
  dat = 42
end select
return
seems to assume dat type is a structure containing pointer sized data,
array index offset, and dtype, which has size_t elem_len, int version, 8-bit
rank, type and 16-bit attribute, so the Fortran FE assumption is there is extra
64-bit (or 32-bit) offset and type/attribute are swapped and have different
types.
Which means from the C side, rank is at offset 20 bytes into the structure for
LP64 and 12 bytes in ILP32, while the Fortran emitted code when it reads
dat->dtype.rank reads it from offset 28 bytes into the structure or for ILP32
16 bytes.

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  ---
Some side remarks:

(In reply to Jakub Jelinek from comment #5)
> The type used on the C side is:
This type is described in the Fortran standard; for Fortran 2018, it is
described in "18.5.3  The CFI_cdesc_t structure type" on page 481, cf.
https://j3-fortran.org/doc/year/18/18-007r1.pdf

That's defined on the gfortran side in libgfortran/ISO_Fortran_binding.h

> typedef struct CFI_cdesc_t
>  {
> void *base_addr;
> size_t elem_len;
…

> where void * and size_t are 64-bit on LP64 and 32-bit on ILP32,
> CFI_rank_t/CFI_attribute_t are 8-bit and CFI_type_t is 16-bit, while for
> integer(c_int), allocatable, intent(out) :: dat(..)
…
> seems to assume dat type is a structure containing pointer sized data,
> array index offset, and dtype, which has size_t elem_len, int version, 8-bit
> rank, type and 16-bit attribute, so the Fortran FE assumption is there is
> extra 64-bit (or 32-bit) offset and type/attribute are swapped and have
> different types.

The conversion between gfortran's internal array descriptor and the one use
with C binding ("CFI_") is done in libgfortran/runtime/ISO_Fortran_binding.c
via cfi_desc_to_gfc_desc and gfc_desc_to_cfi_desc; this function is called from
the Fortran side.  (When calling a bind(C) function or for implementing in
Fortran a bind(C) function.)

The C side calls CFI_establish for a likewise purpose (same file).

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I don't see any conversion function to be called:
fsub (struct array15_integer(kind=4) & restrict dat)
{
  {
integer(kind=4) * __tmp_INTEGER_4_rank_0;

{
  signed char D.3928;
  integer(kind=8) D.3929;
  signed char D.3930;

  D.3928 = dat->dtype.rank;
  D.3929 = (integer(kind=8)) D.3928 + -1;
  D.3930 = D.3928 != 0 ? dat->dim[D.3929].ubound != -1 ? D.3928 : -1 :
D.3928;
  if (D.3930 == 0)
{
  try
{
  __tmp_INTEGER_4_rank_0 = (integer(kind=4) *) dat->data;
  if (__tmp_INTEGER_4_rank_0 != 0B)
{
  _gfortran_runtime_error_at (&"At line 15 of file
/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90"[1]{lb:
1 sz: 1}, &"Attempting to allocate already allocated variable \'%s\'"[1]{lb: 1
sz: 1}, &"__tmp_INTEGER_4_rank_0"[1]{lb: 1 sz: 1});
}
  else
{
  __tmp_INTEGER_4_rank_0 = (integer(kind=4) *) __builtin_malloc
(4);
  if (__tmp_INTEGER_4_rank_0 == 0B)
{
  _gfortran_os_error_at (&"In file
\'/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90\',
around line 16"[1]{lb: 1 sz: 1}, &"Error allocating %lu bytes"[1]{lb: 1 sz: 1},
4);
}
}
  if (__tmp_INTEGER_4_rank_0 != 0B) goto L.4;
  __tmp_INTEGER_4_rank_0 = (integer(kind=4) *) __builtin_malloc
(4);
  L.4:;
  *__tmp_INTEGER_4_rank_0 = 42;
  L.3:;
}
  finally
{
  dat->data = (void * restrict) __tmp_INTEGER_4_rank_0;
}
  goto L.2;
}
}
L.2:;
L.1:;
return;
  }
}

[Bug c++/92475] New: incorrect code with optimization

[gunther.vo...@ssw-trading.com]

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

Bug ID: 92475
   Summary: incorrect code with optimization
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gunther.vo...@ssw-trading.com
  Target Milestone: ---

Created attachment 47219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47219&action=edit
preprocessed source

In the following code, the branch for length==0 (including the string constant
"AAA") is optimized away. Observed with GCC 8.3.0/1. With GCC 9.2.1 and GCC
7.4.0, the generated code is correct.

#include 

size_t
f(char* s)
{
ssize_t i;

for (i = 7; i >= 0; i--) {
if (s[i] != ' ') {
if (i < 7) {
s[i + 1] = '\0';
}
break;
}
}

return static_cast(i + 1);
}

void h(const char*);

void
g(char* s)
{
size_t length = f(s);
std::string(s, length); // bug disappears when this line is removed
h(length ? "BBB" : "AAA");
}

[Bug c++/92475] incorrect code with optimization

[gunther.vo...@ssw-trading.com]

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

--- Comment #1 from Gunther Vogel  ---
Created attachment 47220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47220&action=edit
output of gcc -v -save-temps -W -Wall -O2 -S bug.cc

[Bug c++/92475] incorrect code with optimization

[gunther.vo...@ssw-trading.com]

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

--- Comment #2 from Gunther Vogel  ---
Created attachment 47221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47221&action=edit
assembly - no "AAA" in here

[Bug ipa/92471] [ICE] lto1 segmentation fault: ipa-profile.c ipa_get_cs_argument_count (args=0x0)

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
It also affected bootstrap-lto-lean with PGO:

[12135s] ../../gcc/ada/libgnat/s-except.ads:61:4: note: code may be
misoptimized unless '-fno-strict-aliasing' is used
[12136s] during IPA pass: cp
[12136s] lto1: internal compiler error: Segmentation fault
[12136s] 0x725fa9 ???
[12136s]../sysdeps/x86_64/start.S:120
[12136s] Please submit a full bug report,
[12136s] with preprocessed source if appropriate.
[12136s] Please include the complete backtrace with any bug report.
[12136s] See  for instructions.
[12136s] lto-wrapper: fatal error:
/home/abuild/rpmbuild/BUILD/gcc-10.0.0+r278058/obj-x86_64-suse-linux/./prev-gcc/xg++
returned 1 exit status
[12136s] compilation terminated.
[12136s] /usr/x86_64-suse-linux/bin/ld: error: lto-wrapper failed
[12136s] collect2: error: ld returned 1 exit status

[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.4.0
   Keywords||wrong-code
   Last reconfirmed||2019-11-12
 CC||glisse at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|incorrect code with |[8/9/10 Regression]
   |optimization|incorrect code with
   ||optimization
  Known to fail||10.0, 8.3.0, 9.2.0

--- Comment #3 from Jonathan Wakely  ---
Started with r248447:

 Move "(A & C) == D is false when D & ~C != 0" to match.pd

 2017-05-25  Marc Glisse

 * fold-const.c (fold_binary_loc) [(A & C) == D]: Remove
transformation.
 * match.pd (X == C): Rewrite it here.
 (with_possible_nonzero_bits, with_possible_nonzero_bits2,
 with_certain_nonzero_bits2): New predicates.
 * tree-ssanames.c (get_nonzero_bits): Handle INTEGER_CST.

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[aleksei.voity...@bell-sw.com]

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

Aleksei Voitylov  changed:

   What|Removed |Added

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

--- Comment #4 from Aleksei Voitylov  ---
(In reply to Wilco from comment #1)
> (In reply to Aleksei Voitylov from comment #0)
> > Created attachment 47212 [details]
> > reduced testcase from the openjdk sources
> > 
> > While compiling openjdk sources I bumped into a bug: when -ftree-pre is
> > enabled the optimizer hoists out reload of a variable which subsequently
> > leads to the infinite loop situation.
> > 
> > Below is the relevant piece of code and "new_value" is the variable that
> > gets hoisted out.
> > 
> > template
> > inline T Atomic::CmpxchgByteUsingInt::operator()(T exchange_value,
> > T volatile* dest,
> > T compare_value,
> > atomic_memory_order order) const {
> > printf ("Atomic::CmpxchgByteUsingInt::operator: 1: %d, 2: %d\n",
> > exchange_value, compare_value);
> > uint8_t canon_exchange_value = exchange_value;
> > uint8_t canon_compare_value = compare_value;
> > volatile uint32_t* aligned_dest
> > = reinterpret_cast(align_down(dest,
> > sizeof(uint32_t)));
> > size_t offset = (uintptr_t)dest  - (uintptr_t)aligned_dest;
> > uint32_t cur = *aligned_dest;
> > uint8_t* cur_as_bytes = reinterpret_cast(&cur);
> > cur_as_bytes[offset] = canon_compare_value;
> > do {
> > uint32_t new_value = cur;
> > reinterpret_cast(&new_value)[offset] =
> > canon_exchange_value;
> > printf ("Atomic::CmpxchgByteUsingInt::operator2: 1: %d, 2: %d\n",
> > new_value, cur);
> > uint32_t res = cmpxchg(new_value, aligned_dest, cur, order);
> > if (res == cur) break;
> > cur = res;
> > } while (cur_as_bytes[offset] == canon_compare_value);
> > return PrimitiveConversions::cast(cur_as_bytes[offset]);
> > }
> > 
> > $ g++ -O1 -ftree-pre t.cpp
> > $ ./a.out
> > Atomic::CmpxchgByteUsingInt::operator: 1: 0, 2: 1
> > Atomic::CmpxchgByteUsingInt::operator2: 1: 0, 2: 0
> > 
> > $ g++ -O1 t.cpp
> > $ ./a.out
> > Atomic::CmpxchgByteUsingInt::operator: 1: 0, 2: 1
> > Atomic::CmpxchgByteUsingInt::operator2: 1: 0, 2: 256
> > 
> > Below is the assembler of the loop for the correct version:
> > 
> > .L7:
> > ldr r4, [sp]
> > str r4, [sp, #4]
> > strbr7, [r5, #-4]
> > mov r2, r4
> > ldr r1, [sp, #4]
> > mov r0, r6
> > bl  printf
> > cbz r4, .L6
> > movsr3, #0
> > str r3, [sp]
> > ldrbr3, [r8]@ zero_extendqisi2
> > cmp r3, #1
> > beq .L7
> > 
> > and for the incorrect one:
> > 
> > .L7:
> > str r4, [sp, #4]
> > strbr8, [r6]
> > mov r2, r4
> > ldr r1, [sp, #4]
> > mov r0, r5
> > bl  printf
> > cbz r4, .L6
> > movsr4, #0
> > str r4, [sp]
> > ldrbr3, [r7]@ zero_extendqisi2
> > cmp r3, #1
> > beq .L7
> 
> There are serious aliasing bugs in the source - GCC is quite correct in
> assuming that cur and cur_as_bytes[offset] never alias (obviously) and even
> optimize away the cmpxchg (no idea why, that appears wrong).
Isn't

   uint32_t cur = *aligned_dest;
   uint8_t* cur_as_bytes = reinterpret_cast(&cur);

the very definition of the pointer aliasing? Regardless, if the function being
called is doing atomic operations or not, the variable in question should not
be hoisted? This is the essence of this bug.

Yes, openjdk code is doing nasty things furtheron (and the code predates
builtin gcc operations and is compiled by other compilers as well which may not
be aware of builtins), but the bug as it stands does not depend on that logic.


> Even if you fix the aliasing bugs, it won't emulate a byte-oriented cmpxchg
> correctly, there are bugs in the logic too.
> 
> So I suggest to go back to the drawing board - you can't hack your own
> atomic operations and just hope for the best. GCC supports a standard set of
> atomic operations for a good reason!

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[aleksei.voity...@bell-sw.com]

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

--- Comment #5 from Aleksei Voitylov  ---
(In reply to Richard Biener from comment #3)
> Indeed -fno-strict-aliasing might be a workaround (apart from the atomicity
> issue).  Also using a character type for the access (uint8_t is _not_ a
> character type) would make the alias issue go away.
Actually, it is not. However, -fno-tree-pre can be used as such but the point
is why a workaround is needed here in the first place.

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Earnshaw  ---
(In reply to Aleksei Voitylov from comment #4)
> Isn't
> 
>uint32_t cur = *aligned_dest;
>uint8_t* cur_as_bytes = reinterpret_cast(&cur);
> 
> the very definition of the pointer aliasing? 

No.  the standard says (paraphrasing, read the standard for the exact words)
that pointers to different types cannot point to the same object, unless one of
the pointers is a pointer to char.

As previously explained, uint8_t is not a char.  So the compiler is allowed to
assume that, because cur is not modified inside the loop it can be lifted out
entirely and treated as unchanging.

[Bug tree-optimization/92461] [10 Regression] ICE: verify_ssa failed (error: excess use operand for statement)

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 12 12:08:07 2019
New Revision: 278093

URL: https://gcc.gnu.org/viewcvs?rev=278093&root=gcc&view=rev
Log:
2019-11-12  Richard Biener  

PR tree-optimization/92461
* tree-vect-loop.c (vect_create_epilog_for_reduction): Update
stmt after propagation.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr92461.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/92460] [10 Regression] ICE: verify_ssa failed (error: definition in block 13 does not dominate use in block 22)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 12 12:12:18 2019
New Revision: 278094

URL: https://gcc.gnu.org/viewcvs?rev=278094&root=gcc&view=rev
Log:
2019-11-12  Richard Biener  

PR tree-optimization/92460
* tree-vect-stmts.c (vectorizable_simd_clone_call): Unshare
expression before gimplifying.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug target/92469] [9/10 Regression] ICE: output_operand: invalid use of register 'frame'

[anbu1024.me at gmail dot com]

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

--- Comment #2 from John X  ---
Yes, you are right. If we change "19" to "20", it still ICEs for older versions
of GCC.


$ cat test2.c 

void foo ( void ) 
{ 
register int x asm ( "20" ) ; 

int y = x;
}


$ gcc-snapshot8 --version
gcc (GCC) 8.3.1 20191108
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-snapshot8 test2.c 
during RTL pass: final
test2.c: In function ‘foo’:
test2.c:7:1: internal compiler error: output_operand: invalid use of register
'frame'
 }
 ^
0x7de0b3 output_operand_lossage(char const*, ...)
../../gcc-8-20191108/gcc/final.c:3628
0xd5c00c ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-8-20191108/gcc/config/i386/i386.c:18608
0x7de3e1 output_operand(rtx_def*, int)
../../gcc-8-20191108/gcc/final.c:4070
0x7dee79 output_asm_insn(char const*, rtx_def**)
../../gcc-8-20191108/gcc/final.c:3982
0x7e044c final_scan_insn_1
../../gcc-8-20191108/gcc/final.c:3178
0x7e076b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-8-20191108/gcc/final.c:3224
0x7e0a2c final_1
../../gcc-8-20191108/gcc/final.c:2091
0x7e1444 rest_of_handle_final
../../gcc-8-20191108/gcc/final.c:4677
0x7e1444 execute
../../gcc-8-20191108/gcc/final.c:4755
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ gcc-snapshot7 --version
gcc (GCC) 7.4.1 20191107
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-snapshot7 test2.c 
test2.c: In function ‘foo’:
test2.c:7:1: internal compiler error: in print_reg, at config/i386/i386.c:18041
 }
 ^
0xca56e3 print_reg(rtx_def*, int, _IO_FILE*)
../../gcc-7-20191107/gcc/config/i386/i386.c:18038
0xcc7ddc ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-7-20191107/gcc/config/i386/i386.c:18778
0x7a5701 output_operand(rtx_def*, int)
../../gcc-7-20191107/gcc/final.c:3894
0x7a616b output_asm_insn(char const*, rtx_def**)
../../gcc-7-20191107/gcc/final.c:3810
0x7a6ab9 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-7-20191107/gcc/final.c:3061
0x7a7c7c final(rtx_insn*, _IO_FILE*, int)
../../gcc-7-20191107/gcc/final.c:2051
0x7a85d9 rest_of_handle_final
../../gcc-7-20191107/gcc/final.c:4492
0x7a85d9 execute
../../gcc-7-20191107/gcc/final.c:4569
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #7 from Wilco  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Wilco from comment #1)
> > Even if you fix the aliasing bugs, it won't emulate a byte-oriented cmpxchg
> > correctly, there are bugs in the logic too.
> 
> More than that, it will never be atomic.  You can't do byte wise cmpxchg for
> an word size and think it will be atomic.

And since both Arm and AArch64 have byte-wise __atomic_compare_exchange_n, I
can't see a reason to even try when the compiler already does it correctly and
efficiently.

So my advice is to remove this function altogether and all related code from
openjdk - it's completely incorrect and counterproductive.(In reply to Aleksei
Voitylov from comment #4)
> (In reply to Wilco from comment #1)
> > (In reply to Aleksei Voitylov from comment #0)
> > > Created attachment 47212 [details]
> > > reduced testcase from the openjdk sources
> > > 
> > > While compiling openjdk sources I bumped into a bug: when -ftree-pre is
> > > enabled the optimizer hoists out reload of a variable which subsequently
> > > leads to the infinite loop situation.
> > > 
> > > Below is the relevant piece of code and "new_value" is the variable that
> > > gets hoisted out.
> > > 
> > > template
> > > inline T Atomic::CmpxchgByteUsingInt::operator()(T exchange_value,
> > > T volatile* dest,
> > > T compare_value,
> > > atomic_memory_order order) const {
> > > printf ("Atomic::CmpxchgByteUsingInt::operator: 1: %d, 2: %d\n",
> > > exchange_value, compare_value);
> > > uint8_t canon_exchange_value = exchange_value;
> > > uint8_t canon_compare_value = compare_value;
> > > volatile uint32_t* aligned_dest
> > > = reinterpret_cast(align_down(dest,
> > > sizeof(uint32_t)));
> > > size_t offset = (uintptr_t)dest  - (uintptr_t)aligned_dest;
> > > uint32_t cur = *aligned_dest;
> > > uint8_t* cur_as_bytes = reinterpret_cast(&cur);
> > > cur_as_bytes[offset] = canon_compare_value;
> > > do {
> > > uint32_t new_value = cur;
> > > reinterpret_cast(&new_value)[offset] =
> > > canon_exchange_value;
> > > printf ("Atomic::CmpxchgByteUsingInt::operator2: 1: %d, 2: %d\n",
> > > new_value, cur);
> > > uint32_t res = cmpxchg(new_value, aligned_dest, cur, order);
> > > if (res == cur) break;
> > > cur = res;
> > > } while (cur_as_bytes[offset] == canon_compare_value);
> > > return PrimitiveConversions::cast(cur_as_bytes[offset]);
> > > }
> > > 
> > > $ g++ -O1 -ftree-pre t.cpp
> > > $ ./a.out
> > > Atomic::CmpxchgByteUsingInt::operator: 1: 0, 2: 1
> > > Atomic::CmpxchgByteUsingInt::operator2: 1: 0, 2: 0
> > > 
> > > $ g++ -O1 t.cpp
> > > $ ./a.out
> > > Atomic::CmpxchgByteUsingInt::operator: 1: 0, 2: 1
> > > Atomic::CmpxchgByteUsingInt::operator2: 1: 0, 2: 256
> > > 
> > > Below is the assembler of the loop for the correct version:
> > > 
> > > .L7:
> > > ldr r4, [sp]
> > > str r4, [sp, #4]
> > > strbr7, [r5, #-4]
> > > mov r2, r4
> > > ldr r1, [sp, #4]
> > > mov r0, r6
> > > bl  printf
> > > cbz r4, .L6
> > > movsr3, #0
> > > str r3, [sp]
> > > ldrbr3, [r8]@ zero_extendqisi2
> > > cmp r3, #1
> > > beq .L7
> > > 
> > > and for the incorrect one:
> > > 
> > > .L7:
> > > str r4, [sp, #4]
> > > strbr8, [r6]
> > > mov r2, r4
> > > ldr r1, [sp, #4]
> > > mov r0, r5
> > > bl  printf
> > > cbz r4, .L6
> > > movsr4, #0
> > > str r4, [sp]
> > > ldrbr3, [r7]@ zero_extendqisi2
> > > cmp r3, #1
> > > beq .L7
> > 
> > There are serious aliasing bugs in the source - GCC is quite correct in
> > assuming that cur and cur_as_bytes[offset] never alias (obviously) and even
> > optimize away the cmpxchg (no idea why, that appears wrong).
> Isn't
> 
>uint32_t cur = *aligned_dest;
>uint8_t* cur_as_bytes = reinterpret_cast(&cur);
> 
> the very definition of the pointer aliasing? Regardless, if the function
> being called is doing atomic operations or not, the variable in question
> should not be hoisted? This is the essence of this bug.

The example as is is completely incorrect - it doesn't even return and ends up
executing random code.

> Yes, openjdk code is doing nasty things furtheron (and the code predates
> builtin gcc operations and is compiled by other compilers as well which may
> not be aware of builtins), but the bug as it stands does not depend on that
> logic.

Arm and AArch64 compilers support byte-wise cmpxchg, so my advi

[Bug target/92469] [9/10 Regression] ICE: output_operand: invalid use of register 'frame'

[anbu1024.me at gmail dot com]

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

--- Comment #3 from John X  ---
Yes, you are right. If we change "19" to "20", it still ICEs for older versions
of GCC.


$ cat test2.c 

void foo ( void ) 
{ 
register int x asm ( "20" ) ; 

int y = x;
}


$ gcc-snapshot8 --version
gcc (GCC) 8.3.1 20191108
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-snapshot8 test2.c 
during RTL pass: final
test2.c: In function ‘foo’:
test2.c:7:1: internal compiler error: output_operand: invalid use of register
'frame'
 }
 ^
0x7de0b3 output_operand_lossage(char const*, ...)
../../gcc-8-20191108/gcc/final.c:3628
0xd5c00c ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-8-20191108/gcc/config/i386/i386.c:18608
0x7de3e1 output_operand(rtx_def*, int)
../../gcc-8-20191108/gcc/final.c:4070
0x7dee79 output_asm_insn(char const*, rtx_def**)
../../gcc-8-20191108/gcc/final.c:3982
0x7e044c final_scan_insn_1
../../gcc-8-20191108/gcc/final.c:3178
0x7e076b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-8-20191108/gcc/final.c:3224
0x7e0a2c final_1
../../gcc-8-20191108/gcc/final.c:2091
0x7e1444 rest_of_handle_final
../../gcc-8-20191108/gcc/final.c:4677
0x7e1444 execute
../../gcc-8-20191108/gcc/final.c:4755
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ gcc-snapshot7 --version
gcc (GCC) 7.4.1 20191107
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-snapshot7 test2.c 
test2.c: In function ‘foo’:
test2.c:7:1: internal compiler error: in print_reg, at config/i386/i386.c:18041
 }
 ^
0xca56e3 print_reg(rtx_def*, int, _IO_FILE*)
../../gcc-7-20191107/gcc/config/i386/i386.c:18038
0xcc7ddc ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-7-20191107/gcc/config/i386/i386.c:18778
0x7a5701 output_operand(rtx_def*, int)
../../gcc-7-20191107/gcc/final.c:3894
0x7a616b output_asm_insn(char const*, rtx_def**)
../../gcc-7-20191107/gcc/final.c:3810
0x7a6ab9 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-7-20191107/gcc/final.c:3061
0x7a7c7c final(rtx_insn*, _IO_FILE*, int)
../../gcc-7-20191107/gcc/final.c:2051
0x7a85d9 rest_of_handle_final
../../gcc-7-20191107/gcc/final.c:4492
0x7a85d9 execute
../../gcc-7-20191107/gcc/final.c:4569
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/92469] ICE: output_operand: invalid use of register 'frame' in 7/8/9/10

[anbu1024.me at gmail dot com]

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

--- Comment #4 from John X  ---
Sorry, I submitted the same comment twice due to the bad network environment. I
don't know how to delete the duplicate one. Any one could help me?

[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Can't reproduce starting with r263875, so either it is fixed or latent in 9/10.

[Bug tree-optimization/92460] [10 Regression] ICE: verify_ssa failed (error: definition in block 13 does not dominate use in block 22)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92461] [10 Regression] ICE: verify_ssa failed (error: excess use operand for statement)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
You're right, sorry for not checking 9 and 10 properly. I also see it working
again after r263875.

[Bug testsuite/92466] new test case gfortran.dg/ISO_Fortran_binding_15.f90 in r278025 fails

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu,
   ||i?86-*-*, sparc-*-*,
   ||aarch64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-12
 CC||ro at gcc dot gnu.org
   Host|powerpc64*-linux-gnu|
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Build|powerpc64*-linux-gnu|

--- Comment #1 from Rainer Orth  ---
Happens on several more targets.  E.g. on Solaris/SPARC it SEGVs:

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00011134 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c:29
29if (*(int *)dat.base_addr != 42)
(gdb) where
#0  0x00011134 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c:29
(gdb) p dat.base_addr
$1 = (void *) 0x0

[Bug ipa/92476] New: [10 regression] SEGV in cgraph_edge_brings_value_p

[ro at gcc dot gnu.org]

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

Bug ID: 92476
   Summary: [10 regression] SEGV in cgraph_edge_brings_value_p
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, i686-pc-linux-gnu,
i586-unknown-freebsd11

Between 20191110 (r278013) and 2019 (r278058), three tests regressed on
32-bit x86:
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++2a (test for excess errors)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/pr61654.C  -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/pr63814.C  -std=gnu++14 compilation failed to produce
executable
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/pr63814.C  -std=gnu++17 compilation failed to produce
executable
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/pr63814.C  -std=gnu++2a compilation failed to produce
executable
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/pr63814.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/pr63814.C  -std=gnu++98 compilation failed to produce
executable
+FAIL: g++.dg/other/pr87916.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++2a (test for excess errors)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/other/pr87916.C  -std=gnu++98 (test for excess errors)
Excess errors:
during IPA pass: cp
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ipa/pr61654.C:40:1: internal
compiler error: Segmentation Fault
0x92f954c crash_signal
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:329
0x9be4613 same_node_or_its_all_contexts_clone_p
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:3530
0x9be4613 cgraph_edge_brings_value_p
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:3545
0x9be032d get_info_about_necessary_edges
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:3654
0x9be032d decide_about_value
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:4801
0x9be29c4 decide_whether_version_node
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:4888
0x9be29c4 ipcp_decision_stage
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:5051
0x9be29c4 ipcp_driver
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:5228
0x9be29c4 execute
/vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:5319

Can be reproduced with

$ cc1plus -fpreprocessed pr61654.ii -quiet -O3 -o pr61654.s
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
cgraph_edge_brings_value_p(cgraph_edge*, ipcp_value_source*,
cgraph_node*, ipcp_value*) [clone .cold] ()
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:3545
3545  || !same_node_or_its_all_contexts_clone_p (real_dest, dest)
(gdb) where
#0  cgraph_edge_brings_value_p(cgraph_edge*, ipcp_value_source*,
cgraph_node*, ipcp_value*) [clone .cold] ()
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:3545
#1  0x09be032e in get_info_about_necessary_edges (
caller_count=, count_sum=, 
freq_sum=, dest=0xfa4bb410, val=0xa4cd104)
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:3652
#2  decide_about_value (node=node@entry=0xfa4bb410, 
index=index@entry=2, offset=, val=, 
known_csts=..., known_contexts=...)
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:4801
#3  0x09be29c5 in decide_whether_version_node (node=0xfa4bb410)
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:4888
#4  ipcp_decision_stage (topo=)
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:5051
#5  ipcp_driver () at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:5228
#6  (anonymous namespace)::pass_ipa_cp::execute (this=)
at /vol/gcc/src/hg/trunk/local/gcc/ipa-cp.c:5319
#7  0x0921ca72 in execute_one_pass (pass=0xa4526f0)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2494

[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov  ---
The full preprocessed source is provided and it clearly says

typedef unsigned char uint8_t;

in line 10, so it is in fact a character type.

It's suspicious that cmpxchg_using_helper does not return a value (incorrectly
reduced testcase?) and there's still an aliasing violation when
atomic_cmpxchg_func tries to cast 'dest' from uint8_t* to int*. I think the
report was closed prematurely.

Aleksei - always provide output of 'gcc -v' when reporting such bugs, otherwise
people may be unable to reproduce it when there's really a problem (no way to
tell how your compiler was configured or even its exact version).

[Bug ipa/92476] [10 regression] SEGV in cgraph_edge_brings_value_p

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-12
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed on x86_64-linux-gnu with:

$ ./gcc/xgcc -Bgcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61654.C -c -m32 -O2
during IPA pass: cp
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61654.C:40:1: internal
compiler error: Segmentation fault
   40 | }
  | ^
0x14bccc1 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x7ff6b023314f ???
   
/usr/src/debug/glibc-2.30-1.2.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x232420a ipcp_store_vr_results
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5155
0x23245d0 ipcp_driver
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5231
0x23247a0 execute
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5318
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Again started with r278016.

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[aleksei.voity...@bell-sw.com]

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

--- Comment #9 from Aleksei Voitylov  ---
(In reply to Alexander Monakov from comment #8)
> The full preprocessed source is provided and it clearly says
> 
> typedef unsigned char uint8_t;
> 
> in line 10, so it is in fact a character type.
> 
> It's suspicious that cmpxchg_using_helper does not return a value
> (incorrectly reduced testcase?) and there's still an aliasing violation when
> atomic_cmpxchg_func tries to cast 'dest' from uint8_t* to int*. I think the
> report was closed prematurely.
It is suspicious regarding atomic functionality - from that point the testcase
is over-reduced, you are right. It doesn't invalidate the initial question
about the  hoisting, though.

> Aleksei - always provide output of 'gcc -v' when reporting such bugs,
> otherwise people may be unable to reproduce it when there's really a problem
> (no way to tell how your compiler was configured or even its exact version).

$ g++ -v
Using built-in specs.
COLLECT_GCC=/home/build/toolchain/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/home/build/toolchain/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/7.3.1/lto-wrapper
Target: arm-linux-gnueabihf
Configured with:



Thread model: posix
gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)

[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.4

--- Comment #6 from Richard Biener  ---
I'm going to have a closer look but appreciate a testcase w/o libstdc++.

[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Reduced C testcase:
__attribute__((noipa)) void
quux (unsigned long x)
{
  static int cnt;
  unsigned long v = cnt++ ? 6 : 0;
  if (x != v)
__builtin_abort ();
}

__attribute__((noipa)) void
foo (const char *x)
{
  static int cnt;
  if (__builtin_strcmp (x, cnt++ ? "baz" : "qux") != 0)
__builtin_abort ();
}

__attribute__((noipa)) void
bar (char *b)
{
  long c, e;
  for (c = 7; c >= 0; --c)
if (b[c] != ' ')
  {
b[c + 1] = '\0';
break;
  }
  e = c + 1;
  unsigned long g = e;
  quux (g);
  foo (g ? "baz" : "qux");
}

int
main ()
{
  char buf[9];
  __builtin_memcpy (buf, "", 9);
  bar (buf);
  __builtin_memcpy (buf, "abcdef  ", 9);
  bar (buf);
  return 0;
}

[Bug target/92473] test pr92324-2.c fails on arm and aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-12
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I will have a look.

[Bug c/92472] enhancement: 5 * constify some parameters

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Can you post the patch (and separate out the libstdc++ parts)?

[Bug c++/92477] New: [[nodiscard]] method in a decltype expression causes "warning: ignoring return value of"

[src at andyf dot de]

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

Bug ID: 92477
   Summary: [[nodiscard]] method in a decltype expression causes
"warning: ignoring return value of"
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: src at andyf dot de
  Target Milestone: ---

Hello,

consider this code:

class Test
{
public:
[[nodiscard]] int Get() const { return 42; }
};

template
auto UsedForSFINAE(const T& t) -> decltype(t.Get(), void())
{
}

template
auto UsedAsReturnValue(const T& t) -> decltype(t.Get())
{
return t.Get();
}

int main()
{
Test t{};

UsedForSFINAE(t);
UsedAsReturnValue(t);
}


It tries to SFINAE out the UsedForSFINAE based on whether the type passed has a
method Get. The decltype expression in
UsedForSFINAE causes a warning in GCC with -Wall passed:

warning: ignoring return value of 'int Test::Get() const', declared with
attribute nodiscard [-Wunused-result]

8 | auto UsedForSFINAE(const T& t) -> decltype(t.Get(), void())

:4:23: note: declared here

4 | [[nodiscard]] int Get() const { return 42; }

  |   ^~~

Clang on the other hand is fine with it (see https://godbolt.org/z/9U4ceB). The
warning goes away when t.Get() is casted to void. There is no warning, if the
decltype's resulting type is used as the return type (as for
UsedAsReturnValue).

I talked to Richard Smith about this last week at WG21 Belfast and he told me
that Clang is correct. Unfortunately, I don't recall his exact rational. I
think it was that in [dcl.type.decltype] is says "The operand of the decltype
specifier is an unevaluated operand (7.2)."


Bug 57857 looks a bit similar.

Cheers,
   Andreas

[Bug c/92472] enhancement: 5 * constify some parameters

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Sadly no. 

I am happy for anyone else to pick up my suggested patches and 
post them.

There were about 35 style messages of type "constParameter" produced 
for gcc trunk. I'll have a look at which other ones are suitable for
implementation.

[Bug rtl-optimization/92430] [9/10 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp

[iii at gcc dot gnu.org]

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

--- Comment #5 from iii at gcc dot gnu.org ---
Author: iii
Date: Tue Nov 12 14:24:35 2019
New Revision: 278095

URL: https://gcc.gnu.org/viewcvs?rev=278095&root=gcc&view=rev
Log:
Free dominance info at the beginning of pass_jump_after_combine

try_forward_edges does not update dominance info, and merge_blocks
relies on it being up-to-date.  In PR92430 stale dominance info makes
merge_blocks produce a loop in the dominator tree, which in turn makes
delete_basic_block loop forever.

Fix by freeing dominance info at the beginning of cleanup_cfg.

gcc/ChangeLog:

2019-11-12  Ilya Leoshkevich  

PR rtl-optimization/92430
* cfgcleanup.c (pass_jump_after_combine::execute): Free
dominance info at the beginning.

gcc/testsuite/ChangeLog:

2019-11-12  Ilya Leoshkevich  

PR rtl-optimization/92430
* gcc.dg/pr92430.c: New test (from Arseny Solokha).

Added:
trunk/gcc/testsuite/gcc.dg/pr92430.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/testsuite/ChangeLog

[Bug target/92473] test pr92324-2.c fails on arm and aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 47222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47222&action=edit
patch

Testing the following (on x86_64), inspected aarch64 code to be correct.

[Bug c/92478] New: [8 Regression] ICE: Segmentation fault

[anbu1024.me at gmail dot com]

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

Bug ID: 92478
   Summary: [8 Regression] ICE: Segmentation fault
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

void bar ( char * a , unsigned int b ) 
{
static char const array[] = "STRING" ; 
__builtin_strcpy (a , &array[b == 0] );  
} 


$ gcc-snapshot7 --version
gcc (GCC) 7.4.1 20191107
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-snapshot7 test.c 
/usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status


$ gcc-snapshot8 --version
gcc (GCC) 8.3.1 20191108
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-snapshot8 test.c 
during RTL pass: expand
test.c: In function ‘bar’:
test.c:6:5: internal compiler error: Segmentation fault
 __builtin_strcpy (a , &array[b == 0] );
 ^~
0xa6514f crash_signal
../../gcc-8-20191108/gcc/toplev.c:325
0xcf9403 selt
../../gcc-8-20191108/gcc/wide-int.cc:404
0xcf9403 wi::lts_p_large(long const*, unsigned int, unsigned int, long const*,
unsigned int)
../../gcc-8-20191108/gcc/wide-int.cc:480
0x6b4773 bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc-8-20191108/gcc/wide-int.h:1873
0x6b4773 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
 >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc-8-20191108/gcc/wide-int.h:3170
0x6b4773 tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc-8-20191108/gcc/tree.h:5740
0x6b4773 check_access
../../gcc-8-20191108/gcc/builtins.c:3125
0x6bf482 expand_builtin_strcpy
../../gcc-8-20191108/gcc/builtins.c:3780
0x6bf482 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc-8-20191108/gcc/builtins.c:6978
0x7c9591 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-8-20191108/gcc/expr.c:11062
0x6d935a expand_expr
../../gcc-8-20191108/gcc/expr.h:280
0x6d935a expand_call_stmt
../../gcc-8-20191108/gcc/cfgexpand.c:2704
0x6d935a expand_gimple_stmt_1
../../gcc-8-20191108/gcc/cfgexpand.c:3638
0x6d935a expand_gimple_stmt
../../gcc-8-20191108/gcc/cfgexpand.c:3804
0x6daf1f expand_gimple_basic_block
../../gcc-8-20191108/gcc/cfgexpand.c:5837
0x6e0446 execute
../../gcc-8-20191108/gcc/cfgexpand.c:6443
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/92470] CFI_address wrongly assumes that lower bounds are at zero – invalid for pointers + allocatables

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-12
 Ever confirmed|0   |1

--- Comment #2 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00928.html

 * * *

While fixing it, I run into the question which lower_bound is to be expected
for CFI_section and for CFI_establish, cf.
https://mailman.j3-fortran.org/pipermail/j3/2019-November/thread.html#11740 (PR
89843 also talks about CFI_section.)

The current implementation of CFI_section seems to be fine (according to Bob
and Bill), however, I still think it is not well specified.
Regarding CFI_establish, there is still the question what should be the value
of lower_bound for CFI_attribute_other. (gfortran uses '0' for pointer as
demanded by the standard and '1' otherwise (unspecified).)

[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #15 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #14)
> Ah no, that is all understood.  What I am commenting on is that you
> have an odd-even register pair (9 and 10), while every GCC I know of
> and/or tested uses an even-odd pair (10 and 11 usually).  Curious.

IIRC, register pairs in the rs6000 backend can be either even/odd or odd/even
registers.  The only exception to that is the _Decimal128 type is forced into
even/odd register pairs due to the hardware instructions used to operate on
them require even/odd register pairs.

[Bug sanitizer/92474] Sanitizer breaks tail-recursion optimization

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Note, starting with r273603, the trunk doesn't tail call optimize this either
even without -fsanitize=, unless -fno-tree-sra.

[Bug c++/89070] Attribute [[nodiscard]] should be ignored in unevaluated contexts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||src at andyf dot de

--- Comment #2 from Jonathan Wakely  ---
*** Bug 92477 has been marked as a duplicate of this bug. ***

[Bug c++/92477] [[nodiscard]] method in a decltype expression causes "warning: ignoring return value of"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug sanitizer/92474] Sanitizer breaks tail-recursion optimization

[Hi-Angel at yandex dot ru]

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

--- Comment #2 from Konstantin Kharlamov  ---
(In reply to Jakub Jelinek from comment #1)
> Note, starting with r273603, the trunk doesn't tail call optimize this
> either even without -fsanitize=, unless -fno-tree-sra.

Is there a report for this?

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[kloczko.tomasz at gmail dot com]

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

Tomasz Kłoczko  changed:

   What|Removed |Added

 CC||kloczko.tomasz at gmail dot com

--- Comment #34 from Tomasz Kłoczko  ---
Any progress on that issue?
Just hit that issue trying to build NetworkManager

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/278

[Bug c/92478] [8 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-12
 CC||edlinger at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r247622, got fixed with r262742.

[Bug c++/89070] Attribute [[nodiscard]] should be ignored in unevaluated contexts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug sanitizer/92474] Sanitizer breaks tail-recursion optimization

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
No, feel free to file it.

[Bug c/92479] New: missing warnings for unreachable codes with -Wunreachable-code

[tangyixuan at mail dot dlut.edu.cn]

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

Bug ID: 92479
   Summary: missing warnings for unreachable codes with
-Wunreachable-code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, there is no warning for the unreachable code with [-Wunreachable-code] as
follow. Would it be better to warn developers if the 'break' branch is
unreachable?

$ cat s.c
int main()
{
  for(int i = 1;; i++){
if(0)
  break;
  }
}

$ gcc -c -Wunreachable-code s.c
no warnings.

$ gcc -v
Target: x86_64-pc-linux-gnu
gcc version 10.0.0 20191110 (experimental) (GCC)

$ clang -c -Wunreachable-code-break s.c
s.c:5:7: warning: 'break' will never be executed [-Wunreachable-code-break]
  break;
  ^
1 warning generated.

Best regards

[Bug c/92479] missing warnings for unreachable codes with -Wunreachable-code

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The code for Wunreachable-code was removed a long time ago (around 5-10 years
ago).

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #4 from Peter Bergner  ---
(In reply to Xiong Hu XS Luo from comment #2)
> Sorry that I mistook to change the case pr72804.c: this case has no
> relationship with the parameter -fno-inline-functions --param
> max-inline-insns-single-O2=200.  This test appears in category of "New tests
> that FAIL (6 tests):".

Correct, I don't think -fno-inline-functions --param
max-inline-insns-single-O2=200 should have ever been added to pr72804.c.  The
correct thing would be to remove those options from the test case.

However, I don't see how those options could be causing any change in generated
assembly because there are no inlining opportunities, so how could that
revision be causing the reported error?  Bill, are you sure on that revision?



> Peter added this case pr72804.c in r251153 of Aug 17, 2017 to generate
> better code for -mvsx-timode. But it restrict the condition to
> !BYTES_BIG_ENDIAN and !TARGET_P9_VECTOR:

I added this test to test for poor code generation on POWER7 (and POWER8). 
Looking at the POWER9 output, that code looks good to me.  Maybe we didn't
generate that back when I added the test case?  The POWER8 (BE) code does look
worse to me than what we expect.

Bill, can you reconfirm what revision broke pr72804.c?

[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
(In reply to Thomas Schwinge from comment #6)
> On powerpc64le-unknown-linux-gnu

I can reproduce it on a powerpc64le-unknown-linux-gnu w/o real offloading. It
fails here for subroutine test_dummy_opt_val_callee_2 for
  if (.not.present(c_aptr) .or. .not.present(c_bptr)) stop 150
as both are marked as not present – that's completely unrelated to OpenMP (and
happens with and without -fopenmp).


The callee and caller are:

test_dummy_opt_val_callee_2 (real(kind=8) aa, real(kind=8) bb,
void * c_aptr, void * c_bptr, real(kind=8) * * aptr, real(kind=8) *
* bptr,
logical(kind=1) _aa, logical(kind=1) _bb, logical(kind=1) _c_aptr,
logical(kind=1) _c_bptr)
…
  if ((logical(kind=4)) !_c_aptr || (logical(kind=4)) !_c_bptr)
  _gfortran_stop_numeric (150, 0);

And the call is:
  test_dummy_opt_val_callee_2 (aa, bb, c_aptr, c_bptr, &aptr, &bptr, 1, 1, 1,
1);

At a glance, that looks fine – and a minimal test case also passes. My feeling
is that something with passing the arguments goes wrong – which is hidden in
the gimple and not visible in the tree dump.

[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #8)
In gdb [GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1], which is really not the
newest, I get:

(gdb) pt c_aptr
type = 

and stepping in, gives (all variables should be unitialized, except for those
with leading underscore, which should be 1 alias .TRUE.):

test_dummies_opt_value::test_dummy_opt_val_callee_2 (aa=0,
bb=1.3262473693532952e-315, c_aptr=, 
c_bptr=,
aptr=0x3648, bptr=0x1, _aa=.TRUE., _bb=.TRUE., _c_aptr=.FALSE.,
_c_bptr=96)

Reduced testcase is:

module test_dummies_opt_value
  use iso_c_binding
contains
  subroutine test_dummy_opt_val_call_2()
 real(c_double), target :: aa, bb
 type(c_ptr) :: c_aptr, c_bptr
 real(c_double), pointer :: aptr, bptr
 call test_dummy_opt_val_callee_2(aa, bb, c_aptr, c_bptr, aptr, bptr)
  end subroutine test_dummy_opt_val_call_2
  subroutine test_dummy_opt_val_callee_2(aa, bb, c_aptr, c_bptr, aptr, bptr)
 real(c_double), optional, value, target :: aa, bb
 type(c_ptr), optional, value :: c_aptr, c_bptr
 real(c_double), optional, pointer :: aptr, bptr
 if (.not.present(c_aptr) .or. .not.present(c_bptr)) stop 150
  end subroutine test_dummy_opt_val_callee_2
end module test_dummies_opt_value
program omp_device_addr
  use test_dummies_opt_value
  call test_dummy_opt_val_call_2()
end program omp_device_addr

[Bug c++/92480] New: Parameters in consteval functions should be constant expressions.

[h2+bugs at fsfe dot org]

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

Bug ID: 92480
   Summary: Parameters in consteval functions should be constant
expressions.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Great to see that immediate functions have already landed!

But compiling the following on godbolt with gcc-trunk fails:

consteval int foobar(int i)
{
static_assert(i > 1);
return i + 2;
}

int main()
{
return foobar(3);
}

with

:3:21: error: non-constant condition for static assertion

3 | static_assert(i > 1);

  |   ~~^~~

:3:21: error: 'i' is not a constant expression

But i should be a constant expression inside an immediate function, or not?

[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
The callee is:
 >

and the hidden argument (_c_aptr) is:

 
constant 1>

which both look fine.

[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  ---
Optimized dump is:

  void * c_bptr;
  void * c_aptr;
  real(kind=8) * bptr;
  real(kind=8) bb;
  real(kind=8) * aptr;
  real(kind=8) aa;
  real(kind=8) aa.1_1;
  real(kind=8) bb.2_2;
 :
  aa.1_1 = aa;
  bb.2_2 = bb;
  test_dummy_opt_val_callee_2 (aa.1_1, bb.2_2, c_aptr_4(D), c_bptr_5(D), &aptr,
&bptr, 1, 1, 1, 1);

And assembler:

.cfi_startproc
.LCF1:
0:  addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry
__test_dummies_opt_value_MOD_test_dummy_opt_val_call_2,.-__test_dummies_opt_value_MOD_test_dummy_opt_val_call_2
mflr 0   #,
std 0,16(1)  #,
std 31,-8(1) #,
stdu 1,-112(1)   #,,
.cfi_def_cfa_offset 112
.cfi_offset 65, 16
.cfi_offset 31, -8
mr 31,1  #,
.cfi_def_cfa_register 31
 # foo.f90:8:  call test_dummy_opt_val_callee_2(aa, bb, c_aptr, c_bptr,
aptr, bptr)
lfd 0,64(31) # aa, aa.1_1
lfd 12,80(31)# bb, bb.2_2
addi 8,31,88 # tmp119,,
addi 7,31,72 # tmp120,,
li 9,1   # tmp121,
std 9,40(1)  #, tmp121
li 9,1   # tmp122,
std 9,32(1)  #, tmp122
li 10,1  #,
li 9,1   #,
ld 6,56(31)  # c_bptr,
ld 5,48(31)  # c_aptr,
fmr 2,12 #, bb.2_2
fmr 1,0  #, aa.1_1
bl __test_dummies_opt_value_MOD_test_dummy_opt_val_callee_2

And on the callee side:

test_dummy_opt_val_callee_2 (real(kind=8) aa, real(kind=8) bb, void * c_aptr,
void * c_bptr, real(kind=8) * * aptr, real(kind=8) * * bptr, logical(kind=1)
_aa, logical(kind=1) _bb, logical(kind=1) _c_aptr, logical(kind=1) _c_bptr)
{
  logical(kind=1) _1;
  logical(kind=4) _2;
  logical(kind=1) _3;
  logical(kind=4) _4;
  logical(kind=4) _5;
   :
  _1 = ~_c_aptr_6(D);
  _2 = (logical(kind=4)) _1;
  _3 = ~_c_bptr_7(D);
  _4 = (logical(kind=4)) _3;
  _5 = _2 | _4;
  if (_5 != 0)
goto ; [INV]
  else
goto ; [INV]
   :
  _gfortran_stop_numeric (150, 0);

Which in assembler is:

.cfi_startproc
.LCF0:
0:  addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry
__test_dummies_opt_value_MOD_test_dummy_opt_val_callee_2,.-__test_dummies_opt_value_MOD_test_dummy_opt_val_callee_2
mflr 0   #,
std 0,16(1)  #,
std 31,-8(1) #,
stdu 1,-48(1)#,,
.cfi_def_cfa_offset 48
.cfi_offset 65, 16
.cfi_offset 31, -8
mr 31,1  #,
.cfi_def_cfa_register 31
stfd 1,80(31)# aa, aa
stfd 2,88(31)# bb, bb
std 5,96(31) # c_aptr, c_aptr
std 6,104(31)# c_bptr, c_bptr
std 7,112(31)# aptr, aptr
std 8,120(31)# bptr, bptr
stb 9,128(31)# _aa, tmp123
mr 9,10  # tmp125, tmp124
stb 9,136(31)# _bb, tmp125
 # foo.f90:16:  if (.not.present(c_aptr) .or. .not.present(c_bptr)) stop
150
lbz 9,144(31)# _c_aptr, tmp126
xori 9,9,0x1 #,, tmp127, tmp126
rlwinm 9,9,0,0xff# _1, tmp127
rlwinm 9,9,0,31,31   # tmp128, _1,,
rldicl 10,9,0,32 # _2, tmp128
lbz 9,152(31)# _c_bptr, tmp129
xori 9,9,0x1 #,, tmp130, tmp129
rlwinm 9,9,0,0xff# _3, tmp130
rlwinm 9,9,0,31,31   # tmp131, _3,,
rldicl 9,9,0,32  # _4, tmp131
or 9,10,9#, tmp132, _2, _4
rldicl 9,9,0,32  # _5, tmp132
cmpdi 0,9,0  #, tmp133, _5
beq 0,.L3#
 # foo.f90:16:  if (.not.present(c_aptr) .or. .not.present(c_bptr)) stop
150
li 4,0   #,
li 3,150 #,
bl _gfortran_stop_numeric#
nop

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[amonakov at gcc dot gnu.org]

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

--- Comment #10 from Alexander Monakov  ---
> atomic_cmpxchg_func tries to cast 'dest' from uint8_t* to int*

I made a typo here, I meant uint32_t rather than uint8_t, and there's no
aliasing violation here as signedness difference is explicitly OK.

It doesn't matter if the function in user code is named cmpxchg or dsjfhg,
whether gcc can emit a more efficient bytewise CAS is irrelevant when the user
complains that PRE is miscompiling their code.

uint8_t is obviously a character type in this particular testcase (as well as,
fwiw, on all Glibc targets)

OTOH that cmpxchg_using_helper does not return a value is a serious problem,
that is undefined behavior in C++. You'll need to submit a valid testcase
without that issue.

[Bug c/83688] Please check if buffers may overlap when copying strings using sprintf

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 12 17:18:37 2019
New Revision: 278098

URL: https://gcc.gnu.org/viewcvs?rev=278098&root=gcc&view=rev
Log:
PR middle-end/83688 - check if buffers may overlap when copying strings using
sprintf

gcc/ChangeLog:

PR middle-end/83688
* gimple-ssa-sprintf.c (format_result::alias_info): New struct.
(directive::argno): New member.
(format_result::aliases, format_result::alias_count): New data members.
(format_result::append_alias): New member function.
(fmtresult::dst_offset): New data member.
(pass_sprintf_length::call_info::dst_origin): New data member.
(pass_sprintf_length::call_info::dst_field, dst_offset): Same.
(char_type_p, array_elt_at_offset, field_at_offset): New functions.
(get_origin_and_offset): Same.
(format_string): Call it.
(format_directive): Call append_alias and set directive argument
number.
(maybe_warn_overlap): New function.
(pass_sprintf_length::compute_format_length): Call it.
(pass_sprintf_length::handle_gimple_call): Initialize new members.
* gcc/tree-ssa-strlen.c (): Also enable when -Wrestrict is on.

gcc/testsuite/ChangeLog:

PR tree-optimization/35503
* gcc.dg/tree-ssa/builtin-sprintf-warn-23.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-23.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/35503] Warning about restricted pointers?

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 12 17:18:37 2019
New Revision: 278098

URL: https://gcc.gnu.org/viewcvs?rev=278098&root=gcc&view=rev
Log:
PR middle-end/83688 - check if buffers may overlap when copying strings using
sprintf

gcc/ChangeLog:

PR middle-end/83688
* gimple-ssa-sprintf.c (format_result::alias_info): New struct.
(directive::argno): New member.
(format_result::aliases, format_result::alias_count): New data members.
(format_result::append_alias): New member function.
(fmtresult::dst_offset): New data member.
(pass_sprintf_length::call_info::dst_origin): New data member.
(pass_sprintf_length::call_info::dst_field, dst_offset): Same.
(char_type_p, array_elt_at_offset, field_at_offset): New functions.
(get_origin_and_offset): Same.
(format_string): Call it.
(format_directive): Call append_alias and set directive argument
number.
(maybe_warn_overlap): New function.
(pass_sprintf_length::compute_format_length): Call it.
(pass_sprintf_length::handle_gimple_call): Initialize new members.
* gcc/tree-ssa-strlen.c (): Also enable when -Wrestrict is on.

gcc/testsuite/ChangeLog:

PR tree-optimization/35503
* gcc.dg/tree-ssa/builtin-sprintf-warn-23.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-23.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 83688, which changed state.

Bug 83688 Summary: Please check if buffers may overlap when copying strings 
using sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83688

   What|Removed |Added

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

[Bug middle-end/83688] Please check if buffers may overlap when copying strings using sprintf

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|c   |middle-end
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #10 from Martin Sebor  ---
Done for GCC 10.

[Bug c++/92480] Parameters in consteval functions should be constant expressions.

[h2+bugs at fsfe dot org]

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

Hannes Hauswedell  changed:

   What|Removed |Added

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

--- Comment #1 from Hannes Hauswedell  ---
Ah, well, I am not actually sure that this is supposed to work :(

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[paul.richard.thomas at gmail dot com]

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

--- Comment #8 from paul.richard.thomas at gmail dot com  ---
Hi Jakub,

Thanks for spotting that. For whatever reason,

* trans-decl.c (gfc_get_symbol_decl): Assumed shape and assumed
rank dummies of bind C procs require deferred initialization.

in the patch for PR89843 has just disappeared. I'll have to do a bit
of detective work to find out how or why and come up with a fix.

Regards

Paul

On Tue, 12 Nov 2019 at 10:37, jakub at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
>
> --- Comment #7 from Jakub Jelinek  ---
> I don't see any conversion function to be called:
> fsub (struct array15_integer(kind=4) & restrict dat)
> {
>   {
> integer(kind=4) * __tmp_INTEGER_4_rank_0;
>
> {
>   signed char D.3928;
>   integer(kind=8) D.3929;
>   signed char D.3930;
>
>   D.3928 = dat->dtype.rank;
>   D.3929 = (integer(kind=8)) D.3928 + -1;
>   D.3930 = D.3928 != 0 ? dat->dim[D.3929].ubound != -1 ? D.3928 : -1 :
> D.3928;
>   if (D.3930 == 0)
> {
>   try
> {
>   __tmp_INTEGER_4_rank_0 = (integer(kind=4) *) dat->data;
>   if (__tmp_INTEGER_4_rank_0 != 0B)
> {
>   _gfortran_runtime_error_at (&"At line 15 of file
> /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90"[1]{lb:
> 1 sz: 1}, &"Attempting to allocate already allocated variable \'%s\'"[1]{lb: 1
> sz: 1}, &"__tmp_INTEGER_4_rank_0"[1]{lb: 1 sz: 1});
> }
>   else
> {
>   __tmp_INTEGER_4_rank_0 = (integer(kind=4) *) 
> __builtin_malloc
> (4);
>   if (__tmp_INTEGER_4_rank_0 == 0B)
> {
>   _gfortran_os_error_at (&"In file
> \'/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90\',
> around line 16"[1]{lb: 1 sz: 1}, &"Error allocating %lu bytes"[1]{lb: 1 sz: 
> 1},
> 4);
> }
> }
>   if (__tmp_INTEGER_4_rank_0 != 0B) goto L.4;
>   __tmp_INTEGER_4_rank_0 = (integer(kind=4) *) __builtin_malloc
> (4);
>   L.4:;
>   *__tmp_INTEGER_4_rank_0 = 42;
>   L.3:;
> }
>   finally
> {
>   dat->data = (void * restrict) __tmp_INTEGER_4_rank_0;
> }
>   goto L.2;
> }
> }
> L.2:;
> L.1:;
> return;
>   }
> }
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

[seurer at gcc dot gnu.org]

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

--- Comment #5 from seurer at gcc dot gnu.org ---
The assembler mismatches on power 7 and power 9 date way, way back at least
into early 2019.  The short span where the test case failed to work at all
threw me off.  Sorry about that!

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[hubicka at ucw dot cz]

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

--- Comment #35 from Jan Hubicka  ---
> Any progress on that issue?
> Just hit that issue trying to build NetworkManager
> 
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/278

I am working on a patch for symver attribute, hope to have it done this
week.

Honza

[Bug c/92479] missing warnings for unreachable codes with -Wunreachable-code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=46476,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82100

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> The code for Wunreachable-code was removed a long time ago (around 5-10
> years ago).

There are some other bugs open about reviving -Wunreachable-code. There's bug
46476 for -Wunreachable-code-return, which I thought this was a dup of at
first, but I guess since -Wunreachable-code-break has a different name that
this can stay separate. If we're adding bugs for each of clang's sub-options
for -Wunreachable-code, then I guess it might be worth creating a bug for
-Wunreachable-code-loop-increment, too. (There's also bug 82100 for code that's
unreachable due to conflicting conditions)

[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus  ---
Created attachment 47223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47223&action=edit
-fdump-rtl-expand for test case in comment 9, compiled on
powerpc64le-unknown-linux-gnu using -O0 (it doesn't fail with -O1)

[Bug testsuite/92464] [10 regression] r278033 breaks gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
What is the testcase testing?  Whether we can properly vectorize this
code, right?  And for p7 we now do it correctly, but thought it was
too expensive before?

[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #13 from Tobias Burnus  ---
19:03 < segher> so this is BE, right?
19:03 < segher> the caller does   li 9,1 ; std 9,32(1)
19:04 < segher> so it stores the bool as a 64-bit number
19:04 < segher> but the callee reads it like   lbz 9,144(31)
19:05 < segher> that's the right address, but the wrong end of that 8-byte
thing

[Bug c++/92481] New: g++ 9.2.0 SegFault

[simon.moll at emea dot nec.com]

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

Bug ID: 92481
   Summary: g++ 9.2.0 SegFault
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.moll at emea dot nec.com
  Target Milestone: ---

Created attachment 47224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47224&action=edit
Reproducer (delta reduced, derived from LLVM source code)

Test case crashes with a SegFault (ICE).

How to reproduce

g++ testcase-min.i


c++ --version
=
c++ (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


uname -a

Linux sbox 5.3.10-arch1-1 #1 SMP PREEMPT Sun, 10 Nov 2019 11:29:38 + x86_64
GNU/Linux


Archlinux package (pacman -Q gcc)
=
gcc 9.2.0-4

[Bug fortran/92482] New: Possibly wrong error diagnostic

[jrfsousa at gmail dot com]

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

Bug ID: 92482
   Summary: Possibly wrong error diagnostic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 47225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47225&action=edit
Code demonstrating problems.

What seems to me a spurious error is flagged by gfortran 10.0.0 20191106:

Error: Character argument ‘this’ at (1) must be length 1 because procedure
‘strg_print_0’ is BIND(C)

Gfortran 9.1.0 also issues a warning and the code generated raises a
segmentation fault:

Warning: ‘.this’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

I may be missing the something in the standard but I see no clause demanding 
this behavior and it is used on C.12.14 Mapping of MPI interfaces to Fortran.

Thank you very much.

Best regards,
José Rui

[Bug jit/92483] New: [10 Regression] many jit test failures due to ABRT, SEGV

[msebor at gcc dot gnu.org]

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

Bug ID: 92483
   Summary: [10 Regression] many jit test failures due to ABRT,
SEGV
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Many jit tests fail on today's top of trunk (r278096) that I didn't see fail
yesterday.

=== jit tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /ssd/test/src/gcc/92412/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /ssd/test/src/gcc/92412/gcc/testsuite/jit.dg/jit.exp ...
FAIL: test-accessing-bitfield.c.exe killed: 10017 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-accessing-struct.c.exe killed: 10049 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-accessing-union.c.exe killed: 10081 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-add-driver-options.c.exe killed: 10122 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-alignment.c.exe killed: 10156 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-alignment.cc.exe killed: 10188 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-arith-overflow.c.exe killed: 10220 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-array-as-pointer.c.exe killed: 10252 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-arrays.c.exe killed: 10284 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-autovectorize.c.exe killed: 10316 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-calling-external-function.c.exe killed: 11561 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-calling-function-ptr.c.exe killed: 11593 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-combination.c.exe killed: 11625 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-compile-to-assembler.c.exe killed: 11658 exp7 0 0 CHILDKILLED
SIGABRT SIGABRT
FAIL: test-compile-to-dynamic-library.c.exe killed: 11698 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-compile-to-executable.c.exe killed: 11743 exp7 0 0 CHILDKILLED
SIGABRT SIGABRT
FAIL: test-compile-to-object.c.exe killed: 11778 exp7 0 0 CHILDKILLED SIGABRT
SIGABRT
FAIL: test-compound-assignment.c.exe killed: 11817 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-constants.c.exe killed: 11849 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-debug-strings.c.exe killed: 11881 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-dot-product.c.exe killed: 11913 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-empty.c.exe killed: 11945 exp7 0 0 CHILDKILLED SIGSEGV {segmentation
violation}
FAIL: test-error-array-bounds.c.exe killed: 12021 exp7 0 0 CHILDKILLED SIGABRT
SIGABRT
FAIL: test-error-gcc_jit_context_new_bitfield-invalid-width.c.exe killed: 12469
exp7 0 0 CHILDKILLED SIGABRT SIGABRT
FAIL: test-error-gcc_jit_lvalue_get_address-bitfield.c.exe killed: 12674 exp7 0
0 CHILDKILLED SIGABRT SIGABRT
FAIL: test-error-gcc_jit_timer_pop-mismatch.c.exe killed: 12747 exp7 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-gcc_jit_timer_pop-too-many.c.exe killed: 12779 exp7 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-impossible-must-tail-call.c.exe killed: 12899 exp7 0 0
CHILDKILLED SIGABRT SIGABRT
FAIL: test-error-pr63969-missing-driver.c.exe killed: 13284 exp7 0 0
CHILDKILLED SIGABRT SIGABRT
FAIL: test-error-unrecognized-dump.c.exe killed: 13358 exp7 0 0 CHILDKILLED
SIGABRT SIGABRT
FAIL: test-expressions.c.exe killed: 13431 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-extra-options.c.exe killed: 13463 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-factorial-must-tail-call.c.exe killed: 13495 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-factorial.c.exe killed: 13527 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-fibonacci.c.exe killed: 13559 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-functions.c.exe killed: 13591 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-hello-world.c.exe killed: 13645 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-linked-list.c.exe killed: 13677 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-long-names.c.exe killed: 13709 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-nested-contexts.c.exe killed: 13741 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: did not find a generated reproducer:
t

[Bug fortran/92065] [7/8/9/10 Regression] internal compiler error: in expand_expr_real_1

[rolf.h.myhre at ntnu dot no]

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

Rolf  changed:

   What|Removed |Added

 CC||rolf.h.myhre at ntnu dot no

--- Comment #2 from Rolf  ---
I get the same error message when making a class with two subroutines that take
an array of class(*), dimension(n). It seemed to work fine when there was only
one subroutine or when at least the first subroutine were declared with an
assumed shape array. This minimal example appears to work as long as the second
routine is not declared with intent(out), but this still crashed for the
original code. 

output from gfortran -v :
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.3.0-6ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1~18.04.1)

command line:
gfortran mybug.F90

error message:
during RTL pass: expand
mybug.F90:32:0:

subroutine bar(this, array, n)

internal compiler error: in expand_expr_real_1, at expr.c:10047
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


minimal example, mybug.F90:

module bugbug_mod
!
   implicit none
!
   type :: bug_type
!
   contains
!
  procedure ::  foo
  procedure ::  bar
!
   end type bug_type
!
!
contains
!
!
   subroutine foo(this, array, n)
!
  implicit none
!  
  class(bug_type), intent(in) :: this
!
  integer, intent(in) :: n
!
  class(*), intent(in), dimension(n) :: array
!
   end subroutine foo
!
!  
   subroutine bar(this, array, n)
!
  implicit none
!  
  class(bug_type), intent(in) :: this
!
  integer, intent(in) :: n
!
  class(*), intent(out), dimension(n) :: array
!
   end subroutine bar
!
!  
end module bugbug_mod

[Bug tree-optimization/92412] excessive errno aliasing assumption defeats optimization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 12 18:49:31 2019
New Revision: 278099

URL: https://gcc.gnu.org/viewcvs?rev=278099&root=gcc&view=rev
Log:
PR tree-optimization/92412 - excessive errno aliasing assumption defeats
optimization

gcc/ChangeLog:

PR tree-optimization/92412
* targhooks.c (default_ref_may_alias_errno): Errono can only alias
extern variables.

gcc/testsuite/ChangeLog:

PR tree-optimization/92412
* gcc.dg/strlenopt-91.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-91.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/92412] excessive errno aliasing assumption defeats optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #5 from Martin Sebor  ---
Patch (https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00800.html) committed in
r278099.

[Bug tree-optimization/92412] excessive errno aliasing assumption defeats optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed.

[Bug c/92472] enhancement: 5 * constify some parameters

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||internal-improvement
 CC||egallager at gcc dot gnu.org
 Blocks||89863
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
[Bug 89863] [meta-bug] Issues that static analyzers (cppcheck,
clang-static-analyzer) find that gcc misses