[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 12 07:54:01 2019
New Revision: 278079

URL: https://gcc.gnu.org/viewcvs?rev=278079=gcc=rev
Log:
2019-11-11  Andre Vieira  

PR tree-optimization/92347
* tree-vect-loop.c (vect_transform_loop): Don't overwrite epilogues
safelen with 0.

* gcc.dg/vect/pr92347.c: New test.

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

[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

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Mon, 11 Nov 2019, iii at linux dot ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430
> 
> --- Comment #3 from Ilya Leoshkevich  ---
> Findings so far: when we forward an edge like this:
> 
> #0  redirect_edge_succ (e=0x76d73cc0, new_succ=0x76c2aa90) at
> ../.././gcc/cfg.c:368
> #1  0x00a776ff in redirect_edge_succ_nodup (e=0x76d73cc0,
> new_succ=0x76c2aa90) at ../.././gcc/cfghooks.c:469
> #2  0x00a9c18a in cfg_layout_redirect_edge_and_branch
> (e=0x76d73cc0, dest=0x76c2aa90) at ../.././gcc/cfgrtl.c:4500
> #3  0x00a77419 in redirect_edge_and_branch (e=0x76d73cc0,
> dest=0x76c2aa90) at ../.././gcc/cfghooks.c:373
> #4  0x02496e8d in try_forward_edges (mode=40, b=0x76d86680) at
> ../.././gcc/cfgcleanup.c:563
> #5  0x024a2654 in try_optimize_cfg (mode=40) at
> ../.././gcc/cfgcleanup.c:2961
> #6  0x024a2d1a in cleanup_cfg (mode=40) at
> ../.././gcc/cfgcleanup.c:3175
> #7  0x024a2f29 in (anonymous
> namespace)::pass_jump_after_combine::execute (this=0x38a2b00) at
> ../.././gcc/cfgcleanup.c:3315
> 
> we don't seem to correctly update dominance info (if at all), making it
> inconsistent with the actual CFG. In this particular case, inconsistency
> makes the following call chain produce a loop in the dominator tree:
> 
> #3  0x00b37638 in redirect_immediate_dominators (dir=CDI_DOMINATORS,
> bb=0x76c2ab60, to=0x76d867b8) at ../.././gcc/dominance.c:995
> #4  0x00a7838c in merge_blocks (a=0x76d867b8, b=0x76c2ab60) at
> ../.././gcc/cfghooks.c:852
> #5  0x024a1a1d in try_optimize_cfg (mode=40) at
> ../.././gcc/cfgcleanup.c:2825
> #6  0x024a2d1a in cleanup_cfg (mode=40) at
> ../.././gcc/cfgcleanup.c:3175
> #7  0x024a2f29 in (anonymous
> namespace)::pass_jump_after_combine::execute (this=0x38a2b00) at
> ../.././gcc/cfgcleanup.c:3315
> 
> which ultimately leads to the hang that we are observing.

Passes that do not update dominators need to free them at the start.
RTL is quite lazy here and moving passes around can move it to a part
in the pipeline where they are present.  In particular cleanup_cfg
doesn't.

[Bug middle-end/89230] Bogus uninited usage warning

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to lavr from comment #2)
> > > Okay, but "d" points to a clearly separate storage on stack within a local
> > > frame.  None of the pointers passed to (s)printf() relate to that area
> > > (either they are also clearly separate within the current stack frame,
> > > automatic ("name", "type", "temp"); or the argument values, that function
> > > was called with ("pfx")), so how "d->D_fid[2]" can be changed, in GCC's
> > > point of view?  I mean, within the semantics of the language, that's
> > > impossible; and the warning should only be issued for that kind of a
> > > (mis)use.
> > 
> > It is not obvious from your small code snippet that d does not point to a
> > local struct or if that local struct does not escape.
> > 
> > Without a full testcase (preprocessed source), it is hard to debug this any
> > further.
> 
> Reporter has since provided a full testcase (I haven't made any further
> attempt to debug it myself though)

...thus, this bug probably shouldn't be in WAITING any longer... (dunno if that
necessarily implies that it should be confirmed, though...)

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
so this is only a regression as what was register 19 was removed and what was
register 20 is now register 19.

If we change "19" to "20" it still ICEs for older versions of GCC:
apinski@xeond:~$ gcc t9.c
t9.c: In function ‘foo’:
t9.c:6:1: internal compiler error: in print_reg, at config/i386/i386.c:18026
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


related to PR 79804

[Bug c/92469] New: [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

Bug ID: 92469
   Summary: [9/10 Regression] ICE: output_operand: invalid use of
register 'frame'
   Product: gcc
   Version: 10.0
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 foo ( void ) 
{ 
register int x asm ( "19" ) ; 

int y = x;
}


My command line to compile GCC is

../sourecode_dir/configure --prefix=../install_dir --enable-languages=c,c++
--disable-multilib


$ gcc-snapshot10 --version
gcc (GCC) 10.0.0 20191110 (experimental)
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.

$ gcc-snapshot10 test.c 
during RTL pass: final
test.c: In function ‘foo’:
test.c:7:1: internal compiler error: output_operand: invalid use of register
'frame'
7 | }
  | ^
0x9bff96 output_operand_lossage(char const*, ...)
../../gcc-10-20191110/gcc/final.c:3610
0x9c11a1 output_operand(rtx_def*, int)
../../gcc-10-20191110/gcc/final.c:4052
0x9c1660 output_asm_insn(char const*, rtx_def**)
../../gcc-10-20191110/gcc/final.c:3964
0x9c3674 final_scan_insn_1
../../gcc-10-20191110/gcc/final.c:3107
0x9c395b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-10-20191110/gcc/final.c:3153
0x9c3a56 final_1
../../gcc-10-20191110/gcc/final.c:2021
0x9c4654 rest_of_handle_final
../../gcc-10-20191110/gcc/final.c:4659
0x9c4654 execute
../../gcc-10-20191110/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ gcc-snapshot9 --version
gcc (GCC) 9.2.1 20191109
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.

$ gcc-snapshot9 test.c 
during RTL pass: final
test.c: In function ‘foo’:
test.c:7:1: internal compiler error: output_operand: invalid use of register
'frame'
7 | }
  | ^
0x7f4ce6 output_operand_lossage(char const*, ...)
../../gcc-9-20191109/gcc/final.c:3610
0xd63454 ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-9-20191109/gcc/config/i386/i386.c:18356
0x7f5011 output_operand(rtx_def*, int)
../../gcc-9-20191109/gcc/final.c:4052
0x7f5acc output_asm_insn(char const*, rtx_def**)
../../gcc-9-20191109/gcc/final.c:3964
0x7f7192 final_scan_insn_1
../../gcc-9-20191109/gcc/final.c:3107
0x7f73eb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-9-20191109/gcc/final.c:3153
0x7f76c4 final_1
../../gcc-9-20191109/gcc/final.c:2021
0x7f80a4 rest_of_handle_final
../../gcc-9-20191109/gcc/final.c:4659
0x7f80a4 execute
../../gcc-9-20191109/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This ICE seems doesn't affect gcc-8 and earlier versions.


$ gcc-snapshot8 --version
gcc (GCC) 8.3.1 20191101
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 
test.c: In function ‘foo’:
test.c:4:18: error: the register specified for ‘x’ is not general enough to be
used as a register variable
 register int x asm ( "19" ) ;
  ^

[Bug tree-optimization/90004] [graphite] ICE: Segmentation fault (in scop_get_dependences(scop*))

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
I cannot reproduce the first ICE w/ the current gcc trunk snapshot and isl 0.22
anymore. The second one still fails for me:

#0  0x77ec7fe4 in isl_basic_map_underlying_set () from
/usr/lib64/libisl.so.22
#1  0x77ec3981 in isl_basic_map_is_empty () from
/usr/lib64/libisl.so.22
#2  0x77eaf501 in ?? () from /usr/lib64/libisl.so.22
#3  0x77eb2e5b in ?? () from /usr/lib64/libisl.so.22
#4  0x77eec098 in ?? () from /usr/lib64/libisl.so.22
#5  0x77eecccb in isl_union_access_info_compute_flow () from
/usr/lib64/libisl.so.22
#6  0x0159db5c in scop_get_dependences (scop=scop@entry=0x1eee960)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/graphite-dependences.c:316
#7  0x0159e0e0 in optimize_isl (scop=0x1eee960)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/graphite-optimize-isl.c:126

<…>

I have another Fortran testcase that ICEs in isl_basic_map_underlying_set(),
though w/ a different backtrace.

[Bug debug/92468] gcc generates wrong debug information at -O2 and -O3

[qrzhang at gatech dot edu]

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

Qirun Zhang  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #1 from Qirun Zhang  ---
Bisect points to r255569.

Author: aoliva 
Date:   Tue Dec 12 02:16:31 2017 +

[SFN] Introduce -gstatement-frontiers option, enable debug markers

Introduce a command line option to enable statement frontiers, enabled
by default in optimized builds with DWARF2+ debug information.

This patch depends on an earlier patch that completed the
infrastructure for debug markers, and on another patch that turns -g
into a negatable option prefix.

for  gcc/ChangeLog

* common.opt (gstatement-frontiers): New, setting
debug_nonbind_markers_p.
* rtl.h (MAY_HAVE_DEBUG_MARKER_INSNS): Activate.
* toplev.c (process_options): Autodetect value for debug statement
frontiers option.
* tree.h (MAY_HAVE_DEBUG_MARKER_STMTS): Activate.
* doc/invoke.texi (gstatement-frontiers, gno-statement-frontiers): New.

[Bug debug/92468] New: gcc generates wrong debug information at -O2 and -O3

[qrzhang at gatech dot edu]

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

Bug ID: 92468
   Summary: gcc generates wrong debug information at -O2 and -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It affects the trunk and both 8 and 9 releases. Gcc-7 works fine.
The expected output is k=0 or opt-out. With O2 and O3, gdb outputs k=1.

$ gcc-trunk -v
gcc version 10.0.0 2019 (experimental) [trunk revision 278048] (GCC)

#expected output
$ gcc-trunk -g abc.c
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x40054c: file abc.c, line 20.

Breakpoint 1, main () at abc.c:20
20  if (g) printf("index = %d%d%d\n", b, f, k);  //   
optimize_me_not()
$1 = 0

#wrong output
$ gcc-trunk -g abc.c -O3
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x4003c0: file abc.c, line 20.

Breakpoint 1, main () at abc.c:20
20  if (g) printf("index = %d%d%d\n", b, f, k);  //   
optimize_me_not()
$1 = 1




$ cat abc.c
int a,  b ;
short c[5][16] ;
void
d (e) {
 a =
  a ^ e;
}
int main ()
{
int f, k,  g = 0;
for (; b < 5; b++)
{
f = 0;
for (; f < 4; f++)
{
k = 0;
for (; k < 4; k++)
{
  d (c[b][f] & c[b][f*4+k] & 5);
if (g) printf("index = %d%d%d\n", b, f, k);  //   
optimize_me_not()
}
}
}
}



$ cat cmds
b abc.c:20
r
p k
kill
q

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

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(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.

[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

 CC||wilco at gcc dot gnu.org

--- Comment #1 from Wilco  ---
(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_as_bytes[offset] = canon_compare_value;
> do {
> uint32_t new_value = cur;
> reinterpret_cast(_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).

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 c++/92467] gcc miscompiles ternary expression with omitted first operand ?: involving C++ prvalues

[st at quanttec dot com]

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

--- Comment #3 from Stephan Tolksdorf  ---
Calling release on tmp should set the internal pointer member to null so that
the destructor won't call the deleter on the (void*)1 ptr.

[Bug c++/92467] gcc miscompiles ternary expression with omitted first operand ?: involving C++ prvalues

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
So the question becomes what is the semantics of the extension.  I think GCC
here is doing one that would be similar to what C++ would normally do with
respect of the tmp variable.  So not extending the life time of it if it is
used like that before.

Clang is implementing the semantics of the extension slightly different and
really I don't know where the temporary lifetime ends.  Because the extension
requires a tmp.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Tentative patch: https://gcc.gnu.org/ml/fortran/2019-11/msg00054.html

[Bug c++/92467] gcc miscompiles ternary expression with omitted first operand ?: involving C++ prvalues

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Conditionals.html#Conditionals

If I understand the extension correctly, we have:
({
auto  = get1();
(tmp ? tmp: get2()).release();
})


This means the tmp variable goes out of the scope after the ?: statement ends.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[jakub at gcc dot gnu.org]

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

Bug 92433 Summary: [10 regression] r276645 breaks bootstrap on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92433

   What|Removed |Added

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

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[jakub at gcc dot gnu.org]

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

Bug 92433 Summary: [10 regression] r276645 breaks bootstrap on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92433

   What|Removed |Added

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

[Bug c++/92467] New: gcc miscompiles ternary expression with omitted first operand ?: involving C++ prvalues

[st at quanttec dot com]

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

Bug ID: 92467
   Summary: gcc miscompiles ternary expression with omitted first
operand ?: involving C++ prvalues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: st at quanttec dot com
  Target Milestone: ---

The current trunk version of GCC miscompiles the following code involving a
ternary expression with omitted first operand ("elvis operator"). Compiled with
`g++-9 --std=c++2a` the program prints "deleting: 1" followed by "result: 1".
The same code compiled with clang doesn't erroneously call the deleter
function.

(Note that such use of the ternary operator in C++ will become increasingly
common:
https://stackoverflow.com/questions/58368012/how-to-enable-the-c-c-conditional-with-omitted-operand-aka-elvis-operator
)


#include 
#include 

#define NOINLINE __attribute__ ((noinline))

struct Deleter {
NOINLINE void operator()(void* p) {
std::cout << "deleting: " << (uintptr_t)p << std::endl;
}
};

NOINLINE std::unique_ptr get1() {
return std::unique_ptr{(void*)1};
}
NOINLINE std::unique_ptr get2() {
return std::unique_ptr{(void*)2};
}

NOINLINE void* test() {
return (get1() ?: get2()).release();
}

int main() {
uintptr_t result = (uintptr_t)test();
std::cout << "result: " << result;
return 0;
}

[Bug c++/92447] [10 Regression] ICE in poplevel, at cp/decl.c:585

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|jason at gcc dot gnu.org   |jakub at gcc dot gnu.org

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

[Bug c++/92447] [10 Regression] ICE in poplevel, at cp/decl.c:585

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 11 21:31:29 2019
New Revision: 278068

URL: https://gcc.gnu.org/viewcvs?rev=278068=gcc=rev
Log:
PR c++/92447
* decl.c (finish_function): Move ctype initialization before
DECL_DELETED_FN handling.

* g++.dg/cpp0x/pr92447.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr92447.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

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

[seurer at gcc dot gnu.org]

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

Bug ID: 92466
   Summary: new test case gfortran.dg/ISO_Fortran_binding_15.f90
in r278025 fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Executing on host:
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
c99_runtime14247.c-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never  -S -o c99_runtime14247.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
c99_runtime14247.c -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -S -o c99_runtime14247.s
Executing on host:
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90 
  -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O0   -pedantic-errors 
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c 
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
 -lm  -o ./ISO_Fortran_binding_15.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O0 -pedantic-errors
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./ISO_Fortran_binding_15.exe
PASS: gfortran.dg/ISO_Fortran_binding_15.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test/gcc:.:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300

[Bug other/92465] New: [10 regression] r278034 breaks gcc.dg/pr47763.c

[seurer at gcc dot gnu.org]

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

Bug ID: 92465
   Summary: [10 regression] r278034 breaks gcc.dg/pr47763.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am not sure what is going on here as the update doesn't look like it would
have an effect like this (dump file not existing).  Usually that is because of
a bad test case option.

Executing on host: /home/seurer/gcc/build/gcc-test3/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test3/gcc/
/home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/pr47763.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -O2 -funroll-loops
-fdump-rtl-web -ffat-lto-objects -S -o pr47763.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test3/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test3/gcc/
/home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/pr47763.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -funroll-loops
-fdump-rtl-web -ffat-lto-objects -S -o pr47763.s
PASS: gcc.dg/pr47763.c (test for excess errors)
gcc.dg/pr47763.c: dump file does not exist
UNRESOLVED: gcc.dg/pr47763.c scan-rtl-dump-not web "Web oldreg"
testcase /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds

=== gcc Summary ===

# of expected passes1
# of unresolved testcases   1

[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0

[jb at gcc dot gnu.org]

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

Bug 91828 Summary: gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 
3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828

   What|Removed |Added

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

[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #7 from Janne Blomqvist  ---
Fixed on trunk, closing. Also added a note to
https://gcc.gnu.org/gcc-10/changes.html .

[Bug c++/92438] [7/8/9/10 Regression] Function declaration parsed incorrectly with `-std=c++1z`

[sagebar at web dot de]

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

--- Comment #2 from sagebar at web dot de ---
The c++ standard may not cover it, however in the interest of compatibility
with other compilers, g++ for cygwin actually defines the following predefined
macros (among others):

g++ -dM -E -x c++ - < /dev/null | grep cdecl
```
#define _cdecl __attribute__((__cdecl__))
#define __cdecl __attribute__((__cdecl__))
```

Obviously, these are there for compatibility with msvc, and as it turns out:
msvc _only_ allows calling convention attributes if they are written between a
function's return type, and its name (or in the case of there being
parenthesis: only inside of them).
```
// - The only way that msvc accepts it
// - One of the ways that g++ for cygwin accepts it
int __cdecl foo();
int (__cdecl bar)();
```

So it does make perfect sense, and in a way is very much intended behavior in
my mind that __attribute__((...)) is accepted in that same place, and even more
so: If you look at the windows headers used by cygwin, you'll see that this is
behavior that is very much depended upon.

And even disregarding the (thus far fully maintained) compatibility with msvc
as far as the annotation of calling conventions go, this is most definitely
still a bug since using the typedef'd name `MYINT` as return type breaks g++,
however using the struct's name (including the `struct` prefix) as `struct
myint_struct` gets parsed correctly (so whatever would be the ~correct~ way of
doing, g++ is inconsistent about it).

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 11 20:05:49 2019
New Revision: 278066

URL: https://gcc.gnu.org/viewcvs?rev=278066=gcc=rev
Log:
PR bootstrap/92433
* config/rs6000/rs6000-c.c (altivec_build_resolved_builtin): Guard
ALTIVEC_BUILTIN_VEC_VCMPGE_P argument swapping with n == 3 check.  Use
std::swap.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c

[Bug tree-optimization/92420] [7/8/9/10 Regression] Vectorization miscompilation with negative strides since r238039

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Nov 11 19:43:52 2019
New Revision: 278064

URL: https://gcc.gnu.org/viewcvs?rev=278064=gcc=rev
Log:
Fix SLP downward group access classification (PR92420)

This PR was caused by the SLP handling in get_group_load_store_type
returning VMAT_CONTIGUOUS rather than VMAT_CONTIGUOUS_REVERSE for
downward groups.

A more elaborate fix would be to try to combine the reverse permutation
into SLP_TREE_LOAD_PERMUTATION for loads, but that's really a follow-on
optimisation and not backport material.  It might also not necessarily
be a win, if the target supports (say) reversing and odd/even swaps
as independent permutes but doesn't recognise the combined form.

2019-11-11  Richard Sandiford  

gcc/
PR tree-optimization/92420
* tree-vect-stmts.c (get_negative_load_store_type): Move further
up file.
(get_group_load_store_type): Use it for reversed SLP accesses.

gcc/testsuite/
* gcc.dg/vect/pr92420.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr92420.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[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 #5 from Jakub Jelinek  ---
Created attachment 47214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47214=edit
gcc10-pr92449.patch

Untested patch not to emit UNORDERED_EXPR if !HONOR_NANS from complex lowering.

[Bug testsuite/92464] New: [10 regression] r 278033 breaks gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c

[seurer at gcc dot gnu.org]

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

Bug ID: 92464
   Summary: [10 regression] r 278033 breaks
gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This happens on power 7 but things work fine on power 8 and 9.  Does the test
case just need to be adjusted when run on power 7?

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
   -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O2 -ftree-vectorize
-fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details
-fno-tree-loop-distribute-patterns  -lm  -o ./costmodel-vect-76b.exe   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -ftree-vectorize
-fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details
-fno-tree-loop-distribute-patterns -lm -o ./costmodel-vect-76b.exe
PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c execution test
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ p8vector_hw_available60365.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -mpower8-vector  -lm  -o
p8vector_hw_available60365.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ p8vector_hw_available60365.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -mpower8-vector -lm -o
p8vector_hw_available60365.exe
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: pattern found 1 times
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect
"vectorized 1 loops" 0
gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: pattern found 0 times
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect
"vectorization not profitable" 1
testcase
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/costmodel/ppc/ppc-costmodel-vect.exp
completed in 1 seconds

=== gcc Summary ===

# of expected passes2
# of unexpected failures2

[Bug fortran/92463] New: Cleanups due to minimum MPFR version bump to 3.1.0

[jb at gcc dot gnu.org]

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

Bug ID: 92463
   Summary: Cleanups due to minimum MPFR version bump to 3.1.0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

As part of resolving PR 91828, the minimum MPFR version required to build GCC
was bumped to 3.1.0 from the previous 2.4.0. 

This enables a bunch of cleanups, mostly in the Fortran frontend (hence
assigning this bug to the fortran component).

From https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01544.html :

> For example, you could justify a move to requiring MPFR 3.0.0 or later 
with cleanups to use MPFR_RND* instead of the older GMP_RND*, and 
similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t 
and mpfr_prec_t in fortran/.  You could justify a move to requiring MPC 
1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10.  I don't know what 
if any newer GMP interfaces would be beneficial in GCC.  And as always in 
such cases, it's a good idea to look at e.g. how widespread the newer 
versions are in GNU/Linux distributions, which indicates how many people 
might be affected by an increase in the version requirement.

[Bug ipa/92234] [10 Regression] ICE verify_gimple failed (profiled lto) on s390x-linux-gnu

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #5 from Matthias Klose  ---
this now works again with 20191109, except for powerpc64le-linux-gnu, which is
tracked in PR92235.

[Bug bootstrap/92235] [10 Regression] ICE in host_detect_local_cpu, segfault (profiled lto) on powerpc64le-linux-gnu

[doko at debian dot org]

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

--- Comment #3 from Matthias Klose  ---
same with 20191109

[Bug c++/92458] Constraints do not work with precompiled headers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47213=edit
gcc10-pr92458.patch

Ugh, this is a mess.  PCH remaps pointers and decl_constraints actually isn't
any kind of cache, but needs to map decls to the constraints for the whole FE,
all that can happen is that GC collected keys result in GC of the corresponding
constraints.
The hash_map that was used was using pointer hash, so after the remapping the
pointers are different, but nothing rehashed the hash tables.

The patch fixes it by using DECL_UID as hash value instead, that is stable
across PCH.

[Bug target/92462] New: [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

Bug ID: 92462
   Summary: [arm32] -ftree-pre makes a variable to be wrongly
hoisted out
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aleksei.voity...@bell-sw.com
  Target Milestone: ---

Created attachment 47212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47212=edit
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_as_bytes[offset] = canon_compare_value;
do {
uint32_t new_value = cur;
reinterpret_cast(_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

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[avieira at gcc dot gnu.org]

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Thank you!

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

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from avieira at gcc dot gnu.org ---
The ICE seems to be because vectorizable_simd_clone_call is inserting values
and phi-nodes on the epilogue's preheader edge which uses a value defined in
the main loop's preheader edge (created by the main loop's call to
vectorizable_simd_clone_call). However this definition does not dominate the
use, as the main loop may have been skipped.

Not entirely sure what the best action is here, I didn't get enough time to
figure out what these values represent. I suspect this is not because of my
changes though, but it was a latent issue that now shows up because I turned on
epilogue vectorization.

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

[asolokha at gmx dot com]

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

Bug ID: 92461
   Summary: [10 Regression] ICE: verify_ssa failed (error: excess
use operand for statement)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: avieira at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20191103 snapshot (r277758) ICEs when compiling the following
testcase w/ -O1 -ftree-loop-vectorize:

short int zb;

void
gs (void)
{
  while (zb < 1)
{
  int at;

  zb %= 1;

  for (at = 0; at < 56; ++at)
zb += zb;

  ++zb;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191103 -O1 -ftree-loop-vectorize
-c klumnm2e.c
klumnm2e.c: In function 'gs':
klumnm2e.c:4:1: error: excess use operand for statement
4 | gs (void)
  | ^~
0
_7 = 0 + 1;
during GIMPLE pass: vect
klumnm2e.c:4:1: internal compiler error: verify_ssa failed
0xe4094c verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-ssa.c:1208
0xbab70c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1990
0xbac460 do_per_function
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1638
0xbac460 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:2037

(This was originally reported in PR92347 comment 2.)

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha  ---
(In reply to avieira from comment #5)
> I think it would be useful to split testcases 2 and 3 into two new PR's as
> they are unrelated issues to 1.

PR92460 and PR92461, then.

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

[asolokha at gmx dot com]

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

Bug ID: 92460
   Summary: [10 Regression] ICE: verify_ssa failed (error:
definition in block 13 does not dominate use in block
22)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: avieira at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20191103 snapshot (r277758) ICEs when compiling the following
testcase reduced from gcc/testsuite/gcc.dg/vect/vect-simd-clone-11.c w/ -mavx2
-O1 -fopenmp -ftree-loop-vectorize -ftree-parallelize-loops=2
-fno-tree-loop-ivcanon:

#pragma omp declare simd linear (yu : 6)
int __attribute__ ((noinline))
ms (int yu)
{
  return yu;
}

void
fm (int *kq)
{
  int v1 = 0, r5 = 1;

  while (v1 < 200)
{
  kq[v1] = ms (r5 * 2);
  r5 += 3;
  ++v1;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191103 -mavx2 -O1 -fopenmp
-ftree-loop-vectorize -ftree-parallelize-loops=2 -fno-tree-loop-ivcanon -c
ax2wgtfe.c
ax2wgtfe.c: In function 'fm._loopfn.0':
ax2wgtfe.c:13:9: error: definition in block 13 does not dominate use in block
22
   13 |   while (v1 < 200)
  | ^
for SSA_NAME: _84 in statement:
_147 = _84 + 1;
during GIMPLE pass: vect
ax2wgtfe.c:13:9: internal compiler error: verify_ssa failed
0xe4094c verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-ssa.c:1208
0xbab70c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1990
0xbac460 do_per_function
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1638
0xbac460 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:2037

(This was originally reported in PR92347 comment 2.)

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

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #4 from Segher Boessenkool  ---
If flag_finite_math_only, the backend should never be presented with "ordered"
or "unordered" codes (or uneq, unlt, unge, unle, unge, or ltgt).

But I have a patch to let the rs6000 backend survive even then (well, only for
those first two codes, the rest does not seem to happen).

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[avieira at gcc dot gnu.org]

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

--- Comment #5 from avieira at gcc dot gnu.org ---
Not quite sure the third case has anything to do with epilogue vectorization
though... It still manifests itself with it turned off. Seems to be a lack of
"folding" again.

I think it would be useful to split testcases 2 and 3 into two new PR's as they
are unrelated issues to 1.

[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 linux dot ibm.com]

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

--- Comment #3 from Ilya Leoshkevich  ---
Findings so far: when we forward an edge like this:

#0  redirect_edge_succ (e=0x76d73cc0, new_succ=0x76c2aa90) at
../.././gcc/cfg.c:368
#1  0x00a776ff in redirect_edge_succ_nodup (e=0x76d73cc0,
new_succ=0x76c2aa90) at ../.././gcc/cfghooks.c:469
#2  0x00a9c18a in cfg_layout_redirect_edge_and_branch
(e=0x76d73cc0, dest=0x76c2aa90) at ../.././gcc/cfgrtl.c:4500
#3  0x00a77419 in redirect_edge_and_branch (e=0x76d73cc0,
dest=0x76c2aa90) at ../.././gcc/cfghooks.c:373
#4  0x02496e8d in try_forward_edges (mode=40, b=0x76d86680) at
../.././gcc/cfgcleanup.c:563
#5  0x024a2654 in try_optimize_cfg (mode=40) at
../.././gcc/cfgcleanup.c:2961
#6  0x024a2d1a in cleanup_cfg (mode=40) at
../.././gcc/cfgcleanup.c:3175
#7  0x024a2f29 in (anonymous
namespace)::pass_jump_after_combine::execute (this=0x38a2b00) at
../.././gcc/cfgcleanup.c:3315

we don't seem to correctly update dominance info (if at all), making it
inconsistent with the actual CFG. In this particular case, inconsistency
makes the following call chain produce a loop in the dominator tree:

#3  0x00b37638 in redirect_immediate_dominators (dir=CDI_DOMINATORS,
bb=0x76c2ab60, to=0x76d867b8) at ../.././gcc/dominance.c:995
#4  0x00a7838c in merge_blocks (a=0x76d867b8, b=0x76c2ab60) at
../.././gcc/cfghooks.c:852
#5  0x024a1a1d in try_optimize_cfg (mode=40) at
../.././gcc/cfgcleanup.c:2825
#6  0x024a2d1a in cleanup_cfg (mode=40) at
../.././gcc/cfgcleanup.c:3175
#7  0x024a2f29 in (anonymous
namespace)::pass_jump_after_combine::execute (this=0x38a2b00) at
../.././gcc/cfgcleanup.c:3315

which ultimately leads to the hang that we are observing.

[Bug target/91710] [9/10 Regression] unexpected ABI change note

[jbeulich at suse dot com]

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

--- Comment #4 from jbeulich at suse dot com ---
(In reply to Andrew Pinski from comment #3)
> @@ -4908,7 +4908,8 @@ aarch64_function_arg_boundary (machine_mode mode,
> const_tree type)
>bool abi_break;
>unsigned int alignment = aarch64_function_arg_alignment (mode, type,
>_break);
> -  if (abi_break & warn_psabi)
> +
> +  if (alignment >= STACK_BOUNDARY && abi_break & warn_psabi)
>  inform (input_location, "parameter passing for argument of type "
> "%qT changed in GCC 9.1", type);

Wouldn't this then want to be > PARM_BOUNDARY instead of >= STACK_BOUNDARY? In
#1 you also say "But if it is equal to STACK_BOUNDARY ...", so perhaps even >
PARM_BOUNDARY && <= STACK_BOUNDARY?

I also find it a little odd for the adjustment not be to
aarch64_function_arg_alignment()'s setting of abi_break, but I guess doing so
would be incompatible with some of the other uses of the function.

(Also I guess the opportunity should be taken to convert the slightly
suspicious pre-existing & to &&.)

[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

 Status|ASSIGNED|NEW

--- Comment #7 from Tobias Burnus  ---
(In reply to Thomas Schwinge from comment #6)
> And indeed I'm seeing that, too, 

Cool. Can you then debug it? Here, it works!

As mentioned several times in the PR, I cannot reproduce it neither locally
(without true offloading) nor with nvptx offloading.

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

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
See also bug 92333, comment #4.

[Bug fortran/92457] [10 Regression] FAIL: gfortran.dg/ISO_Fortran_binding_16.f90

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Tobias Burnus  ---
Already FIXED in Rev. 278055, cf.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00758.html

Sorry for the breakage; seemingly, something went wrong with patches and
renaming. (File name changed to avoid naming collision after another patch went
in.)

[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

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47211=edit
gcc10-pr92452.patch

Untested fix.  TRUNC_DIV_EXPR of a POLY_INT_CST with INTEGER_CST folds into
NULL_TREE, because for poly ints only +/-/* and similar operations are handled.

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

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
The first testcase has (at expand time)
  if (_13 unord _14)
which doesn't mean anything with -ffast-math (-Ofast): unordered does
not *exist*.

The second testcase is similar, but we generate that unordered from the
builtin.  Should we allow that builtin with -ffast-math at all?  It makes
no real sense.

[Bug tree-optimization/90930] Excessive memory consumption

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 11 16:07:54 2019
New Revision: 278059

URL: https://gcc.gnu.org/viewcvs?rev=278059=gcc=rev
Log:
2019-11-11  Richard Biener  

Backport from mainline
2019-06-25  Richard Biener  

PR tree-optimization/90930
* tree-ssa-reassoc.c (reassociate_bb): Only rewrite expression
into parallel form in the last pass instance.

* gcc.dg/tree-ssa/reassoc-24.c: Adjust.
* gcc.dg/tree-ssa/reassoc-25.c: Likewise.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.dg/tree-ssa/reassoc-24.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/tree-ssa/reassoc-25.c
branches/gcc-9-branch/gcc/tree-ssa-reassoc.c

[Bug c++/92459] New: out of class method definition did not match (when declaration contains expression that uses in class defined enum)

[nok.raven at gmail dot com]

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

Bug ID: 92459
   Summary: out of class method definition did not match (when
declaration contains expression that uses in class
defined enum)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

template 
struct S {};

struct X {
enum E { A };

template 
S* foo();
};

template 
S* X::foo() {
return 0;
}

int main() {
X().foo();
}

https://godbolt.org/z/YNUVzC

When enum is defined outside of a class it compiles.

---

template 
struct S {};

struct X {
enum E { A };

template
inline static constexpr bool q = A == e;

template 
S>* foo();
//S>* foo(); // this one compiles
};

template 
S>* X::foo() {
return 0;
}

int main() {
X().foo();
}

https://godbolt.org/z/AvjYYr

With this one Clang has problems too.

[Bug lto/91935] Unneeded .debug_info entries in .symtab when using LTO

[dimitar.yordanov at sap dot com]

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

--- Comment #2 from Dimitar Yordanov  ---
Probably already clear, but to write down what I read so far and did not write
with the initial report:

PR lto/83452. is actually not the regression, it is just a workaround to "Make
discarded global symbols hidden weak"

and 

PR lto/91478 is a different implementation of the same workaround that instead
aliases discarded global symbols to a debug_info entry, which should always be
present.

But in the end the dead symbols are there.

[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2

[jb at gcc dot gnu.org]

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

--- Comment #6 from Janne Blomqvist  ---
Author: jb
Date: Mon Nov 11 15:59:48 2019
New Revision: 278058

URL: https://gcc.gnu.org/viewcvs?rev=278058=gcc=rev
Log:
Bump minimum MPFR version to 3.1.0

Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
requirement one can still build GCC with the operating system provided
MPFR on old but still supported operating systems like SLES 12 (MPFR
3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).

This allows removing some code in the Fortran frontend, as well as
fixing PR 91828.

ChangeLog:

2019-11-11  Janne Blomqvist  

PR fortran/91828
* configure.ac: Bump minimum MPFR to 3.1.0, recommended to 3.1.6+.
* configure: Regenerated.

gcc/ChangeLog:

2019-11-11  Janne Blomqvist  

PR fortran/91828
* doc/install.texi: Document that the minimum MPFR version is
3.1.0.

gcc/fortran/ChangeLog:

2019-11-11  Janne Blomqvist  

PR fortran/91828
* simplify.c (gfc_simplify_fraction): Remove fallback path for
MPFR < 3.1.0.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c

[Bug ipa/92454] [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
I think the patch is (In reply to Jan Hubicka from comment #2)
> This is the usual problem of trying to process node with no summary
> attached to it. The following fixes the ICE, but I am not sure if there
> is a cleaner approach.
> 
> Martin, i suppose the issue here is with thunks in addition to stuff
> optimized with -fno-ipa-cp?

I don't think any -fno-ipa-cp is involved, it is just a thunk which is
a part of an SCC because of speculative dervirtualization and the code
simply did not anticipate such situation - thunk was though of as
always a target of indirect calls, at least pre-IPA-CP.

In any event, adding the test here seems to be the right thing to do,
plus we probably want a similar test in spread_undeadness.

[Bug middle-end/92455] Unnecessary memory read in a loop

[antoshkka at gmail dot com]

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

--- Comment #4 from Antony Polukhin  ---
(In reply to Richard Biener from comment #3)
> But maybe
> you can provide benchmark data (including compile-time/memory-use figures)?

OK. Is there any GCC specific tool or flag for that?

[Bug fortran/92142] CFI_setpointer corrupts descriptor

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Author: burnus
Date: Mon Nov 11 15:35:50 2019
New Revision: 278055

URL: https://gcc.gnu.org/viewcvs?rev=278055=gcc=rev
Log:
Fix commit for PR fortran/92142 - CFI_setpointer corrupts descriptor

2019-11-11  Tobias Burnus  
Mark Eggleston  

PR fortran/92142
* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90:
Correct dg-additional-sources.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90

[Bug c++/92458] New: Constraints do not work with precompiled headers

[redi at gcc dot gnu.org]

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

Bug ID: 92458
   Summary: Constraints do not work with precompiled headers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

// header, compile with g++ -std=gnu++2a -c
template concept C = sizeof(T) > 1;
template struct S { };
template requires C struct S { };
template requires (!C) struct S { };

// source file, compile with g++ -std=gnu++2a -c
#include "h.h"
S s;


If no precompiled header exists, this compiles OK. If h.h.gch has been produced
by compiling the header with -std=gnu++2a -c then compiling the source file
gives an error:

h.cc:2:8: error: ambiguous template instantiation for 'struct S'
2 | S s;
  |^
h.h:4:43: note: candidates are: 'template struct S [with T = int]'
4 | template requires (!C) struct S { };
  |   ^~~~
h.h:5:46: note: 'template struct S [with T = int]'
h.cc:2:8: error: aggregate 'S s' has incomplete type and cannot be defined
2 | S s;
  |^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-11
 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r277976.

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[avieira at gcc dot gnu.org]

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

--- Comment #4 from avieira at gcc dot gnu.org ---
The second case seems to be because vectorizable_simd_clone_call seems to be
inserting values and phi-nodes on the epilogue's preheader edge which uses a
value defined in the main loop's preheader edge (created by the main loop's
call to vectorizable_simd_clone_call). However this definition does not
dominate the use, as the main loop may have been skipped.

Not entirely sure what the best action is here, I didn't get enough time to
figure out what these values represent.

[Bug c++/92447] [10 Regression] ICE in poplevel, at cp/decl.c:585

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47210=edit
gcc10-pr92447.patch

Untested fix.  The goto cleanup for deleted fns bypassed ctype setting and thus
current_binding_level went out of sync.

[Bug middle-end/92455] Unnecessary memory read in a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Antony Polukhin from comment #2)
> Can the -ftree-partial-pre flag be enabled by default for -O2?

It used to be quite slow in its dataflow compute but that has improved.
It's still quadratic in size though and it's scope is extremely limited
(partial antic but fully available).  So I don't think so.  But maybe
you can provide benchmark data (including compile-time/memory-use figures)?

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[avieira at gcc dot gnu.org]

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

--- Comment #3 from avieira at gcc dot gnu.org ---
I had a look at the first testcase. I think the problem is I was setting the
epilogue's safelen to the loop's safelen, after the loop->safelen had been
cleared, as we do this after vectorization. Removing that update and letting
epilogue keep the original safelen seems to solve the first ICE.  The second is
something different, looking at that now.

[Bug middle-end/92455] Unnecessary memory read in a loop

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
Can the -ftree-partial-pre flag be enabled by default for -O2?

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #5)
>   if (y)
> {
>   gcc_assert (n == 3);
>   std::swap (arg_type[1], arg_type[2]);
> }
> 
> 
> ?

gcc_assert will work too unless the host compiler is older than 4.5 (or is
clang), but I think we don't really make -Werror on in that case, at least not
by default (only in second stage that is built with trunk gcc already).
So, I can bootstrap/regtest:
2019-11-11  Jakub Jelinek  

PR bootstrap/92433
* config/rs6000/rs6000-c.c (altivec_build_resolved_builtin): Add
assertion that n is 3 for ALTIVEC_BUILTIN_VEC_VCMPGE_P.  Use
std::swap.

--- gcc/config/rs6000/rs6000-c.c.jj 2019-08-27 12:26:30.115019661 +0200
+++ gcc/config/rs6000/rs6000-c.c2019-11-11 15:03:57.299102261 +0100
@@ -6080,10 +6080,10 @@ altivec_build_resolved_builtin (tree *ar
   && desc->overloaded_code != ALTIVEC_BUILTIN_VCMPGEFP_P
   && desc->overloaded_code != VSX_BUILTIN_XVCMPGEDP_P)
 {
-  tree t;
-  t = args[2], args[2] = args[1], args[1] = t;
-  t = arg_type[2], arg_type[2] = arg_type[1], arg_type[1] = t;
-  
+  gcc_assert (n == 3);
+  std::swap (args[1], args[2]);
+  std::swap (arg_type[1], arg_type[2]);
+
   args[0] = fold_build2 (BIT_XOR_EXPR, TREE_TYPE (args[0]), args[0],
 build_int_cst (NULL_TREE, 2));
 }

too if you prefer it that way.  Richi said on IRC he prefers a rs6000-c.c
change in this case.

[Bug fortran/92457] [10 Regression] FAIL: gfortran.dg/ISO_Fortran_binding_16.f90

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-11
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug fortran/92457] New: [10 Regression] FAIL: gfortran.dg/ISO_Fortran_binding_16.f90

[marxin at gcc dot gnu.org]

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

Bug ID: 92457
   Summary: [10 Regression] FAIL:
gfortran.dg/ISO_Fortran_binding_16.f90
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
  Target Milestone: ---

I see the test-case failure since the revision it was added:

Executing on host: /dev/shm/objdir/gcc/testsuite/gfortran1/../../gfortran
-B/dev/shm/objdir/gcc/testsuite/gfortran1/../../
-B/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
   -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O0  -pedantic-errors
-fbounds-check 
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c
 -B/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libatomic/.libs
-B/dev/shm/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs  -lm  -o
./ISO_Fortran_binding_16.exe(timeout = 300)
spawn -ignore SIGHUP /dev/shm/objdir/gcc/testsuite/gfortran1/../../gfortran
-B/dev/shm/objdir/gcc/testsuite/gfortran1/../../
-B/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O0 -pedantic-errors
-fbounds-check
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c
-B/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libatomic/.libs
-B/dev/shm/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o
./ISO_Fortran_binding_16.exe
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
/tmp/ccBWUky4.o: in function `main':
ISO_Fortran_binding_15.c:(.text+0x0): multiple definition of `main';
/tmp/ccgBvJc3.o:ISO_Fortran_binding_16.f90:(.text+0xa1): first defined here
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
/tmp/ccgBvJc3.o: in function `MAIN__':
ISO_Fortran_binding_16.f90:(.text+0x5c): undefined reference to `c_setpointer'
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
/tmp/ccBWUky4.o: in function `main':
ISO_Fortran_binding_15.c:(.text+0x6c): undefined reference to `Fsub'
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O0  (test for excess errors)
Excess errors:
ISO_Fortran_binding_15.c:(.text+0x0): multiple definition of `main';
/tmp/ccgBvJc3.o:ISO_Fortran_binding_16.f90:(.text+0xa1): first defined here
ISO_Fortran_binding_16.f90:(.text+0x5c): undefined reference to `c_setpointer'
ISO_Fortran_binding_15.c:(.text+0x6c): undefined reference to `Fsub'

[Bug other/92456] New: libiberty/make-relative-prefix.c: read buffer overflow in split_directories()

[tim.ruehsen at gmx dot de]

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

Bug ID: 92456
   Summary: libiberty/make-relative-prefix.c: read buffer overflow
in split_directories()
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

Created attachment 47209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47209=edit
Patch proposal to fix the issue

In L189
  if (dirs[num_dirs - 1] == NULL)
'num_dirs' can be 0 if name is an empty string.

Same in L129.

The attached patch fixes both.

[Bug middle-end/92455] Unnecessary memory read in a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
You need partial-PRE to perform the desired transform.  With -O3 or -O2
-ftree-partial-pre we do what you suggest (plus also cache *max->ptr in
exchange
for another IV):

f1:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
leaq40(%rdi), %rcx
movq%rdi, %rsi
movl(%rax), %edx
.L3:
movq8(%rdi), %rax
addq$8, %rdi
movl(%rax), %eax
cmpl%edx, %eax
jle .L2
movl%eax, %edx
movq%rdi, %rsi
.L2:
cmpq%rdi, %rcx
jne .L3
movq(%rsi), %rax
ret

because of the two conditional values (*max and *max->ptr_) the cmov
transform doesn't trigger.

[Bug ipa/92454] [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
This is the usual problem of trying to process node with no summary
attached to it. The following fixes the ICE, but I am not sure if there
is a cleaner approach.

Martin, i suppose the issue here is with thunks in addition to stuff
optimized with -fno-ipa-cp?


Honza

Index: ipa-cp.c
===
--- ipa-cp.c(revision 278023)
+++ ipa-cp.c(working copy)
@@ -5008,19 +5089,19 @@ identify_dead_nodes (struct cgraph_node
 {
   struct cgraph_node *v;
   for (v = node; v; v = ((struct ipa_dfs_info *) v->aux)->next_cycle)
-if (v->local
+if (v->local && IPA_NODE_REF (v)
&& !v->call_for_symbol_thunks_and_aliases
 (has_undead_caller_from_outside_scc_p, NULL, true))
   IPA_NODE_REF (v)->node_dead = 1;

   for (v = node; v; v = ((struct ipa_dfs_info *) v->aux)->next_cycle)
-if (!IPA_NODE_REF (v)->node_dead)
+if (IPA_NODE_REF (v) && !IPA_NODE_REF (v)->node_dead)
   spread_undeadness (v);

   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   for (v = node; v; v = ((struct ipa_dfs_info *) v->aux)->next_cycle)
-   if (IPA_NODE_REF (v)->node_dead)
+   if (IPA_NODE_REF (v) && IPA_NODE_REF (v)->node_dead)
  fprintf (dump_file, "  Marking node as dead: %s.\n", v->dump_name
());
 }
 }

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-10-23 00:00:00 |2019-11-11
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
(In reply to David Binderman from comment #2)
> For the file testsuite/gcc.target/x86_64/abi/callabi/leaf-2.c,
> with compiler flag -O3 -arch=knm, I get the same thing.
> 
> The revision at fault seem to be between 277650 and 277700.

With --param vect-epilogues-nomask=1 it also started with r276648.

[Bug ipa/92454] [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/92455] New: Unnecessary memory read in a loop

[antoshkka at gmail dot com]

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

Bug ID: 92455
   Summary: Unnecessary memory read in a loop
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

typedef struct {
int* ptr_; 
} int_ptr;  

int_ptr f1(int_ptr* x) {
int_ptr* max = x;
for (int i =0 ; i < 5; ++ i) {
++ x;
if (*max->ptr_ < *x->ptr_) {
max = x;
}
}
return *max;
}

GCC with -O2 generates the following assembly:

f1(int_ptr*):
  lea rsi, [rdi+40]
  mov rax, rdi
.L3:
  mov rcx, QWORD PTR [rax]  ; <== This could be removed from the loop
  mov rdx, QWORD PTR [rdi+8]
  add rdi, 8
  mov edx, DWORD PTR [rdx]
  cmp DWORD PTR [rcx], edx
  cmovl rax, rdi
  cmp rsi, rdi
  jne .L3
  mov rax, QWORD PTR [rax]
  ret


If we rewrite the example to avoid int_ptr:

int* f2(int** x) {
int** max = x;
for (int i =0 ; i < 5; ++ i) {
++ x;
if (**max < **x) {
max = x;
}
}
return *max;
}

Then there'll be less memory accesses in a loop:
f2(int**):
  mov rax, QWORD PTR [rdi] ; <=== Not in a loop any more
  lea rcx, [rdi+40]
.L8:
  mov rdx, QWORD PTR [rdi+8]
  add rdi, 8
  mov esi, DWORD PTR [rdx]
  cmp DWORD PTR [rax], esi
  cmovl rax, rdx
  cmp rcx, rdi
  jne .L8
  ret


Please improve the memory accesses for the first case

Godbolt playground: https://godbolt.org/z/CaGbT2

[Bug tree-optimization/92429] [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918

[avieira at gcc dot gnu.org]

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

--- Comment #2 from avieira at gcc dot gnu.org ---
So I had a look at this, the ICE occurs because 'vectorizable_condition' does
not know how to handle a constant cond_expr.

The reason this cond_expr is constant in the epilogue is because
'simplify_replace_tree' folds the replacement and the replacement in this case
is:

"_34 < 0" where "_34 = _33 * _33", and fold-const is able to assert that _34 is
therefore always positive or zero and can fold the check to false. The question
now is, why was the original 'cond_expr' that we copied over not folded? I
suspect its because of the -fno-tree-fre.

If we want this to work I suggest we either:
1) teach 'vectorizable_condition' to learn how to deal with constant
cond_expr's
2) change 'simplify_replace_tree' to optionally fold.

I don't like 2) much because this doesn't guarantee we don't fold elsewhere. 
If we want the vectorizer to accept loop code in sub-optimal format I suggest
we do 1).

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---

For the file testsuite/gcc.target/x86_64/abi/callabi/leaf-2.c,
with compiler flag -O3 -arch=knm, I get the same thing.

The revision at fault seem to be between 277650 and 277700.

[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
Forgot to mention: The task is considered completed when the necessary changes
have been merged upstream so that m68k will be part of GCC-11 and newer
releases.

[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gpubnames

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mark at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
The pubtables cause us to keep otherwise unused type DIEs:

  /* Also set the mark on nodes referenced from the pubname_table.  Enumerators
 are unusual in that they are pubnames that are the children of pubtypes.
 They should only be marked via their parent DW_TAG_enumeration_type die,
 not as roots in themselves.  */
  FOR_EACH_VEC_ELT (*pubname_table, i, pub)
if (pub->die->die_tag != DW_TAG_enumerator)
  prune_unused_types_mark (pub->die, 1);

and the pubtables itself are not set up to avoid duplicates.  I would guess
for code like Boost Spirit we have gazillions of fancy template instantiations
getting pubnames which blows memory use.  Not sure why -gsplit-dwarf requires
those or if in the modern C++ world the pubnames section are still useful?

size_of_pubnames () at output_pubnames computes 1331806040, "only" 1.3GB
(for generated DWARF), for the data structure in GCC itself we have
19136 entries in pubname_table and 90654 in the pubtype_table which
computes to 3.0GB data.

Overall this hardly sounds useful, esp. if pubname "creation" is done
before unused type pruning.  Not sure why we have add_pubname sprinkled
all over dwarf2out rather than gathering pubnames from a DIE tree walk
at some suitable point (after type pruning, possibly at dwarf2out_early_finish
time before breaking out comdats).

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
  if (y)
{
  gcc_assert (n == 3);
  std::swap (arg_type[1], arg_type[2]);
}


?

[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 linux dot ibm.com]

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 CC||iii at linux dot ibm.com,
   ||krebbel1 at de dot ibm.com

--- Comment #2 from Ilya Leoshkevich  ---
I'm looking into this.

[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gpubnames

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|Compiling Boost.Spirit.X3   |Compiling Boost.Spirit.X3
   |code uses exuberant amount  |code uses exuberant amount
   |of RAM with -gsplit-dwarf   |of RAM with -gpubnames

--- Comment #3 from Richard Biener  ---
-gpubnames (enabled by -gsplit-dwarf) is enough to provoke this.

[Bug c++/92446] [10, C++20] template argument deduction fails for custom non-type parameters

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
Summary|[C++20] template argument   |[10, C++20] template
   |deduction fails for custom  |argument deduction fails
   |non-type parameters |for custom non-type
   ||parameters

--- Comment #1 from Jakub Jelinek  ---
Used to be rejected as unsupported before r26578, then started to ICE, the ICE
got fixed in r267108, but it is still rejected afterwards.

[Bug c++/92438] [7/8/9/10 Regression] Function declaration parsed incorrectly with `-std=c++1z`

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|Function declaration parsed |[7/8/9/10 Regression]
   |incorrectly with|Function declaration parsed
   |`-std=c++1z`|incorrectly with
   ||`-std=c++1z`

--- Comment #1 from Jakub Jelinek  ---
This changed in r245314.  Although, __attribute__ is a GNU extension and as
such, it is the compiler and its documentation that determines what is correct
and is not correct, C++ standard doesn't cover it.

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

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-11
 CC||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Thomas Schwinge  ---
Same for 'libgomp.fortran/use_device_addr-2.f90', per several
 posts.


And indeed I'm seeing that, too, as already reported two weeks ago in
:

| --- a/libgomp/testsuite/libgomp.fortran/use_device_addr-1.f90
| +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-1.f90
| @@ -0,0 +1 @@
| +! { dg-do run }
| 
| --- a/libgomp/testsuite/libgomp.fortran/use_device_addr-2.f90
| +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-2.f90
| @@ -0,0 +1 @@
| +! { dg-do run }
| 
| On powerpc64le-unknown-linux-gnu without offloading, I'm seeing (only) the
'-O0' execution tests FAIL for both these, with 'STOP 1' message.


Tobias, please have a look at some point.

[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Anyway, the merge does not happen now on trunk for:

  false returned: 'operand_equal_p failed' in compare_operand at
/home/marxin/Programming/gcc/gcc/ipa-icf-gimple.c:306
  false returned: 'GIMPLE assignment operands are different' in
compare_gimple_assign at /home/marxin/Programming/gcc/gcc/ipa-icf-gimple.c:624
  different statement for code: GIMPLE_ASSIGN (compare_bb:471):
_1 = this_20(D)->x;
_1 = this_20(D)->x;
  false returned: '' in equals_private at
/home/marxin/Programming/gcc/gcc/ipa-icf.c:882
Equals called for: cross/314:cross/607 with result: false

[Bug ipa/92454] [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-11
  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, started with r278016.

[Bug ipa/92454] New: [10 Regression] ICE: Segmentation fault (in identify_dead_nodes)

[asolokha at gmx dot com]

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

Bug ID: 92454
   Summary: [10 Regression] ICE: Segmentation fault (in
identify_dead_nodes)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase reduced from gcc/testsuite/g++.dg/ipa/pr91969.C w/ -O3 --param
ipa-cp-eval-threshold=1:

% g++-10.0.0-alpha20191110 -O3 --param ipa-cp-eval-threshold=1 -c egqeoohx.C
during IPA pass: cp
egqeoohx.C:21:1: internal compiler error: Segmentation fault
   21 | }
  | ^
0xe81bf0 crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/toplev.c:329
0x7c5a4b identify_dead_nodes
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-cp.c:5017
0x7c5a4b ipcp_decision_stage
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-cp.c:5056
0x7c5a4b ipcp_driver
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-cp.c:5228
0x7c5a4b execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-cp.c:5319

[Bug demangler/92453] New: write buffer overflow in cplus_demangle()

[tim.ruehsen at gmx dot de]

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

Bug ID: 92453
   Summary: write buffer overflow in cplus_demangle()
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

The following code, compiled in libiberty/ causes a write buffer overflow in
cplus_demangle().

### repro1.c ###
#include "../include/demangle.h"
void main(void)
{
  cplus_demangle("a_dSO__dSO__d_d", DMGL_GNAT);
}
###

gcc repro1.c -o repro1 libiberty.a
valgrind ./repro1

==4906== Invalid write of size 1
==4906==at 0x10B763: ada_demangle (cplus-dem.c:477)
==4906==by 0x10B8CE: cplus_demangle (cplus-dem.c:195)
==4906==by 0x10B219: main (in /home/tim/src/binutils-gdb/libiberty/repro1)
==4906==  Address 0x4a4e057 is 0 bytes after a block of size 23 alloc'd
==4906==at 0x483577F: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4906==by 0x1184F0: xmalloc (xmalloc.c:147)
==4906==by 0x10B372: ada_demangle (cplus-dem.c:252)
==4906==by 0x10B8CE: cplus_demangle (cplus-dem.c:195)
==4906==by 0x10B219: main (in /home/tim/src/binutils-gdb/libiberty/repro1)

[Bug fortran/92142] CFI_setpointer corrupts descriptor

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Tobias Burnus  ---
FIXED on the trunk (GCC 10); I think it is neither a regression nor a serious
bug (for valid code), hence, it doesn't merit a GCC 9 backport. (But I am open
for reasons stating why a backport is useful.)

Hence, closed the bug as FIXED.

[Bug fortran/92142] CFI_setpointer corrupts descriptor

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Author: burnus
Date: Mon Nov 11 10:18:14 2019
New Revision: 278048

URL: https://gcc.gnu.org/viewcvs?rev=278048=gcc=rev
Log:
PR fortran/92142 - CFI_setpointer corrupts descriptor

2019-11-11  José Rui Faustino de Sousa  

libgfortran/
PR fortran/92142
* runtime/ISO_Fortran_binding.c (CFI_setpointer): Don't
override descriptor attribute; with -fcheck, check that
it is a pointer.

gcc/testsuite/
PR fortran/92142
* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c: New.
* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90: New.
* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c: Correct
upper bounds for case 0.


Added:
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/ISO_Fortran_binding.c

[Bug target/92448] Confusing using of TARGET_PREFER_AVX128

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On November 11, 2019 10:20:10 AM GMT+01:00, crazylht at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92448
>
>--- Comment #1 from Hongtao.liu  ---
>Also with TARGET_AVX128_OPTIMAL plus -mprefer-vector-width=256, 256-bit
>vectorization may be not generated since TARGET_AVX128_OPTIMAL will
>change
>vec_cost.
>
>
>/* Return cost of vector operation in MODE given that scalar version
>has
>   COST.  */
>
>static int
>ix86_vec_cost (machine_mode mode, int cost)
>{
>  if (!VECTOR_MODE_P (mode))
>return cost;
>
>  if (GET_MODE_BITSIZE (mode) == 128
>  && TARGET_SSE_SPLIT_REGS)
>return cost * 2;
>  if (GET_MODE_BITSIZE (mode) > 128
>  && TARGET_AVX128_OPTIMAL)
>return cost * GET_MODE_BITSIZE (mode) / 128;
>  return cost;
>}
>-

But this is because 128 optimal really means 256 bit ops are split into two 128
bit ones. The tuning is possibly poorly named. 

Richard.

[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

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
(In reply to Paul Thomas from comment #3)
> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90

On x86_64-pc-linux-gnu for '-m32' multilib testing, I'm seeing all execution
tests FAIL (no message given), and likewise for powerpc64le-unknown-linux-gnu,
but '-O0' only.

[Bug target/87833] [8/9/10 Regression] -fPIC isn't used to create offload shared library

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #11 from Thomas Schwinge  ---
.

[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
> > context 
> ...
> > context >
> 
> But whoever built the constructor with two differnt types did someting
> wrong.
> 

I've probably got it:

$ $14 = void
(gdb) p debug_tree(lhs_type->type_common.context)
  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x776750a8
fields 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality
pointer_to_this  reference_to_this
>
unsigned nonlocal DI ice9.ii:177:10 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context 
pointer_to_this >

$ $13 = void
(gdb) p debug_tree(rhs1_type->type_common.context)
  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77675738
fields 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality>
unsigned nonlocal DI ice5.ii:375:10 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context >

So one btConvexHullInternal type lives in a namespace VHACD and second one in
any. So the types have different ODR names..

[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92279
> 
> --- Comment #3 from Martin Liška  ---
> Created attachment 47208
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47208=edit
> Reproducer
> 
> So using a revision before it disappeared I see:
> 
> $ g++ -O2 -flto ice*.ii -c && gcc -O2 -flto *.i -c && g++ *.o -O2 -flto
> ...
> ice8.ii: In member function ‘MergeConvexHulls.constprop’:
> ice8.ii:883:6: error: non-trivial conversion in ‘constructor’
>   883 | void VHACD::MergeConvexHulls(const Parameters ) {
>   |  ^
> struct Point64
> struct Point64

This means that types does not satisfy useless_type_conversion_p.
I would single step through, but I think for record types it boils down
to comparing main variants for equality. 

The ODR type still may get unmerged which is valid (but unfortunate,
in this case it is unmerged because its TYPE_CONTEXT is unmerged.)
You may try to figure out why it is different:

> context 
...
> context >

But whoever built the constructor with two differnt types did someting
wrong.

Honza
> 
> and where canonical types are the same as the types:
> 
> (gdb) p lhs_type->type_common.canonical
> $3 = (tree) 0x77688dc8
> (gdb) p rhs1_type->type_common.canonical
> $4 = (tree) 0x77675e70
> 
> This seems wrong as the types have same ODR name and have equal declaration.
> @Honza: Can you please help me with that?
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gsplit-dwarf

[vanboxem.ruben at gmail dot com]

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

--- Comment #2 from Ruben Van Boxem  ---
I hit the submit button too early, I was still removing commandline options.
Indeed the -gsplit-dwarf option seems the culprit here.

I added it to decrease library link times (seems like it did at least something
in that directionà, guess I should remove it again to prevent OOM when
compiling until this is fixed.

[Bug target/92448] Confusing using of TARGET_PREFER_AVX128

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
Also with TARGET_AVX128_OPTIMAL plus -mprefer-vector-width=256, 256-bit
vectorization may be not generated since TARGET_AVX128_OPTIMAL will change
vec_cost.


/* Return cost of vector operation in MODE given that scalar version has
   COST.  */

static int
ix86_vec_cost (machine_mode mode, int cost)
{
  if (!VECTOR_MODE_P (mode))
return cost;

  if (GET_MODE_BITSIZE (mode) == 128
  && TARGET_SSE_SPLIT_REGS)
return cost * 2;
  if (GET_MODE_BITSIZE (mode) > 128
  && TARGET_AVX128_OPTIMAL)
return cost * GET_MODE_BITSIZE (mode) / 128;
  return cost;
}
-

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase that results in the warning also on x86_64-linux with -O2
-Wall:
struct S { void *p; struct S *q; };
void bar (int, ...);

void
foo (struct S *x, int n, int y)
{
  void *arg_type[3];
  for (int i = 0; i < n; i++)
{
  arg_type[i] = x->p;
  x = x->q;
}
  if (y)
{
  void *t = arg_type[2]; arg_type[2] = arg_type[1]; arg_type[1] = t;
}
  switch (n)
{
case 0: bar (0); break;
case 1: bar (1, arg_type[0]); break;
case 2: bar (2, arg_type[0], arg_type[1]); break;
case 3: bar (3, arg_type[0], arg_type[1], arg_type[2]); break;
}
}

Using if (n == 3 && y) makes the warning go away.
The compiler indeed doesn't know if y implies n == 3, although the caller
guarantees it.

So, we could do:
--- gcc/config/rs6000/rs6000-c.c.jj 2019-08-27 12:26:30.115019661 +0200
+++ gcc/config/rs6000/rs6000-c.c2019-11-11 10:12:00.954282097 +0100
@@ -6076,13 +6076,13 @@ altivec_build_resolved_builtin (tree *ar
  condition (LT vs. EQ, which is recognizable by bit 1 of the first
  argument) is reversed.  Patch the arguments here before building
  the resolved CALL_EXPR.  */
-  if (desc->code == ALTIVEC_BUILTIN_VEC_VCMPGE_P
+  if (n == 3
+  && desc->code == ALTIVEC_BUILTIN_VEC_VCMPGE_P
   && desc->overloaded_code != ALTIVEC_BUILTIN_VCMPGEFP_P
   && desc->overloaded_code != VSX_BUILTIN_XVCMPGEDP_P)
 {
-  tree t;
-  t = args[2], args[2] = args[1], args[1] = t;
-  t = arg_type[2], arg_type[2] = arg_type[1], arg_type[1] = t;
+  std::swap (args[1], args[2]);
+  std::swap (arg_type[1], arg_type[2]);

   args[0] = fold_build2 (BIT_XOR_EXPR, TREE_TYPE (args[0]), args[0],
 build_int_cst (NULL_TREE, 2));
to make it clear to the compiler that VCMPGE_P has 3 arguments and that it is
actually safe to use all of them, or of course we could clear arg_type first.

I don't find the may be used uninitialized warning wrong (at least not
completely) when the compiler sees a possible code path where it is
uninitialized (desc->code == ALTIVEC_BULTIN_VEC_VCMPGE_P with n < 3).

[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 47208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47208=edit
Reproducer

So using a revision before it disappeared I see:

$ g++ -O2 -flto ice*.ii -c && gcc -O2 -flto *.i -c && g++ *.o -O2 -flto
...
ice8.ii: In member function ‘MergeConvexHulls.constprop’:
ice8.ii:883:6: error: non-trivial conversion in ‘constructor’
  883 | void VHACD::MergeConvexHulls(const Parameters ) {
  |  ^
struct Point64
struct Point64
# .MEM_220 = VDEF <.MEM_219>
t ={v} {CLOBBER};
during GIMPLE pass: fixup_cfg
ice8.ii:883:6: internal compiler error: verify_gimple failed
0xcf1b21 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5427
0xbcf6bf execute_function_todo
../../gcc/passes.c:1983
0xbd046e execute_todo
../../gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Where the types are following:

$ (gdb) p debug_tree(lhs_type)
  constant 192>
unit-size  constant 24>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77688dc8
fields 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77879738 precision:64 min  max >
nonlocal DI ice9.ii:58:11 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
nonlocal DI ice9.ii:59:11 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
context 
pointer_to_this >
$1 = void
(gdb) p debug_tree(rhs1_type)
  constant 192>
unit-size  constant 24>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77675e70
fields 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77879738 precision:64 min  max >
nonlocal DI ice5.ii:264:11 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
nonlocal DI ice5.ii:265:11 size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
context >

and where canonical types are the same as the types:

(gdb) p lhs_type->type_common.canonical
$3 = (tree) 0x77688dc8
(gdb) p rhs1_type->type_common.canonical
$4 = (tree) 0x77675e70

This seems wrong as the types have same ODR name and have equal declaration.
@Honza: Can you please help me with that?

[Bug c/92428] Crash on conflicting types

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
It's likely an invalid code:

$ clang pr92428.c
pr92428.c:4:5: error: conflicting types for 'foo'
Foo foo(void){ return 0; }
^
pr92428.c:3:10: note: previous declaration is here
enum Foo foo(void);
 ^
1 error generated.

ICC says:

(1): warning #102: forward declaration of enum type is nonstandard

  enum Foo;

   ^



(2): error: invalid redeclaration of type name "Foo" (declared at line
1)

  typedef unsigned Foo;

   ^



(4): error: cannot overload functions distinguished by return type
alone

  Foo foo(void){ return 0; }

  ^



compilation aborted for  (code 2)

Compiler returned: 2

[Bug ipa/92421] [10 Regression] ICE in inline_small_functions, at ipa-inline.c:2001 since r277759

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||9.2.0
   Keywords|needs-reduction |ice-on-valid-code
   Last reconfirmed||2019-11-11
  Component|c++ |ipa
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|[10 Regression] ice in  |[10 Regression] ICE in
   |inline_small_functions, at  |inline_small_functions, at
   |ipa-inline.c:2001   |ipa-inline.c:2001 since
   ||r277759
  Known to fail||10.0

--- Comment #5 from Martin Liška  ---
Confirmed, started with r277759.