[Bug tree-optimization/87325] determine_base_object does not consider consider address space of base expr

[amker at gcc dot gnu.org]

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

--- Comment #2 from bin cheng  ---
Seems alloc_iv doesn't infer base object correctly:
  /* Lower address expression in base except ones with DECL_P as operand.
 By doing this:
   1) More accurate cost can be computed for address expressions;
   2) Duplicate candidates won't be created for bases in different
  forms, like [0] and   */
  STRIP_NOPS (expr);
  if ((TREE_CODE (expr) == ADDR_EXPR && !DECL_P (TREE_OPERAND (expr, 0)))
  || contain_complex_addr_expr (expr))
{
  aff_tree comb;
  tree_to_aff_combination (expr, TREE_TYPE (expr), );
  base = fold_convert (TREE_TYPE (base), aff_combination_to_tree ());
}

  iv->base = base;
  iv->base_object = determine_base_object (base);

Given:
(gdb) call debug_generic_expr(expr)
[1].y

in which "ts" is a VAR_DECL in specific address space:
(gdb) call debug_generic_expr(*addr_p)
ts
(gdb) p (*addr_p)->base.code
$8 = VAR_DECL
(gdb) p (*addr_p)->typed.type->base.u.bits.address_space
$10 = 7

Question is, should be build appropriate pointer type for "ts[1].y", for now, 
  base = build_fold_addr_expr (base);
returns:
(gdb) call debug_generic_expr(base)
[1].y
(gdb) call debug_generic_expr(base->typed.type)
float *

Thanks

[Bug c++/55588] Failure to diagnose non-template-id prefixed by keyword template

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Ville Voutilainen from comment #2)
> Also present in 4.9 trunk, and I recently got a user complaint about this
> bug. How can I upvote? :)

If Bug 86315 is fixed, adding yourself on cc will become kinda like upvoting,
so since you've already added yourself on cc, you've already upvoted.

[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097

[siddhesh at gotplt dot org]

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

--- Comment #2 from Siddhesh Poyarekar  ---
Thanks, I'll take a look.  Kyrill can you please assign the bug to me?  I don't
seem to have to chops to edit the bz.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[egallager at gcc dot gnu.org]

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

--- Comment #12 from Eric Gallager  ---
(In reply to Marc Glisse from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > Sadly I have no better suggestion than -Wno-error=maybe-uninitialized
> 
> Move -Wmaybe-uninitialized from -Wall to -Wextra?

That sounds like a decent suggestion

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||manu at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
cc-ing relevant people

[Bug target/87288] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"

[amker at gcc dot gnu.org]

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

--- Comment #4 from bin cheng  ---
In dump for IVOPTs, there is niter analyzed like:
Applying pattern match.pd:1651, generic-match.c:16009
Analyzing # of iterations of loop 1
  exit condition [1, + , 1](no_overflow) < bnd.8_41
  bounds on difference of bases: 0 ... 2147483646
Applying pattern match.pd:, generic-match.c:115
Applying pattern match.pd:1167, generic-match.c:16905
Applying pattern match.pd:108, generic-match.c:50
  result:
# of iterations bnd.8_41 + 4294967295, bounded by 2147483646
  number of iterations bnd.8_41 + 4294967295

for below GIMPLE:
   [local count: 105119324]:
  niters.6_33 = (unsigned int) n_14;
  ni_gap.7_40 = niters.6_33 + 4294967295;
  bnd.8_41 = ni_gap.7_40 >> 1;

   [local count: 567644349]:
  # vectp.11_44 = PHI 
  # vectp_jacobianTransposeds.15_51 = PHI 
  # ivtmp_54 = PHI 
  vect__5.13_46 = MEM[(double *)vectp.11_44];
  vectp.11_47 = vectp.11_44 + 16;
  vect__5.14_48 = MEM[(double *)vectp.11_47];
  vect_perm_even_49 = VEC_PERM_EXPR ;
  MEM[(double &)vectp_jacobianTransposeds.15_51] = vect_perm_even_49;
  vectp.11_45 = vectp.11_47 + 16;
  vectp_jacobianTransposeds.15_52 = vectp_jacobianTransposeds.15_51 + 16;
  ivtmp_55 = ivtmp_54 + 1;
  if (ivtmp_55 >= bnd.8_41)
goto ; [16.67%]
  else
goto ; [83.33%]

So # of iterations is wrong, it should be:
  bnd.8_41 == 0 ? 0 : bnd.8_41 + 4294967295

This is because bounds is wrongly computed by below code:
  // iv1->base = bnd.8_4;
  // iv0->base =0;
  bound_difference (loop, iv1->base, iv0->base, );

because of wrong range information for bnd.8_4 as in dump for slp1:
;;   basic block 5, loop depth 0, count 105119324 (estimated locally), maybe
hot
;;prev block 3, next block 4, flags: (NEW, VISITED)
;;pred:   2 [89.0% (guessed)]  count:105119324 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  niters.6_33 = (unsigned int) n_14;
  ni_gap.7_40 = niters.6_33 + 4294967295;
  # RANGE [1, 2147483647] NONZERO 2147483647
  bnd.8_41 = ni_gap.7_40 >> 1;

Seems to me bnd.8_41 can take value ZERO.

Is this related to changes in VRP?  Thanks.

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

[asolokha at gmx dot com]

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

Bug ID: 87342
   Summary: [9 Regression] ICE: verify_ssa failed (error:
definition in block 10 does not dominate use in block
8)
   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: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20180916 snapshot (r264351) ICEs when compiling the following
snippet w/ -O1 or -Og:

int ix;

void
o6 (int rh)
{
  if (rh == 0)
{
  ix = 0;
  while (ix < 1)
{
}

  for (;;)
if (ix == 0)
  while (rh < 1)
{
  if (rh == 0)
{
  __builtin_unreachable ();

 kp:
  if (ix == 0)
{
 hk:
  ix = 0;
}
}

  while (rh < 1)
if (ix == 0)
  goto kp;

  while (rh < 1)
{
}
}
else
  goto kp;
}

  goto hk;
}

% gcc-9.0.0-alpha20180916 -O1 -c ifjkuamu.c
ifjkuamu.c: In function 'o6':
ifjkuamu.c:42:1: error: definition in block 10 does not dominate use in block 8
42 | }
   | ^
for SSA_NAME: ix.3_4 in statement:
if (ix.3_4 == 0)
during GIMPLE pass: fre
ifjkuamu.c:42:1: internal compiler error: verify_ssa failed
0xec982e verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-ssa.c:1188
0xbe75ad execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/passes.c:1950
0xbe839e execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/passes.c:1997

[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)

[mi+gcc at aldan dot algebra.com]

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

--- Comment #4 from mi+gcc at aldan dot algebra.com ---
(In reply to Andrew Pinski from comment #3)
> This is a binutils bug, in gold.
> --enable-gold
> 
> Please report this to binutils instead.

Is there a work-around, perhaps? Some additional command-line option I could
give to gfortran now to avoid rebuilding/reinstalling the entire gcc with
--disable-gold? (I already tried -fuse-ld=bfd to no avail.)

Also, this may indeed be a binutils bug, but all I did was run configure with
the advertised options -- and got an unusable Fortran compiler for my
troubles...

If --enable-languages=fortran is incompatible with --enable-gold, configure
should've errored (or warned) right there, should it not have?

If this is a known problem, then either this bug should be used to track it --
or the resolution should be DUPLICATE, with reference to the earlier bug
describing the same...

Thank you for the prompt response.

[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Andrew Pinski  ---
This is a binutils bug, in gold.
--enable-gold

Please report this to binutils instead.

[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)

[mi+gcc at aldan dot algebra.com]

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

--- Comment #2 from mi+gcc at aldan dot algebra.com ---
BTW, I'd dearly love if not a fix, then a work-around ASAP. Is there some kind
of command-line option I can add to gfortran's command-line? Thanks!

[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)

[mi+gcc at aldan dot algebra.com]

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

--- Comment #1 from mi+gcc at aldan dot algebra.com ---
Invoking gfortran with -v I get the following details:

Driving: gfortran -v -o xscblat1 c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a -l
gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-cxx --enable-alloca
--prefix=/prod/pfe/local --with-gmp=/prod/pfe/local --with-mpfr=/prod/pfe/local
--with-mpc=/prod/pfe/local --enable-valgrind-tests --with-system-libz
--with-gcc-major-version-only --enable-lto --enable-gold --enable-ld
--enable-libssp --with-pkgversion=Misha@Local --with-as=/prod/pfe/local/bin/as
--enable-languages=c,c++,fortran,lto,jit,objc --enable-vtable-verify
--enable-gnu-indirect-function --enable-initfini-array --enable-host-shared
Thread model: posix
gcc version 8.2.0 (Misha@Local) 
Reading specs from
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-o' 'xscblat1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
COMPILER_PATH=/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/lib/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'xscblat1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/collect2 -plugin
/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/liblto_plugin.so
-plugin-opt=/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccKgaJkR.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath
-plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
xscblat1 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/crtbegin.o
-L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8
-L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/lib
-L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../.. c_sblat1.o c_sblas1.o
../lib/cblas_LINUX.a -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc
-lc -lgcc_s -lgcc /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/crtend.o
/usr/lib/../lib64/crtn.o
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld:
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so:
_edata: invalid version 21 (max 4)
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld:
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so:
error adding symbols: bad value
collect2: error: ld returned 1 exit status

[Bug fortran/87341] New: gfortran can not link executables: _edata: invalid version 21 (max 4)

[mi+gcc at aldan dot algebra.com]

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

Bug ID: 87341
   Summary: gfortran can not link executables: _edata: invalid
version 21 (max 4)
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mi+gcc at aldan dot algebra.com
  Target Milestone: ---

The entire gcc-8.2 configured with the following:

./configure --enable-cxx --enable-alloca --prefix=/prod/pfe/local
--with-gmp=/prod/pfe/local --with-mpfr=/prod/pfe/local
--with-mpc=/prod/pfe/local --enable-valgrind-tests --with-system-libz
--with-gcc-major-version-only --enable-lto --enable-gold --enable-ld
--enable-libssp --with-pkgversion=Misha@Local --with-as=/prod/pfe/local/bin/as
--enable-languages=c,c++,fortran,lto,jit,objc --enable-vtable-verify
--enable-gnu-indirect-function --enable-initfini-array --enable-host-shared

The resulting C++ and C compilers both seem to work well.

Gfortran also creates object files with ease, however linking the executables
(and the shared libraries) fails thus:

gfortran  -o xscblat1 c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a  
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld:
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so:
_edata: invalid version 21 (max 4)
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld:
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so:
error adding symbols: bad value

[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I'm not sure that changing the meaning of fundamental language constructs like
declarations and writes to them in such a profound way would be viewed as a
good idea.  One way to find out is to email the gcc mailing list.  An even
better way is to prototype it and post an RFC patch to gcc-patches.

[Bug c++/87340] New: Stack overflow problem for c++filt

[poppeter1982 at gmail dot com]

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

Bug ID: 87340
   Summary: Stack overflow problem for c++filt
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: poppeter1982 at gmail dot com
  Target Milestone: ---

Created attachment 44709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44709=edit
PoCs to demonstrate segfaults of c++filt

Hi There

Our fuzzer caught stack overflows in c++filt of the latest binutils code base,
those inputs will cause the segment faults and I have confirmed them with
address sanitizer too. Please use the “c++filt < input” to reproduce the bug. 
If you have any questions, please let me know.

The ASAN dumps the stack trace as follows:

==25314==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc1fb15f58 (pc
0x004a5672 bp 0x7ffc1fb167a0 sp 0x7ffc1fb15f40 T0)
#0 0x4a5671 in malloc
/home/peter668/AFL_KLEE_FUZZ/toolchain/LLVM/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:39
#1 0x5845d4 in xmalloc
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./xmalloc.c:147:12
#2 0x56912c in string_need
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4906:21
#3 0x56a23a in string_append
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4961:3
#4 0x56a23a in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4578
#5 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#6 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#7 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#8 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#9 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#10 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#11 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#12 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#13 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#14 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#15 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#16 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#17 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#18 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#19 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#20 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#21 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#22 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#23 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#24 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#25 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#26 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#27 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#28 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#29 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#30 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#31 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#32 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#33 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#34 0x563e74 in do_type
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:3719
#35 0x56a97b in do_arg
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4332:8
#36 0x56a417 in demangle_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4659:9
#37 0x563e74 in demangle_nested_args
/home/peter668/lipeng/TMP/binutils-gdb/libiberty/./cplus-dem.c:4713:12
#38 0x563e74 in do_type

[Bug c++/86881] tree check fail with flag Wshadow-compatible-local

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-17
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Nathan Sidwell  ---
No lambda's required.  Just the outer one must have some kind of class type:

struct Proxy { };

void Two ()
{
  auto my = Proxy ();
  {
auto my = int (); // boom
  }
}

[Bug c++/86881] tree check fail with flag Wshadow-compatible-local

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Nathan Sidwell  ---
Created attachment 44708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44708=edit
A similar testcase

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Eric Gallager from comment #6)
> > (In reply to Jorn Wolfgang Rennecke from comment #4)
> > > The bug is not fixed; the gcc.c patch has not been reviewed.
> > 
> > What about now, after r169891? As mentioned in the comment after you:
> > 
> > (In reply to simonb from comment #5)
> > > Author: simonb
> > > Date: Mon Feb  7 18:10:15 2011
> > > New Revision: 169891
> > > 
> > > URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=169891
> > > Log:
> > > Auto-detect suitable default behaviour for prefix canonicalization.
> > > 
> > > Current gcc offers -no-canonical-prefixes to turn off realpath() for 
> > > prefixes
> > > generated from the path used to address the gcc driver.  This allows gcc 
> > > to
> > > work in "symlink farm" installations, where every file in gcc is actually 
> > > a
> > > symlink to its real contents.  However, the flag has to be given 
> > > explicitly.
> > > If not, the default is to use realpath() to create prefixes and the result
> > > is usually failure to find cc1[plus], f951, etc.
> > > 
> > > This patch adds a check for a file as a way to auto-detect whether prefix
> > > canonicalization is appropriate or not.  Detection can be overridden by
> > > using the -[no-]canonical-prefixes flags.
> > > 
> > > The patch also completes the fix for PR/29931, adding code that covers the
> > > unadopted portion of this PR's attached patch.
> > > 
> > > gcc/ChangeLog.google:
> > > 2011-02-07  Simon Baldwin  
> > > 
> > >   PR driver/29931
> > >   * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation.
> > >   * gcc.c (display_help): Help text for -[no-]canonical-prefixes.
> > >   (driver_handle_option): Ignore OPT_canonical_prefixes.
> > >   (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect
> > >   suitable default prefix canonicalization mode.
> > >   * common.opt (canonical-prefixes): New flag.
> > > 
> > > Google ref: 40029, 38719
> > > 
> > > 
> > > Modified:
> > > branches/google/integration/gcc/ChangeLog.google-integration
> > > branches/google/integration/gcc/common.opt
> > > branches/google/integration/gcc/doc/invoke.texi
> > > branches/google/integration/gcc/gcc.c
> 
> WAITING on a reply

Assuming this was FIXED

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[egallager at gcc dot gnu.org]

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

Bug 29931 Summary: following argv[0] symlink in process_command breaks 
symlinked-together toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
(In reply to Jürgen Reuter from comment #0)
> Discussed on c.l.f. Sep. 16, 2018.

https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/qhiZMe0snPQ

Replacing

  integer, target :: a( 2:4 )

by

  integer, pointer :: a(:)
  allocate (a( 2:4 ))

"fixes" the issue.

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> To me, two things are unclear in the quote: whether the option is intended
> to be used with other languages at all, and why specifically it "is not
> generally sufficient to protect against stack-clash attacks".

The answer is probably: not really and this doesn't belong to the user manual.

The current wording is Jeff's and I think that it's pretty good, but you are of
course free to post improvements to gcc-patches@

[Bug c/87339] gcc.dg/warn-abs-1.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c/87339] New: gcc.dg/warn-abs-1.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 87339
   Summary: gcc.dg/warn-abs-1.c FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.*, aarch64-unknown-linux-gnu,
powerpc64-unknown-linux-gnu

The new gcc.dg/warn-abs-1.c test FAILs on Solaris/SPARC (32 and 64-bit) and,
according to gcc-testresults, on Linux/Aarch64 and Linux/PowerPC64:

+FAIL: gcc.dg/warn-abs-1.c  (test for warnings, line 48)

I suspect this happens on targets without a distinct _Float128 type.

[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64

[jason.duerstock at gmail dot com]

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

--- Comment #1 from Jason Duerstock  ---
Here is the full build log:
https://buildd.debian.org/status/fetch.php?pkg=gcc-8=ia64=8.2.0-6=1536516302=0

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[sch...@linux-m68k.org]

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

--- Comment #14 from Andreas Schwab  ---
(In reply to Rich Felker from comment #9)
> FWIW, glibc supports building with -fstack-check and seems to be attempting
> to use it for this purpose too. See for example
> https://sourceware.org/bugzilla/show_bug.cgi?id=21253

Glibc does not use -fstack-check, this is a gentoo local setting.

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[amonakov at gcc dot gnu.org]

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

--- Comment #13 from Alexander Monakov  ---
(In reply to Eric Botcazou from comment #12)
> We're going in circles...  -fstack-clash-protection is not stack checking a
> la Ada, it's stack protection against clash attacks and it indeed has
> different requirements that stack checking.

I do not see from existing documentation what the differences are.

(In reply to Eric Botcazou from comment #10)
> Well, that's implicit, if you want to detect stack overflow, you need to
> compile the entire software with stack checking, whatever the implementation
> method.

To add to what Rich said, with -fstack-check callers need to probe one page
ahead even they don't use any stack themselves; this is not obvious and would
be nice to have explained in the documentation. I think a common expectation is
that only subroutines with nontrivial stack usage would have stack probing code
added to them.

int f(int (*p)(void))
{
  return -p();
}

f:
subq$4136, %rsp
orq $0, (%rsp)
addq$4128, %rsp
call*%rdi
negl%eax
addq$8, %rsp
ret


> > I think an indication that this option is intended for use with Ada also
> > would help.
> 
> So what isn't clear in the current wording exactly?
> 
>  `-fstack-check=' is designed for Ada's needs to detect infinite
>  recursion and stack overflows.  `specific' is an excellent choice
>  when compiling Ada code.  It is not generally sufficient to
>  protect against stack-clash attacks.  To protect against those you
>  want `-fstack-clash-protection'.

To me, two things are unclear in the quote: whether the option is intended to
be used with other languages at all, and why specifically it "is not generally
sufficient to protect against stack-clash attacks".

[Bug bootstrap/87338] New: gcc 8.2 fails to bootstrap on ia64

[jason.duerstock at gmail dot com]

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

Bug ID: 87338
   Summary: gcc 8.2 fails to bootstrap on ia64
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.duerstock at gmail dot com
  Target Milestone: ---

In GCC 8.2, the compiler fails to bootstrap due to many files differing between
stage2 and stage3.  After removing the "STAGE2_CFLAGS += -gtoggle" line from
src/config/bootstrap-debug.mk, the compiler successfully bootstraps.

This is with the Debian gcc-8 packaging.

[Bug fortran/87337] New: Internal compiler error on coarrays

[alexey.burluka at northumbria dot ac.uk]

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

Bug ID: 87337
   Summary: Internal compiler error on coarrays
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexey.burluka at northumbria dot ac.uk
  Target Milestone: ---

Created attachment 44707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44707=edit
The fortran code producing the bug.

Attempt to compile a program with co-arrays produces:

internal compiler error: in gfc_conv_descriptor_token, at
fortran/trans-array.c:305
0x6a13b0 gfc_conv_descriptor_token(tree_node*)
../../srcdir/gcc/fortran/trans-array.c:303
0x6aa72d structure_alloc_comps
../../srcdir/gcc/fortran/trans-array.c:8726
0x6c6dfc gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../srcdir/gcc/fortran/trans-expr.c:8831
0x6d64ac gfc_trans_assignment_1
../../srcdir/gcc/fortran/trans-expr.c:10127
0x706a89 gfc_trans_allocate(gfc_code*)
../../srcdir/gcc/fortran/trans-stmt.c:6357
0x69bb87 trans_code
../../srcdir/gcc/fortran/trans.c:1976
0x6c0cf7 gfc_generate_function_code(gfc_namespace*)
../../srcdir/gcc/fortran/trans-decl.c:6335
0x655196 translate_all_program_units
../../srcdir/gcc/fortran/parse.c:6075
0x655196 gfc_parse_file()
../../srcdir/gcc/fortran/parse.c:6275
0x69848f gfc_be_parse_file
../../srcdir/gcc/fortran/f95-lang.c:204

The compilation/linking command is:
gfortran -g -ffree-form -Wall -fcheck=all -fcoarray=lib -o bl1 bl_bug.f95

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> I don't see that as implicit, and it's certainly not true for
> -fstack-clash-protection.

We're going in circles...  -fstack-clash-protection is not stack checking a la
Ada, it's stack protection against clash attacks and it indeed has different
requirements that stack checking.

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[bugdal at aerifal dot cx]

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

--- Comment #11 from Rich Felker  ---
This problem starded because I read "not generally sufficient" in the sense
that it's helpful but not a complete fix for the kinds of issues that
-fstack-clash-protection mitigates. Based on my findings and followup
discussion, I think it's not even helpful, and I wonder why glibc is supporting
it for this use (separate topic of course, but it indicates there's a
misunderstanding of its intended and real capabilities, I think).

Regarding:

> Well, that's implicit, if you want to detect stack overflow, you need to 
> compile the entire software with stack checking, whatever the implementation 
> method.

I don't see that as implicit, and it's certainly not true for
-fstack-clash-protection. Callers that know they have large stacks but don't
use them can of course call into dubious code that might try to use ridiculous
amounts of stack as long as the latter is compiled with stack clash protection.
Likewise (assuming a guard page) a library where all functions have trivial
stack usage is safe to call from a caller that may have almost exhausted its
stack already, even if the library was not compiled with
-fstack-clash-protection.

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> Okay, so can you please document that -fstack-check probes one extra page
> ahead by design, skipping one page adjacent to current stack pointer on the
> assumption that callers are also compiled with -fstack-check and therefore
> must have probed that page previously?

Well, that's implicit, if you want to detect stack overflow, you need to
compile the entire software with stack checking, whatever the implementation
method.

> I think an indication that this option is intended for use with Ada also
> would help.

So what isn't clear in the current wording exactly?

 `-fstack-check=' is designed for Ada's needs to detect infinite
 recursion and stack overflows.  `specific' is an excellent choice
 when compiling Ada code.  It is not generally sufficient to
 protect against stack-clash attacks.  To protect against those you
 want `-fstack-clash-protection'.

[Bug c/87334] RFE: Add '__builtin_ms_va_list' support to ARM64

[mike at cchtml dot com]

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

--- Comment #2 from Michael Cronenworth  ---
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1629910

[Bug c/87334] RFE: Add '__builtin_ms_va_list' support to ARM64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Confirmed. (This should probably be reported to Red Hat's bugzilla too).

[Bug fortran/87336] New: [8/9 regression] wrong output for pointer dummy assiocated to target actual argument

[juergen.reuter at desy dot de]

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

Bug ID: 87336
   Summary: [8/9 regression] wrong output for pointer dummy
assiocated to target actual argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following code is expected to give:
 a [before] =  2 3 4
 arr =  2 3 4
 bounds =  2 4
 arr2=  200 200 200
 a [after]  =  200 200 200
(and did so with gfortran 5.4), but gives with gfortran 8 and 9:
 a [before] =2   3   4
 arr =2   2   2
 bounds =2   4
 arr2=  200 200 200
 a [after]  =  200   3   4

The code is:

program main
  implicit none
  integer, target :: a( 2:4 )

  a = [2,3,4]
  print *, "a [before] = ", a
  call show( a )
  print *, "a [after]  = ", a

contains
  subroutine show( arr )
integer, pointer, intent(in) :: arr(:)
print *, "arr = ", arr
print *, "bounds = ", lbound(arr), ubound(arr)
arr(:) = 200
print *, "arr2= ", arr
  end subroutine show
  end program

Discussed on c.l.f. Sep. 16, 2018.

[Bug c++/87335] New: The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)

[wcventure at 126 dot com]

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

Bug ID: 87335
   Summary: The stack overflow in function cplus_demangle_type in
cp-demangle.c:2565 (c++filt -t)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wcventure at 126 dot com
  Target Milestone: ---

Created attachment 44706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44706=edit
Stack_overflow_in_c++filt-t

Hi,

We have found a stack overflow in function cplus_demangle_type in
cp-demangle.c:2565 in c++filt of the latest binutils code base. 

Here is the POC file. Please use the “c++filt -t < $POC ” to reproduce the bug.
Thank you very much.


Command：“c++filt -t < $POC ” (Please remember to use the option -t)

AddressSanitizer:DEADLYSIGNAL
=
==21814==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcafaefbc0 (pc
0x008d3eb1 bp 0x7ffcafaf02d0 sp 0x7ffcafaefbc0 T0)
#0 0x8d3eb0 in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2367
#1 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#2 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#3 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#4 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#5 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#6 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#7 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#8 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#9 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
...
...
...
#246 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#247 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#248 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5
#249 0x8d523c in cplus_demangle_type
/binutils-2.31/libiberty/./cp-demangle.c:2565:5

SUMMARY: AddressSanitizer: stack-overflow
/binutils-2.31/libiberty/./cp-demangle.c:2367 in cplus_demangle_type
==21814==ABORTING
Aborted

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[bugdal at aerifal dot cx]

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

--- Comment #9 from Rich Felker  ---
FWIW, glibc supports building with -fstack-check and seems to be attempting to
use it for this purpose too. See for example
https://sourceware.org/bugzilla/show_bug.cgi?id=21253

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
(In reply to Manuel López-Ibáñez from comment #10)

Yes, the warning should use the %G directive.  It might be worth reviewing all
the middle-end warnings for this improvement.  Unless we get rid of %G/%K first
and make GCC print the inlining stack unconditionally.

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-09-17
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
My reading of the attribute malloc documentation:

  the pointer P returned by the function cannot alias any other pointer valid
when the function returns, and moreover no pointers to valid objects occur in
any storage addressed by P.

is that in

  int **q = g (sizeof (int*));
  *q = 0;   // *q cannot be equal to *p prior to the assignment

the assignment to *q cannot clobber any object because *q doesn't store a
pointer to any storage.

[Bug c/87334] New: RFE: Add '__builtin_ms_va_list' support to ARM64

[mike at cchtml dot com]

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

Bug ID: 87334
   Summary: RFE: Add '__builtin_ms_va_list' support to ARM64
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike at cchtml dot com
  Target Milestone: ---

Wine 3.0.3 (and 3.8) introduced a change[1] to require the
'__builtin_ms_va_list' extension and when it is missing wine will compile with
clang. Clang 5.0 or higher is required for this extension and RHEL 7 ships
Clang 3. Wine no longer compiles on arm64 and RHEL 7.

RHEL 7 gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
Tested as missing on gcc 8.2.1 as well (Fedora Rawhide).

[1]
https://source.winehq.org/git/wine.git/commit/295359a17447d6ad487b6c652c3a98bbe17cee6e

[Bug middle-end/63155] [6/7/8/9 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
Created attachment 44705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44705=edit
patch

This "simple" one helps.  It builds partition bases similar to the
-ftree-coalesce-vars case.  Correctness needs to be verified still but I think
it errs on the safe side (computing too many dependences at most).  In
particular it avoids computing dependences between things we'll later not try
coalescing anyways.

[Bug tree-optimization/87325] determine_base_object does not consider consider address space of base expr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-17
 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

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

[Bug tree-optimization/87328] [9 Regression] ICE in do_rpo_vn, at tree-ssa-sccvn.c:6566

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 17 13:28:04 2018
New Revision: 264369

URL: https://gcc.gnu.org/viewcvs?rev=264369=gcc=rev
Log:
2018-09-17  Richard Biener  

PR tree-optimization/87328
* tree-ssa-sccvn.c (process_bb): Remove assertion about not
visiting unexecutable backedges when not iterating.
(do_rpo_vn): Mark all edges not executable even when not
iterating.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87328.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/87328] [9 Regression] ICE in do_rpo_vn, at tree-ssa-sccvn.c:6566

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
(In reply to Eric Botcazou from comment #7)
> We cannot reasonably document that a feature does exactly the opposite of
> what it is intended to do, can we?  You need to compile the entire software
> with the
> option, that's all.

Okay, so can you please document that -fstack-check probes one extra page ahead
by design, skipping one page adjacent to current stack pointer on the
assumption that callers are also compiled with -fstack-check and therefore must
have probed that page previously?

I think an indication that this option is intended for use with Ada also would
help.

[Bug c/87316] gcc: internal compiler error: Killed (program cc1)

[david at pgmasters dot net]

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

--- Comment #8 from David  ---
Thanks, using -ftree-coalesce-vars cuts the time down by about 5x and allows
the unit tests to compile in available memory.

We may be able to cut down on the number of setjmps in the unit test macros,
but they are very convenient for testing.

[Bug c++/87333] New: A stack overflow problem for c++filt

[wcventure at 126 dot com]

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

Bug ID: 87333
   Summary: A stack overflow problem for c++filt
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wcventure at 126 dot com
  Target Milestone: ---

Created attachment 44704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44704=edit
c++filt < POC

We have found some stack overflow in c++filt of the latest binutils code base.
Here are the POC files with different kinds of stack overflow.

Please use the “c++filt < POC ” to reproduce the bug.
Please check it and debug it.
Thank you very much.


ASAN output:

(1)binutils-2.31/build/bin$ ./c++filt < POC1

ASAN:DEADLYSIGNAL
=
==7555==ERROR: AddressSanitizer: stack-overflow on address 0x7fffefbe1f48 (pc
0x009566e8 bp 0x7fffefbe2140 sp 0x7fffefbe1f48 T0)
#0 0x9566e7  (/mnt/d/Project/binutils-2.31/build/bin/c++filt+0x9566e7)
#1 0xcccf00  (/mnt/d/Project/binutils-2.31/build/bin/c++filt+0xcccf00)

SUMMARY: AddressSanitizer: stack-overflow
(/mnt/d/Project/binutils-2.31/build/bin/c++filt+0x9566e7) 
==7555==ABORTING
Aborted (core dumped)

(2)binutils-2.31/build/bin$ ./c++filt < POC2

ASAN:DEADLYSIGNAL
=
==14325==ERROR: AddressSanitizer: stack-overflow on address 0x7fffdbe5dff8 (pc
0x7f9d75b4364f bp 0x0018 sp 0x7fffdbe5dfe0 T0)
#0 0x7f9d75b4364e  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x10364e)
#1 0x7f9d75b43137  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x103137)
#2 0x7f9d75a682b1  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x282b1)
#3 0x7f9d75b1eb5a in __interceptor_malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb5a)
#4 0x9cad7c in xmalloc xmalloc.c:147
#5 0x8f22e0 in do_arg cplus-dem.c:4330
#6 0x8f2d70 in demangle_args cplus-dem.c:4659
#7 0x8d9039 in demangle_nested_args cplus-dem.c:4713
#8 0x8d9039 in do_type cplus-dem.c:3719
#9 0x8f1d39 in do_arg cplus-dem.c:4332
#10 0x8f2d70 in demangle_args cplus-dem.c:4659
#11 0x8d9039 in demangle_nested_args cplus-dem.c:4713
#12 0x8d9039 in do_type cplus-dem.c:3719
#13 0x8f1d39 in do_arg cplus-dem.c:4332
#14 0x8f2d70 in demangle_args cplus-dem.c:4659
#15 0x8d9039 in demangle_nested_args cplus-dem.c:4713
#16 0x8d9039 in do_type cplus-dem.c:3719
#17 0x8f1d39 in do_arg cplus-dem.c:4332
#18 0x8f2d70 in demangle_args cplus-dem.c:4659
#19 0x8d9039 in demangle_nested_args cplus-dem.c:4713
#20 0x8d9039 in do_type cplus-dem.c:3719

[Bug other/87332] New: Issues related to Identical Code Folding (ICF)

[marxin at gcc dot gnu.org]

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

Bug ID: 87332
   Summary: Issues related to Identical Code Folding (ICF)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

[Bug libstdc++/83601] std::regex_replace C++14 conformance issue: escaping in SED mode

[dhaumann at kde dot org]

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

Dominik Haumann  changed:

   What|Removed |Added

 CC||dhaumann at kde dot org

--- Comment #4 from Dominik Haumann  ---
If there is interest, another (smaller) test case would be:

const std::string input= R"((.))";
const std::string expected = R"(\(\.\))";
const std::string obtained_std = std::regex_replace(input,
std::regex(R"([.^$|()\[\]{}*+?\\])"), R"(\\&)",
   std::regex_constants::match_default |
std::regex_constants::format_sed);
const std::string obtained_boost = boost::regex_replace(input,
boost::regex(R"([.^$|()\[\]{}*+?\\])"), R"(\\&)",
   boost::regex_constants::match_default |
boost::regex_constants::format_sed);

std::cout << "expected...='" << expected   << "'" << std::endl;
std::cout << "obtained(std)..='" << obtained_std   << "'" << std::endl;
std::cout << "obtained(boost)='" << obtained_boost << "'" << std::endl;

Output with GCC < 8:

expected...='\(\.\)'
obtained(std)..='\\(\\(\\.\\)\\)'
obtained(boost)='\(\(\.\)\)'

With GCC >= 8, it works and it's the same as with boost.

[Bug web/86315] Bugzilla: add "cc count" and "duplicate count" columns

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Is there please any update?

[Bug c++/86001] explicit default constructor not allowed in anonymous aggregate

[raphael.kubo.da.costa at intel dot com]

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

Raphael Kubo da Costa  changed:

   What|Removed |Added

 CC||raphael.kubo.da.costa@intel
   ||.com

--- Comment #1 from Raphael Kubo da Costa  ---
This looks similar to bug 77314.

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Fixed on trunk. It only took 4 years :-(

What are you up to these days, FX?

Paul

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Mon Sep 17 11:22:27 2018
New Revision: 264365

URL: https://gcc.gnu.org/viewcvs?rev=264365=gcc=rev
Log:
2018-09-17  Paul Thomas  

PR fortran/64120
* trans-decl.c (gfc_get_symbol_decl): Flag allocatable, scalar
characters with a variable length expression for deferred init.
(gfc_trans_deferred_vars): Perform the assignment for these
symbols by calling gfc_conv_string_length.

2018-09-17  Paul Thomas  

PR fortran/64120
* gfortran.dg/allocatable_scalar_14.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_14.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/87311] missing integer overflow detection on negation of the minimum value with -ftrapv or UB sanitizer

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Richard Biener from comment #3)
> Yes, I think we have quite some opportunistic replacement of traps by
> "correct" results (according to twos complement).

Yes, that's "correct" according to two's complement, but this may also be a
real overflow that should have been caught (assuming -fwrapv hasn't been
provided).

[Bug tree-optimization/87320] [8/9 Regression] Last iteration of vectorized loop not executed when peeling for gaps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||wrong-code
   Last reconfirmed||2018-09-17
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Last iteration of   |[8/9 Regression] Last
   |vectorized loop not |iteration of vectorized
   |executed when peeling for   |loop not executed when
   |gaps|peeling for gaps
   Target Milestone|--- |8.3
  Known to fail||8.1.0

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

[Bug middle-end/87319] When vector is wrapped, expression is not optimized.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization,
   ||wrong-code
 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Two issues then.  Note the fold-const.c code is considered premature
optimization...

[Bug c/87316] gcc: internal compiler error: Killed (program cc1)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Looks very much related to PR63155.  Lots of setjmp calls in the testcase.
Use -ftree-coalesce-vars when not optimizing.

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

[Bug middle-end/63155] [6/7/8/9 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||david at pgmasters dot net

--- Comment #24 from Richard Biener  ---
*** Bug 87316 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
The issue is in ptrs_compare_unequal () which is limited because points-to
analysis doesn't conservatively propagate NULL and also because it doesn't
handle STRING_CST (similar reason, we drop all pointed-to-readonly-string).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You fail to see that g may clobber *p because p points to global memory.  GCC
knwos that malloc doesn't do such clobbering but you didn't tell GCC that g
does not (looks like you actually can't do that right now).

[Bug c/87311] missing integer overflow detection on negation of the minimum value with -ftrapv or UB sanitizer

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Yes, I think we have quite some opportunistic replacement of traps by "correct"
results (according to twos complement).  -ftrapv is not getting much love and
generally we recommend to use sanitizers these days.  Elsewhere it was
suggested
to lower -ftrapv code to __builtin_()s.

[Bug tree-optimization/87309] [9 Regression] Spurious note: messages when building with -fopt-info-vec-optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||dmalcolm at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|Spurious note: messages |[9 Regression] Spurious
   |when building with  |note: messages when
   |-fopt-info-vec-optimized|building with
   ||-fopt-info-vec-optimized

[Bug testsuite/87304] [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/87328] [9 Regression] ICE in do_rpo_vn, at tree-ssa-sccvn.c:6566

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/87301] [9 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 17 10:21:21 2018
New Revision: 264364

URL: https://gcc.gnu.org/viewcvs?rev=264364=gcc=rev
Log:
2018-09-17  Richard Biener  

PR tree-optimization/87301
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_cleanup): Properly
clean EH info from leftover copy assignments.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87301.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/87301] [9 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/85871] [8/9 Regression] g++.dg/gcov/gcov-8.C random failures

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||9.0
  Known to fail|9.0 |

--- Comment #12 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/85871] [8/9 Regression] g++.dg/gcov/gcov-8.C random failures

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Mon Sep 17 10:19:02 2018
New Revision: 264363

URL: https://gcc.gnu.org/viewcvs?rev=264363=gcc=rev
Log:
Fix out-of-bounds in gcov.c (PR gcov-profile/85871).

2018-09-17  Martin Liska  

PR gcov-profile/85871
* gcov.c (output_intermediate_file): Fix out of bounds
access.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov.c

[Bug c++/87331] if delete "node->operator_type = kADD;" will report "internal compiler error: Segmentation fault"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-09-17
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs/ and provide the requested information.

[Bug c++/87331] New: if delete "node->operator_type = kADD;" will report "internal compiler error: Segmentation fault"

[wucunhua at bytedance dot com]

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

Bug ID: 87331
   Summary: if delete "node->operator_type = kADD;" will report
"internal compiler error: Segmentation fault"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wucunhua at bytedance dot com
  Target Milestone: ---

[Bug fortran/86470] [6/7/8/9 Regression] [OOP] ICE with OMP

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The !$ use omp_lib
line isn't really needed.

Started to ICE with r211397.

[Bug c/87311] missing integer overflow detection on negation of the minimum value with -ftrapv or UB sanitizer

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
I think the current behavior is "by design", beside match.pd frontends do some
opportunistic folding on their own, and neither try hard to avoid concealing
overflow that would be caught by ubsan.

I hope it can change though, with mandatory folding (required by language
standards, e.g. constant expressions) and opportunistic folding for
optimization cleanly separated.

[Bug fortran/87239] ICE in deferred-length string

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #4)
> Duplicate of/ related to pr77325 and pr84109.

PR84109 is completely different. The array descriptor 'elem_len' is being set
to zero during the allocation.

PR77325 is also not related. It appears that the vla type is not being
registered so that the gimplifier is cannot determine the space allocation.

In this PR, the code is OK but in the wrong order. The call to gettwo uses
'S.2' and 'str.3' before they are declared.

I will take this one and will come back to the other two when I am done.

Paul

[Bug c++/87327] [8/9 Regression] Calling member functions on captured constexpr variables "is not a constant expression"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-17
 CC||jason at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|Calling member functions on |[8/9 Regression] Calling
   |captured constexpr  |member functions on
   |variables "is not a |captured constexpr
   |constant expression"|variables "is not a
   ||constant expression"
 Ever confirmed|0   |1
  Known to fail||8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Regression started with r253266:

PR c++/56973, DR 696 - capture constant variables only as needed.

[Bug c++/87300] -Wredundant-move gives false positives in C++11 mode

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Sorry you're right, I forgot we're talking about the converting case here. The
move doesn't prevent elision (because elision isn't possible here).

[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #10 from Martin Liška  ---
I found root cause of it, I'm testing patch for it.

[Bug c++/87322] [8/9 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-09-17
 Ever confirmed|0   |1
Summary|[GCC 8.1+] GCC fails to |[8/9 Regression] GCC fails
   |parse captured lambda of|to parse captured lambda of
   |2nd inner lambda if the |2nd inner lambda if the
   |captured lambda has "," |captured lambda has ","
   |(having 2 arguments)|(having 2 arguments)
   Target Milestone|--- |8.3
  Known to fail||8.2.0, 9.0

--- Comment #2 from Jonathan Wakely  ---
Regression started with r251433 "Reimplement handling of lambdas in templates."

[Bug tree-optimization/87328] [9 Regression] ICE in do_rpo_vn, at tree-ssa-sccvn.c:6566

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-17
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r264273.

[Bug libgomp/87140] Segmentation fault in priority_list_upgrade_task function when execution tasks with priority

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2018-09-17
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Not really fixed in GCC sources though.

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
Created attachment 44703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44703=edit
Patch for the PR

This rather trivial patch fixes the PR.

Paul

[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||siddhesh at gotplt dot org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
CC'ing Siddhesh as this is in the new Falkor pass.

[Bug target/87330] New: ICE in scan_rtx_reg, at regrename.c:1097

[marxin at gcc dot gnu.org]

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

Bug ID: 87330
   Summary: ICE in scan_rtx_reg, at regrename.c:1097
   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
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Following ICEs:

$ aarch64-linux-gnu-gcc  -mtune=qdf24xx -fno-schedule-insns2 -O3
-funroll-all-loops
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/char_eoshift_4.f90
during RTL pass: tag_collision_avoidance
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/char_eoshift_4.f90:39:0:

39 |   call test (eoshift (a, shift4, dim = 2), .false.)
   | 
internal compiler error: in scan_rtx_reg, at regrename.c:1097
0x5d26dd scan_rtx_reg
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regrename.c:1096
0xaa674f scan_rtx
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regrename.c:1424
0xaa674f record_out_operands
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regrename.c:1603
0xaa7967 build_def_use
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regrename.c:1864
0xaa7967 regrename_analyze(bitmap_head*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regrename.c:742
0xdf22ee execute_tag_collision_avoidance()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/config/aarch64/falkor-tag-collision-avoidance.c:812
0xdf36f8 pass_tag_collision_avoidance::execute(function*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/config/aarch64/falkor-tag-collision-avoidance.c:869
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ada/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Investigating.

[Bug rtl-optimization/87329] New: ICE in patch_jump_insn, at cfgrtl.c:1271

[marxin at gcc dot gnu.org]

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

Bug ID: 87329
   Summary: ICE in patch_jump_insn, at cfgrtl.c:1271
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu, ppc64le-linux-gnu

Following causes ICE:

$ aarch64-suse-linux-gcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr47355.C -fmodulo-sched
-O -freorder-blocks-and-partition
during RTL pass: sms
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr47355.C: In function
'void foo()':
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr47355.C:39:1: internal
compiler error: in patch_jump_insn, at cfgrtl.c:1271
 }
 ^
0x76b9afea __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,

[Bug ada/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Still present in 64-bit mode.

[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Mon Sep 17 07:18:17 2018
New Revision: 264358

URL: https://gcc.gnu.org/viewcvs?rev=264358=gcc=rev
Log:
2018-09-17  Paul Thomas  

PR fortran/85954
* resolve.c (resolve_assoc_var): If the target expression is a
deferred charlen dummy and the associate name shares the
charlen, generate a new one. Make sure that new charlens are in
the namespace list so that they get cleaned up.
* trans-array.c (gfc_is_reallocatable_lhs): Associate names are
not reallocatable.
* trans-decl.c (gfc_get_symbol_decl): Put deferred character
length dummy and result arrays on the deferred initialization
list so that the variable length arrays can be correctly dealt
with.
* trans-expr.c (gfc_conv_string_length): Return if 'expr' is
NULL rather than ICEing..

2018-09-17  Paul Thomas  

PR fortran/85954
* gfortran.dg/deferred_character_21.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/deferred_character_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/87328] New: [9 Regression] ICE in do_rpo_vn, at tree-ssa-sccvn.c:6566

[asolokha at gmx dot com]

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

Bug ID: 87328
   Summary: [9 Regression] ICE in do_rpo_vn, at
tree-ssa-sccvn.c:6566
   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: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20180916 snapshot (r264351) ICEs when compiling the following
snippet w/ -O1 (-Og) -fno-tree-ccp -fno-tree-forwprop:

void
tp (void)
{
  int qt;

  qt = 0;
  if (qt != 0)
{
  if (0)
{
 h5:
  qt = 0;
  while (qt < 1)
{
}
}

  ++qt;
}

  goto h5;
}

% gcc-9.0.0-alpha20180916 -O1 -fno-tree-ccp -fno-tree-forwprop -c hyr6b31a.c
during GIMPLE pass: fre
hyr6b31a.c: In function 'tp':
hyr6b31a.c:22:1: internal compiler error: in do_rpo_vn, at
tree-ssa-sccvn.c:6566
22 | }
   | ^
0x6a712b do_rpo_vn
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-ssa-sccvn.c:6566
0xe7946c execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-ssa-sccvn.c:6726