[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can confirm the issue with ASAN:

==10808==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xaaf536f0 at pc 0x01cc3bdc bp 0xcfc5bb40 sp 0xcfc5bb58
READ of size 8 at 0xaaf536f0 thread T0
#0 0x1cc3bd8 in regstat_bb_compute_calls_crossed ../../gcc/regstat.c:327
#1 0x1cc43dc in regstat_compute_calls_crossed() ../../gcc/regstat.c:379
#2 0x3d89080 in sched_init() ../../gcc/haifa-sched.c:7335
#3 0x3d891cc in haifa_sched_init() ../../gcc/haifa-sched.c:7352
#4 0x1de31a8 in schedule_insns() ../../gcc/sched-rgn.c:3514
#5 0x1de5508 in rest_of_handle_sched2 ../../gcc/sched-rgn.c:3746
#6 0x1de5954 in execute ../../gcc/sched-rgn.c:3882
#7 0x1b8b500 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2494
#8 0x1b8be8c in execute_pass_list_1 ../../gcc/passes.c:2580
#9 0x1b8bf10 in execute_pass_list_1 ../../gcc/passes.c:2581
#10 0x1b8bf10 in execute_pass_list_1 ../../gcc/passes.c:2581
#11 0x1b8bfcc in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2591
#12 0xe9bb6c in cgraph_node::expand() ../../gcc/cgraphunit.c:2194
#13 0xe9cda4 in expand_all_functions ../../gcc/cgraphunit.c:2332
#14 0xe9f684 in symbol_table::compile() ../../gcc/cgraphunit.c:2688
#15 0xea0198 in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868
#16 0x1f6a6f4 in compile_file ../../gcc/toplev.c:481
#17 0x1f74fd4 in do_compile ../../gcc/toplev.c:2166
#18 0x1f75a1c in toplev::main(int, char**) ../../gcc/toplev.c:2301
#19 0x407f270 in main ../../gcc/main.c:39
#20 0xaea6a3e8 in __libc_start_main (/lib64/libc.so.6+0x243e8)
#21 0x87c324  (/home/marxin/Programming/gcc/objdir/gcc/cc1+0x87c324)

0xaaf536f0 is located 0 bytes to the right of 240-byte region
[0xaaf53600,0xaaf536f0)
allocated by thread T0 here:
#0 0xaeeb9918 in malloc (/usr/lib64/libasan.so.5+0xe8918)
#1 0x42a95bc in xrealloc ../../libiberty/xmalloc.c:177
#2 0xf26e1c in df_grow_insn_info() ../../gcc/df-scan.c:544
#3 0xf242bc in df_scan_alloc(bitmap_head*) ../../gcc/df-scan.c:262
#4 0x177e470 in do_reload ../../gcc/ira.c:5558
#5 0x177eeb0 in execute ../../gcc/ira.c:5681
#6 0x1b8b500 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2494
#7 0x1b8be8c in execute_pass_list_1 ../../gcc/passes.c:2580
#8 0x1b8bf10 in execute_pass_list_1 ../../gcc/passes.c:2581
#9 0x1b8bfcc in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2591
#10 0xe9bb6c in cgraph_node::expand() ../../gcc/cgraphunit.c:2194
#11 0xe9cda4 in expand_all_functions ../../gcc/cgraphunit.c:2332
#12 0xe9f684 in symbol_table::compile() ../../gcc/cgraphunit.c:2688
#13 0xea0198 in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868
#14 0x1f6a6f4 in compile_file ../../gcc/toplev.c:481
#15 0x1f74fd4 in do_compile ../../gcc/toplev.c:2166
#16 0x1f75a1c in toplev::main(int, char**) ../../gcc/toplev.c:2301
#17 0x407f270 in main ../../gcc/main.c:39
#18 0xaea6a3e8 in __libc_start_main (/lib64/libc.so.6+0x243e8)
#19 0x87c324  (/home/marxin/Programming/gcc/objdir/gcc/cc1+0x87c324)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../gcc/regstat.c:327 in
regstat_bb_compute_calls_crossed
Shadow bytes around the buggy address:
  0x200ff55ea680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
  0x200ff55ea690: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x200ff55ea6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ff55ea6b0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
  0x200ff55ea6c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x200ff55ea6d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa
  0x200ff55ea6e0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x200ff55ea6f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ff55ea700: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x200ff55ea710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ff55ea720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
 

[Bug tree-optimization/92401] [10 Regression] ICE in fold_ternary_loc, at fold-const.c:11698

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Indeed, previously we didn't call resimplify on the CTOR because it has
TREE_CODE_LENGTH zero.  So I guess your patch is OK, but

+ && TREE_CODE_LENGTH (code) == 1)

here code should be res_op->code (in other places, too)?

Thanks.

Sorry for not looking earlier...

[Bug target/92132] new test case gcc.dg/vect/vect-cond-reduc-4.c fails with its introduction in r277067

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #5 from Kewen Lin  ---
Fixed on trunk.

[Bug target/92132] new test case gcc.dg/vect/vect-cond-reduc-4.c fails with its introduction in r277067

[linkw at gcc dot gnu.org]

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

--- Comment #4 from Kewen Lin  ---
Author: linkw
Date: Fri Nov  8 07:37:07 2019
New Revision: 277947

URL: https://gcc.gnu.org/viewcvs?rev=277947&root=gcc&view=rev
Log:
  [rs6000]Fix PR92132 by adding vec_cmp and vcond_mask supports

  To support full condition reduction vectorization, we have to define
  vec_cmp* and vcond_mask_*.  This patch is to add related expands.
  Also add the missing vector fp comparison RTL pattern supports
  like: ungt, unge, unlt, unle, ne, lt and le.

gcc/ChangeLog

2019-11-08  Kewen Lin  

PR target/92132
* config/rs6000/predicates.md
(signed_or_equality_comparison_operator): New predicate.
(unsigned_or_equality_comparison_operator): Likewise.
* config/rs6000/rs6000.md (one_cmpl2): Remove expand.
(one_cmpl3_internal): Rename to one_cmpl2.
* config/rs6000/vector.md
(vcond_mask_ for VEC_I and VEC_I): New expand.
(vec_cmp for VEC_I and VEC_I): Likewise.
(vec_cmpu for VEC_I and VEC_I): Likewise.
(vcond_mask_ for VEC_F): New expand for float
vector modes and same-size integer vector modes.
(vec_cmp for VEC_F): Likewise.
(vector_lt for VEC_F): New expand.
(vector_le for VEC_F): Likewise.
(vector_ne for VEC_F): Likewise.
(vector_unge for VEC_F): Likewise.
(vector_ungt for VEC_F): Likewise.
(vector_unle for VEC_F): Likewise.
(vector_unlt for VEC_F): Likewise.
(vector_uneq): Expose name.
(vector_ltgt): Likewise.
(vector_unordered): Likewise.
(vector_ordered): Likewise.

gcc/testsuite/ChangeLog

2019-11-08  Kewen Lin  

PR target/92132
* gcc.target/powerpc/pr92132-fp-1.c: New test.
* gcc.target/powerpc/pr92132-fp-2.c: New test.
* gcc.target/powerpc/pr92132-int-1.c: New test.
* gcc.target/powerpc/pr92132-int-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr92132-fp-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr92132-fp-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr92132-int-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr92132-int-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/vector.md
trunk/gcc/testsuite/ChangeLog

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
It's fixed now, thanks.

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
> 
> I have to leave the office now but I am testing the attached fix on an
> x86_64 - I have lost connection to the i686 I was using (gcc45).

I would recommend here to use your machine and set up a KVM where you can
install i686 openSUSE. It's likely much faster machine that we have in compile
farm ;)

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
I just noticed this bug. Since I implemented STREAM I/O in the first place, I
wiil study this a bit and get back to you. I have experimented with the code
and I think something is wrong.

[Bug c++/91388] -Wreturn-type "no return statement" warning in function that is already ill-formed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> That's for C and this is very specifically about C++ (as I'm attempting to
> suppress duplicate errors after manually diagnosing ill-formed
> instantiations of a template, via type traits and if-constexpr ... none of
> which exist in C :-)
> 
> Definitely appropriate for the "See Also" field though, thanks.

OK, confirming this as a separate bug then

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

[luoxhu at cn dot ibm.com]

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

--- Comment #3 from Xiong Hu XS Luo  ---
Power8 BE generates:
L.bar:
.LFB1:
.cfi_startproc
mtvsrd 0,4
mtvsrd 1,5
xxpermdi 12,0,1,0
xxlnor 0,12,12
stxvd2x 0,0,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE1:


and source code is below for all:
void
bar (__int128_t *dst, __int128_t src)
{
 *dst =  ~src;
}

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

[luoxhu at cn dot ibm.com]

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

Xiong Hu XS Luo  changed:

   What|Removed |Added

 CC||luoxhu at cn dot ibm.com

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

Checked the test result history:
For Power9, it is failed since r268152 of Jan 22, 2019. 
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg02232.html.
For Power 7, it starts to fail since r267319 of Dec 21, 2018.
https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02500.html

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

+;; Peepholes to catch loads and stores for TImode if TImode landed in
+;; GPR registers on a little endian system.
+(define_peephole2
+  [(set (match_operand:VSX_TI 0 "int_reg_operand")
+   (rotate:VSX_TI (match_operand:VSX_TI 1 "memory_operand")
+  (const_int 64)))
+   (set (match_operand:VSX_TI 2 "int_reg_operand")
+   (rotate:VSX_TI (match_dup 0)
+  (const_int 64)))]
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && TARGET_VSX_TIMODE && !TARGET_P9_VECTOR
+   && (rtx_equal_p (operands[0], operands[2])
+   || peep2_reg_dead_p (2, operands[0]))"
+   [(set (match_dup 2) (match_dup 1))])


I am not sure these failures are leaved for won't fix or need update the vsx.md
to generate better code?

On Power9, the expected code is:
0020 :
 20:   f8 20 84 7c not r4,r4
 24:   f8 28 a5 7c not r5,r5
 28:   00 00 83 f8 std r4,0(r3)
 2c:   08 00 a3 f8 std r5,8(r3)
 30:   20 00 80 4e blr

But actual code is:
0020 :
 20:   66 23 05 7c mtvsrdd vs0,r5,r4
 24:   10 05 00 f0 xxlnor  vs0,vs0,vs0
 28:   05 00 03 f4 stxvvs0,0(r3)
 2c:   20 00 80 4e blr

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[egallager at gcc dot gnu.org]

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

--- Comment #20 from Eric Gallager  ---
(In reply to Martin Sebor from comment #19)
> That's a valid concern.  Issuing a warning (either at the same time as or in
> lieu of the folding) would be a way to detect and prevent these kinds of
> problems.  Exposing it to enough code (like in a whole distro rebuild) would
> give us a pretty good idea about what the appropriate defaults ought to be.

How exactly is this different from the warning discussed in bug 81453? It seems
awfully similar to me...

[Bug target/92295] Inefficient vector constructor

[liuhongt at gcc dot gnu.org]

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

--- Comment #2 from liuhongt at gcc dot gnu.org ---
Author: liuhongt
Date: Fri Nov  8 05:34:25 2019
New Revision: 277946

URL: https://gcc.gnu.org/viewcvs?rev=277946&root=gcc&view=rev
Log:
Fix inefficient vector constructor.

Changelog
gcc/
PR target/92295
* config/i386/i386-expand.c (ix86_expand_vector_init_concat)
Enhance ix86_expand_vector_init_concat.

gcc/testsuite
* gcc.target/i386/pr92295.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92295.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-expand.c
trunk/gcc/testsuite/ChangeLog

[Bug c/87569] defining type in ‘sizeof’ expression is invalid in C++ references wrong operator

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug debug/92417] New: gcc generates wrong debug information at -O2

[qrzhang at gatech dot edu]

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

Bug ID: 92417
   Summary: gcc generates wrong debug information at -O2
   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 happens at O2 only. "-O1" and "-O3" works fine. It's a recent regression
since "gcc-9 -O2" also works.



The expected value of l_1162[0][0][0] should be 61344 or opt-out. However, with
"-O2", gdb outputs "l_1162[0][0][0]=3".



$ gcc-trunk -v
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191107 (experimental) [trunk revision 277920] (GCC)

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

Breakpoint 1, n () at abc.c:23
23  if (b)  // optimize_me_not()
$1 = 61344

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

Breakpoint 1, n () at abc.c:23
23  if (b)  // optimize_me_not()
$1 = 3



$ cat abc.c
int a, d, e, f, h, l;
short b, g, i, m;
char c;
void n() {
  char o;
  int p = 0, j, k;
  int q[70] = {0};
  for (; i <= 1; i++) {
unsigned short l_1162[6][2][2];
l = 0;
for (; l < 6; l++) {
  j = 0;
  for (; j < 2; j++) {
k = 0;
for (; k < 2; k++)
  l_1162[l][j][k] = 61344;
  }
}
for (; f <= 1; f++)
  if (d)
for (; p >= 0; p--)
  d = q[f];
if (b)  // optimize_me_not()
  h = l_1162[4][1][0];
for (; e; e++)
  g = l_1162[5][0][1] <= o;
c = a ? c : 0;
q[1] = m;
  }
}
int main() {
  n();
  printf("%X\n");
}



$ cat cmds
b abc.c:23
r
p l_1162[0][0][0]
kill
q

[Bug tree-optimization/87313] attribute malloc not used for alias analysis when it could be

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91582

--- Comment #3 from Martin Sebor  ---
This limitation is also getting in the way of detecting out-of-bounds accesses
by string functions to dynamically allocated arrays, including VLAs.

With the patch for pr91582 I'm testing, GCC detects the invalid access in
functions f0() and f3() below, but because of this limitation, it doesn't
detect the same bug in functions f1() or f2() (when the loop is unrolled). 
That's because __builtin_alloca_with_align is neither declared with attribute
malloc nor recognized as "special" like malloc in that the pointer it returns
doesn't alias any other pointer in the program.

$ cat c.c && gcc -O2 -S -Wall -Wextra c.c
$ cat c.c && /build/gcc-91582/gcc/xgcc -B /build/gcc-91582/gcc -O2 -S -Wall
-Wextra c.c
void sink (void*);

void f0 (unsigned n)
{
  if (n > 4)
n = 4;

  char a[n];
  a[4] = 0;   // warning (good)
  sink (a);
}

void f1 (unsigned n)
{
  if (n > 4)
n = 4;

  char a[n];
  a[3] = 0;
  a[4] = 0;   // missing warning
  sink (a);
}

void f2 (unsigned n)
{
  if (n > 4)
n = 4;

  char a[n];
  int i = 0;
  do {
a[i] = i;   // missing warning when loop is unrolled
  } while (i++ != 4);
  sink (a);
}

void f3 (unsigned n)
{
  if (n > 4)
n = 4;

  char *p = (char*)__builtin_malloc (n);
  int i = 0;
  do {
p[i] = i;   // warning (good)
  } while (i++ != 4);
  sink (p);
}
c.c: In function ‘f0’:
c.c:9:8: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
9 |   a[4] = 0;   // warning (good)
  |   ~^~~
c.c:8:8: note: at offset 4 to an object with size at most 4 declared here
8 |   char a[n];
  |^
c.c: In function ‘f3’:
c.c:45:10: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   45 | p[i] = i;   // warning (good)
  | ~^~~
c.c:42:20: note: at offset 4 to an object with size at most 4 allocated by
‘__builtin_malloc’ here
   42 |   char *p = (char*)__builtin_malloc (n);
  |^~~~

[Bug middle-end/87731] Detection of mismatched alloc/free pairs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91582

--- Comment #6 from Martin Sebor  ---
See also pr91582 for a related project (the detection could be done in the
strlen pass that's being enhanced to track dynamic memory allocation, or it
could be done in a separate pass of its own, at the cost of duplicating some
functionality).

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
This bug means we now have to leave out a part of libsanitizer that uses
blocks:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00262.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00268.html

[Bug middle-end/87736] New attributes to mark custom alloc/free function pair

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91582

--- Comment #3 from Martin Sebor  ---
The solution I'm working on for pr91582 adds tracking of dynamically allocated
objects to the strlen pass (including alloca, VLAs, and user-defined allocation
functions declared with attribute alloc_size).  A natural extension of the
project is to detect accesses to deallocated objects.  A new function attribute
such as "free" to parallel attributes malloc and alloca_size will be required
to detect such deallocation by user-defined functions (the attribute will need
to apply to specific function arguments to make it possible to use it with
functions taking two more pointers).  I expect to submit my patch for pr91582
in time for GCC 10 but the new attribute will most likely have to wait until
GCC 11.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #29 from Rich Felker  ---
For reference, here are the affected functions in musl (fmax, fmaxf, fmin,
fminf):

https://git.musl-libc.org/cgit/musl/tree/src/math/powerpc64?id=v1.1.24

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #28 from Segher Boessenkool  ---
(In reply to A. Wilcox (awilfox) from comment #25)
> GCC typically announces deprecations for publicly-documented interfaces
> being removed versions ahead of time, and I'm surprised that wasn't followed
> here.

This wasn't meant to be documented, and it was not expected that anyone uses
it.
The more basic constraints ("wa", "d", "v") are easier to use and more correct.

> Then a discussion could have taken place on if the deprecated
> interfaces were still needed, ways to refactor to make it less of a
> maintenance burden in the meantime, ways to move forward without breaking
> existing code, and so on.

See above.  Those work in older compilers, too.

> It is disturbing to me that "fixing up historical mistakes" appears to mean
> that GCC developers can just yank out public interfaces with no notice.

> > supports old POWER, never mind that no one ever uses that any more.
> 
> I'm still using 970s daily.  IBM's ppc64 kernel CI got a "new" G5 last year.
> ZTE (Chinese telecom) uses POWER6.  Older POWER is definitely still used.

Old POWER is RIOS1.  From the year 1990.  (And RIOS2, from 1993).  It has a
different assembler syntax and somewhat different semantics than the later
PowerPC.  All machines you name are PowerPC.  Which later was rebaptised to
"POWER Architecture" or "Power ISA" etc.  "Old POWER" some of us use to refer
to the ancient systems.

[ "ws" needs at least a Power7, btw. ]

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #27 from Rich Felker  ---
> Have I already mentioned that if any program "in the wild" will use "ws" with
> GCC 10, then of course we can add an alias (to "wa") for it?  No program 
> should
> use "ws" in inline assembler, ever, but if some programs cannot fix that, we
> can fix it for them, sure.

I would very much appreciate it if the "ws" (and "ww") aliases could be added.
I hope you can appreciate how clang users would respond when linked to this BZ
ticket after musl broke for them, if we just changed it to use "wa". Even if
(rather, "even though" - I believe you that they're wrong) clang is wrong to
reject "wa" here, it would come across to them as completely unreasonable that
we broke the constraints that previously worked fine on all compilers.

I'm not sure if you would rather us have to do some sort of configure-time
check here. Maybe one can be devised that doesn't risk wrong semantics when we
can only measure whether the compiler accepts it, not whether it generates the
wrong code, but I don't know how (and what's to guarantee that someday someone
won't, seeing the combinations "ws" and "ww" as unused, invent a new meaning
for one of them?), and even if it is possible, I would find such a configure
check to be really ugly long-term maintenance cost in relation to a simple
alias to preserve the long-documented behavior.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #26 from Segher Boessenkool  ---
(In reply to Rich Felker from comment #24)
> > Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
> 
> Nothing is broken on our side here. We are using the documented
> functionality from gcc 9 going all the way back to whatever version first
> added this stuff.

Yes, as I told you before, that should never have been documented like that.
As powerpc maintainer, let me apologise for that.

> > I will not add back all constraints I removed.  I *cannot* add back many of
> > those constraints, not with similar semantics anyway.
> >
> > Oh, and there were 24 I removed for 10, if I count correctly.  All were
> > internal.  That they were documented was a bug;
> 
> How many others were actually-internal

All of them.  All of them are either "wa" (or "v" or "d" in some cases) if
you have certain compiler options (mainly -mcpu=), and terminate the compiler
if you do not have those options. (Or they generate incorrect assembler code
in the really unfortunate cases).

Internally to the compiler you can have multiple alternatives for different
cpus (or whatever), with different assembler templates.  In inline assembler,
you can not.

> vs having this ridiculous excuse of
> "it was a bug that we documented it so we can retroactively blame
> programmers for using it rather than taking responsibility for the contract
> we documented"?

I am not blaming you.  I am telling you that you shouldn't use "ws", you
should just use "wa".  That is the correct constraint to use here, and always
was.  Again, sorry for the misleading documentation.

I am also asking you to -- after that code change -- reconsider whether "ws"
is still useful for you, when compiling with GCC 10.

> Are any of the "*cannot* add back" ones things that were
> documented?

Yes, all of them made their way into the manual.

> If not, then you can add back all the ones that were documented
> with no harm done to anything.

Adding them back cannot be done.  But I can make aliases for the ones still
likely to be used in the wild with GCC 10, so they behave exactly like "wa".

> which seems to be your desire to break things
> on a whim.

I wanted to remove 24 useless, dangerous, problematical constraints, which
for all intents and purposes were completely internal, and could not be
used for any purpose where the more basic constraints could not.  I did not
expect anyone to ever have used them.


> Users generally do not use
> unstable GCC; my understanding is that it's not recommended to do so.

But developers are encouraged to, esp. developers for things that exercise
the compiler more than average code.

> > The point is that we will never get to a good state if we cannot fix
> > up any historical mistakes.
> 
> That's an extreme exaggeration.

It is not.  What do you think I have done the last N years?

Did I remove rios support and SPE and 750 PS and xilinx float etc. etc. etc.
just to annoy the one remaining user of those?  What about all the refactoring
and rewriting and replastering and whatnot, was that just done to destabilise
things?

The Power backend is old.  It has a lot of history.  It is called "rs6000"
even, internally anyway, not even PowerPC, which will be 30 years old itself
in just a few short years.  At some point we need to shed some of that
baggage, because it has become an encumbrance.  That "ws" was introduced just
six years ago (with somewhat different semantics, btw!) doesn't change this
much.


Have I already mentioned that if any program "in the wild" will use "ws" with
GCC 10, then of course we can add an alias (to "wa") for it?  No program should
use "ws" in inline assembler, ever, but if some programs cannot fix that, we
can fix it for them, sure.

[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner  ---
Author: bergner
Date: Fri Nov  8 00:34:09 2019
New Revision: 277942

URL: https://gcc.gnu.org/viewcvs?rev=277942&root=gcc&view=rev
Log:
Add another test case to exercise the previous MODE_PARTIAL_INT change.

gcc/testsuite/
PR other/92090
* gcc.target/powerpc/pr92090-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr92090-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/92416] New: ICE with spaceship and vector types

[redi at gcc dot gnu.org]

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

Bug ID: 92416
   Summary: ICE with spaceship and vector types
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

constexpr auto
cmp()
{
  [[gnu::vector_size(4)]] int i = { };
  return i <=> i;
}

static_assert( cmp() );

With recent trunk and -std=gnu+2a this crashes:

ice.cc: In function 'constexpr auto cmp()':
ice.cc:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xf802af crash_signal
/home/jwakely/src/gcc/gcc/gcc/toplev.c:329
0x60cd8f tree_check(tree_node const*, char const*, int, char const*, tree_code)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3522
0x60cd8f id_equal(tree_node const*, char const*)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3810
0x60cd8f is_cat
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1000
0x9409b2 cat_tag_for
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1011
0x9409b2 genericize_spaceship(tree_node*, tree_node*, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1048
0x8ae59a genericize_spaceship
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:1155
0x8ae59a cp_genericize_r
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:1589
0x124501b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:11946
0x124572d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12276
0x1245690 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12051
0x8aee2b cp_genericize_r
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:1398
0x124501b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:11946
0x8ab0c8 cp_genericize_tree
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:1706
0x8ab362 cp_genericize(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:1855
0x8e9f3a finish_function(bool)
/home/jwakely/src/gcc/gcc/gcc/cp/decl.c:16957
0x995bcf cp_parser_function_definition_after_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28564
0x9969d3 cp_parser_function_definition_from_specifiers_and_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28477
0x9969d3 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20495
0x976482 cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Sadly, neither of those regressions is fixed on i686-linux.
Still the same
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/cast-function-1.c:49:1: error:
non-trivial conversion in 'ssa_name'
struct str_t
int
{} = arg_32;
during GIMPLE pass: einline
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/cast-function-1.c:49:1: internal
compiler error: verify_gimple failed
0x8ab2e63 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5427
0x8986378 execute_function_todo
../../gcc/passes.c:1983
0x89872ae do_per_function
../../gcc/passes.c:1638
0x89872ae execute_todo
../../gcc/passes.c:2037
for the cast-function-1.c one.
But, you should be able to test it easily even on x86_64-linux,
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
dg.exp=cast-function-1.c'
still FAILs there too.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[awilfox at adelielinux dot org]

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

A. Wilcox (awilfox)  changed:

   What|Removed |Added

 CC||awilfox at adelielinux dot org

--- Comment #25 from A. Wilcox (awilfox)  ---
(In reply to rsand...@gcc.gnu.org from comment #21)
> But it was a mistake made by the GCC developers.  Once something
> is documented publicly, we shouldn't just remove it without
> warning unless there's no realistic alternative.  And it sounds
> from what Jakub says like it's simple to keep this working.

Thank you for being the voice of reason :)  There is no reason to break a
public interface when it is a one-liner to fix.  At the *very* least, it would
allow more time for discussion with musl and LLVM developers and other
interested parties.


(In reply to Segher Boessenkool from comment #23)
> I will not add back all constraints I removed.

Nobody here has asked for all constraints to be re-added.  Only one, which was
publicly documented for years, and used in real code.


> The point is that we will never get to a good state if we cannot fix
> up any historical mistakes.

GCC typically announces deprecations for publicly-documented interfaces being
removed versions ahead of time, and I'm surprised that wasn't followed here. 
Then a discussion could have taken place on if the deprecated interfaces were
still needed, ways to refactor to make it less of a maintenance burden in the
meantime, ways to move forward without breaking existing code, and so on.

It is disturbing to me that "fixing up historical mistakes" appears to mean
that GCC developers can just yank out public interfaces with no notice.  I do
not think this is what the community wants in a system compiler.


> supports old POWER, never mind that no one ever uses that any more.

I'm still using 970s daily.  IBM's ppc64 kernel CI got a "new" G5 last year. 
ZTE (Chinese telecom) uses POWER6.  Older POWER is definitely still used.

[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

  Known to work||7.0
  Known to fail||10.0, 8.0, 9.0

--- Comment #14 from Peter Bergner  ---
(In reply to Peter Bergner from comment #13)
> Added:
> trunk/gcc/testsuite/gcc.target/powerpc/pr92090.c

This reduced test case does not FAIL on GCC 8 or GCC 9.  Using creduce using
GCC 9 with the original testsuite test case, I created another reduced test
case and that does FAIL on both GCC 8 and GCC 9.  My patch fixes the ICE on
both GCC versions, so I'm in the process of testing the backports.

None of the test cases FAIL using GCC 7.

[Bug testsuite/92415] New: new test case g++.dg/cpp2a/spaceship-scalar1-neg.C introduced in r277925 fails

[seurer at gcc dot gnu.org]

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

Bug ID: 92415
   Summary: new test case g++.dg/cpp2a/spaceship-scalar1-neg.C
introduced in r277925 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-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C  
 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=c++2a  -pedantic-errors -Wno-long-long   
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm  -o ./spaceship-scalar1-neg.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++2a -pedantic-errors -Wno-long-long
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./spaceship-scalar1-neg.exe
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C:
In function 'int main()':
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C:13:23:
error: invalid operands of types 'void (*)()' and 'void (*)()' to binary
'operator<=>'
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C:18:30:
error: invalid operands of types 'int main()::A::*' and 'int main()::A::*' to
binary 'operator<=>'
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C:23:30:
error: invalid operands of types 'void (main()::A::*)()' and 'void
(main()::A::*)()' to binary 'operator<=>'
compiler exited with status 1
PASS: g++.dg/cpp2a/spaceship-scalar1-neg.C  -std=c++2a  (test for errors, line
13)
PASS: g++.dg/cpp2a/spaceship-scalar1-neg.C  -std=c++2a  (test for errors, line
18)
PASS: g++.dg/cpp2a/spaceship-scalar1-neg.C  -std=c++2a  (test for errors, line
23)
PASS: g++.dg/cpp2a/spaceship-scalar1-neg.C  -std=c++2a (test for excess errors)
UNRESOLVED: g++.dg/cpp2a/spaceship-scalar1-neg.C  -std=c++2a compilation failed
to produce executable
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/dg.exp completed in 1
seconds

=== g++ Summary ===

# of expected passes4
# of unresolved testcases   1
# of unsupported tests  3

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #24 from Rich Felker  ---
> Sure, and I'll do that, *if there are users*, *after they fix their stuff*.

Nothing is broken on our side here. We are using the documented functionality
from gcc 9 going all the way back to whatever version first added this stuff.

> I will not add back all constraints I removed.  I *cannot* add back many of
> those constraints, not with similar semantics anyway.
>
> Oh, and there were 24 I removed for 10, if I count correctly.  All were
> internal.  That they were documented was a bug;

How many others were actually-internal vs having this ridiculous excuse of "it
was a bug that we documented it so we can retroactively blame programmers for
using it rather than taking responsibility for the contract we documented"? 
Are any of the "*cannot* add back" ones things that were documented? If not,
then you can add back all the ones that were documented with no harm done to
anything. If there really are technical reasons that some of the ones removed
are difficult to recreate, please say so. I would still strongly disagree with
the choice to make such a regression, but at least it would have some
reasonable motivation rather than the only motivation I've seen so far, which
seems to be your desire to break things on a whim.

> that one was actually used
> by any program was unexpected (and it took literally half a year before this
> was found out, or reported here at least).

At least "ws" and "ww" are used, for fmax, fmaxf, fmin, and fminf. The reason
it was not found for "literally half a year" is because the regression is not
present in any release. Users generally do not use unstable GCC; my
understanding is that it's not recommended to do so.

> The point is that we will never get to a good state if we cannot fix
> up any historical mistakes.

That's an extreme exaggeration. There is nothing holding back a "good state"
about having two aliases for "wa" to preserve documented historical behavior.

[Bug c++/92414] [10 Regression] internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/92414] [10 Regression] internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/92414] internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-07
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r276622.

[Bug c++/92414] New: internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009

[mpolacek at gcc dot gnu.org]

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

Bug ID: 92414
   Summary: internal compiler error: tree check: expected
constructor, have error_mark in
cxx_eval_store_expression, at cp/constexpr.c:4009
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct A { virtual void a(); };

struct B : A {
  constexpr B(int);
  constexpr ~B() { }
};

struct D : B {
  constexpr D() : B(42) { }
};

constexpr D d;

$ ./cc1plus -quiet ice.C -std=c++2a
ice.C:12:13:   in ‘constexpr’ expansion of ‘D()’
ice.C:9:23: error: ‘constexpr B::B(int)’ used before its definition
9 |   constexpr D() : B(42) { }
  |   ^
ice.C:12:13:   in ‘constexpr’ expansion of ‘((D*)(& d))->D::~D()’
ice.C:12:13: internal compiler error: tree check: expected constructor, have
error_mark in cxx_eval_store_expression, at cp/constexpr.c:4110
   12 | constexpr D d;
  | ^
0x18bb352 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/mpolacek/src/gcc/gcc/tree.c:9676
0x87f84f tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3267
0x8fa7c5 cxx_eval_store_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4110
0x8fdf7d cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5013
0x8ff174 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5380
0x8fe226 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5064
0x8fe226 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5064
0x8fbd44 cxx_eval_statement_list
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4505
0x8ffc82 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5508
0x8ffd01 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5512
0x8fbd44 cxx_eval_statement_list
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4505
0x8ffc82 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5508
0x8f17d4 cxx_eval_call_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:2072
0x8fd60c cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4924
0x90178c cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5868
0x9023c4 cxx_constant_dtor(tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6027
0x998cc3 cxx_maybe_build_cleanup(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl.c:17212
0x974ae7 expand_static_init
/home/mpolacek/src/gcc/gcc/cp/decl.c:8737
0x970763 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl.c:7783
0xa8ea3f cp_parser_init_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:20727
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/91370] Implement P1041R4 and P1139R2: Stronger Unicode requirements

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov  7 20:24:38 2019
New Revision: 277929

URL: https://gcc.gnu.org/viewcvs?rev=277929&root=gcc&view=rev
Log:
PR c++/91370 - Implement P1041R4 and P1139R2 - Stronger Unicode reqs
* charset.c (narrow_str_to_charconst): Add TYPE argument.  For
CPP_UTF8CHAR diagnose whenever number of chars is > 1, using
CPP_DL_ERROR instead of CPP_DL_WARNING.
(wide_str_to_charconst): For CPP_CHAR16 or CPP_CHAR32, use
CPP_DL_ERROR instead of CPP_DL_WARNING when multiple char16_t
or char32_t chars are needed.
(cpp_interpret_charconst): Adjust narrow_str_to_charconst caller.

* g++.dg/cpp1z/utf8-neg.C: Expect errors rather than -Wmultichar
warnings.
* g++.dg/ext/utf16-4.C: Expect errors rather than warnings.
* g++.dg/ext/utf32-4.C: Likewise.
* g++.dg/cpp2a/ucn2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/ucn2.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1z/utf8-neg.C
trunk/gcc/testsuite/g++.dg/ext/utf16-4.C
trunk/gcc/testsuite/g++.dg/ext/utf32-4.C
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #23 from Segher Boessenkool  ---
(In reply to rsand...@gcc.gnu.org from comment #21)
> > I am saying it is a mistake that GCC ever documented this for public
> > use.  Every use of "ws" in inline asm should be "wa".
> 
> But it was a mistake made by the GCC developers.  Once something
> is documented publicly, we shouldn't just remove it without
> warning unless there's no realistic alternative.  And it sounds
> from what Jakub says like it's simple to keep this working.

Sure, and I'll do that, *if there are users*, *after they fix their stuff*.

I will not add back all constraints I removed.  I *cannot* add back many of
those constraints, not with similar semantics anyway.

Oh, and there were 24 I removed for 10, if I count correctly.  All were
internal.  That they were documented was a bug; that one was actually used
by any program was unexpected (and it took literally half a year before this
was found out, or reported here at least).

> I also disagree that this is as common a problem as you're saying.
> Like Jakub says, there's long been a distinction between internal
> and public constraints.

Yeah, since 2006, and multiple ports still haven't caught up.

And only x86 documents the output modifiers so far, and that only
since 2014.

>  And for the most part, the public constraints
> for MIPS and AArch64 were chosen to be ones that we thought were useful
> and that we could continue to support.

Which is exactly what I plan to do for GCC 10.

The point is that we will never get to a good state if we cannot fix
up any historical mistakes.

> There's also precedent for defining compatibility constraints.

Sure, I know that.  That isn't the same thing as keeping all mistakes
around forever.

> The MIPS "v" constraint is only provided for asm compatibility,
> even though no internal patterns use it any more.

We have at least M N P es like that -- we don't delete them, because
someone *might* use them.  And we put back some output modifiers that
are used by some headers, and even the alternate syntax thing (so that
people can write inline asm that also supports old POWER, never mind
that no one ever uses that any more).

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Created attachment 47195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47195&action=edit
Hopefully the fix

I have to leave the office now but I am testing the attached fix on an x86_64 -
I have lost connection to the i686 I was using (gcc45).  If someone could test
this on an affected platform for me, that would be great.

[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner  ---
Author: bergner
Date: Thu Nov  7 18:48:45 2019
New Revision: 277928

URL: https://gcc.gnu.org/viewcvs?rev=277928&root=gcc&view=rev
Log:
Allow MODE_PARTIAL_INT modes for integer constant input operands.

gcc/
PR other/92090
* config/rs6000/predicates.md (input_operand): Allow MODE_PARTIAL_INT
modes for integer constants.

gcc/testsuite/
PR other/92090
* gcc.target/powerpc/pr92090.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr92090.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/92413] [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation

[dblaikie at gmail dot com]

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

David Blaikie  changed:

   What|Removed |Added

 CC||dblaikie at gmail dot com

--- Comment #1 from David Blaikie  ---
>From the LLVM bug, I believe this code is valid C++ but GCC produces an error
for it:

template  struct C {void foo();};
template struct C;
template  void C::foo() {
  static_assert(sizeof(int) == 1);
}

[Bug c++/92413] New: [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation

[i at maskray dot me]

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

Bug ID: 92413
   Summary: [temp.explicit] Explicit template instantiations
should not define member functions that are not
defined at the point of instantiation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

https://wg21.cmeerw.net/cwg/issue546

Change 17.8.2 [temp.explicit] paragraph 8 as follows:

An explicit instantiation definition that names a class template specialization
explicitly instantiates the class template specialization and is only an
explicit instantiation definition of members whose definition is
visible>that have been defined at the point of
instantiation.


template  struct C {void foo();};
template struct C;
template  void C::foo() {}


GCC<4.9 does not define C::foo(), while GCC>=4.9 defines C::foo()

I am not sure whether this example is non-conforming, but -Wall -Wextra
-pedantic gives no diagnostic. (clang 3.0~trunk does not define C::foo().
You may read the discussions at https://bugs.llvm.org/show_bug.cgi?id=43937)

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-07
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The otherwise untested change below allows the test case to be optimized as I
expect:

index fee4cc271cd..2af88f4dff3 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1415,9 +1415,12 @@ default_ref_may_alias_errno (ao_ref *ref)
   if (TYPE_UNSIGNED (TREE_TYPE (base))
   || TYPE_MODE (TREE_TYPE (base)) != TYPE_MODE (integer_type_node))
 return false;
-  /* The default implementation assumes an errno location
- declaration is never defined in the current compilation unit.  */
+  /* The default implementation assumes an errno location declaration
+ is never defined in the current compilation unit and be aliased
+ by a local or read-only variable.  */
   if (DECL_P (base)
+  && DECL_EXTERNAL (base)
+  && !TREE_READONLY (base)
   && !TREE_STATIC (base))
 return true;
   else if (TREE_CODE (base) == MEM_REF

[Bug other/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
Confirmed, at least on the i686, and mine.

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

[msebor at gcc dot gnu.org]

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

Bug ID: 92412
   Summary: excessive errno aliasing assumption defeats
optimization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC folds to false the test for a's contents in f() below but it doesn't do the
same in g().  It appears to be caused by the call to strlen which, when being
optimized by the strlen pass, triggers a call to GCC's
default_ref_may_alias_errno().  Although the default_ref_may_alias_errno()
function called to determine whether errno can alias a variable returns false
for static variables defined in the same translation unit it returns true for
local variables like a.

Other compilers (Clang and Visual C/C++) fold the tests in both functions to
false.

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.c
void* f (void)
{ 
  const char a[] = "123";

  void *p = __builtin_malloc (sizeof a);

  if (a[0] != '1' || a[1] != '2' || a[2] != '3' || a[3] != '\0')   // folded to
false
__builtin_abort ();

  return p;
}

void* g (void)
{
  const char a[] = "123";

  void *p = __builtin_malloc (__builtin_strlen (a) + 1);

  if (a[0] != '1' || a[1] != '2' || a[2] != '3' || a[3] != '\0')   // not
folded
__builtin_abort ();

  return p;
}


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

f ()
{
  void * p;

   [local count: 1073741824]:
  p_3 = __builtin_malloc (4); [tail call]
  return p_3;

}



;; Function g (g, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=1)

Removing basic block 8
Removing basic block 9
Removing basic block 10
Removing basic block 11
g ()
{
  void * p;
  const char a[4];
  char _3;
  char _4;
  char _5;
  char _6;

   [local count: 1073741824]:
  a = "123";
  p_10 = __builtin_malloc (4);
  _3 = a[0];
  if (_3 != 49)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 1073741824]:
  _4 = a[1];
  if (_4 != 50)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 1073741824]:
  _5 = a[2];
  if (_5 != 51)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 1073741824]:
  _6 = a[3];
  if (_6 != 0)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  return p_10;

}

[Bug c++/92411] New: conformance issue with reinterpret_cast in constant expressions

[Darrell.Wright at gmail dot com]

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

Bug ID: 92411
   Summary: conformance issue with reinterpret_cast in constant
expressions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Darrell.Wright at gmail dot com
  Target Milestone: ---

It looks like there is a regression in trunk(20171107 on CE) that allows
reinterpret_casts in constant expressions.
https://gcc.godbolt.org/z/m7Qytn


using size_t = decltype(sizeof(int));

constexpr char const * func( char const * ptr ) {
return reinterpret_cast( ptr );
}

static_assert( func( nullptr ) == nullptr );

template
constexpr char const * func2( char const (&s)[N] ) {
return reinterpret_cast( s );
}

static_assert( *func2( "Hello" ) == 'H' );

I think this should be ill formed with a diag according to the following links,
but it is allowed 
https://eel.is/c++draft/expr.const#4.15
https://eel.is/c++draft/dcl.pre#6

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #22 from Rich Felker  ---
And to be clear, pretty much all gcc versions from 3.4.6 to present, and all
clang/LLVM versions since they fixed some critical bugs (like -ffreestanding
not working, which was a show-stopper), are supported compilers for targets
they support. We do not drop support for some existing supported compilers
because the latest version made an incompatible change.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #20 from Rich Felker  ---
> After both musl and LLVM are fixed, if you then *still* feel you
> need "ws", then we can talk of course.  Deal?

No, it's not a deal. Your proposal is *breaking all currently-working versions*
of clang because GCC wants to remove a documented public interface. I don't
make users of one tool suffer because the maintainers of another tool broke
things. That would not be responsible maintenance on my part.

If GCC is committed to breaking this, I'll make a configure check to fallback
to the C implementation if "ws" does not work, and ship patches in
musl-cross-make to fix the GCC regression so that users who get the patch won't
be affected.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[rsandifo at gcc dot gnu.org]

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

--- Comment #21 from rsandifo at gcc dot gnu.org  
---
(In reply to Segher Boessenkool from comment #19)
> (In reply to Rich Felker from comment #16)
> > > Using "ws" in inline asm never made sense.  It was always the same as
> > > "wa", for all cases where either could be used in inline asm at all.
> > 
> > It made sense insomuch as it was documented and was the most
> > clearly-documented as matching the intended usage case, and still makes
> > sense in that the other widely-used compiler did not properly (according to
> > your interpretation) implement "wa", so that "ws" was the only constraint
> > that worked with both.
> 
> I am saying it is a mistake that GCC ever documented this for public
> use.  Every use of "ws" in inline asm should be "wa".

But it was a mistake made by the GCC developers.  Once something
is documented publicly, we shouldn't just remove it without
warning unless there's no realistic alternative.  And it sounds
from what Jakub says like it's simple to keep this working.

I also disagree that this is as common a problem as you're saying.
Like Jakub says, there's long been a distinction between internal
and public constraints.  And for the most part, the public constraints
for MIPS and AArch64 were chosen to be ones that we thought were useful
and that we could continue to support.  There are many more internal
ones. (I ended up having to say "for the most part" because it was
probably a mistake to include "Ush" for AArch64.  Oh well...)

There's also precedent for defining compatibility constraints.
The MIPS "v" constraint is only provided for asm compatibility,
even though no internal patterns use it any more.

[Bug c/92088] aggregates with VLAs and nested functions are broken

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
Yes, pointers to VLA are variably modified (but are OK in function 
arguments even for extern functions, as VLAs there get treated as [*]).

So maybe you should use C_TYPE_VARIABLE_SIZE as the test on the types of 
the arguments (and the return value, or is it OK for that to be 
variable-size?).

[Bug middle-end/92333] missing variable name referencing VLA in warnings

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
The ICE is caused by int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize)
returning a nul for constant arguments, and caller assuming it's non-null.  The
poly_int_binop function apparently doesn't know how to do TRUNC_DIV_EXP for
constant poly_int arguments.  I don't know if that's just because it hasn't
been needed anywhere else up until now or because of some inherent limitation
of these poly_ints.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool  ---
(In reply to Rich Felker from comment #16)
> > Using "ws" in inline asm never made sense.  It was always the same as
> > "wa", for all cases where either could be used in inline asm at all.
> 
> It made sense insomuch as it was documented and was the most
> clearly-documented as matching the intended usage case, and still makes
> sense in that the other widely-used compiler did not properly (according to
> your interpretation) implement "wa", so that "ws" was the only constraint
> that worked with both.

I am saying it is a mistake that GCC ever documented this for public
use.  Every use of "ws" in inline asm should be "wa".

If that doesn't work with LLVM, then LLVM needs fixing.

After both musl and LLVM are fixed, if you then *still* feel you
need "ws", then we can talk of course.  Deal?

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #18 from Rich Felker  ---
> So use "wa" instead of "ws" in the two files you use it, and can we get
> on with our lives?

Translation: Introduce a regression on all existing versions of clang because
GCC broke a documented public interface. How about no?

> The places where in the past we put old internal constraints (and output
> modifiers) back are places where for example glibc used it in installed
> headers.  That takes a decade or more to fix.

These are not old internal constraints. They're publicly documented ones.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to Rich Felker from comment #13)
> > That does not look at types.  It complains that "x" lives in memory,
> > while the constraint requires a register (a floating point register).
> 
> That does not sound accurate.

But it is.

> > No, they are not.  The constraints are an implementation detail.  And
> > they *have* to be, or we could never again improve anything.
> 
> If they are in the documentation, they're not implementation details.

There also is a documentation bug, yes.

> > Unfortunately we currently document most of them in the user manual as
> > well.  It's on my list of things to change, for GCC 10.  Most targets
> > still have this problem, fwiw.
> 
> If you intend to remove documented functionality on an even larger scale,
> that is a breaking change, and one which I will (loudly) oppose.

Feel free.  What I will do is remove the buggy documentation.

> > What I am talking about is that people rely on implementation details
> > no matter what we do, and then prevent us from changing them.
> 
> That may be true, but it's not related to this bug report and I have not
> seen evidence of it happening. I'll gladly fix it if we're doing that
> anywhere.

So use "wa" instead of "ws" in the two files you use it, and can we get
on with our lives?

The places where in the past we put old internal constraints (and output
modifiers) back are places where for example glibc used it in installed
headers.  That takes a decade or more to fix.

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Thu Nov  7 17:08:11 2019
New Revision: 277927

URL: https://gcc.gnu.org/viewcvs?rev=277927&root=gcc&view=rev
Log:

PR ipa/92406
* ipa-fnsummary.c (analyze_function_body): Use get_create to copy
summary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c

[Bug other/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
As I wrote in https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00518.html, I'm
seeing it on i686-linux too, and there also nested.d ICEs.

[Bug middle-end/92410] New: Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[matmal01 at gcc dot gnu.org]

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

Bug ID: 92410
   Summary: Invalid access to df->insns[] in
regstat_bb_compute_calls_crossed (caught by hwasan)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu
 Build: aarch64-none-linux-gnu

On trying to rebase the hwasan patches to a newer GCC version, I've found that
hwasan catches a bug newly introduced between commits r275833 and r277678.


The stack trace of the access (as given by hwasan) is:

#0 0x6293ac in SigTrap<3>
../../../../gcc/libsanitizer/hwasan/hwasan_checks.h:27
#1 0x6293ac in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 3>
../../../../gcc/libsanitizer/hwasan/hwasan_checks.h:88
#2 0x6293ac in __hwasan_load8
../../../../gcc/libsanitizer/hwasan/hwasan.cpp:478
#3 0x10cff94 in regstat_bb_compute_calls_crossed
../../gcc/gcc/regstat.c:327
#4 0x10cff94 in regstat_compute_calls_crossed() ../../gcc/gcc/regstat.c:379
#5 0x21c0858 in sched_init() ../../gcc/gcc/haifa-sched.c:7337
#6 0x21d3994 in haifa_sched_init() ../../gcc/gcc/haifa-sched.c:7354
#7 0x11376c8 in schedule_insns() ../../gcc/gcc/sched-rgn.c:3514
#8 0x1138584 in rest_of_handle_sched2 ../../gcc/gcc/sched-rgn.c:3746
#9 0x1138584 in execute ../../gcc/gcc/sched-rgn.c:3882
#10 0x102911c in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2494
#11 0x1029c58 in execute_pass_list_1 ../../gcc/gcc/passes.c:2580
#12 0x1029c74 in execute_pass_list_1 ../../gcc/gcc/passes.c:2581
#13 0x1029c74 in execute_pass_list_1 ../../gcc/gcc/passes.c:2581
#14 0x1029cd0 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2591
#15 0x955aa4 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2196
#16 0x956f38 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2334
#17 0x956f38 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2684
#18 0x95ac58 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2597
#19 0x95ac58 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2864
#20 0x1209bf8 in compile_file ../../gcc/gcc/toplev.c:481
#21 0x61e9d4 in do_compile ../../gcc/gcc/toplev.c:2199
#22 0x61e9d4 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2334
#23 0x621758 in main ../../gcc/gcc/main.c:39
#24 0x8b46889c in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f89c)


While the stack trace of the allocation aronud this address (as given by
hwasan) is:

[0xefe68400,0xefe68500) is a small allocated heap chunk; size: 256
offset: 240
0xefe684f0 is located 0 bytes to the right of 240-byte region
[0xefe68400,0xefe684f0)
allocated here:
#0 0x62ae0c in __sanitizer_malloc
../../../../gcc/libsanitizer/hwasan/hwasan_interceptors.cpp:169
#1 0x24b3df8 in xrealloc ../../gcc/libiberty/xmalloc.c:177
#2 0x99c434 in df_grow_insn_info() ../../gcc/gcc/df-scan.c:545
#3 0x99e928 in df_scan_alloc(bitmap_head*) ../../gcc/gcc/df-scan.c:262
#4 0xe34ee0 in do_reload ../../gcc/gcc/ira.c:5574
#5 0xe34ee0 in execute ../../gcc/gcc/ira.c:5697
#6 0x102911c in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2494
#7 0x1029c58 in execute_pass_list_1 ../../gcc/gcc/passes.c:2580
#8 0x1029c74 in execute_pass_list_1 ../../gcc/gcc/passes.c:2581
#9 0x1029cd0 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2591
#10 0x955aa4 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2196
#11 0x956f38 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2334
#12 0x956f38 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2684
#13 0x95ac58 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2597
#14 0x95ac58 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2864
#15 0x1209bf8 in compile_file ../../gcc/gcc/toplev.c:481
#16 0x61e9d4 in do_compile ../../gcc/gcc/toplev.c:2199
#17 0x61e9d4 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2334
#18 0x621758 in main ../../gcc/gcc/main.c:39
#19 0x8b46889c in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f89c)
#20 0x624e34 
(/home/ubuntu/working-directory/gcc-objdir-hwasan/gcc/cc1+0x624e34)



I've verified the bug by compiling on r277678 and viewing the relevent command
in gdb.
After running a full bootstrap (convert filenames as relevent):

/home/ubuntu/working-directory/gcc-objdir/./gcc/xgcc
-B/home/ubuntu/working-directory/gcc-objdir/./gcc/
-B/home/ubuntu/working-directory/gcc-install/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/working-directory/gcc-install/aarch64-unknown-linux-gnu/lib/
-isystem
/home/ubuntu/working-directory/gc

[Bug middle-end/92408] strlen(s) != 0 not folded into *s

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83026,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90626,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90876,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90879
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
This is similar to the optimization discussed in pr83026, pr90626, pr90876, and
pr90879.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug ada/92362] [9/10 regression] double elaboration of expression with Address aspect

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug ada/92362] [9/10 regression] double elaboration of expression with Address aspect

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-07
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |9.3
Summary|Compiler generates 2|[9/10 regression] double
   |function calls in a 'with   |elaboration of expression
   |Address' aspect |with Address aspect
   |specification that uses a   |
   |function|
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Really stupid mistake.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #16 from Rich Felker  ---
> Using "ws" in inline asm never made sense.  It was always the same as
> "wa", for all cases where either could be used in inline asm at all.

It made sense insomuch as it was documented and was the most clearly-documented
as matching the intended usage case, and still makes sense in that the other
widely-used compiler did not properly (according to your interpretation)
implement "wa", so that "ws" was the only constraint that worked with both.

[Bug tree-optimization/92401] [10 Regression] ICE in fold_ternary_loc, at fold-const.c:11698

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I guess one way to fix this would be:
--- gcc/gimple-match-head.c.jj  2019-11-01 22:19:49.604831956 +0100
+++ gcc/gimple-match-head.c 2019-11-07 17:40:32.799882669 +0100
@@ -191,7 +191,11 @@ gimple_resimplify1 (gimple_seq *seq, gim
 {
   tree tem = NULL_TREE;
   if (res_op->code.is_tree_code ())
-   tem = const_unop (res_op->code, res_op->type, res_op->ops[0]);
+   {
+ if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (res_op->code))
+ && TREE_CODE_LENGTH (code) == 1)
+   tem = const_unop (res_op->code, res_op->type, res_op->ops[0]);
+   }
   else
tem = fold_const_call (combined_fn (res_op->code), res_op->type,
   res_op->ops[0]);
@@ -252,8 +256,12 @@ gimple_resimplify2 (gimple_seq *seq, gim
 {
   tree tem = NULL_TREE;
   if (res_op->code.is_tree_code ())
-   tem = const_binop (res_op->code, res_op->type,
-  res_op->ops[0], res_op->ops[1]);
+   {
+ if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (res_op->code))
+ && TREE_CODE_LENGTH (code) == 2)
+   tem = const_binop (res_op->code, res_op->type,
+  res_op->ops[0], res_op->ops[1]);
+   }
   else
tem = fold_const_call (combined_fn (res_op->code), res_op->type,
   res_op->ops[0], res_op->ops[1]);
@@ -325,9 +333,13 @@ gimple_resimplify3 (gimple_seq *seq, gim
 {
   tree tem = NULL_TREE;
   if (res_op->code.is_tree_code ())
-   tem = fold_ternary/*_to_constant*/ (res_op->code, res_op->type,
-   res_op->ops[0], res_op->ops[1],
-   res_op->ops[2]);
+   {
+ if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (res_op->code))
+ && TREE_CODE_LENGTH (code) == 3)
+   tem = fold_ternary/*_to_constant*/ (res_op->code, res_op->type,
+   res_op->ops[0], res_op->ops[1],
+   res_op->ops[2]);
+   }
   else
tem = fold_const_call (combined_fn (res_op->code), res_op->type,
   res_op->ops[0], res_op->ops[1], res_op->ops[2]);

const_unop/const_binop are actually quite forgiving on what they are called
with, just return NULL_TREE, but fold_ternary is not.  res_op->code in this
case is a CONSTRUCTOR with 3 elts.

[Bug other/92409] New: [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[seurer at gcc dot gnu.org]

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

Bug ID: 92409
   Summary: [10 regression] r277920 causes ICE in
gcc.dg/cast-function-1.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: ---

FAIL: gcc.dg/cast-function-1.c (internal compiler error)
FAIL: gcc.dg/cast-function-1.c (test for excess errors)

I only see this on a powerpc64 BE machine; it works fine on LE.

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/cast-function-1.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O3 -S -o
cast-function-1.s(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/cast-function-1.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -S -o cast-function-1.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c: In function
'bar':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:21:8:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:22:8:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:23:8:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:24:4:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:28:8:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:30:8:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:31:4:
warning: function called through a non-compatible type
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:49:1: error:
non-trivial conversion in 'ssa_name'
struct str_t
int
# .MEM_38 = VDEF <.MEM_36>
s = arg_32;
during GIMPLE pass: einline
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:49:1:
internal compiler error: verify_gimple failed
0x10ab930b verify_gimple_in_cfg(function*, bool)
/home/seurer/gcc/gcc-test2/gcc/tree-cfg.c:5427
0x1090d30b execute_function_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:1983
0x1090e67b do_per_function
/home/seurer/gcc/gcc-test2/gcc/passes.c:1638
0x1090e893 execute_todo
/home/seurer/gcc/gcc-test2/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.
compiler exited with status 1
FAIL: gcc.dg/cast-function-1.c (internal compiler error)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 21)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 22)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 23)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 24)
PASS: gcc.dg/cast-function-1.c  (test for bogus messages, line 25)
PASS: gcc.dg/cast-function-1.c  (test for bogus messages, line 26)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 28)
PASS: gcc.dg/cast-function-1.c  (test for bogus messages, line 29)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 30)
PASS: gcc.dg/cast-function-1.c  (test for warnings, line 31)
PASS: gcc.dg/cast-function-1.c  (test for bogus messages, line 32)
PASS: gcc.dg/cast-function-1.c  (test for bogus messages, line 33)
FAIL: gcc.dg/cast-function-1.c (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:49:1: error:
non-trivial conversion in 'ssa_name'
struct str_t
int
# .MEM_38 = VDEF <.MEM_36>
s = arg_32;
during GIMPLE pass: einline
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cast-function-1.c:49:1:
internal compiler error: verify_gimple failed
0x10ab930b verify_gimple_in_cfg(function*, bool)
/home/seurer/gcc/gcc-test2/gcc/tree-cfg.c:5427
0x1090d30b execute_function_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:1983
0x1090e67b do_per_function
/home/seurer/gcc/gcc-test2/gcc/passes.c:1638
0x1090e893 execute_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:2037

testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds

=== gcc Summary ===

# of expected passes12
# of unexpected failures2

[Bug middle-end/92408] New: strlen(s) != 0 not folded into *s

[msebor at gcc dot gnu.org]

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

Bug ID: 92408
   Summary: strlen(s) != 0 not folded into *s
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In simple expressions, GCC folds strlen(*s) calls whose result is only used in
a test for equality with zero to tests for the first character being nul.  But
it does only a superficial job and doesn't also do the same folding when the
result is stored in a variable that is then tested for the same equality.

Clang folds both.

$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
void f (void);

void g (const char *s)
{
  if (__builtin_strlen (s))   // folded to if (*s)
f ();
}

void h (const char *s)
{
  __SIZE_TYPE__ n = __builtin_strlen (s);
  if (n)  // not folded into if (*s) but could be
f ();
}

;; Function g (g, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

Removing basic block 5
g (const char * s)
{
  char _1;

   [local count: 1073741824]:
  _1 = *s_4(D);
  if (_1 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334802]:
  f (); [tail call]

   [local count: 1073741824]:
  return;

}



;; Function h (h, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=1)

Removing basic block 5
h (const char * s)
{
  long unsigned int n;

   [local count: 1073741824]:
  n_4 = __builtin_strlen (s_3(D));
  if (n_4 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334802]:
  f (); [tail call]

   [local count: 1073741824]:
  return;

}

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Segher Boessenkool from comment #10)
> > No, they are not.  The constraints are an implementation detail.  And
> > they *have* to be, or we could never again improve anything.
> > 
> > Unfortunately we currently document most of them in the user manual as
> > well.  It's on my list of things to change, for GCC 10.  Most targets
> > still have this problem, fwiw.
> 
> I disagree with that.  We do have public and internal constraints, public
> are roughly those that are documented in gcc.info (rather than gccint.info,
> i.e.
> things in md.texi not guarded with @ifset INTERNALS).

We still do not have separate public documentation for this, for rs6000
(just like many other targets).

> In constraints.md one can also use @internal to mark constraint as internal.

Yes, and the ones marked like that for us are mostly the ones that *should*
be public!

> Limiting inline asm use to just what is in common.md is clearly insufficient.
> 
> So, if "ws" has been documented in the user documentation, perhaps just
> (define_register_constraint "ws" "rs6000_constraints[RS6000_CONSTRAINT_wa]"
>   "Compatibility alias to wa")
> could be added?  If it has not been documented, it is fine to remove it.

Using "ws" in inline asm never made sense.  It was always the same as
"wa", for all cases where either could be used in inline asm at all.

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

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
r277904 looks like it fixes this problem but introduces (or allows it to get
to) others:

FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not  4
FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not lxvd2x
FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not stxvd2x

These assembler instruction count tests are touchy and it looks like the above
only happens on power 7 (BE).


> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not  4
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times std  2

And these only happen on power 9 (LE).

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #14 from Rich Felker  ---
> So, if "ws" has been documented in the user documentation, perhaps just
> (define_register_constraint "ws" "rs6000_constraints[RS6000_CONSTRAINT_wa]"
>   "Compatibility alias to wa")
> could be added?  If it has not been documented, it is fine to remove it.

It is clearly documented here:

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Machine-Constraints.html

Whoever removed it in gcc 10 was aware of this because they explicitly deleted
it from the documentation:

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html

This should not be a permitted change, at least not without major discussion to
reach consensus.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #13 from Rich Felker  ---
> That does not look at types.  It complains that "x" lives in memory,
> while the constraint requires a register (a floating point register).

That does not sound accurate. An (in this case lvalue since it's an output too,
but for input0-only, non-lvalues as well) expression does not "live in memory";
that is not the problem here. Unless the address has leaked outside of the
current scope of transformations, objects may not live in memory at all, only
in registers, or a mix of registers and temporary spills, etc. The asm
constraints guide the compiler's choices of where to put it (and may *force* it
to be moved back/forth, e.g. if you use an "m" constraint for a variable that
could otherwise be kept in a register, or a register constraint for one that
otherwise would only be accessed via memory), not the other way around.

The problem here is that GCC has no way to bind an integer expression to a
floating point register. It *is* a matter of type. There are probably
subtleties to this that I don't understand, but it's not about "living in
memory".

> No, they are not.  The constraints are an implementation detail.  And
> they *have* to be, or we could never again improve anything.

If they are in the documentation, they're not implementation details. They're
interfaces necessary to be able to use inline asm, which is a documented and
important feature of the "GNU C" language.

In particular, "ws" is documented for the purpose we're using it for:

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Machine-Constraints.html

> Unfortunately we currently document most of them in the user manual as
> well.  It's on my list of things to change, for GCC 10.  Most targets
> still have this problem, fwiw.

If you intend to remove documented functionality on an even larger scale, that
is a breaking change, and one which I will (loudly) oppose. If there are
legitimate reasons for such changes to be made internally, a layer should be
put in place so that code using the constraints continues to work without
imposing on the backend implementation.

> What I am talking about is that people rely on implementation details
> no matter what we do, and then prevent us from changing them.

That may be true, but it's not related to this bug report and I have not seen
evidence of it happening. I'll gladly fix it if we're doing that anywhere.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #10)
> No, they are not.  The constraints are an implementation detail.  And
> they *have* to be, or we could never again improve anything.
> 
> Unfortunately we currently document most of them in the user manual as
> well.  It's on my list of things to change, for GCC 10.  Most targets
> still have this problem, fwiw.

I disagree with that.  We do have public and internal constraints, public are
roughly those that are documented in gcc.info (rather than gccint.info, i.e.
things in md.texi not guarded with @ifset INTERNALS).
In constraints.md one can also use @internal to mark constraint as internal.
Limiting inline asm use to just what is in common.md is clearly insufficient.

So, if "ws" has been documented in the user documentation, perhaps just
(define_register_constraint "ws" "rs6000_constraints[RS6000_CONSTRAINT_wa]"
  "Compatibility alias to wa")
could be added?  If it has not been documented, it is fine to remove it.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
(In reply to Rich Felker from comment #9)
> And ok, to be more productive rather than just angry about the regression,
> if you really think the "ws" constraint should be removed, what is the
> proper preprocessor/configure-time check to determine the right constraint
> and asm form to use without special-casing specific compiler names and
> versions? Short of an answer to that, the only solution I can see to this on
> our side is just disabling the asm if a configure check determines that the
> current code doesn't compile, and that would be rather bleh.

Easy: always use "wa" whenever you want a VSX register.  Always
use "d" when you want an FP register, and use "v" if you want an
AltiVec register.  Use the "%x" output modifier if you want
the VSX register numbering (so 0..63) in the assembler output
(instead of 0..31 for both halves of it: vs0..vs31 are f0..f31,
and vs32..vs63 are v0..v31).  Which of those register sets you
should use depends on what machine insns you use.

This is the same in any compiler version that supports VSX.  With
compiler versions that do not support VSX, you cannot use VSX, it
won't work.  There is the __VSX__ preprocessor predefine for
detecting this.

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

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Submitted and approved patch:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00072.html – still to be
committed by the author.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Rich Felker from comment #8)
> > Then LLVM has more to fix.  Constraints never look at types.  A register
> > constraint (like "wa") simply says what registers are valid.
> 
> This is blatently false. For x86:
> 
> int foo(int x)
> {
> __asm__("" : "+f"(x));
> return x;
> }
> 
> yields "error: inconsistent operand constraints in an 'asm'".

That does not look at types.  It complains that "x" lives in memory,
while the constraint requires a register (a floating point register).

There are three different places a datum can live: in a register, in
memory, or in a constant.  "r", "m", and "i" as constraints, very
roughly.  PowerPC has *no* instructions that accept more than one of
these three (you can still have it in uncommon assembler code that
does not generate machine insns -- as a simple dumb example, in a
comment for example, like   asm("# %0" :: "g"(some_var));
("g" means "rmi" essentially).

And "types" are not the same as "modes".  This is another common
misunderstanding.

> > For many w* using it in inline asm is plain wrong; for the rest of the
> > register constraints it is useless, plain "wa" should be used; and there
> > are some special ones that are so far GCC implementation detail that you
> > probably wouldn't even consider using them.
> 
> The asm register constraints are a public interface of "GNU C" for the
> particular target architecture.

No, they are not.  The constraints are an implementation detail.  And
they *have* to be, or we could never again improve anything.

Unfortunately we currently document most of them in the user manual as
well.  It's on my list of things to change, for GCC 10.  Most targets
still have this problem, fwiw.

> Randomly removing them is a breaking change
> in the language. There is no documented or even reliable way to detect which
> ones work correctly for a particular compiler version, so change or removal
> of semantics is particularly problematic.

Yes.  Use the common ones only.

> > The maintenance cost for all the constraints we keep around because some
> > important projects used them is considerable, fwiw.
> 
> One line in a table to preserve stability of the language is not what I call
> "maintenance cost".

That is the other side of it: yes, we should give people more guidance
what they should (and shouldn't!) do in inline asm.

What I am talking about is that people rely on implementation details
no matter what we do, and then prevent us from changing them.

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

[fxue at gcc dot gnu.org]

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

--- Comment #14 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Thu Nov  7 15:43:01 2019
New Revision: 277923

URL: https://gcc.gnu.org/viewcvs?rev=277923&root=gcc&view=rev
Log:
Loop split on semi-invariant conditional statement

2019-11-07  Feng Xue 

PR tree-optimization/89134
* doc/invoke.texi (min-loop-cond-split-prob): Document new --params.
* params.def: Add min-loop-cond-split-prob.
* tree-ssa-loop-split.c (split_loop): Remove niter parameter, move some
outside checks on loop into the function.
(split_info): New class.
(find_vdef_in_loop, get_control_equiv_head_block): New functions.
(find_control_dep_blocks, vuse_semi_invariant_p): Likewise.
(ssa_semi_invariant_p, loop_iter_phi_semi_invariant_p): Likewise.
(control_dep_semi_invariant_p, stmt_semi_invariant_p_1): Likewise.
(stmt_semi_invariant_p, branch_removable_p): Likewise.
(get_cond_invariant_branch, compute_added_num_insns): Likewise.
(get_cond_branch_to_split_loop, do_split_loop_on_cond): Likewise.
(split_loop_on_cond): Likewise.
(tree_ssa_split_loops): Add loop split on conditional statement.

2019-11-07  Feng Xue  

PR tree-optimization/89134
* gcc.dg/tree-ssa/loop-cond-split-1.c: New test.
* g++.dg/tree-ssa/loop-cond-split-1.C: New test.
* gcc.dg/torture/pr55107.c: Add -fno-split-loops.


Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/loop-cond-split-1.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-cond-split-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr55107.c
trunk/gcc/tree-ssa-loop-split.c

[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469

[bergner at gcc dot gnu.org]

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

--- Comment #12 from Peter Bergner  ---
(In reply to Peter Bergner from comment #11)
> I've been working on allowing in the rs6000 patterns.

This fixes the ICE for me.  I have not regtested the patch though:

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 277861)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1047,7 +1047,8 @@ (define_predicate "input_operand"
 return 1;

   /* Allow any integer constant.  */
-  if (GET_MODE_CLASS (mode) == MODE_INT
+  if ((GET_MODE_CLASS (mode) == MODE_INT
+   || GET_MODE_CLASS (mode) == MODE_PARTIAL_INT)
   && CONST_SCALAR_INT_P (op))
 return 1;

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
The problem is in finalize_nrv_r which does:
  /* Change all cleanups for the NRV to only run when an exception is
 thrown.  */
  else if (TREE_CODE (*tp) == CLEANUP_STMT
   && CLEANUP_DECL (*tp) == dp->var)
CLEANUP_EH_ONLY (*tp) = 1;
The reason that is done is that when NRV optimizing some variable, we don't
want to run the destructor if the scope is left through return statement,
obviously we still need to run it if exception is thrown, but we need to run
the destructor
also if the scope is left through other means like goto in this testcase;
unfortunately we don't have an IL construct that can do that, we have
TRY_FINALLY_EXPR (coming from CLEANUP_STMT with !CLEANUP_EH_ONLY) where the
cleanup is run always when leaving the scope, and TRY_CATCH_EXPR where the
cleanup is run only when leaving the scope through exceptions.
So, either we need some new construct that would run cleanup whenever not left
through RETURN_EXPR, or need to use TRY_FINALLY_EXPR with some helper bool
variable initialized to something and set to something else right before
RETURN_EXPRs and conditionallize the cleanup on that bool.  The worry here is
whether it could be optimized to whatever we used to emit soon if there are no
gotos and how much worse code it would emit at -O0.

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

[Dave.Poston at gs dot com]

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

--- Comment #4 from Dave Poston  ---
Yep, also changing problem()/foo() to void and not returning the struct, works
properly

[Bug fortran/91253] [9/10 Regression] gfortran.dg/continuation_6.f fails when using -pre_include as done with latest glibc

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-07
 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|gfortran.dg/continuation_6. |[9/10 Regression]
   |f fails when using latest   |gfortran.dg/continuation_6.
   |glibc   |f fails when using
   ||-pre_include as done with
   ||latest glibc
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
CC Martin as he added -pre_include in r266509 for GCC 9 ("Support simd function
declarations via a pre-include.").


The problem is that the continuation-line count is off by the number of lines
in the -pre_include file – if you add as many additional lines as are in the
-pre_include file, the diagnostic works.

It also works if one forcefully sets "line_head = NULL" after the
"load_file (flag_pre_include" call in fortran/scanner.c's gfc_new_file.

I tried to set various other flags to 0, but it didn't make a difference.

The problem is that
  if (gfc_linebuf_linenum (gfc_current_locus.lb) == continue_line + 1)
is not entered for the first continuation line but only for the
#lines-th line.

And the continue_line is:
  if (gfc_current_locus.lb != NULL
  && continue_line < gfc_linebuf_linenum (gfc_current_locus.lb))
continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);

In terms of linemap_add calls, it doesn't look too bad, however. One has:
* LC_ENTER for continuation_6.f via f95-lang.c's gfc_init.
* LC_RENAME to ""  (next line)
* LC_ENTER math-vector-fortran.h gfc_new_file -> load_file (pre_include
* LC_LEAVE  (and of load_file)
And then load_file (gfc_source_file is called, which starts with an LC_RENAME
to  "continuation_6.f".

[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
(In reply to Xiong Hu XS Luo from comment #10)
> This could fix the ICE, but I am not sure whether it is reasonable:
> 
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 0db6d3151cd..325904ac473 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -3886,7 +3886,9 @@ curr_insn_transform (bool check_only_p)
> subst = get_equiv_with_elimination (old, curr_insn);
> original_subreg_reg_mode[i] = VOIDmode;
> equiv_substition_p[i] = false;
> -   if (subst != old)
> +   if (subst != old
> +   && !(GET_MODE (old) == E_PTImode && GET_CODE (old) == REG
> +&& GET_CODE (subst) == CONST_WIDE_INT))
>   {
> equiv_substition_p[i] = true;
> subst = copy_rtx (subst);

Is there a reason we shouldn't allow loading a constant into a PTImode pseudo?
I've been working on allowing in the rs6000 patterns.

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I think it is well defined.
Simplified testcase:
struct A
{
  A () { a++; }
  A (const A &) { a++; }
  ~A () { a--; }
  static int a;
};
int A::a = 0;

A
foo ()
{
  int cnt = 10;
lab:
  A a;
  if (cnt--)
goto lab;
  return a;
}

int
main ()
{
  foo ();
  if (A::a)
__builtin_abort ();
}

I believe the reason why this doesn't work is NRV, at least if return a; is
changed to return A ();, so that the a variable is not NRV optimized, it works
properly.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[giuliano.belinassi at usp dot br]

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

--- Comment #32 from Giuliano Belinassi  ---
(In reply to Eric Gallager from comment #31)
> I think this came up at Cauldron, but I forget what exactly people said
> about it...

Actually this PR comes before Cauldron 2019. One way to fix this issue is to
make the match.pd parser output several smaller gimple-match.c, and add these
to the Makefile. Also repeat this procedure to other big files.

Another solution is to parallelize GCC internals and make GCC communicate with
Make somehow so that when a CPU is idle, it starts compiling some files in
parallel.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #9 from Rich Felker  ---
And ok, to be more productive rather than just angry about the regression, if
you really think the "ws" constraint should be removed, what is the proper
preprocessor/configure-time check to determine the right constraint and asm
form to use without special-casing specific compiler names and versions? Short
of an answer to that, the only solution I can see to this on our side is just
disabling the asm if a configure check determines that the current code doesn't
compile, and that would be rather bleh.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #8 from Rich Felker  ---
> Then LLVM has more to fix.  Constraints never look at types.  A register
> constraint (like "wa") simply says what registers are valid.

This is blatently false. For x86:

int foo(int x)
{
__asm__("" : "+f"(x));
return x;
}

yields "error: inconsistent operand constraints in an 'asm'".

> For many w* using it in inline asm is plain wrong; for the rest of the
> register constraints it is useless, plain "wa" should be used; and there
> are some special ones that are so far GCC implementation detail that you
> probably wouldn't even consider using them.

The asm register constraints are a public interface of "GNU C" for the
particular target architecture. Randomly removing them is a breaking change in
the language. There is no documented or even reliable way to detect which ones
work correctly for a particular compiler version, so change or removal of
semantics is particularly problematic.

> The maintenance cost for all the constraints we keep around because some
> important projects used them is considerable, fwiw.

One line in a table to preserve stability of the language is not what I call
"maintenance cost".

[Bug other/92396] -ftime-trace support

[trass3r at gmail dot com]

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

--- Comment #4 from Trass3r  ---
Nice! Btw the traces can be viewed independently of the browser using
https://www.speedscope.app.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Created attachment 47194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47194&action=edit
diff for results.f

So with the attached diff for results.f and a simple

> cat t.f
   subroutine foobar
   end
> gfortran -c t.f

and linking in t.o into calculix the comparison no longer fails.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Adding

!GCC$ unroll 0

before line 848 or adding a call to an empty function after the loop nest
(after 857) fixes the miscompare.  GIMPLE level difference with the function
call
is one missed invariant motion of a load from a function parameter (iperturb)
but assembly level diff is ~7000 lines :/  The iperturb change can be
compensated
for in the source which still fixes the miscompare (but assembly level
difference
doesn't improve much).

The odd thing is that the differences aren't _too_ big so [stack] memory
corruption seems unlikely(?).

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> > Hi,
> > does this patch fix the problem?
> > Honza
> 
> Yes, it fixed the issue.
Great, thanks.  I was overzealous here with getting rid of get_create :)

Honza

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Jan Hubicka from comment #4)
> Created attachment 47193 [details]
> Proposed patch
> 
> Hi,
> does this patch fix the problem?
> Honza

Yes, it fixed the issue.

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The goto defeats finalization here but construction happens multiple times.
Not sure if that's allowed by the standard, but I'd say you invoke undefined
behavior here?

[Bug other/92396] -ftime-trace support

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Created attachment 47193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47193&action=edit
Proposed patch

Hi,
does this patch fix the problem?
Honza

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

[Dave.Poston at gs dot com]

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

--- Comment #1 from Dave Poston  ---
In fact, fill() isn't even needed.

Smaller repro:
https://godbolt.org/z/ubXl7Y

---
#include

struct MyStruct
{
MyStruct() {
std::cout << "Constructed" << std::endl;
}
~MyStruct() {
std::cout << "Destructed" << std::endl;
}
int a;
};

MyStruct problem() {
int cnt = 100;
start:
MyStruct a;
if( cnt-- )
goto start;
return a;
}

int main( int argc, char** argv )
{
problem();
return 0;
}

[Bug other/92396] -ftime-trace support

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-07
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Yes, I think we can do something similar to what clang does.
I can work on that next stage1.

[Bug c++/92407] New: Destruction of objects returned from functions skipped by goto

[Dave.Poston at gs dot com]

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

Bug ID: 92407
   Summary: Destruction of objects returned from functions skipped
by goto
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Dave.Poston at gs dot com
  Target Milestone: ---

The code below only outputs 'Destructed' once:

Godbolt link: https://godbolt.org/z/Foy-vc

Bug appears to be present in all versions of GCC available in godbolt.

---
#include

struct MyStruct
{
MyStruct() {
std::cout << "Constructed" << std::endl;
}
~MyStruct() {
std::cout << "Destructed" << std::endl;
}
int a;
};

MyStruct fill() {
MyStruct bla;
bla.a = 100;
return bla;
}
MyStruct problem() {
int cnt = 100;
start:
MyStruct a = fill();
if( cnt-- )
goto start;
return a;
}

int main( int argc, char** argv )
{
problem();
return 0;
}
---
output is:
Constructed

Constructed

Constructed

Constructed

Constructed

Constructed

Constructed

Constructed
...

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/92405] [10 regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1683

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92405] [10 regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1683

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Nov  7 11:49:09 2019
New Revision: 277921

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

PR tree-optimization/92405
* tree-vect-loop.c (vectorizable_reduction): Appropriately
restrict lane-reducing ops to single stmt chains.

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

[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr

[edlinger at gcc dot gnu.org]

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

--- Comment #6 from Bernd Edlinger  ---
I tried this, and it contradicts what above comment says:

$ cat test1.cc 
void foo()
{
  char *x = int();
}

gcc -Wall -S -std=c++17 test1.cc 
test1.cc: In function ‘void foo()’:
test1.cc:3:9: warning: unused variable ‘x’
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-variable-Wunused-variable]8;;]
3 |   char *x = int();
  | ^

So I would have expected that to be rejected with c++11 and above
and accepted with c++98, but it is accepted with all C++ versions.

BTW: can we get rid of this URL-escapes in the warnings, soon?

[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr

[edlinger at gcc dot gnu.org]

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

--- Comment #5 from Bernd Edlinger  ---
Some insight, why the crash only happens with -std=c++98:

-Wshadow=compatible-local tries to find out if there is an
implicit conversion between the "int16_t f" and "a f".
The only candidate is a::a(char *);
The conversion is only allowed when it f is NULL.

  /* [conv.ptr]
 A null pointer constant can be converted to a pointer type; ... A
 null pointer constant of integral type can be converted to an
 rvalue of type std::nullptr_t. */
  if ((tcode == POINTER_TYPE || TYPE_PTRMEM_P (to)
   || NULLPTR_TYPE_P (to))
  && ((expr && null_ptr_cst_p (expr))
  || NULLPTR_TYPE_P (from)))
conv = build_conv (ck_std, to, conv);

and now null_ptr_cst_p is invoked with "int16_t()", aka CAST_EXPR(NULL_TREE):

bool
null_ptr_cst_p (tree t)
{
  tree type = TREE_TYPE (t);

  /* [conv.ptr]

 A null pointer constant is an integer literal ([lex.icon]) with value
 zero or a prvalue of type std::nullptr_t.  */
  if (NULLPTR_TYPE_P (type))
return true;

  if (cxx_dialect >= cxx11)
{
  STRIP_ANY_LOCATION_WRAPPER (t);

  /* Core issue 903 says only literal 0 is a null pointer constant.  */
  if (TREE_CODE (t) == INTEGER_CST
  && !TREE_OVERFLOW (t)
  && TREE_CODE (type) == INTEGER_TYPE
  && integer_zerop (t)
  && !char_type_p (type))
return true;
}
  else if (CP_INTEGRAL_TYPE_P (type))
{
  t = fold_non_dependent_expr (t, tf_none);
  STRIP_NOPS (t);
  if (integer_zerop (t) && !TREE_OVERFLOW (t))
return true;
}

  return false;

and now fold_non_dependent_expr fails.

With above patch we enter with the t = f, the decl we want to cast,
it is obviously not null.

[Bug target/92388] [10 Regression] ICE in insert_regs, at cse.c:1129

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-11-06 00:00:00 |2019-11-07
   Target Milestone|--- |10.0
Summary|ICE in insert_regs, at  |[10 Regression] ICE in
   |cse.c:1129  |insert_regs, at cse.c:1129
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on trunk.

[Bug middle-end/92333] missing variable name referencing VLA in warnings

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
(In reply to Martin Sebor from comment #3)
> Patch (https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00179.html) committed
> in r277854.

Hi, this patch is causing an ICE on aarch64:
during GIMPLE pass: vrp
/gcc/testsuite/c-c++-common/pr60101.c: In function 'foo':
/gcc/testsuite/c-c++-common/pr60101.c:8:1: internal compiler error:
Segmentation fault
0xccbf0f crash_signal
/gcc/toplev.c:326
0x948baa contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
/gcc/tree.h:3636
0x948baa int_const_binop(tree_code, tree_node const*, tree_node const*, int)
/gcc/fold-const.c:1179
0xfb6c7f vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
/gcc/tree-vrp.c:4158
0xfba94f vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
/gcc/tree-vrp.c:4081
0xfba94f check_array_bounds
/gcc/tree-vrp.c:4657
0xffce12 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/gcc/tree.c:11942
0xffd3c6 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/gcc/tree.c:12272
0x9c9850 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/gcc/gimple-walk.c:203
0xfb158f check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
/gcc/tree-vrp.c:4715
0x15264ba dom_walker::walk(basic_block_def*)
/gcc/domwalk.c:309
0xfb4aee vrp_prop::check_all_array_refs()
/gcc/tree-vrp.c:4732
0xfbce6e vrp_prop::vrp_finalize(bool)
/gcc/tree-vrp.c:6756
0xfc5851 execute_vrp
/gcc/tree-vrp.c:6824
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: c-c++-common/pr60101.c  -Wc++-compat  (internal compiler error)
FAIL: c-c++-common/pr60101.c  -Wc++-compat  (test for excess errors)



on arm, there is an error:
/gcc/testsuite/c-c++-common/pr60101.c: In function 'foo':
/gcc/testsuite/c-c++-common/pr60101.c:40:24: warning: array subscript n8 is
outside array bounds of '_Complex double[ + 1]' [-Warray-bounds]
FAIL: c-c++-common/pr60101.c  -Wc++-compat  (test for excess errors)

[Bug lto/70929] [7/8/9/10 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor  ---
Author: jamborm
Date: Thu Nov  7 10:55:43 2019
New Revision: 277920

URL: https://gcc.gnu.org/viewcvs?rev=277920&root=gcc&view=rev
Log:
Remove gimple_call_types_likely_match_p (PR 70929)

2019-11-07  Martin Jambor  

PR lto/70929
* cif-code.def (MISMATCHED_ARGUMENTS): Removed.
* cgraph.h (gimple_check_call_matching_types): Remove
* cgraph.c (gimple_check_call_args): Likewise.
(gimple_check_call_matching_types): Likewise.
(symbol_table::create_edge): Do not call
gimple_check_call_matching_types.
(cgraph_edge::make_direct): Likewise.
(cgraph_edge::redirect_call_stmt_to_callee): Likewise.
* value-prof.h (check_ic_target): Remove.
* value-prof.c (check_ic_target): Remove.
(gimple_ic_transform): Do nat call check_ic_target.
* auto-profile.c (function_instance::find_icall_target_map): Likewise.
(afdo_indirect_call): Likewise.
* ipa-prop.c (update_indirect_edges_after_inlining): Do not call
gimple_check_call_matching_types.
* ipa-inline.c (early_inliner): Likewise.

testsuite/
* g++.dg/lto/pr70929_[01].C: New test.
* gcc.dg/winline-10.c: Adjust for the fact that inlining happens.


Added:
trunk/gcc/testsuite/g++.dg/lto/pr70929_0.C
trunk/gcc/testsuite/g++.dg/lto/pr70929_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/auto-profile.c
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cif-code.def
trunk/gcc/ipa-inline.c
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/winline-10.c
trunk/gcc/value-prof.c

[Bug lto/92406] [10 Regression] ICE in ipa_call_summary at ipa-fnsummary.h:253 with lto and pgo

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #3 from Martin Liška  ---
Steps to reproduce:
$ git clone https://github.com/python/cpython.git
$ cd cpython
$ ./configure --enable-optimizations --with-lto
$ make

[Bug tree-optimization/92405] [10 regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1683

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target|i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||x86_64-linux-gnu
 Status|UNCONFIRMED |ASSIGNED
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #3 from Martin Liška  ---
Confirmed, started with r277882.