[Bug fortran/85796] ICE: Floating point exception

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.3.1.

[Bug c++/85795] bad_alloc thrown from allocation function when bad_array_length is expected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-16
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
Yes, if the expression is erroneous, we should avoid calling the allocation
function.

[Bug c/85800] New: A miscompilation bug with unsigned char

[juneyoung.lee at sf dot snu.ac.kr]

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

Bug ID: 85800
   Summary: A miscompilation bug with unsigned char
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juneyoung.lee at sf dot snu.ac.kr
  Target Milestone: ---

Created attachment 44136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44136=edit
A source file that raises the bug.

```
$ cat test-main.c
#include 
#include 
#include 

// If f(A, B + 4) is given, and integer representation of A and B + 4
// are the same, c1 == c2 in the loop becomes true,
// so arr3 = arr1. Hence r = A, and *A should be 10.
// However, if compiled with -O3, *A is still 1.
void store_10_to_p(int *p, int *q) {
  unsigned char arr1[8];
  unsigned char arr2[8];
  unsigned char arr3[8];
  // Type punning with char* is allowed.
  memcpy((unsigned char*)arr1, (unsigned char *), sizeof(p));
  memcpy((unsigned char*)arr2, (unsigned char *), sizeof(q));
  // Now arr1 is p, arr2 is q.

  for (int i = 0; i < sizeof(q); i++) {
int c1 = (int)arr1[i], c2 = (int)arr2[i];
// Note that c1 == c2 is a comparison between _integers_ (not pointers).
if (c1 == c2)
  // Always true if p and q have same integer representation.
  arr3[i] = arr1[i];
else
  arr3[i] = arr2[i];
  }
  // Now arr3 is equivalent to arr1, which is p.
  int *r;
  memcpy(, (unsigned char *)arr3, sizeof(r));
  // Now r is p.
  *p = 1;
  *r = 10;
}

int main() {
  int B[4], A[4];
  printf("%p %p\n", A, [4]);
  store_10_to_p(A, [4]);
  printf("%d\n", A[0]);
  return 0;
}
$ gcc -O3 -o test-main test-main.c
$ ./test-main
0x7fffe5a0 0x7fffe5a0
1
$ gcc -O0 -o test-main test-main.c
$ ./test-main
0x7fffe5b0 0x7fffe5b0
10
```

The output should be 10 because the integral representation of A and B[4] are
the same, but compiling with -O3 gives 1.

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

[msebor at gcc dot gnu.org]

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

Bug 85753 Summary: missing -Wrestrict on memcpy into a member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85753

   What|Removed |Added

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

[Bug tree-optimization/85753] missing -Wrestrict on memcpy into a member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|8.0 |8.1.1
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Fixed by r260280.

[Bug tree-optimization/85753] missing -Wrestrict on memcpy into a member array

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Wed May 16 02:30:38 2018
New Revision: 260280

URL: https://gcc.gnu.org/viewcvs?rev=260280=gcc=rev
Log:
PR tree-optimization/85753 - missing -Wrestrict on memcpy into a member array

gcc/ChangeLog:

PR tree-optimization/85753
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Handle
RECORD_TYPE in addition to ARRAY_TYPE.

gcc/testsuite/ChangeLog:

PR tree-optimization/85753
* gcc.dg/Wrestrict-10.c: Adjust.
* gcc.dg/Wrestrict-16.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wrestrict-10.c

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Attachment #43637|0   |1
is obsolete||

--- Comment #14 from Jason Merrill  ---
Created attachment 44135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44135=edit
updated patch

Here's an updated implementation, which is limited to -Wall, so it doesn't
affect the building or testing of the library.  I'm sure you will still want to
adjust the library to avoid warnings when users try to build with -Wall.

On looking more closely at some of the places I was getting warnings in the
compiler, I noticed that they often seemed to be actual errors.  For instance,
if someone copies an aa_tree and then destroys one of the aa_trees, the other
is left with a pointer to garbage.

I also realized that we want to avoid warning when the copy is elided,
particularly given C++17 mandatory copy elision; if the prvalue directly
initializes a variable, there's no problematic copying.

An interesting subcategory I noticed when I had the warning on by default is
classes with a virtual destructor, such as the exception hierarchy.  The
warning calls attention to potential slicing problems, and so I think we don't
want to add defaulted copy ops; it's good for users to be encouraged to e.g.
catch by reference.

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
A variable of scoped enumeration type can hold any value of its underlying type
(int in this case) and is not limited to the value of the enumerators. 

The warning seems reasonable.

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

[john at jlindgren dot net]

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

John Lindgren  changed:

   What|Removed |Added

 CC||john at jlindgren dot net

--- Comment #11 from John Lindgren  ---
I think I am hitting the same issue in 8.1.0.  Input ranges are thoroughly
checked in the below code, and there is no possibility of truncation, yet a
warning is emitted.

>From reading this and other reports, it seems to come down to random chance
whether -Wformat-truncation is reliable or not, as it depends on range data in
the optimizer that was never intended for error-checking diagnostics.

Can you please remove -Wformat-truncation from -Wall until it actually works?

#include 

void format_time (char buf[7], int time)
{
if (time < 0) time = 0;
if (time > 359) time = 359;

if (time < 6000)
snprintf (buf, 7, " %02d:%02d", time / 60, time % 60);
else if (time < 6)
snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
else
snprintf (buf, 7, "%3d:%02d", time / 3600, time / 60 % 60);
}

$ gcc -Wall -O2 -c test.c
test.c: In function ‘format_time’:
test.c:11:32: warning: ‘%02d’ directive output may be truncated writing 2 bytes
into a region of size between 1 and 3 [-Wformat-truncation=]
 snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
^~~~
test.c:11:27: note: directive argument in the range [0, 59]
 snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
   ^~
test.c:11:9: note: ‘snprintf’ output between 7 and 9 bytes into a destination
of size 7
 snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
 ^~~

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Tue May 15 21:56:29 2018
New Revision: 260272

URL: https://gcc.gnu.org/viewcvs?rev=260272=gcc=rev
Log:
PR c++/64372 - CWG 1560, gratuitous lvalue-rvalue conversion in ?:

* call.c (build_conditional_expr_1): Don't force_rvalue when one arm
is a throw-expression.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/dr1560.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Committed into trunk in r260271.

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue May 15 21:52:16 2018
New Revision: 260271

URL: https://gcc.gnu.org/viewcvs?rev=260271=gcc=rev
Log:
PR middle-end/85643 - attribute nonstring fails to squash -Wstringop-truncation
warning

gcc/ChangeLog:

PR middle-end/85643
* calls.c (get_attr_nonstring_decl): Handle MEM_REF.

gcc/testsuite/ChangeLog:

PR middle-end/85643
* c-c++-common/attr-nonstring-7.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/attr-nonstring-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85799] __builin_expect doesn't propagate through inlined functions

[redbeard0531 at gmail dot com]

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

--- Comment #1 from Mathias Stearn  ---
LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=37476

[Bug c++/85799] New: __builin_expect doesn't propagate through inlined functions

[redbeard0531 at gmail dot com]

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

Bug ID: 85799
   Summary: __builin_expect doesn't propagate through inlined
functions
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

It seems like __builtin_expect doesn't propagate to conditions when inlined.
This is unfortunate because in some cases it would be nice to be able to put
the expectation into methods so that every user doesn't need to do their own
hinting. Currently we need to use macros to achieve this.

See https://godbolt.org/g/MuPM77 for full example

inline bool expect_false(bool b) {
return __builtin_expect(b, false);
}

void inline_func_hint(bool b) {
if (expect_false(b)) {
unlikely(); // treated as more likely!!!
} else {
likely();
}
}


inline_func_hint(bool):
testdil, dil
je  .L11
jmp unlikely()
.L11:
jmp likely()

[Bug tree-optimization/85788] False positive of -Wstringop-overflow= warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed at -O2 with GCC 8.1 but only at -O3 on trunk where the warning sees:

n ()
{
  int * c;
  int b.2_13;
  int b.2_16;
  int pretmp_25;
  int pretmp_26;
  int _28;
  int _31;
  long unsigned int _33;

   [local count: 1073741826]:
  c_3 = d;
  if (c_3 != 0B)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 1073741817]:
  pretmp_25 = m.g;
  pretmp_26 = m.h;
  _28 = pretmp_25 / 8;
  _31 = pretmp_26 * _28;
  _33 = (long unsigned int) _31;
  b.2_16 = b;
  __builtin___memset_chk (, b.2_16, _33, 64000); [tail call]
  return;

   [local count: 955630226]:
  c_4 = e;
  if (c_4 != 0B)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 955630226]:
  MEM[(int *)] = 140733193420799;
  b.2_13 = b;
  __builtin___memset_chk (, b.2_13, 134180865, 64000);
  goto ; [100.00%]

   [local count: 7731917263]:
  goto ; [100.00%]

   [local count: 8687547448]:
  goto ; [100.00%]

}


In function ‘a’,
inlined from ‘make_str_raster.constprop’ at t.c:17:3,
inlined from ‘n’ at t.c:22:12:
t.c:5:3: warning: ‘__builtin___memset_chk’ writing 134180865 bytes into a
region of size 64000 overflows the destination [-Wstringop-overflow=]
   __builtin___memset_chk(k, b, l, f);
   ^~

[Bug other/85778] unexpected results with -O2, wrong code?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
(In reply to Scott Emmons from comment #4)
> > glibc has stat annotated with nonnull(1, 2)
> 
> 1. Can you provide a reference to this code? This is helpful so that other
> people running into this (and it *will* happen, this ancient code no longer
> runs correctly). Thank you.

stat() is a POSIX function and (similarly to C) POSIX specifies (in 2.1.1 Use
and Implementation of Functions of XSH) that:

If an argument to a function has an invalid value (such as a value outside the
domain of the function, or a pointer outside the address space of the program,
or a null pointer), the behavior is undefined.

A link to the section in the latest spec:
pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_01_01

[Bug fortran/85798] ICE in get_array_index, at fortran/data.c:69

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

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

--- Comment #1 from G. Steinmetz  ---

For comparison :


$ cat z2.f90
program p
   integer, allocatable :: a(:)
   data a(1) / 789 /
end


$ gfortran-9-20180513 -c z2.f90
z2.f90:3:7:

data a(1) / 789 /
   1
Error: DATA attribute conflicts with ALLOCATABLE attribute in 'a' at (1)

[Bug fortran/85798] New: ICE in get_array_index, at fortran/data.c:69

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

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

Bug ID: 85798
   Summary: ICE in get_array_index, at fortran/data.c:69
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

While wrapped in a type, hits versions down to at least 4.8 :


$ cat z1.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type(t) :: z
   data z%a(1) / 789 /
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x68e8da get_array_index
../../gcc/fortran/data.c:69
0x68e8da gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
../../gcc/fortran/data.c:282
0x711ee9 check_data_variable
../../gcc/fortran/resolve.c:15479
0x712232 traverse_data_var
../../gcc/fortran/resolve.c:15608
0x71cd01 resolve_data
../../gcc/fortran/resolve.c:15663
0x71cd01 resolve_types
../../gcc/fortran/resolve.c:16481
0x71839c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16570
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85797] New: ICE in gfc_element_size, at fortran/target-memory.c:126

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

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

Bug ID: 85797
   Summary: ICE in gfc_element_size, at
fortran/target-memory.c:126
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -Wsurprising or -Wall, down to at least 4.8 :


$ cat z1.f90
subroutine a
   c = transfer(a, b)
end


$ cat z2.f90
subroutine a
   c = transfer(a, a)
end


$ cat z3.f90
subroutine a
   c = transfer(b, a)
end


$ cat z4.f90
recursive subroutine a
   c = transfer(a, b)
end


$ gfortran-9-20180513 -c z4.f90
$
$ gfortran-9-20180513 -c z1.f90
z1.f90:2:16:

c = transfer(a, b)
1
Warning: Non-RECURSIVE procedure 'a' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'


$ gfortran-9-20180513 -c z4.f90 -Wsurprising
f951: internal compiler error: Invalid expression in gfc_element_size.
0x6a7d3f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1358
0x73cdbb gfc_element_size(gfc_expr*)
../../gcc/fortran/target-memory.c:126
0x73ce01 gfc_target_expr_size(gfc_expr*)
../../gcc/fortran/target-memory.c:152
0x684a23 gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned
long*, unsigned long*, unsigned long*)
../../gcc/fortran/check.c:5408
0x684b88 gfc_check_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/check.c:5472
0x6baf24 check_specific
../../gcc/fortran/intrinsic.c:4545
0x6c4ee4 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4781
0x70ee65 resolve_unknown_f
../../gcc/fortran/resolve.c:2870
0x70ee65 resolve_function
../../gcc/fortran/resolve.c:3179
0x70ef8a gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6719
0x715810 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11100
0x7182aa resolve_codes
../../gcc/fortran/resolve.c:16537
0x7183ae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16572
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85796] New: ICE: Floating point exception

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

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

Bug ID: 85796
   Summary: ICE: Floating point exception
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Invalid and supplementary to pr84134, ICEs down to at least 4.8 :


$ cat z1.f90
program p
   integer :: i, j, x(2,2)
   data ((x(i,j), i=1,2,j-1), j=1,2) /3*789/
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Floating point exception
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x7123ee traverse_data_list
../../gcc/fortran/resolve.c:15554
0x7123ee traverse_data_var
../../gcc/fortran/resolve.c:15606
0x712436 traverse_data_list
../../gcc/fortran/resolve.c:15564
0x712436 traverse_data_var
../../gcc/fortran/resolve.c:15606
0x71cd01 resolve_data
../../gcc/fortran/resolve.c:15663
0x71cd01 resolve_types
../../gcc/fortran/resolve.c:16481
0x71839c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16570
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85786] [8/9 Regression] Segfault in associated intrinsic

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Tue, May 15, 2018 at 06:47:49PM +, dominiq at lps dot ens.fr wrote:
> 
> --- Comment #6 from Dominique d'Humieres  ---
> Likely r251949.
> 

There are no changes within trans-intrinsic.c(gfc_conv_associated)
that correspond to that revision.  My best guess with looking at
'svn annotate' is the offending commit is r190641.  The function
has grown over time, the missing lines I inserted with my patch
may have at one time been present but code motion moved them to
a different block.

[Bug fortran/72714] [6/7/8/9 Regression] [Coarray] ICE in gfc_array_init_size, at fortran/trans-array.c:5235

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

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

G. Steinmetz  changed:

   What|Removed |Added

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

--- Comment #4 from G. Steinmetz  ---
Simplified a bit :


$ cat z5.f90
program p
   integer, allocatable :: z[:,:]
   allocate (z[:2,*])
end


$ gfortran-9-20180513 -c z5.f90 -fcoarray=single
z5.f90:3:0:

allocate (z[:2,*])

internal compiler error: in gfc_array_init_size, at fortran/trans-array.c:5496
0x757ac0 gfc_array_init_size
../../gcc/fortran/trans-array.c:5496
0x757ac0 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, tree_node*, bool)
../../gcc/fortran/trans-array.c:5770
0x7bb737 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6300
0x74b6e7 trans_code
../../gcc/fortran/trans.c:1996
0x772c49 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701d40 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701d40 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85786] [8/9 Regression] Segfault in associated intrinsic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[regression] Segfault in|[8/9 Regression] Segfault
   |associated intrinsic|in associated intrinsic

--- Comment #6 from Dominique d'Humieres  ---
Likely r251949.

Note that on darwin I don't get any segfault but only

...
loc(cs%v(2)%p) = 140579551852496
 not associated

[Bug fortran/85786] [regression] Segfault in associated intrinsic

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Tue, May 15, 2018 at 05:49:15PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786
> 
> kargl at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>Priority|P3  |P4
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2018-05-15
>  CC||pault at gcc dot gnu.org
>   Known to work||6.4.1, 7.3.1
> Summary|Segfault in associated  |[regression] Segfault in
>|intrinsic   |associated intrinsic
>  Ever confirmed|0   |1
>   Known to fail||8.1.1, 9.0
> 

Seems I liekly found the issue.

Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c   (revision 260235)
+++ gcc/fortran/trans-intrinsic.c   (working copy)
@@ -7903,6 +7903,8 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
   /* A pointer to an array, call library function _gfor_associated. 
*/
   arg1se.want_pointer = 1;
   gfc_conv_expr_descriptor (, arg1->expr);
+ gfc_add_block_to_block (>pre, );
+ gfc_add_block_to_block (>post, );

   arg2se.want_pointer = 1;
   gfc_conv_expr_descriptor (, arg2->expr);

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug fortran/85786] [regression] Segfault in associated intrinsic

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 CC||pault at gcc dot gnu.org
  Known to work||6.4.1, 7.3.1
Summary|Segfault in associated  |[regression] Segfault in
   |intrinsic   |associated intrinsic
 Ever confirmed|0   |1
  Known to fail||8.1.1, 9.0

--- Comment #4 from kargl at gcc dot gnu.org ---
This could be fallout from the recent change in the
internal representation of the array descriptor.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

--- Comment #9 from Paul Smith  ---
Sorry; Andrew's original reply seemed to say that the use-case is
non-conforming so the issue was WONTFIX.  I also thought your comment #6 was
referring to my example in comment #5: I just wanted to clarify that that
example was conforming (although still, admittedly, very unrealistic).

If this issue is best left WONTFIX in deference to the more accurate/detailed
one you opened that's fine with me.

Cheers!

[Bug fortran/85786] Segfault in associated intrinsic

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, May 15, 2018 at 04:50:41AM +, angus at agibson dot me wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786
> 
> --- Comment #2 from Angus Gibson  ---
> Changing the declaration of e to also be 'target', and associating the 
> pointer:
> 
> CS%v(2)%p => e
> if (query_ptr(e, CS)) then
> ...
> 
> still causes the segfault.  Perhaps I disconnected this from the original code
> too much! Even if CS%v(2)%p wasn't associated, I don't see why there should be
> a segfault?

Here's a slight rewrite with debugging print statements.
Certainly, seems like you've found a bug :(


program test

   implicit none

   type :: p2d
  real, pointer :: p(:,:) => null()
   end type p2d

   type :: test_cs
  type(p2d), pointer :: v(:) => null()
   end type test_cs

   type(test_cs), pointer :: cs
   real, allocatable, target :: e(:,:)

   allocate(cs)
   print '(A,L1)', 'associated(cs) = ', associated(cs)

   allocate(cs%v(2))
   print '(A,L1)', 'associated(cs%v) = ', associated(cs%v)

   allocate(e(2,2))
   e = 42
   print '(A,I0)', 'loc(e) = ', loc(e)
   print '(A,4F6.1)', 'e = ', e

   if (query_ptr(e, cs)) then
  print *, 'associated'
   else
  print *, 'not associated'
   end if

   contains

  logical function query_ptr(f_ptr, cs)

 real, target, intent(in) :: f_ptr(:,:)
 type(test_cs), pointer, intent(inout) :: cs

 print '(A,I0)','loc(f_ptr) = ', loc(f_ptr)
 print '(A,4F6.1)', 'f_ptr = ', f_ptr

 if (associated(cs)) then
print *, 'in query'
print '(A,L1)', 'associated(cs%v) = ', associated(cs%v)
cs%v(2)%p => f_ptr
print '(A,L1)', 'associated(cs%v(2)%p) = ', associated(cs%v(2)%p)
print '(A,I0)', 'loc(cs%v(2)%p) = ', loc(cs%v(2)%p)
query_ptr = associated(cs%v(2)%p, f_ptr)
 else
query_ptr = .false.
 end if
  end function query_ptr

end program test

Pretty good indication of why I don't use pointers.

[Bug c++/83400] g++ -O1 doesn't execute any code in destructors with a throw statement if it sees another throw

[redbeard0531 at gmail dot com]

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

--- Comment #3 from Mathias Stearn  ---
This is related to https://wg21.link/CWG2219

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
There is no standard way to say "don't inline this function."  It's up to the
compiler to decide what to inline just so long as it doesn't violate the
requirements.

There is also no requirement that the definition of the replacement operator
contain an explicit throw statement.  Your example in comment #5 is fine.

But I'm not sure what the point is of these questions.  I explained what causes
the warning, and what makes the original test case less than 100% conforming. 
I'm not disputing that the warning is unhelpful (with a conforming test case or
otherwise), or that it would be nice to avoid.  I just don't see a way to do it
in GCC (except by fixing bug 85795).  That's why I resolved this as WONTFIX and
not as INVALID, and why I opened bug 85795.  That's a separate conformance
issue that should be considered on its own.  If that happens to get rid of the
warning that's a bonus.

What would you prefer me to do instead?

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

--- Comment #7 from Paul Smith  ---
Is there a way (in standard C++) to force non-inline?  I'm not aware of one. 
So that means the only standard-conforming way to replace operator new is if
it's in its own compilation unit all by itself?  I don't have a copy of the
standard but cppreference says only that replacement operator new can't have an
inline specifier, that it can't be static, and that it has to be in the global
namespace, all of which requirements this example appears to meet.

Regarding throw, does the standard really say that the throw must be explicit
in the implementation of the function directly?  If my operator new[] invokes a
function to throw, rather than throwing directly, is that not
standard-conforming?  That seems bizarre to me: just because the compiler can't
prove to itself that my operator new will throw properly, the compiler is
allowed to assume the code is non-conforming?

[Bug tree-optimization/85794] [8/9 Regression][AArch64] ICE in expand_vector_condition in GIMPLE pass: veclower2

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |8.2
 Ever confirmed|0   |1

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

[Bug libstdc++/85749] Possible -Wsign-conversion false negative with std::default_random_engine

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Inlining happens automatically unless it's disabled.  The inlining of the
operator results in the excessive constant argument (created by the C++
front-end) to propagate to the call to malloc().  That's what triggers the
warning.  The GIMPLE for the function in my smaller test case (from the output
of -fdump-tree-gimple) shows this:

f (size_t n)
{
  void * D.6084;
  void * D.6059;
  size_t iftmp.1;
  long unsigned int n.2;
  struct A * retval.3;
  struct A * D.6060;
  struct A * D.6061;
  long int D.6062;
  size_t iftmp.4;

  if (n == 0) goto ; else goto ;
  :
  D.6084 = 0B;
  // predicted unlikely by early return (on trees) predictor.
  return D.6084;
  :
  n.2 = n;
  if (n.2 <= 9223372036854775800) goto ; else goto ;
  :
  iftmp.1 = n.2 + 8;
  goto ;
  :
  iftmp.1 = 18446744073709551615;   <<< SIZE_MAX
  :
  D.6059 = operator new [] (iftmp.1);   <<< call to replacement operator new
  MEM[(sizetype *)D.6059] = n.2;

(Adding attribute noinline to the operator eliminates the warning.)

As we discussed in the past, the C++ standard imposes a couple of requirements
on replacement operator new that your test case violates:

1) it must not be declared inline (there must be exactly one operator new in a
program)
2) it must either return valid new pointer or fail by throwing an exception

To make the test case strictly valid the replacement operator would either have
to throw, or it would have to be the nothrow form (taking const std::nothrow_t&
as an argument), and the call to it would have to pass it std::nothrow.

The warning doesn't trigger if the replacement operator throws.  It does
trigger for the nothrow operator, which is why I agree the warning in that case
is a false positive.  (But you're not replacing the nothrow operator.)

Having said that, the C++ standard requires compilers to avoid calling the
allocation function with an argument in excess of some implementation-defined
limit, but GCC calls it regardless (e.g., it calls it with N = SIZE_MAX for new
(nothrow) T[N] even when sizeof (T) > 1).  That's a bug, and (indirectly) the
reason for the warning.  I've raised bug 85795 for that.

[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Tue May 15 16:39:43 2018
New Revision: 260266

URL: https://gcc.gnu.org/viewcvs?rev=260266=gcc=rev
Log:

PR lto/85583
* lto-partition.c (account_reference_p): Do not account
references from aliases; do not account refernces from
external initializers.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-partition.c

[Bug c++/85795] New: bad_alloc thrown from allocation function when bad_array_length is expected

[msebor at gcc dot gnu.org]

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

Bug ID: 85795
   Summary: bad_alloc thrown from allocation function when
bad_array_length is expected
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

(This report was prompted by bug 85783.)

In [expr.new], p7, the C++ standard requires implementations to avoid calling
an allocation function when the non-constant size expression in a new
expression is in excess of some implementation-defined limit.  I can't find
this limit documented anywhere but it stands to reason it's no more than
SIZE_MAX.  The program below shows that G++ violates this requirement and calls
the allocation function regardless.  The code that causes this was added in
r190546 as a fix for bug 19351.  (Jason privately confirmed that this is a
likely bug.)

$ cat u.C && g++ -O2 -Wall u.C && ./a.out 
#include 

typedef __SIZE_TYPE__ size_t;

void* operator new[](size_t n)
{
  __builtin_printf ("%s (%zx)\n", __func__, n);

  if (void* p = __builtin_malloc (n))
return p;

  throw std::bad_alloc ();
}

struct A
{
  int i;

  A ();
  ~A ();
};

__attribute__ ((noipa)) A::A () { }
__attribute__ ((noipa)) A::~A () { }

size_t n = __SIZE_MAX__ / 2 - 1;

int main ()
{
  __builtin_printf ("calling new A[%zx]: expect bad_array_new_length\n", n);

  try {
void *p = new A[n];
__builtin_printf ("%p: failure\n", p);
  }
  catch (const std::bad_array_new_length&) {
__builtin_printf ("caught bad_array_new_length: success\n");
return 0;
  }
  catch (const std::bad_alloc&) {
__builtin_printf ("caught bad_alloc: failure\n");
  }
  catch (...) {
__builtin_printf ("caught unknown exception: failure\n");
  }

  __builtin_abort ();
}
calling new A[7ffe]: expect bad_array_new_length
operator new [] ()
caught bad_alloc: failure
Aborted (core dumped)

[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 CC||amker at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from amker at gcc dot gnu.org ---
Confirmed.  I will have a look.

[Bug target/85791] multiply overflow (128 bit)

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Ruslan Nikolaev from comment #0)
> 2. unsigned long long func(unsigned long long a, unsigned long long b)
> {
> __uint128_t c = (__uint128_t) a * b;
> if (c > (unsigned long long) -1LL) {

It should not be too hard to recognize in GIMPLE the case of a widening mul of
unsigned numbers that has only 2 uses, one narrowing, the other comparing to
this constant (or to a widened version of the narrowed value, or extracting the
high part and comparing it to 0, etc).

Independently, it may be possible to teach RTL/target that some mul+cmp+jump is
equivalent to mul+jmp.

[Bug other/85778] unexpected results with -O2, wrong code?

[sesail999 at gmail dot com]

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

--- Comment #4 from Scott Emmons  ---
> glibc has stat annotated with nonnull(1, 2)

1. Can you provide a reference to this code? This is helpful so that other
people running into this (and it *will* happen, this ancient code no longer
runs correctly). Thank you.

2. The manpage for stat(2) should be updated to reflect that calling stat()
with a NULL pathname will result in unpredictable behavior.

3. I'll create a pull request against cronolog and work with Debian/Ubuntu to
at least get it fixed in those distributions.

[Bug tree-optimization/85794] New: [8/9 Regression][AArch64] ICE in expand_vector_condition in GIMPLE pass: veclower2

[sudi at gcc dot gnu.org]

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

Bug ID: 85794
   Summary: [8/9 Regression][AArch64] ICE in
expand_vector_condition in GIMPLE pass: veclower2
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi at gcc dot gnu.org
  Target Milestone: ---

The following code ICEs with -O3 with aarch64-none-linux-gnu

int a, b, *c, d, *e;
int *f[6];
void fn1() {
  b = 1;
  for (; b >= 0; b--) {
d = 0;
for (; d <= 3; d++) {
  int **g = 
  *g = 
  *e |= f[b * 5] != c;
}
  }
}

./build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-gcc f.c -O3
-S -fdump-tree-all
during GIMPLE pass: veclower2
dump file: f.c.173t.veclower21
f.c: In function ‘fn1’:
f.c:6:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~
0xbd57ff crash_signal
/work/trunk/src/gcc/gcc/toplev.c:325
0xe55d90 tree_class_check
/work/trunk/src/gcc/gcc/tree.h:3257
0xe55d90 expand_vector_condition
/work/trunk/src/gcc/gcc/tree-vect-generic.c:901
0xe587c1 expand_vector_operations_1
/work/trunk/src/gcc/gcc/tree-vect-generic.c:1582
0xe587c1 expand_vector_operations
/work/trunk/src/gcc/gcc/tree-vect-generic.c:1829
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/85749] Possible -Wsign-conversion false negative with std::default_random_engine

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 15:36:46 2018
New Revision: 260263

URL: https://gcc.gnu.org/viewcvs?rev=260263=gcc=rev
Log:
PR libstdc++/85749 constrain seed sequences for random number engines

Constrain constructors and member functions of random number engines so
that functions taking seed sequences can only be called with types that
meet the seed sequence requirements.

PR libstdc++/85749
* include/bits/random.h (__detail::__is_seed_seq): New SFINAE helper.
(linear_congruential_engine, mersenne_twister_engine)
(subtract_with_carry_engine, discard_block_engine)
(independent_bits_engine, shuffle_order_engine): Use __is_seed_seq to
constrain function templates taking seed sequences.
* include/bits/random.tcc (linear_congruential_engine::seed(_Sseq&))
(mersenne_twister_engine::seed(_Sseq&))
(subtract_with_carry_engine::seed(_Sseq&)): Change return types to
match declarations.
* include/ext/random (simd_fast_mersenne_twister_engine): Use
__is_seed_seq to constrain function templates taking seed sequences.
* include/ext/random.tcc (simd_fast_mersenne_twister_engine::seed):
Change return type to match declaration.
* testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/independent_bits_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/linear_congruential_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/mersenne_twister_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lineno.
* testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/
seed_seq2.cc: New.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/
seed_seq2.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/independent_bits_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/mersenne_twister_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/subtract_with_carry_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed_seq2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc
trunk/libstdc++-v3/include/ext/random
trunk/libstdc++-v3/include/ext/random.tcc
trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc

[Bug tree-optimization/85720] bad codegen for looped assignment of primitives at -O2

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> (In reply to Mathias Stearn from comment #4)
> > (In reply to Marc Glisse from comment #3)
> > > Again, you are ignoring aliasing issues (just like in your other PR the
> > > function copy isn't equivalent to memmove). Does adding __restrict change
> > > the result? Also, B[i]=B[i]+1 doesn't look like a memset...
> > 
> > Sorry, I typoed. It was supposed to be B[i] = A[i] + 1. That still does
> > basically the same thing though: https://godbolt.org/g/dtmU5t. Good point
> > about aliasing though. I guess the right code gen in that case would
> > actually be something that detected the overlap and did the right calls to
> > memset to only set each byte once. Or just do the simple thing:
> > 
> > if (b > a && b < a + n) {
> >   memset(b, 1, n);
> >   memset(a, 0, n);
> > } else {
> >   memset(a, 0, n);
> >   memset(b, 1, n);
> > }
> > 
> > Yes, __restrict helps, but that isn't part of standard c++, and it seems
> > like it never will be.
> 
> GCC supports it since forever...  but yes, currently loop distribution
> doesn't consider runtime aliasing in this case (it can do it now but
This should be easy to improve for builtin distribution cases.
> is keyed to vectorization).  It also doesn't have a way to distinguish
> forward vs. backward dependence and split the case like you propose.
IMHO, this isn't optimizer's responsibility.  If break-conditions for
forward/backward dependence need to be supported, it seems more reasonable to
be supported in dependence analysis.

[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Problem is that we do not account correctly duplicated symbols because we do
not
add them into boundary
Index: lto/lto-partition.c
===
--- lto/lto-partition.c (revision 260258)
+++ lto/lto-partition.c (working copy)
@@ -439,13 +439,24 @@
 {
   if (cgraph_node *cnode = dyn_cast  (n1))
 n1 = cnode;
+  /* Do not account references from aliases - they are never split across
+ partitions.  */
+  if (n1->alias)
+return false;
   /* Do not account recursion - the code below will handle it incorrectly
- otherwise.  Also do not account references to external symbols.
- They will never become local.  */
+ otherwise.  Do not account references to external symbols: they will
+ never become local.  Finally do not account references to duplicated
+ symbols: they will be always local.  */
   if (n1 == n2 
-  || DECL_EXTERNAL (n2->decl)
-  || !n2->definition)
+  || !n2->definition
+  || n2->get_partitioning_class () != SYMBOL_PARTITION)
 return false;
+  /* If referring node is duplicated symbol, we can not compute the boundary
+ cost, because we do not know what partition will be added to until
+ the boundary is computed.  */
+  if (contained_in_symbol (n1)
+   ->get_partitioning_class () != SYMBOL_PARTITION)
+return false;
   return true;
 }

[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

[Bug c/85793] New: [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[sudi at gcc dot gnu.org]

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

Bug ID: 85793
   Summary: [8/9 Regression][AARCH64] ICE in verify_gimple during
GIMPLE pass vect.
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi at gcc dot gnu.org
  Target Milestone: ---

The following test case fails with aarch64-none-lunux-gnu-gcc -O3

int a, c, d;
long b[6];
void fn1() {
  for (; a < 2; a++) {
c = 0;
for (; c <= 5; c++)
  d &= b[a * 3];
  }
}

$ ./build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-gcc f.c -O3
-fdump-tree-all-all
f.c: In function ‘fn1’:
f.c:7:6: error: type mismatch in vector pack expression
 void fn1() {
  ^~~
vector(2) int
long int
long int
vect__3.16_63 = VEC_PACK_TRUNC_EXPR <_59, _61>;
during GIMPLE pass: vect
dump file: f.c.161t.vect
f.c:7:6: internal compiler error: verify_gimple failed
0xc2dcb8 verify_gimple_in_cfg(function*, bool)
/work/trunk/src/gcc/gcc/tree-cfg.c:5355
0xaee93a execute_function_todo
/work/trunk/src/gcc/gcc/passes.c:1994
0xaef385 execute_todo
/work/trunk/src/gcc/gcc/passes.c:2048
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/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[vincent-gcc at vinc17 dot net]

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

--- Comment #27 from Vincent Lefèvre  ---
(In reply to Waynem Ccollough from comment #26)
> Does the issue already fixed? 

For the simplest cases, it is. But complex cases still trigger a warning, see
e.g. PR 80454.

[Bug target/85791] multiply overflow (128 bit)

[nruslan_devel at yahoo dot com]

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

--- Comment #3 from Ruslan Nikolaev  ---
That is OK, I was talking about an extra 'cmp' instruction for the case when
the check is explicit

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[waynemccollough at gmx dot com]

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

Waynem Ccollough  changed:

   What|Removed |Added

 CC||waynemccollough at gmx dot com

--- Comment #26 from Waynem Ccollough  ---
Does the issue already fixed? 

Waynem Ccollough
https://amsterdamdiary.com/

[Bug libstdc++/84159] filesystem::path::operator/= with has root directory path

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 8.2, thanks for the report.

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #3 from Jonathan Wakely  ---
Fixed for 8.2, thanks for the report.

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 13:51:03 2018
New Revision: 260260

URL: https://gcc.gnu.org/viewcvs?rev=260260=gcc=rev
Log:
PR libstdc++/83891 fix path::is_absolute() for non-POSIX targets

The correct definition seems to be has_root_directory() for all systems
we care about.

PR libstdc++/83891
* include/bits/fs_path.h (path::is_absolute()): Use same definition
for all operating systems.
* include/experimental/bits/fs_path.h (path::is_absolute()): Likewise.
* testsuite/27_io/filesystem/path/query/is_absolute.cc: New.
* testsuite/27_io/filesystem/path/query/is_relative.cc: Fix comment.
* testsuite/experimental/filesystem/path/query/is_absolute.cc: New.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/query/is_absolute.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/fs_path.h
branches/gcc-8-branch/libstdc++-v3/include/experimental/bits/fs_path.h
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_relative.cc

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 13:50:49 2018
New Revision: 260259

URL: https://gcc.gnu.org/viewcvs?rev=260259=gcc=rev
Log:
PR libstdc++/83891 fix path::is_absolute() for non-POSIX targets

The correct definition seems to be has_root_directory() for all systems
we care about.

PR libstdc++/83891
* include/bits/fs_path.h (path::is_absolute()): Use same definition
for all operating systems.
* include/experimental/bits/fs_path.h (path::is_absolute()): Likewise.
* testsuite/27_io/filesystem/path/query/is_absolute.cc: New.
* testsuite/27_io/filesystem/path/query/is_relative.cc: Fix comment.
* testsuite/experimental/filesystem/path/query/is_absolute.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/path/query/is_absolute.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fs_path.h
trunk/libstdc++-v3/include/experimental/bits/fs_path.h
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_relative.cc

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
The bug is latent on gcc7 and gcc6, I plan to commit the fix there at the end
of this week.

[Bug tree-optimization/85757] tree optimizers fail to fully clean up fixed-size memcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Mine.  Working on some refactoring to make this possible.

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #4 from Richard Biener  ---
Thanks.

[Bug target/85791] multiply overflow (128 bit)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |target

--- Comment #2 from Andrew Pinski  ---
Note on some x86, cmov is slower than using the conditional branch.

[Bug c/85791] multiply overflow (128 bit)

[nruslan_devel at yahoo dot com]

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

--- Comment #1 from Ruslan Nikolaev  ---
Optimization flags -O2 in all cases

[Bug libstdc++/85792] New: #include triggers Wctor-dtor-privcay

[sshannin at gmail dot com]

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

Bug ID: 85792
   Summary: #include  triggers Wctor-dtor-privcay
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sshannin at gmail dot com
  Target Milestone: ---

seth@dev9:~$ cat tmp.cpp
#include 

seth@dev9:~$ /build/toolchain13/bin/g++ tmp.cpp -Wctor-dtor-privacy -std=c++17
-c
In file included from tmp.cpp:1:
/build/toolchain13/include/c++/8.1.0/variant:463:7: note:
‘std::__detail::__variant::_Copy_ctor_base<,
_Types>::_Copy_ctor_base(const
std::__detail::__variant::_Copy_ctor_base<, _Types>&)’ is public,
but requires an existing ‘struct
std::__detail::__variant::_Copy_ctor_base<, _Types>’ object
   _Copy_ctor_base(const _Copy_ctor_base& __rhs)
   ^~~
/build/toolchain13/include/c++/8.1.0/variant:497:7: note:
‘std::__detail::__variant::_Move_ctor_base<,
_Types>::_Move_ctor_base(std::__detail::__variant::_Move_ctor_base<,
_Types>&&)’ is public, but requires an existing ‘struct
std::__detail::__variant::_Move_ctor_base<, _Types>’ object
   _Move_ctor_base(_Move_ctor_base&& __rhs)
   ^~~
/build/toolchain13/include/c++/8.1.0/variant:562:7: note:
‘std::__detail::__variant::_Copy_assign_base<,
_Types>::_Copy_assign_base(const
std::__detail::__variant::_Copy_assign_base<, _Types>&)’ is public,
but requires an existing ‘struct
std::__detail::__variant::_Copy_assign_base<, _Types>’ object
   _Copy_assign_base(const _Copy_assign_base&) = default;
   ^
/build/toolchain13/include/c++/8.1.0/variant:631:7: note:
‘std::__detail::__variant::_Move_assign_base<,
_Types>::_Move_assign_base(const
std::__detail::__variant::_Move_assign_base<, _Types>&)’ is public,
but requires an existing ‘struct
std::__detail::__variant::_Move_assign_base<, _Types>’ object
   _Move_assign_base(const _Move_assign_base&) = default;
   ^

seth@dev9:~$ /build/toolchain13/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/build/toolchain13/bin/g++
COLLECT_LTO_WRAPPER=/build/toolchain13/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_8_1_0/configure --prefix=/build/toolchain13
--enable-languages=c,c++ --enable-lto --disable-plugin --program-suffix=-8.1.0
--disable-multilib --disable-shared
Thread model: posix
gcc version 8.1.0 (GCC) 
seth@dev9:~$

[Bug c/85791] New: multiply overflow (128 bit)

[nruslan_devel at yahoo dot com]

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

Bug ID: 85791
   Summary: multiply overflow (128 bit)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

Just noticed that code is generated differently when using
__builtin_mul_overflow and an explicit check:

1. unsigned long long func(unsigned long long a, unsigned long long b)
{
unsigned long long c;
if (__builtin_mul_overflow(a, b, ))
return 0;
return c;
}

yields:
func:
.LFB0:
.cfi_startproc
movq%rdi, %rax
mulq%rsi
jo  .L7
rep ret
.L7:
xorl%eax, %eax
ret

2. unsigned long long func(unsigned long long a, unsigned long long b)
{
__uint128_t c = (__uint128_t) a * b;
if (c > (unsigned long long) -1LL) {
return 0;
}
return (unsigned long long) c;
}

yields slightly less efficient code:

func:
.LFB0:
.cfi_startproc
movq%rdi, %rax
mulq%rsi
cmpq$0, %rdx
jbe .L2
xorl%eax, %eax
.L2:
rep ret

3. clang/llvm can generate better code (identical) in both cases:

func:   # @func
.cfi_startproc
# %bb.0:
xorl%ecx, %ecx
movq%rdi, %rax
mulq%rsi
cmovoq  %rcx, %rax
retq

[Bug libstdc++/84159] filesystem::path::operator/= with has root directory path

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 12:57:25 2018
New Revision: 260257

URL: https://gcc.gnu.org/viewcvs?rev=260257=gcc=rev
Log:
PR libstdc++/84159 fix appending strings to paths

The path::operator/=(const Source&) and path::append overloads were
still following the semantics of the Filesystem TS not C++17. Only
the path::operator/=(const path&) overload was correct.

This change adds more tests for path::operator/=(const path&) and adds
new tests to verify that the other append operations have equivalent
behaviour.

PR libstdc++/84159
* include/bits/fs_path.h (path::operator/=, path::append): Construct
temporary path before calling _M_append.
(path::_M_append): Change parameter to path and implement C++17
semantics.
* testsuite/27_io/filesystem/path/append/path.cc: Add helper function
and more examples from the standard.
* testsuite/27_io/filesystem/path/append/source.cc: New.
* testsuite/27_io/filesystem/path/decompose/filename.cc: Add comment.
* testsuite/27_io/filesystem/path/nonmember/append.cc: New.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/nonmember/append.cc
  - copied, changed from r260247,
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/append/path.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/fs_path.h
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/append/path.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/decompose/filename.cc

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

--- Comment #5 from Paul Smith  ---
I simplified my example too much; I think this should be re-opened.

In my real code, operator new[] does not invoke exit(); it invokes my own
function (which is defined as noreturn, but that's not required).  There's no
way for the compiler to know whether this function will throw or not, so
"replacing a non-throwing operator new[]" isn't why my case is not working. 
Also, you mention an inline implementation of operator new[], but there's
nothing in your code example that I can see that forces my replacement to be
inline.  Is there some magic about global operator new replacement that I'm
forgetting?

Here's an example which still fails with the warning and which I think is valid
C++ (interestingly this version requires -O2 to show the problem):

void allocFail(__SIZE_TYPE__ _s);

void* operator new[](__SIZE_TYPE__ n)
{
  void* p = __builtin_malloc (n);
  if (!p)  allocFail (n);
  return p;
}

struct A
{
  A ();
  ~A ();
};


void* f (__SIZE_TYPE__ n)
{
  if (!n)
return 0;

  return new A[n];
}

In function 'void* operator new [](long unsigned int)',
inlined from 'void* f(long unsigned int)' at p1.cpp:22:17:
p1.cpp:5:30: warning: argument 1 value '18446744073709551615' exceeds maximum
object size 9223372036854775807 [-Walloc-size-larger-than=]
   void* p = __builtin_malloc (n);
 ~^~~
p1.cpp: In function 'void* f(long unsigned int)':
p1.cpp:5:30: note: in a call to built-in allocation function 'void*
__builtin_malloc(long unsigned int)'

[Bug libstdc++/84159] filesystem::path::operator/= with has root directory path

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 12:07:09 2018
New Revision: 260255

URL: https://gcc.gnu.org/viewcvs?rev=260255=gcc=rev
Log:
PR libstdc++/84159 fix appending strings to paths

The path::operator/=(const Source&) and path::append overloads were
still following the semantics of the Filesystem TS not C++17. Only
the path::operator/=(const path&) overload was correct.

This change adds more tests for path::operator/=(const path&) and adds
new tests to verify that the other append operations have equivalent
behaviour.

PR libstdc++/84159
* include/bits/fs_path.h (path::operator/=, path::append): Construct
temporary path before calling _M_append.
(path::_M_append): Change parameter to path and implement C++17
semantics.
* testsuite/27_io/filesystem/path/append/path.cc: Add helper function
and more examples from the standard.
* testsuite/27_io/filesystem/path/append/source.cc: New.
* testsuite/27_io/filesystem/path/decompose/filename.cc: Add comment.
* testsuite/27_io/filesystem/path/nonmember/append.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/nonmember/append.cc
  - copied, changed from r260254,
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/append/path.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fs_path.h
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/append/path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/decompose/filename.cc

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> If the variable is unused, why is any stack assigned to it?

I guess it's due to -O0 or am I wrong?

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
If the variable is unused, why is any stack assigned to it?

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Is it resolved now?

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #3)
> Can we say in sanopt look for variables only referenced in these
> poison/unpoison ifns and not by anything else and just drop those ifns?

That's actually what happens, we remove all IFNs for these variables. But then
their stack slot is poisoned (by another VAR_DECL shading a slot) and we don't
do a clean-up in function epilogue.

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from Wilco  ---
(In reply to Tamar Christina from comment #2)
> It's not r250673, That was committed 2017-07-28 and a GCC built 2017-08-17
> does the correct thing for non-Armv8.2-a. It promotes the fp16 values to 32
> bits does the operations and converts them back to fp16.
> 
> somewhere along the line something has decided to no longer do this. I can
> fix the ICE by adding the missing pattern explicitly, but it should have not
> generated this insn to begin with.

Yes it looks like a reload bug - choosing an alternative without checking it is
valid.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #6 from Martin Liška  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Martin Liška  ---
> [...]
> > According to log file alias support is mission on solaris. Thus following 
> > patch
> > should fix that by skipping the test:
> >
> > diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> > b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> > index 85531ab1cf3..45525844551 100644
> > --- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> > +++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> > @@ -1,4 +1,5 @@
> >  /* { dg-do link } */
> > +/* { dg-require-alias "" } */
> >  /* { dg-options "-O2 -fdump-ipa-icf -flto -fdump-tree-fixup_cfg4" } */
> >  /* { dg-require-effective-target lto } */
> >  /* { dg-additional-sources "ipa-icf-38a.c" }*/
> >
> > Can you please verify that?
> 
> The patch doesn't make a difference as Solaris *does* support attribute
> alias, even when using as and ld.  However, I noticed that the
> unmodified test PASSes when using gas/gld instead, so there is a
> toolchain difference that causes this failure.

So can you please debug why we go into following branch:
  1277if (!create_wrapper
  1278&& !alias->call_for_symbol_and_aliases
(cgraph_node::has_thunk_p,
  1279NULL, true)
  1280&& !alias->can_remove_if_no_direct_calls_p ())
  1281  {
  1282if (dump_file)
  1283  fprintf (dump_file, "Not unifying; can not make wrapper and
"
  1284   "function has other uses than direct calls\n\n");
  1285return false;
  1286  }

I'm curious why can_remove_if_no_direct_calls_p returns false.

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Can we say in sanopt look for variables only referenced in these
poison/unpoison ifns and not by anything else and just drop those ifns?

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
It's very interesting issue, took me some time to investigate what happens.
So first gimplifier creates a stack vars that have no usage:

Setup ()
{
  const struct function D.31062;
  struct __lambda0 D.30927;
  struct __lambda0 D.35389;
  const struct function D.31201;
  struct __lambda1 D.31102;
  struct __lambda1 D.35390;

  {
switch (1) , case 1: , case 2: >
{
  :
  {
typedef struct __lambda0 __lambda0;

ASAN_MARK (UNPOISON, , 32);
ASAN_MARK (UNPOISON, , 1);
try
  {
std::function::function > (,
D.35389);
try
  {
try
  {
DoFunc ();
  }
finally
  {
std::function::~function ();
  }
  }
finally
  {
ASAN_MARK (POISON, , 32);
  }
  }
finally
  {
ASAN_MARK (POISON, , 1);
  }
goto ;
  }
  :
  {
typedef struct __lambda1 __lambda1;

ASAN_MARK (UNPOISON, , 32);
ASAN_MARK (UNPOISON, , 1);
try
  {
std::function::function > (,
D.35390);
try
  {
try
  {
DoFunc ();
  }
finally
  {
std::function::~function ();
  }
  }
finally
  {
ASAN_MARK (POISON, , 32);
  }
  }
finally
  {
ASAN_MARK (POISON, , 1);
  }
goto ;
  }
  :
  goto ;
}
:
  }
  DoSomething ();
}


The problematic one is e.g. struct __lambda0 D.30927;
It looks as follows after asan0 pass:

;; Function Setup (_Z5Setupv, funcdef_no=1368, decl_uid=30911, cgraph_uid=294,
symbol_order=298)

Setup ()
{
  struct __lambda1 D.35390;
  struct __lambda1 D.31102;
  const struct function D.31201;
  struct __lambda0 D.35389;
  struct __lambda0 D.30927;
  const struct function D.31062;

   :
  ASAN_MARK (UNPOISON, , 32);
  ASAN_MARK (UNPOISON, , 1);
  std::function::function > (, D.35389);

   :
  DoFunc ();

   :
  std::function::~function ();
  ASAN_MARK (POISON, , 32);
  ASAN_MARK (POISON, , 1);

   :
  DoSomething ();
  return;

   :
:
  std::function::~function ();
  resx 3

   :
:
  ASAN_MARK (POISON, , 32);
  resx 2

   :
:
  ASAN_MARK (POISON, , 1);
  resx 1

}


Then sanopt removes all ASAN_MARK statements for the  Then we end up
with following stack partitioning:

Partition 1: size 32 align 16
D.31201 D.31062
Partition 0: size 1 align 8
D.31102 D.30927

And we have trouble as asan_emit_stack_protection is called for the stack
variables that have none usage.
Thus following code in asan.c is never executed:

  1520/* Unpoison shadow memory that corresponds to a variable that is 
  1521   is subject of use-after-return sanitization.  */
  1522if (l > 2)
  1523  {
  1524decl = decls[l / 2 - 2];
  1525if (asan_handled_variables != NULL
  1526&& asan_handled_variables->contains (decl))
  1527  {
  1528HOST_WIDE_INT size = offsets[l - 3] - offsets[l - 2];
  1529if (dump_file && (dump_flags & TDF_DETAILS))
  1530  {
  1531debug_tree(decl);
  1532const char *n = (DECL_NAME (decl)
  1533 ? IDENTIFIER_POINTER (DECL_NAME
(decl))
  1534 : "");
  1535fprintf (dump_file, "Unpoisoning shadow stack for
variable: "
  1536 "%s (%" PRId64 " B)\n", n, size);
  1537  }
  1538  
  1539  last_size += size & ~(ASAN_RED_ZONE_SIZE -
HOST_WIDE_INT_1);
  1540  }
  1541  }

And thus we don't clean up stack in a function epilogue. One possible solution
would be
to mark all stack variables handled by ASAN (asan_handled_variables) to always
conflict
for partitioning. But I hope there's a nicer way how to do it.
Jakub?

[Bug c++/85790] New: c++17 - Access control issue with template argument deduction

[paolo.monteverde at gmail dot com]

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

Bug ID: 85790
   Summary: c++17 - Access control issue with template argument
deduction
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paolo.monteverde at gmail dot com
  Target Milestone: ---

struct B {
protected:
static constexpr unsigned i = 0; 
};

[Bug c/85789] New: Signed integer overflow with nonzero optimization in cse.c

[zeccav at gmail dot com]

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

Bug ID: 85789
   Summary: Signed integer overflow with nonzero optimization in
cse.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

// Signed integer overflow in sanitized version of gcc trunk 260152
// Taken from testcase pr82596.c
// Must be compiled with nonzero optimization 
// ../../gcc/gcc/cse.c:2194:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long int'
//
#define SSIZE_MAX __PTRDIFF_MAX__
#define SSIZE_MIN (-SSIZE_MAX - 1)

void s (int, ...);


void test (int i)
{
  s (""[SSIZE_MIN + 1]);
  s (""[1]);   
}

[Bug target/41084] Filling xmm register with all bit set is not optimized

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #2 from Alexander Monakov  ---
Starting from gcc-4.5 (released in 2010) GCC emits pcmpeq for the
explicit-constructor variant (where it would previously emit a load) as well as
for a more concise form:

  __m128i r = {-1, -1};

The implicit variant with _mm_cmpeq_epi32 is optimized as expected starting
with gcc-5 (released in 2015).

So as far as I can see both issues raised in this report have been addressed in
the meantime. If there are other cases that are not well optimized, please let
us know (they deserve separate bug reports).

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-15
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug libstdc++/85773] Embedded nulls in filesystem::path cause problems

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yes, doing nothing is also possible, and a reasonable choice.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Jan from comment #12)
> And yes I use a gentoo system. But I'm using the gcc patches from clear
> linux but this bug doesn't seem relate to that.

Good, then having a gentoo image system. How can I reproduce that please?

[Bug tree-optimization/85788] New: False positive of -Wstringop-overflow= warning

[marxin at gcc dot gnu.org]

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

Bug ID: 85788
   Summary: False positive of -Wstringop-overflow= warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Probably a know scenario, but I'll report that anyway. It's reduced from
cuneiform package:

$ cat tc2.i
int b;
int *d = 0, *e;
void a(void *k, long l) {
  long f = __builtin_object_size(k, 0);
  __builtin___memset_chk(k, b, l, f);
}
typedef struct {
  int g;
  int h;
  char i[8000 * 8];
} j;
static int make_str_raster(j *k) {
  int *c = d;
  for (; c; c = e)
k->g = k->h = 32767;

  a(k->i, k->g / 8 * k->h);
  for (; d;)
;
}
j m;
void n() { make_str_raster(); }

$ gcc tc2.i -O2
In function ‘a’,
inlined from ‘make_str_raster.constprop’ at tc2.i:17:3,
inlined from ‘n’ at tc2.i:22:12:
tc2.i:5:3: warning: ‘__builtin___memset_chk’ writing 134180865 bytes into a
region of size 64000 overflows the destination [-Wstringop-overflow=]
   __builtin___memset_chk(k, b, l, f);
   ^~

As seen, d == 0, thus 'for (; c; c = e)' never executes. It's combination of
jump-threading and VRP that triggers the warning.

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[lh_mouse at 126 dot com]

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

--- Comment #3 from Liu Hao  ---
Created attachment 44134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44134=edit
preprocessed source with GCC 8.1

N.B. This file is very large.

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[lh_mouse at 126 dot com]

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

--- Comment #2 from Liu Hao  ---
(In reply to Richard Biener from comment #1)
> Works for me on x86_64-linux with boost 1.54.0
> 
> Can you please attach preprocessed source?

There is one on  .

URL: https://sourceforge.net/p/mingw-w64/bugs/694/attachment/TestClass.ii

[Bug other/85778] unexpected results with -O2, wrong code?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unknown |8.1.0
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
glibc has stat annotated with nonnull(1, 2)

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
   Target Milestone|--- |7.4
Summary|[7/8 Regression]|[7/8/9 Regression]
   |-fsanitize=undefined makes  |-fsanitize=undefined makes
   |a -Wmaybe-uninitialized |a -Wmaybe-uninitialized
   |warning disappear   |warning disappear
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  I see that UBSAN_BOUNDS and UBSAN_OBJECT_SIZE have VDEFs.  I also
see that pass_ubsan preceeds (immediately) the early uninit pass for whatever
reasons (but some instrumentations already happened before - UBSAN_OBJECT_SIZE
is introduced by the pass though).

So

Index: gcc/passes.def
===
--- gcc/passes.def  (revision 259470)
+++ gcc/passes.def  (working copy)
@@ -58,8 +58,8 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_fixup_cfg);
   NEXT_PASS (pass_build_ssa);
   NEXT_PASS (pass_warn_nonnull_compare);
-  NEXT_PASS (pass_ubsan);
   NEXT_PASS (pass_early_warn_uninitialized);
+  NEXT_PASS (pass_ubsan);
   NEXT_PASS (pass_nothrow);
   NEXT_PASS (pass_rebuild_cgraph_edges);
   POP_INSERT_PASSES ()

in addition to making the internal fns above ECF_NOVOPS.

Index: gcc/internal-fn.def
===
--- gcc/internal-fn.def (revision 260250)
+++ gcc/internal-fn.def (working copy)
@@ -246,13 +246,13 @@ DEF_INTERNAL_FN (LOOP_VECTORIZED, ECF_NO
 DEF_INTERNAL_FN (LOOP_DIST_ALIAS, ECF_NOVOPS | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (ANNOTATE,  ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_NULL, ECF_LEAF | ECF_NOTHROW, ".R.")
-DEF_INTERNAL_FN (UBSAN_BOUNDS, ECF_LEAF | ECF_NOTHROW, NULL)
+DEF_INTERNAL_FN (UBSAN_BOUNDS, ECF_LEAF | ECF_NOTHROW | ECF_NOVOPS, NULL)
 DEF_INTERNAL_FN (UBSAN_VPTR, ECF_LEAF | ECF_NOTHROW, ".RR..")
 DEF_INTERNAL_FN (UBSAN_CHECK_ADD, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_SUB, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_PTR, ECF_LEAF | ECF_NOTHROW, ".R.")
-DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
+DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW | ECF_NOVOPS, NULL)
 DEF_INTERNAL_FN (ABNORMAL_DISPATCHER, ECF_NORETURN, NULL)
 DEF_INTERNAL_FN (BUILTIN_EXPECT, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (ASAN_CHECK, ECF_TM_PURE | ECF_LEAF | ECF_NOTHROW, "..R..")


More generally sanitizer instrumentation is expected to affect diagnostics,
that really cannot be avoided.

The above doesn't seem to help btw., probably because UBSAN keeps f aliased
and in memory.

[Bug target/41084] Filling xmm register with all bit set is not optimized

[agner at agner dot org]

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

Agner Fog  changed:

   What|Removed |Added

 CC||agner at agner dot org

--- Comment #1 from Agner Fog  ---
What is the status of this bug? It doesn't seem to have been fixed.

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||mingw-w64
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Works for me on x86_64-linux with boost 1.54.0

Can you please attach preprocessed source?

[Bug libstdc++/85773] Embedded nulls in filesystem::path cause problems

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> GIGO?

Or rather I told the doctor it hurt when I do this and he just told me not to
do it any more.

[Bug libstdc++/85773] Embedded nulls in filesystem::path cause problems

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
GIGO?

[Bug target/85770] [9 Regression] ICE: in lra_eliminate, at lra-eliminations.c:1439 with -march=nano-1000

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
  Known to work||8.1.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1

[Bug tree-optimization/83648] missing -Wsuggest-attribute=malloc on a trivial malloc-like function

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Tue May 15 06:07:48 2018
New Revision: 260250

URL: https://gcc.gnu.org/viewcvs?rev=260250=gcc=rev
Log:
2018-05-15  Prathamesh Kulkarni  

PR tree-optimization/83648
* ipa-pure-const.c (malloc_candidate_p): Allow function with NULL
return value as malloc candidate.

testsuite/
* gcc.dg/tree-ssa/pr83648.c: New test.
* gcc.dg/tree-ssa/pr83648-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83648-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
Created attachment 44133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44133=edit
patch

This has existed for five years (r199918).  Wow.