[Bug target/86987] New: ICE in simplify_binary_operation_1, at simplify-rtx.c:3515 on ppc64le

[marxin at gcc dot gnu.org]

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

Bug ID: 86987
   Summary: ICE in simplify_binary_operation_1, at
simplify-rtx.c:3515 on ppc64le
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following ICEs:

$ powerpc64le-suse-linux-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-short.c
-O -mno-optimize-swaps -c -S
during RTL pass: fwprop1
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-short.c:
In function 'test_obs':
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-short.c:44:1:
internal compiler error: in simplify_binary_operation_1, at simplify-rtx.c:3643
 vector bool short test_obs () { const vector bool short y = {1, 2, 3, 4, 5, 6,
7, 8}; return vec_splat (y, 0b10010); }
 ^~
0x769affea __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/86988] New: [7/9 Regression] ICE: tree check: expected integer_cst, have var_decl in get_len, at tree.h:5563

[marxin at gcc dot gnu.org]

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

Bug ID: 86988
   Summary: [7/9 Regression] ICE: tree check: expected
integer_cst, have var_decl in get_len, at tree.h:5563
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---

Starting from r246662 we ICE on:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/vla19.C
-Warray-bounds -O2 -c
during GIMPLE pass: vrp
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/vla19.C: In function
‘void foo()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/vla19.C:8:1: internal
compiler error: tree check: expected integer_cst, have var_decl in get_len, at
tree.h:5563
8 | foo ()
  | ^~~
0x7870e4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9351
0x1153cd7 tree_check(tree_node const*, char const*, int, char const*,
tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3376
0x1153cd7 wi::extended_tree<128>::get_len() const
/home/marxin/Programming/gcc/gcc/tree.h:5563
0x1153cd7 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
/home/marxin/Programming/gcc/gcc/wide-int.h:964
0x1153cd7 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
/home/marxin/Programming/gcc/gcc/wide-int.h:1013
0x1153cd7 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/home/marxin/Programming/gcc/gcc/wide-int.h:788
0x1153cd7 wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::result_type
wi::add >,
int>(generic_wide_int > const&, int const&)
/home/marxin/Programming/gcc/gcc/wide-int.h:2402
0x1146a85 wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::operator_result
operator+ >,
int>(generic_wide_int > const&, int const&)
/home/marxin/Programming/gcc/gcc/wide-int.h:3273
0x1146a85 vrp_prop::check_mem_ref(unsigned int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/tree-vrp.c:4690
0x1146cd9 check_array_bounds
/home/marxin/Programming/gcc/gcc/tree-vrp.c:4897
0x117486b 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/marxin/Programming/gcc/gcc/tree.c:11484
0xc6e850 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:202
0x113e5f1 check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-vrp.c:4950
0x1677567 dom_walker::walk(basic_block_def*)
/home/marxin/Programming/gcc/gcc/domwalk.c:353
0x114235c vrp_prop::check_all_array_refs()
/home/marxin/Programming/gcc/gcc/tree-vrp.c:4967
0x1143e52 vrp_prop::vrp_finalize(bool)
/home/marxin/Programming/gcc/gcc/tree-vrp.c:6743
0x1151e6e execute_vrp
/home/marxin/Programming/gcc/gcc/tree-vrp.c:6816
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

GCC 8 branch is fine, it again appeared in r263511.

[Bug target/86989] New: ICE in rs6000_output_addr_const_extra, at config/rs6000/rs6000.c:20994

[marxin at gcc dot gnu.org]

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

Bug ID: 86989
   Summary: ICE in rs6000_output_addr_const_extra, at
config/rs6000/rs6000.c:20994
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following causes ICE:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr82337.c
-fno-rerun-cse-after-loop -mminimal-toc -Os
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr82337.c: In
function ‘g’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr82337.c:27:1:
internal compiler error: in rs6000_output_addr_const_extra, at
config/rs6000/rs6000.c:20994
27 | }
   | ^
0x14d9c69 rs6000_output_addr_const_extra
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:20992
0xb96fb3 output_addr_const(_IO_FILE*, rtx_def*)
/home/marxin/Programming/gcc/gcc/final.c:4202
0x14d9b05 print_operand_address(_IO_FILE*, rtx_def*)
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:20973
0x102fb5c default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/targhooks.c:366
0xb968f1 output_address(machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/final.c:4066
0x14d966b print_operand(_IO_FILE*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:20886
0x102fb33 default_print_operand(_IO_FILE*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/targhooks.c:351
0xb9688d output_operand(rtx_def*, int)
/home/marxin/Programming/gcc/gcc/final.c:4050
0xb96452 output_asm_insn(char const*, rtx_def**)
/home/marxin/Programming/gcc/gcc/final.c:3962
0xb948e0 final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.c:3100
0xb94b05 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.c:3146
0xb92333 final_1
/home/marxin/Programming/gcc/gcc/final.c:2019
0xb97bdc rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.c:4657
0xb97f98 execute
/home/marxin/Programming/gcc/gcc/final.c:4731

[Bug rtl-optimization/86990] New: wrong code at -O2 on x86_64-linux-gnu in 64-bit mode

[su at cs dot ucdavis.edu]

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

Bug ID: 86990
   Summary: wrong code at -O2 on x86_64-linux-gnu in 64-bit mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It appears to be a recent regression.  The reduced version is still quite large
and complex, but it should be valid.  The original unreduced test is
miscompiled at -O2 and -O3 in both 32-bit and 64-bit modes. 


$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180817 (experimental) [trunk revision 263611] (GCC) 
$ 
$ gcctk -Os -w small.c; ./a.out
5
$ gcc-8.1.0 -O2 -w small.c; ./a.out
5
$ 
$ gcctk -O2 -w small.c; ./a.out
7
$ 


---


int printf (const char *, ...);

int i[6];
static int j, v, e, f, h = 5, k, l, n, o, p, q, r, s, u, w, x, y, z, aa, ab,
ac,
   ad, ae, af, ag = 8, ah, ai, aj, ak, al;
char c;
struct a {
  unsigned b;
  int c : 9;
  int d;
} static g = {9, 5};
static short m[1], t = 95, am;
int an, ao, ap;
void aq(ar) {
  j = j & 5 ^ i[j ^ v & 5];
  j = j & 5 ^ i[(j ^ v) & 5];
  j = j & 4095 ^ (j ^ v) & 5;
}
void as(ar) {
  if (n)
s = 0;
}
static unsigned at() {
  int au[] = {4073709551615, 0};
  for (; al; al--) {
if (r)
  --x;
if (g.d)
  l++;
printf("", j);
if (u)
  ae = n = au[al];
  }
  r = 0;
  return 0;
}
int aw(ar) {
  int ax[] = {9, 5, 5, 9, 5}, ay = 3;
  struct a az = {1, 3};
av:
  an = (as((at(), ax)[2]), ax[4]);
  {
int ba[] = {5, 5, 9, 8, 1, 0, 5, 5, 9, 8, 1, 0,
5, 5, 9, 8, 1, 0, 5, 5, 9, 8, 1};
int a[] = {8, 2, 8, 2, 8, 2, 8};
int b[] = {1027239, 8, 1, 7, 9, 2, 9, 4, 4, 2, 8, 1, 0, 4, 4, 2,
   4,   4, 2, 9, 2, 9, 8, 1, 7, 9, 2, 9, 4, 4, 2};
if (z) {
  struct a bc;
bb:
  for (; e; e++)
for (; q;)
  return ax[e];
  if (bc.c < g.d <= a[7])
aa--;
}
{
  struct a bd = {5};
  int d[20] = {1, 9, 7, 7, 8, 4, 4, 4, 4, 8, 1, 9, 7, 7, 8, 4, 4, 4, 4};
  c = h | r % g.c ^ x;
  printf("", g);
  am -= t | x;
  if (h)
while (1) {
  if (a[o]) {
struct a be;
if (ar) {
  struct a bf = {908, 5, 3};
  int bg[3], bh = k, bj = ag | ae, bk = aj + 3, bl = u << e;
  if (f)
if (ac)
  ak = w;
  ag = -(ag & t);
  af = ag ^ af;
  if (8 < af)
break;
  if (bj)
goto bi;
  if (s)
printf("", 6);
  be.d = k;
  w = f - bh;
  printf("", be);
  if (w)
goto bb;
  ao = r - aa && g.b;
  if (y)
k++;
  goto av;
bi:
  if (aa)
continue;
  if (f)
if (k)
  printf("", g);
  aj = ac + k ^ g.c;
  g.c = bk;
  ah = 0;
  for (; ah < 3; ah++)
if (s)
  bg[ah] = 8;
  if (!ay)
printf("", ai);
  u = bl;
  g = bf;
} else
  for (;; o += a[ap])
;
int bm[] = {0};
for (; p; p++)
  c = ad;
ad = l;
if (bd.c) {
  printf(" ");
  goto bi;
}
  }
  int bn[] = {5, 2, 2, 5, 2, 2, 5, 2, 2, 5, 2, 2, 5, 2, 2, 5,
  2, 2, 5, 2, 2, 5, 2, 2, 5, 2, 2, 5, 2, 2, 5, 2,
  2, 5, 2, 2, 5, 2, 2, 5, 2, 2, 5, 2, 2, 5, 2};
  struct a a[] = {905266581905224, 2, 8, 4, 2, 8, 4, 4, 2, 8, 4};
  struct a b = {3075920};
  if (f) {
aq(m[am + e]);
printf("", j);
printf("", e);
ab--;
  }
  if (ax[4]) {
if (l)
  goto av;
++f;
  } else
ay = az.c && a;
  for (; ac; ac++)
m[f] = 0;
}
  h = 9;
  for (; y; y = 1)
if (f)
  goto av;
}
  }
  return 0;
}
int main() {
  aw(1);
  printf("%d\n", g.c);
  return 0;
}

[Bug tree-optimization/86991] New: internal compiler error: in vectorizable_reduction, at tree-vect-loop.c:6919

[konstantin.vladimirov at gmail dot com]

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

Bug ID: 86991
   Summary: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:6919
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
  Target Milestone: ---

Minimal reproduction:

int b;
extern unsigned c[];
unsigned d;
long e;

void f() {
  unsigned g, h;
  for (; d; d += 2) {
g = 1;
for (; g; g += 3) {
  h = 2;
  for (; h < 6; h++)
c[h] = c[h] - b - ~e;
}
  }
}

Compiler:

gcc -v
Reading specs from
/apps/gcc/8.1.0/.bin/../lib64/gcc/x86_64-suse-linux/8.1.0/specs
COLLECT_GCC=/apps/gcc/8.1.0/.bin/gcc
COLLECT_LTO_WRAPPER=/apps/gcc/8.1.0/.bin/../libexec/gcc/x86_64-suse-linux/8.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ./configure --prefix=/apps/gcc/8.1.0
--libdir=/apps/gcc/8.1.0/lib64 --libexecdir=/apps/gcc/8.1.0/libexec
--bindir=/apps/gcc/8.1.0/bin --with-isl=/apps/gcc/8.1.0
--with-libelf=/apps/gcc/8.1.0 --with-mpfr=/apps/gcc/8.1.0
--with-gmp=/apps/gcc/8.1.0 --with-mpc=/apps/gcc/8.1.0
--disable-gnu-unique-object --enable-gold=yes --enable-lto
--enable-languages=c,c++,objc,fortran --build=x86_64-suse-linux
--host=x86_64-suse-linux --target=x86_64-suse-linux --enable-libotm
--disable-multilib --disable-bootstrap --disable-libstdcxx-pch
Thread model: posix
gcc version 8.1.0 (GCC)

Compile with:

gcc min.c -O3

You shall see:

during GIMPLE pass: vect
min.c: In function ‘f’:
min.c:7:6: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:6919
 void f() {
  ^
0x620ba8 ???
../sysdeps/x86_64/elf/start.S:113

[Bug middle-end/86505] [6/7/8 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[6/7/8/9 Regression]|[6/7/8 Regression]
   |__builtin_va_arg_pack_len() |__builtin_va_arg_pack_len()
   |computes the number of  |computes the number of
   |arguments wrongly   |arguments wrongly
  Known to fail|9.0 |

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/86505] [6/7/8 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Aug 17 08:48:58 2018
New Revision: 263613

URL: https://gcc.gnu.org/viewcvs?rev=263613&root=gcc&view=rev
Log:
2018-08-17  Richard Biener  

PR middle-end/86505
* tree-inline.c (copy_bb): When inlining __builtin_va_arg_pack_len ()
across a va-arg-pack using call adjust its return value accordingly.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr86505.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug middle-end/86505] [6/7/8 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #6 from Richard Biener  ---
I wonder if the auto-regression police can help here increasing coverage?

[Bug c++/54710] moderately large tuple, with many gets, increases compile time

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Eric Gallager from comment #11)
> Created attachment 41894 [details]
> result of compiling with -ftime-report -ftime-report-details -fstats
> 
> (In reply to Larry Evans from comment #10)
> > Created attachment 28294 [details]
> > with optimized clang, still with optimized gcc, both with -O1
> > 
> > Remade clang with make ENABLE_OPTIMIZED=1.  Clang times improved a lot.
> > 
> > Now, the degradation of relative performance of gcc w.r.t. clang
> > is more dramatic.
> > 
> > Still, gcc does better at low LAST_LESS, but reaches break even
> > at lower LAST_LESS (about 8).
> 
> Confirmed:
> 
> $ /usr/local/bin/gcc -c -O1 -time tuple.benchmark.mini.horiz.cpp
> # cc1plus 4.62 0.25
> # as 0.02 0.01
> $
> 
> I guess 4 and a half seconds is kinda long. Attaching a more detailed time
> report as a separate file.

Time is spent in the C++ parser and the GIMPLE/tree verifiers.  Your
cc1plus is built with --enable-checking=yes ...

[Bug tree-optimization/86841] ICE in gcc/gcc/tree-vrp.c:1325 with graphite

[rguenth at gcc dot gnu.org]

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

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  ---
It's a problem with the VRP machinery assuming shift counts are never bigger
than 64bits...

  /* Transform left shifts by constants into multiplies.  */
  if (wi::eq_p (vr1_lb, vr1_ub))
{
  int shift = wi::extract_uhwi (vr1_ub, 0, vr1_ub.get_precision ());
  wide_int tmp = wi::set_bit_in_zero (shift, prec);
  return wide_int_range_multiplicative_op (res_lb, res_ub,
   MULT_EXPR, sign, prec,
   vr0_lb, vr0_ub, tmp, tmp,
   overflow_undefined,
   /*overflow_wraps=*/true);

this should use wi::to_uhwi.

[Bug tree-optimization/86841] ICE in gcc/gcc/tree-vrp.c:1325 with graphite

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Aug 17 09:26:53 2018
New Revision: 263615

URL: https://gcc.gnu.org/viewcvs?rev=263615&root=gcc&view=rev
Log:
2018-08-17  Richard Biener  

PR tree-optimization/86841
* wide-int-range.cc (wide_int_range_lshift): Use to_uhwi.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/wide-int-range.cc

[Bug other/86992] New: [8 Regression] gcc: error: unrecognized command line option ‘-fcilkplus’

[marxin at gcc dot gnu.org]

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

Bug ID: 86992
   Summary: [8 Regression] gcc: error: unrecognized command line
option ‘-fcilkplus’
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r255195 the option should be ignored, but is not. On trunk fixed
in r263614.

[Bug tree-optimization/86841] ICE in gcc/gcc/tree-vrp.c:1325 with graphite

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

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

Bug 86841 Summary: ICE in gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841

   What|Removed |Added

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

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
The issue looks like that

(jump_insn 19 18 20 3 (parallel [
(set (pc)
(reg:DI 94))
(use (label_ref 21))
]) -1
 (nil)
 -> 21)
(barrier 20 19 21)

doesn't have the jump at the end.  Whoever inserted that barrier insn did it
wrong.  But I'm not too much of an expert here either.

[Bug c++/57510] initializer_list memory leak

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Comment 1 was fixed, but comment 0 was not, this bug is still present on trunk.
The example in comment 0 built with ASan shows:


=
==6556==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 2 object(s) allocated from:
#0 0x7ffa9489a340 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:90
#1 0x400ef6 in X::X() /tmp/leak2.cc:6
#2 0x400db1 in main /tmp/leak2.cc:20
#3 0x7ffa93b33f29 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s).



Possibly a dup of PR 66139

[Bug c++/57510] initializer_list memory leak

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
The example from PR 57930 isn't fixed either:

extern "C" int printf(const char *,...);
struct B {
B(int,int) { printf("CB %p\n",this); }
B(const B&) { printf("const CB %pn\n",this); }
B(B&&) { printf("const CB %pn\n",this); }
~B() { printf("B %p\n",this);  }
};
struct C {
int c;
int c2;
};
struct A {
 struct B b;
 struct C c;
};
A test() {
//const A a1 = { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B
called
//const A &a2 = { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B
not called
return { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B not
called
};
int main() {
try {
test();
} catch (...) {
}
}

This prints:

CB 0x7ffd6eac7620


But should be:

CB 0x7ffd6eac7620
B 0x7ffd6eac7620

[Bug other/86992] [8 Regression] gcc: error: unrecognized command line option ‘-fcilkplus’

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-17
  Known to work||7.3.0, 9.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |8.3
 Ever confirmed|0   |1
  Known to fail||8.2.0

[Bug c++/86986] [6/7/8/9 Regression] Unexpected errors for template parameter pack in a template template parameter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-17
  Known to work||4.8.5
Summary|Unexpected errors for   |[6/7/8/9 Regression]
   |template parameter pack in  |Unexpected errors for
   |a template template |template parameter pack in
   |parameter   |a template template
   ||parameter
 Ever confirmed|0   |1
  Known to fail||4.9.0, 5.5.0, 6.4.0, 7.3.0,
   ||8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
GCC 4.8 compiled it too, so this is a regression.

[Bug c++/86986] [6/7/8/9 Regression] Unexpected errors for template parameter pack in a template template parameter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Started with r208178

PR c++/54440
* pt.c (get_template_parm_index): New.
(fixed_parameter_pack_p_1, fixed_parameter_pack_p): New.
(process_template_parm): Allow bare packs in template template
parm template parms.
(coerce_template_parameter_pack): Handle fixed template template
parm packs and fixed packs not at the end of the parm list.
(coerce_template_parms): Handle template parm packs not at the end
of the parm list.
(gen_elem_of_pack_expansion_instantiation): Handle a decl
expansion.

[Bug c++/86980] Lambda function with return type rvalue reference dtor issue

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yes.

[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
No, because the same code is generated for -fabi-version=12 and
-fabi-version=13

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
It should happen everywhere, no explicit lto1 invocation should be necessary.

> ./xgcc -B. t.c -flto -c
> ./xgcc -B. t.o -m32
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible libgcc_s.so.1 when searching for libgcc_s.so.1
lto1: internal compiler error: in operator[], at vec.h:841
0x871a92 vec::operator[](unsigned int)
/tmp/trunk/gcc/vec.h:841
0x870416 vec::operator[](unsigned int)
/tmp/trunk/gcc/vec.h:1360
0x11e26fe streamer_tree_cache_get_tree
/tmp/trunk/gcc/tree-streamer.h:98
0x11e6b18 streamer_get_pickled_tree(lto_input_block*, data_in*)
/tmp/trunk/gcc/tree-streamer-in.c:1100
...

but as said, fixing aka diagnosing this in a "nicer" form is somewhat
difficult.

[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/86884] aggressive loop optimization and effective type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
It's invalid in GIMPLE as well.  You are accessing the storage through p->c[n]
which constrains the accesses to the array size of c (it is not a trailing
array).

[Bug c++/86993] New: assignment of read-only variable error reported at wrong location

[malcolm.parsons at gmail dot com]

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

Bug ID: 86993
   Summary: assignment of read-only variable error reported at
wrong location
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malcolm.parsons at gmail dot com
  Target Milestone: ---

For this C++ code:
int main() {
const int i = 5;
i = 5 + 6;
}

g++ 5.1 reports:
: In function 'int main()':
:3:7: error: assignment of read-only variable 'i'
 i = 5 + 6;
   ^

but g++ 6.1 and later report:
: In function 'int main()':
:3:13: error: assignment of read-only variable 'i'
 i = 5 + 6;
 ^

gcc doesn't have this issue for C code.

See https://godbolt.org/g/Hoojyt and https://godbolt.org/g/WQR5XS

[Bug tree-optimization/86889] s390x gcc build fails when configured with --disable-checking

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
So the issue is that the __builtin_unreachable () elides the g >= 0 test,
effectively making the loop endless.  If you disable EVRP and CUNROLLI then
VRP1 will do this transform.

 :
# g_2 = PHI <1(2), g_7(5)>
if (g_2 != -1)
  goto ; [INV]
else
  goto ; [INV]

It goes like EVRP computing the range of g_2 to [0, 1] (correctly, based on
the __builtin_unreachable) and then CFG cleanup simplifying the conditional
to false, removing the __builtin_unreachable () call.

cunrolli then computes the loop to run twice and inserts that stray [-1] array
reference, exposing it's old latent issue of sometimes emitting stray
iterations as the reporter already analyzed (it can at most handle the _last_
iteration when marking blocks as never executed, but in cases where the IV
increment is at unfortunate places it has to look at the previous peeled
copy as well).

Maybe I can get to improve this.  Don't hold your breath.

I think we have dups of this (but maybe closed because they no longer warn).

[Bug tree-optimization/80334] [5 Regression] Segfault when taking address of copy of unaligned struct

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Alexandre Oliva from comment #12)
> Created attachment 44527 [details]
> candidate patch to fix the error noted in comment 11
> 
> This patch fixes the unaligned accesses in the testcase in comment 11.  I
> haven't yet tested it otherwise.

The patch doesn't make much sense.  Whoever is "consuming" the pointer
does the wrong thing.

Please open a new bug as well.

[Bug libstdc++/86963] std::tuple incorrectly assigned

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/86927] [8/9 Regression] Gcc miscompiles at -O3 on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Mine then.

[Bug c++/86993] [6/7/8/9 Regression] assignment of read-only variable error reported at wrong location

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-17
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Started with r231293

C++ FE: expression ranges

gcc/ChangeLog:
* convert.c (convert_to_real_1): When converting from a
REAL_TYPE, preserve the location of EXPR in the result.
* tree.c (get_pure_location): Make non-static.
(set_source_range): Return the resulting location_t.
(make_location): New function.
* tree.h (get_pure_location): New decl.
(get_finish): New inline function.
(set_source_range): Convert return type from void to location_t.
(make_location): New decl.

...

[Bug other/86992] [8 Regression] gcc: error: unrecognized command line option ‘-fcilkplus’

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Fri Aug 17 11:33:25 2018
New Revision: 263616

URL: https://gcc.gnu.org/viewcvs?rev=263616&root=gcc&view=rev
Log:
Fix wrong option declaration of fcilkplus (PR other/86992).

2018-08-17  Martin Liska  

PR other/86992
* c.opt: Fix declaration of cilkplus.

Modified:
branches/gcc-8-branch/gcc/c-family/ChangeLog
branches/gcc-8-branch/gcc/c-family/c.opt

[Bug other/86992] [8 Regression] gcc: error: unrecognized command line option ‘-fcilkplus’

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug c++/86763] [7/8 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Aug 17 11:51:48 2018
New Revision: 263617

URL: https://gcc.gnu.org/viewcvs?rev=263617&root=gcc&view=rev
Log:
2018-08-17  Richard Biener  

Backport from mainline
2018-08-02  Richard Biener  

PR c++/86763
* class.c (layout_class_type): Copy TYPE_TYPELESS_STORAGE
to the CLASSTYPE_AS_BASE.

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

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr86763.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/class.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/86994] New: [9 regression] 64-bit gcc.target/i386/20040112-1.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 86994
   Summary: [9 regression] 64-bit gcc.target/i386/20040112-1.c
FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i?86-*-*, x86-*-*

Between 20180816 (r263590) and 20180817 (r263613), gcc.target/i386/20040112-1.c
started to FAIL for 64-bit:

+FAIL: gcc.target/i386/20040112-1.c scan-assembler testb

Seen on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.

Compared to the gcc-8 branch, the code changed from

-   testb   %al, %al
-   jns .L2
+   cmpb$-1, %al
+   jg  .L2

[Bug target/86994] [9 regression] 64-bit gcc.target/i386/20040112-1.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__

[phd at phd dot re]

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

Piotr Henryk Dabrowski  changed:

   What|Removed |Added

 CC||phd at phd dot re

--- Comment #6 from Piotr Henryk Dabrowski  ---
You can use:

#line 2 "FileName.cpp"

at the very top (!) of all your files
to change the content of __FILE__.
This also affects compiler messages.

[Bug middle-end/86995] New: [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 86995
   Summary: [9 regression]
c-c++-common/torture/builtin-arith-overflow-17.c etc.
FAIL
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*, powerpc64-*-*

Between 20180816 (r263590) and 20180817 (r263613), two tests started to FAIL
on 64-bit Solaris/x86 and Linux/x86_64:

+FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O0  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2 -flto  execution
test
+FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2 -flto
-flto-partition=none  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c   -O0  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c   -O2 -flto 
execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c   -O2 -flto
-flto-partition=none  execution test

There's also a report on Linux/PowerPC64.

The test aborts here:

#0  0x7fffbe855cca in __lwp_sigqueue () from /lib/64/libc.so.1
#1  0x7fffbe84c522 in thr_kill () from /lib/64/libc.so.1
#2  0x7fffbe7870f9 in raise () from /lib/64/libc.so.1
#3  0x7fffbe750eb1 in abort () from /lib/64/libc.so.1
#4  0x0042c3a2 in t150sub ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10
#5  0x00435736 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:18

[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/86996] New: [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 86996
   Summary: [9 regression]
gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: edlinger at gcc dot gnu.org, law at gcc dot gnu.org,
msebor at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.*

Between 20180816 (r263590) and 20180817 (r263613), a test started to FAIL on
Solaris/SPARC and x86, both 32 and 64-bit:

+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1563)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1563:3:
warning: '__builtin_snprintf' output may be truncated before the last format
character [-Wformat-truncation=]

This suggests strongly one of the strlen etc. patches committed in that
timeframe.

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #1 from Bernd Edlinger  ---
is this a target where wchar_t is 16-bit wide?

[Bug c++/86997] New: error: call of overloaded ‘NoDestructor()’ is ambiguous

[marxin at gcc dot gnu.org]

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

Bug ID: 86997
   Summary: error: call of overloaded
‘NoDestructor()’ is
ambiguous
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

All GCC releases reject a test-case isolated from Chromium:

$ cat browser_theme_pack.ii
class a;

struct NoDestructor {
  NoDestructor();
  NoDestructor(a);
};

int main()
{
  NoDestructor b({});
}

$ g++ -c browser_theme_pack.ii
browser_theme_pack.ii: In function ‘int main()’:
browser_theme_pack.ii:10:20: error: call of overloaded
‘NoDestructor()’ is ambiguous
   NoDestructor b({});
^
browser_theme_pack.ii:5:3: note: candidate: ‘NoDestructor::NoDestructor(a)’
   NoDestructor(a);
   ^~~~
browser_theme_pack.ii:3:8: note: candidate: ‘constexpr
NoDestructor::NoDestructor(const NoDestructor&)’
 struct NoDestructor {
^~~~
browser_theme_pack.ii:3:8: note: candidate: ‘constexpr
NoDestructor::NoDestructor(NoDestructor&&)’

While clang++ and ICC accept that:

$ clang++ -c browser_theme_pack.ii -S -o/dev/stdout | grep call
callq   _ZN12NoDestructorC1Ev

$ c++filt _ZN12NoDestructorC1Ev
NoDestructor::NoDestructor()

[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-17
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Bernd Edlinger  ---
> is this a target where wchar_t is 16-bit wide?

No, wchar_t is always 32-bit.  Cf. gcc/config/sol2.h:

/* wchar_t is called differently in  for 32 and 64-bit
   compilations.  This is called for by SCD 2.4.1, p. 6-83, Figure 6-65
   (32-bit) and p. 6P-10, Figure 6.38 (64-bit).  */

#undef WCHAR_TYPE
#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int")

#undef WCHAR_TYPE_SIZE
#define WCHAR_TYPE_SIZE 32

[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Looks like a dup of PR 59389

[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__

[rdiezmail-gcc at yahoo dot de]

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

--- Comment #7 from R. Diez  ---
(In reply to Piotr Henryk Dabrowski from comment #6)
> You can use:
> 
> #line 2 "FileName.cpp"
> 
> at the very top (!) of all your files
> to change the content of __FILE__.
> This also affects compiler messages.

I do not want to override __FILE__. Its original content may be needed for
something else. I just want an alternative to generate smaller asserts.

Besides, maintaining such a "#line" hack in all files is uncomfortable. I
already mentioned that I am including other libraries with their own source
code and build systems. I need a way to tweak the assert definition for all of
them in Newlib. Otherwise, I have to patch all components everywhere.

[Bug c++/86998] New: Improve diagnostic for missing comma in template-parameter-list

[redi at gcc dot gnu.org]

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

Bug ID: 86998
   Summary: Improve diagnostic for missing comma in
template-parameter-list
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template void f() { }

GCC says:

err.cc:1:19: error: expected nested-name-specifier before 'T'
1 | template void f() { }
  |   ^
err.cc:1:21: error: expected '>' before 'typename'
1 | template void f() { }
  | ^~~~


The first error is not helpful. The second error is OK, although it would be
more correct (and helpful) to say that a comma would also be accepted, as Clang
does:


err.cc:1:19: error: expected a qualified name after 'typename'
template void f() { }
  ^
err.cc:1:21: error: expected ',' or '>' in template-parameter-list
template void f() { }
^
2 errors generated.


I don't know why all of GCC, Clang and EDG say something about a
nested-name-specifier or qualified name for the first template-parameter. I
don't think the grammar allows a qualified-id there, only a plain identifier.

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Rainer, can you compile the test with -save-temps on one of your solaris boxes
and attach it?  Thanks

[Bug c++/86998] Improve diagnostic for missing comma in template-parameter-list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-17
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The ideal would be a fix-it hint suggesting to add the comma.

Adding the '>' that the parser says is expected would not make the code correct
because 'template typename U>' isn't valid as a top-level
declaration (only as a template-parameter).

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Created attachment 44553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44553&action=edit
i386-pc-solaris2.11 -m32 builtin-sprintf-warn-1.i

Sure, here's the 32-bit Solaris 11.5/x86 version.

[Bug c++/86942] A trailing-return-type is allowed when the return type is not 'auto' for using declarations

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00990.html

[Bug fortran/82036] [F08] Recursive allocatable class components cause infinite loop in compilation

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
In the meantime, this has become an ICE.

[Bug c++/86763] [7 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Fri Aug 17 14:17:10 2018
New Revision: 263621

URL: https://gcc.gnu.org/viewcvs?rev=263621&root=gcc&view=rev
Log:
2018-08-17  Richard Biener  

Backport from mainline
2018-08-02  Richard Biener  

PR c++/86763
* class.c (layout_class_type): Copy TYPE_TYPELESS_STORAGE
to the CLASSTYPE_AS_BASE.

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

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr86763.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/class.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/86763] [7 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
   Target Milestone|8.3 |7.4
  Known to fail||7.3.0

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

[Bug c++/86970] Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Removed `#include`:


template
struct faketuple
{
template
constexpr faketuple(U&& u) { }

constexpr faketuple(const faketuple&) = default;
};

namespace ns {
template 
class Foo : private A
{
public:
template 
explicit constexpr Foo(FA&& a)
: A{static_cast(a)}
{}
};

template 
Foo(A)->Foo;

template 
constexpr auto frobnicate(T&& val)
{
return [val = static_cast(val)] {};
}

template 
class Bar
{
A a;
faketuple b;

public:
template 
explicit constexpr Bar(FA&& a, FB&& b)
: a{a}
, b{b}
{}
};

template 
Bar(A, B)->Bar;

constexpr auto Baz = ns::Foo{ns::frobnicate(ns::Bar{[] {}, [](int) {}})};
}


But `std::tuple` has a move constructor, unlike `faketuple` :/

[Bug middle-end/86999] New: Incorrect code generation and missing optimization with -fno-signed-zeros.

[asd0025 at gmail dot com]

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

Bug ID: 86999
   Summary: Incorrect code generation and missing optimization
with -fno-signed-zeros.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asd0025 at gmail dot com
  Target Milestone: ---

Consider the following trivial example (https://godbolt.org/g/5ms6Bf):

  #include 

  typedef float v4f __attribute__((vector_size(16)));
  typedef int v4i __attribute__((vector_size(16)));

  v4f foo(v4f n, v4f p)
  {
 return n * p + p;
  }

  template  v4f __neg1(v4f a)
  {
v4i v = {((N & 1) ? INT_MIN : 0), ((N & 2) ? INT_MIN : 0), ((N & 4) ?
INT_MIN : 0), ((N & 8) ? INT_MIN : 0)};
return __builtin_ia32_xorps(a, (v4f)v);
  }

  template  v4f __neg2(v4f a)
  {
v4i v = {((N & 1) ? INT_MIN : 0), ((N & 2) ? INT_MIN : 0), ((N & 4) ?
INT_MIN : 0), ((N & 8) ? INT_MIN : 0)};
return (v4f)((v4i)a ^ v);
  }

  v4f neg1C(v4f a)
  {
return __neg1<0x0C>(a);
  }

  v4f neg2C(v4f a)
  {
return __neg2<0x0C>(a);
  }

On GCC 7.x/8.x with -fno-signed-zeros (or implied by other flags eg.: -Ofast)
foo() is not optimal on FMA capable hardware:

  foo(float __vector(4), float __vector(4)):
vmulps  xmm0, xmm0, xmm1
vaddps  xmm0, xmm0, xmm1
ret

With -fsigned-zeros:

  foo(float __vector(4), float __vector(4)):
vfmadd132ps xmm0, xmm1, xmm1
ret

Incorrect code is generated only on GCC 8.x with -fno-signed-zeros:

  neg1C(float __vector(4)):
ret

With -fsigned-zeros or with GCC 7.x:

  neg1C(float __vector(4)):
vxorps  xmm0, xmm0, XMMWORD PTR .LC1[rip]
ret
  .LC1:
.long   0
.long   0
.long   2147483648
.long   2147483648

Note however when using bitwise xor instead of __builtin_ia32_xorps() the
generated code is correct in all cases:

  neg2C(float __vector(4)):
vxorps  xmm0, xmm0, XMMWORD PTR .LC1[rip]
ret
  .LC1:
.long   0
.long   0
.long   2147483648
.long   2147483648

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[nsz at gcc dot gnu.org]

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

--- Comment #19 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Aug 17 17:26:11 2018
New Revision: 263624

URL: https://gcc.gnu.org/viewcvs?rev=263624&root=gcc&view=rev
Log:
Fix poly types after PR tree-optimization/71625 strlen optimization

Same as r263561, but for arm: avoid compilation errors caused by poly
initializers getting treated as string literals.

Tested on arm-none-linux-gnueabihf.

gcc/ChangeLog:

* config/arm/arm-builtins.c (arm_init_simd_builtin_types): Clear
polyNxK_t element's TYPE_STRING_FLAG.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c

[Bug libfortran/87000] New: LBOUND and UBOUND give unexpected result for arrays without 1-based indices if in subprogram

[gavin.keith.ridley at gmail dot com]

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

Bug ID: 87000
   Summary: LBOUND and UBOUND give unexpected result for arrays
without 1-based indices if in subprogram
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gavin.keith.ridley at gmail dot com
  Target Milestone: ---

If an array is allocated with indices that don't start at one, lbound and
ubound seem to give incorrect answers if the array is passed to any subprogram.
This program clearly illustrates the issue, compiled with no flags:

program asdf
  use iso_fortran_env
  implicit none
  real(real64), dimension(-5:10) :: arr
  print *, 'lbound = ', lbound(arr)
  print *, 'ubound = ', ubound(arr)
  call boundprinter(arr)

  contains
subroutine boundprinter(x)
  real(real64), intent(in), dimension(:) :: x
  print *, 'lbound = ', lbound(x)
  print *, 'ubound = ', ubound(x)
endsubroutine boundprinter
endprogram asdf

Which prints:

 lbound =   -5
 ubound =   10
 lbound =1
 ubound =   16

Shouldn't these be consistent?

Very notably, it seems gcc 4 gives the correct answer, but not gcc 8.1.0. This
bug causes segfaults in a program called MPACT developed by Oak Ridge National
Lab and University of Michigan which I'd estimate somewhere between 50 and 100
people use. As a result of this, all of their compiles are still done on gcc 4.

[Bug libfortran/87000] LBOUND and UBOUND give unexpected result for arrays without 1-based indices if in subprogram

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Gavin Ridley from comment #0)
> If an array is allocated with indices that don't start at one, lbound and
> ubound seem to give incorrect answers if the array is passed to any
> subprogram. This program clearly illustrates the issue, compiled with no
> flags:
> 
> program asdf
>   use iso_fortran_env
>   implicit none
>   real(real64), dimension(-5:10) :: arr
>   print *, 'lbound = ', lbound(arr)
>   print *, 'ubound = ', ubound(arr)
>   call boundprinter(arr)
> 
>   contains
> subroutine boundprinter(x)
>   real(real64), intent(in), dimension(:) :: x
>   print *, 'lbound = ', lbound(x)
>   print *, 'ubound = ', ubound(x)
> endsubroutine boundprinter
> endprogram asdf
> 
> Which prints:
> 
>  lbound =   -5
>  ubound =   10
>  lbound =1
>  ubound =   16
> 
> Shouldn't these be consistent?
> 
> Very notably, it seems gcc 4 gives the correct answer, but not gcc 8.1.0.
> This bug causes segfaults in a program called MPACT developed by Oak Ridge
> National Lab and University of Michigan which I'd estimate somewhere between
> 50 and 100 people use. As a result of this, all of their compiles are still
> done on gcc 4.

I think you may have found a bug in your code.

F2003, 5.1.2.5.2, Assumed-shape array

An assumed-shape array is a nonpointer dummy argument array
that takes its shape from the associated actual argument array.

R514 assumed-shape-spec   is [ lower-bound ] :

The rank is equal to the number of colons in the
assumed-shape-spec-list.

The extent of a dimension of an assumed-shape array dummy
argument is the extent of the corresponding dimension of
the associated actual argument array.  If the lower bound
value is 'd' and the extent of the corresponding dimension
of the associated actual argument array is 's', then the
value of the upper bound is 's + d - 1'.  The lower bound
is 'lower-bound', if present, and 1 otherwise.

Of course, I could be wrong.

[Bug middle-end/86999] Incorrect code generation and missing optimization with -fno-signed-zeros.

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
For the first problem -fno-signed-zeros is a bit of a red herring, the real
reason is enabling -fassociative-math makes GCC turn

  return n * p + p;

to 'return (n + 1) * p;' and while we slightly optimize it on RTL we don't
recover fma from it.

For the second problem, the expression '(v4f)v' is {0.0f, 0.0f, -0.0f, -0.0f}
and by specifying -fno-signed-zeros you're allowing the compiler to change it
to all-positive-zeros, making the function a no-op. So that is not a bug.

[Bug libstdc++/86963] std::tuple incorrectly assigned

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Fri Aug 17 17:52:49 2018
New Revision: 263625

URL: https://gcc.gnu.org/viewcvs?rev=263625&root=gcc&view=rev
Log:
PR libstdc++/86963 Implement LWG 2729 constraints on tuple assignment

PR libstdc++/86963
* include/std/tuple (__tuple_base): New class template with deleted
copy assignment operator.
(tuple, tuple<_T1, _T2>): Derive from __tuple_base so that
implicit copy/move assignment operator will be deleted/suppressed.
(tuple::__assignable, tuple<_T1, _T2>::__assignable): New helper
functions for SFINAE constraints on assignment operators.
(tuple::__nothrow_assignable, tuple<_T1, _T2>::__nothrow_assignable):
New helper functions for exception specifications.
(tuple::operator=(const tuple&), tuple::operator=(tuple&&))
(tuple<_T1, _T2>::operator=(const tuple&))
(tuple<_T1, _T2>::operator=(tuple&&)): Change parameter types to
__nonesuch_no_braces when the operator should be defined implicitly.
Use __nothrow_assignable for exception specifications.
(tuple::operator=(const tuple<_UElements...>&))
(tuple::operator=(tuple<_UElements...>&&))
(tuple<_T1, _T2>::operator=(const tuple<_U1, _U2>&))
(tuple<_T1, _T2>::operator=(tuple<_U1, _U2>&&))
(tuple<_T1, _T2>::operator=(const pair<_U1, _U2>&))
(tuple<_T1, _T2>::operator=(pair<_U1, _U2>&&)): Constrain using
__assignable and use __nothrow_assignable for exception
specifications.
* python/libstdcxx/v6/printers.py (is_specialization_of): Accept
gdb.Type as first argument, instead of a string.
(StdTuplePrinter._iterator._is_nonempty_tuple): New method to check
tuple for expected structure.
(StdTuplePrinter._iterator.__init__): Use _is_nonempty_tuple.
* testsuite/20_util/tuple/dr2729.cc: New test.
* testsuite/20_util/tuple/element_access/get_neg.cc: Change dg-error
to dg-prune-output.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/dr2729.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc

[Bug libfortran/87000] LBOUND and UBOUND give unexpected result for arrays without 1-based indices if in subprogram

[gavin.keith.ridley at gmail dot com]

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

--- Comment #2 from Gavin Ridley  ---
OK, I see, thank you. I believe you're right on that. When I tried to make this
example, I cut out an important part that seems to cause the difference between
gcc compiler versions. This code:

program asdf
  use iso_fortran_env
  implicit none
  real(real64), dimension(:), allocatable :: arr
  allocate(arr(-5:10))
  print *, 'lbound = ', lbound(arr)
  print *, 'ubound = ', ubound(arr)
  call boundprinter(arr)

  contains
subroutine boundprinter(x)
  class(*), intent(in), dimension(:) :: x
  print *, 'lbound = ', lbound(x)
  print *, 'ubound = ', ubound(x)
endsubroutine boundprinter
endprogram asdf

Gives the difference I'm looking to illustrate. Insteady of specifying the type
of the array, this instead has the polymorphic class(*) which gives lbound=-5
on gcc 4.9.3 but gives lbound=1 on gcc 7.3.1. Which gcc is correct?

[Bug libfortran/87000] LBOUND and UBOUND give unexpected result for arrays without 1-based indices if in subprogram

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Aug 17, 2018 at 06:34:01PM +, gavin.keith.ridley at gmail dot com
wrote:
> OK, I see, thank you. I believe you're right on that. When I
> tried to make this example, I cut out an important part that
> seems to cause the difference between
> gcc compiler versions. This code:
> 
> program asdf
>   use iso_fortran_env
>   implicit none
>   real(real64), dimension(:), allocatable :: arr
>   allocate(arr(-5:10))
>   print *, 'lbound = ', lbound(arr)
>   print *, 'ubound = ', ubound(arr)
>   call boundprinter(arr)
> 
>   contains
> subroutine boundprinter(x)
>   class(*), intent(in), dimension(:) :: x
>   print *, 'lbound = ', lbound(x)
>   print *, 'ubound = ', ubound(x)
> endsubroutine boundprinter
> endprogram asdf
> 
> Gives the difference I'm looking to illustrate.  Insteady of
> specifying the type of the array, this instead has the polymorphic
> class(*) which gives lbound=-5 on gcc 4.9.3 but gives lbound=1
> on gcc 7.3.1. Which gcc is correct?

Hmm, I don't use Fortran's OOP features such as CLASS(*), so
I don't know if there are different rules for CLASS(*) dummy
arguments.  I would presume the F2003, 5.1.2.5.2, would still
hold in F2008 and later.

Just checked.  F2008, 5.3.8.3, appears to be indentical to 
F2003. So, I suspect that gcc 7.3.1 is correct.  I'll that
or unlimited polymorphic variables (CLASS(*)) first appeared
in gfortran in 4.8.x, so the older version like had a bug.

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-17
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
Confirmed.  On Solaris, wint_t is signed but on Linux it's unsigned, so
(wint_t)'\x80' (which is what the test uses) is treated differently between the
two.  The failed assertion is fallout from the change to the sprintf pass
(r263612).

[Bug c++/86998] Improve diagnostic for missing comma in template-parameter-list

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> I don't know why all of GCC, Clang and EDG say something about a
> nested-name-specifier or qualified name for the first template-parameter. I
> don't think the grammar allows a qualified-id there, only a plain identifier.

It is allowed, when naming a non-type template parameter using a qualiflied-id
e.g.

template
struct X {
  template struct Y { };
};

The rest of the PR still stands, we should add a fix-it for the comma.

[Bug libstdc++/86963] std::tuple incorrectly assigned

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for GCC 9.

[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[iains at gcc dot gnu.org]

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

--- Comment #44 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #43)
> (In reply to Iain Sandoe from comment #42)
> > (In reply to Elliot Saba from comment #41)
> > > Has there been any progress on this?  We are running into this while 
> > > trying
> > > to cross-compile GCC for Darwin.  Has this been fixed in 8.3.0?
> > 
> > I will be posting two patches (one just posted today) that are my proposed
> > solution - basically, v2 above plus removing a target hook.
> 
> One is here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00798.html

(this one still needs review from someone for the dwarf2out / final)

the other was
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00767.html

(approved and applied, will be backported soon)

[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335

[snowfed at mail dot ru]

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

--- Comment #7 from snowfed  ---
Wow! Read your book with great pleasure! (the Russian translation of it)

(In reply to Arjen Markus from comment #6)
> Yes, I am :).
> 
> Regards,
> 
> Arjen
>

[Bug c++/87001] New: False error "expansion pattern 'x' contains no argument packs"

[v.reshetnikov at gmail dot com]

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

Bug ID: 87001
   Summary: False error "expansion pattern 'x' contains no
argument packs"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

/*** BEGIN SOURCE ***/
template
struct X {
template class U>
struct Y {
template
using type = U;
};
};
/ END SOURCE /

Or, without using the `typeof` extension, it can be written:

/*** BEGIN SOURCE ***/
template
struct X {
template class U>
struct Y {
template
using type = U;
};
};
/ END SOURCE /


There is an unexpected error:

:6:28: error: expansion pattern 'x' contains no parameter packs
6 | using type = U;
  |^
Compiler returned: 1

For comparison, it compiles fine with Clang.

[Bug testsuite/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|middle-end  |testsuite
 Resolution|--- |FIXED

--- Comment #7 from Martin Sebor  ---
Test adjusted in r263636.

[Bug middle-end/86996] [9 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-1.c FAILs

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Fri Aug 17 21:58:27 2018
New Revision: 263636

URL: https://gcc.gnu.org/viewcvs?rev=263636&root=gcc&view=rev
Log:
PR testsuite/86996

gcc/testsuite/CHangeLog:
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

[Bug jit/87002] New: allow integers larger than "long"

[tromey at gcc dot gnu.org]

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

Bug ID: 87002
   Summary: allow integers larger than "long"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

gcc-jit has gcc_jit_context_new_rvalue_from_int and
gcc_jit_context_new_rvalue_from_long, but on some platforms
long might be 32 bits, but a program could still use int64_t
or long long.  I think gcc-jit should have an intmax_t function,
and perhaps uintmax_t as well.

[Bug jit/87003] New: use nonnull attribute in libgccjit.h

[tromey at gcc dot gnu.org]

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

Bug ID: 87003
   Summary: use nonnull attribute in libgccjit.h
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Many functions in libgccjit.h take a pointer argument,
and it isn't clear which of these can be NULL and which cannot.
It would be a bit helpful if the nonnull attribute were applied
where appropriate.

[Bug jit/87004] New: no way to mark a function as noreturn

[tromey at gcc dot gnu.org]

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

Bug ID: 87004
   Summary: no way to mark a function as noreturn
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Currently all blocks must be terminated either with a jump or a return.
I think it should also be possible to terminate a block with
a call to a noreturn function.  But, there is no way to indicate
that a function is noreturn.

[Bug jit/87005] New: gcc_jit_context_get_builtin_function not documented

[tromey at gcc dot gnu.org]

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

Bug ID: 87005
   Summary: gcc_jit_context_get_builtin_function not documented
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

The function gcc_jit_context_get_builtin_function is not documented.

[Bug c/87006] New: Stack Protection with Large File support

[tausrd at gmail dot com]

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

Bug ID: 87006
   Summary: Stack Protection with Large File support
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tausrd at gmail dot com
  Target Milestone: ---

Dear Sirs,

I would like to report a bug in:

gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609

When adding large file features :

#define _FILE_OFFSET_BITS 64

and gcc option :

-D_FILE_OFFSET_BITS=64

The program compiles ok, but when it runs : gets error "Smashed Stack Detected"
when doing "fclose" to a large file.

The error gets cleaned if I use "gcc ...  -fno-stack-protector", but there is
no protection of stack.

I would prefer to have "stack protection enabled" always with large files
support.

Please, help me to fix this. 

Best Regards,

Claudio SR

[Bug target/87006] Stack Protection with Large File support

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
You should report this to Ubuntu since it is their compiler.

Also do you have a full testcase which is causing the failure at runtime?