[Bug c/82599] New: Assignments from statically initialized flexible arrays copy too much

[karzes at sonic dot net]

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

Bug ID: 82599
   Summary: Assignments from statically initialized flexible
arrays copy too much
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karzes at sonic dot net
  Target Milestone: ---

Created attachment 42388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42388=edit
C program that demonstrates the bug

I am running on a 32-bit Ubuntu system.

The attached file, fa4.c, shows a problem with the gcc extension which allows
static initialization of flexible array members.

The problem is in main, with the declaration and initialization of second:

s second = first;

The compiler isn't allocating space for the flexible array member in second,
which makes sense.  However, it is copying *all* of first into second,
including the space that was allocated for the flexible array member.  The
result is that it writes past the end of second, and continues writing into the
array v.  When v is printed, instead of printing , it instead prints
the tail of the string that was copied from first, which comes out as .

The same behavior is seen if the declaration of and assignment to s are split
into:

s second;
second = first;

I believe the assignment should only copy sizeof(s) bytes, rather than
including the storage allocated for the flexible array member.

Note that if the declaration and static initialization of first is moved to a
separate file, the problem disappears, and the structure copy behaves as it
should.  But when gcc sees the true allocated size of first, it copies too much
in the assignment.  It should always copy the same amount regardless of where
first is defined.

[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 17 Oct 2017, egallager at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
> 
> Eric Gallager  changed:
> 
>What|Removed |Added
> 
>  CC||egallager at gcc dot gnu.org
> 
> --- Comment #3 from Eric Gallager  --- How 
> essential is the "when inlining or unrolling" portion of the title for 
> this bug? i.e., can it be used as a meta-bug for all -Warray-bounds 
> issues? If not, how to tell if any given -Warray-bounds bug is related 
> to inlining/unrolling or not?

It's hard to tell.  Unless we have another meta-bug just re-use this one.

[Bug tree-optimization/82563] [8 Regression] [graphite] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/82550] program using submodules fails to link

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Wed Oct 18 08:55:27 2017
New Revision: 253848

URL: https://gcc.gnu.org/viewcvs?rev=253848=gcc=rev
Log:
2017-10-18  Paul Thomas  

PR fortran/82550
* trans_decl.c (gfc_get_symbol_decl): Procedure symbols that
have the 'used_in_submodule' attribute should be processed by
'gfc_get_extern_function_decl'.

2017-10-18  Paul Thomas  

PR fortran/82550
* gfortran.dg/submodule_30.f08 : New test.

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

[Bug tree-optimization/56456] [meta-bug] bogus/missing warning (when inlining or unrolling): "array subscript is above array bounds" [-Warray-bounds]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Depends on||82596, 82588, 82585, 82583,
   ||82581, 69224, 82455
Summary|[meta-bug] bogus warning|[meta-bug] bogus/missing
   |when inlining or unrolling: |warning (when inlining or
   |"array subscript is above   |unrolling): "array
   |array bounds"   |subscript is above array
   ||bounds" [-Warray-bounds]
  Alias||Warray-bounds

--- Comment #6 from Eric Gallager  ---
(In reply to rguent...@suse.de from comment #4)
> 
> It's hard to tell.  Unless we have another meta-bug just re-use this one.

I couldn't find another one that looked relevant so I'll re-use this one.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224
[Bug 69224] [6/7/8 Regression] -Warray-bounds false positive with -O3 and
struct pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82455
[Bug 82455] missing -Warray-bounds on strcpy offset in an out-of-bounds range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82581
[Bug 82581] missing -Warray-bounds on writing past the end of a member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583
[Bug 82583] missing -Warray-bounds on out-of-bounds inner indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82585
[Bug 82585] missing -Warray-bounds calling strlen on a member at out-of-bounds
offfset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588
[Bug 82588] missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82596
[Bug 82596] missing -Warray-bounds on an out-of-bounds index into string
literal

[Bug tree-optimization/82603] New: [8 Regression] ICE in ifcvt_local_dce w/ -O2 -ftree-loop-vectorize

[asolokha at gmx dot com]

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

Bug ID: 82603
   Summary: [8 Regression] ICE in ifcvt_local_dce w/ -O2
-ftree-loop-vectorize
   Product: gcc
   Version: 8.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-8.0.0-alpha20171015 snapshot (r253772) ICEs when compiling the following
snippet w/ -O2 -ftree-loop-vectorize:

int
mr (unsigned int lf, int ms)
{
  unsigned int sw = 0;
  char *cu = (char *)

  while (ms < 1)
{
  if (lf == 0)
ms = 0;
  else
ms = 0;
  ms += ((lf > 0) && ((lf > sw) ? 1 : ++*cu));
}

  if (lf != 0)
cu = (char *)
  *cu = lf;

  return ms;
}

% gcc-8.0.0-alpha20171015 -O2 -ftree-loop-vectorize -c qmv6xgzo.c
during GIMPLE pass: ifcvt
qmv6xgzo.c: In function 'mr':
qmv6xgzo.c:2:1: internal compiler error: Segmentation fault
 mr (unsigned int lf, int ms)
 ^~

[Bug c++/79474] Multiple definitions of user-defined conversion operator cause ICE (internal compiler error)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/69057] [C++14] constexpr static variable template assertion segmentation fault

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Oct 18 07:53:27 2017
New Revision: 253844

URL: https://gcc.gnu.org/viewcvs?rev=253844=gcc=rev
Log:
2017-10-18  Paolo Carlini  

PR c++/69057
* g++.dg/cpp1y/auto-fn45.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn45.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/82598] [8 Regression] lto debugobj lacks .note.GNU-stack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2017-10/msg01127.htm
   ||l
   Last reconfirmed||2017-10-18
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/82601] New: missing uninitialized warning with -O0 / -Og

[janus at gcc dot gnu.org]

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

Bug ID: 82601
   Summary: missing uninitialized warning with -O0 / -Og
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Consider this simple Fortran test case:


program uninit

   integer :: p,q
   p = -1
   call sub(p, q)
   if (p

[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"

[slash.tmp at free dot fr]

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

--- Comment #5 from Mason  ---
Slightly smaller testcase, similar to bug 80907.

extern int M[16];
void foo(int n)
{
for (int i = 0; i < n; ++i)
for (int j = 0; j < i; ++j)
M[i+j] = 0;
}

$ gcc-7 -O3 -Wall -S testcase4.c 
testcase4.c: In function 'foo':
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
M[i+j] = 0;
~^
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]
testcase4.c:6:5: warning: array subscript is above array bounds
[-Warray-bounds]

Same result with trunk.

Using -fopt-info adds:
testcase4.c:5:3: note: loop turned into non-loop; it never loops.
testcase4.c:5:3: note: loop with 17 iterations completely unrolled

[Bug tree-optimization/82585] missing -Warray-bounds calling strlen on a member at out-of-bounds offfset

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Probably one form is folded to [4] and p->a + 4 is not folded to >a[4].

[Bug lto/82575] New: [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails

[amodra at gmail dot com]

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

Bug ID: 82575
   Summary: [8 Regression] lto debugobj references __gnu_lto_slim,
ld test liblto-17 fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
   Summary: [8 Regression] lto debugobj references __gnu_lto_slim,
ld test liblto-17 fails

I recently upgraded the set of cross-compilers I use to test binutils, and
found that gcc trunk causes fails of some ld lto tests.

+FAIL: Build liblto-17a.so
+FAIL: Build liblto-17b.so 1
+FAIL: Build liblto-17b.so 2

Seen on aarch64-linux, arm-linuxeabi, hppa-linux, m68k-linux, mips64-linux,
nios2-linux, powerpc64le-linux, powerpc64-linux, powerpc-linux, s390-linux,
s390x-linux, sparc64-linux, tilepro-linux, and x86_64-linux.

Breakpoint 3, elf_link_add_object_symbols (info=, abfd=0xa6d1c0)
at /home/alan/src/binutils-gdb/bfd/elflink.c:4336
4336  if (isym->st_shndx == SHN_COMMON
(gdb) p name
$8 = 0xa70cd3 "__gnu_lto_slim"
(gdb) p abfd->filename
$9 = 0xa6d100 "/tmp/ccF0RcA1debugobj"

The debugobj is from
powerpc64le-linux-gcc -B /home/alan/build/gas/powerpc64le-linux/ld/tmpdir/ld/
-mcpu=power8 -r -nostdlib -o /tmp/ccF0RcA1debugobj /tmp/ccuOMpMydebugobjtem
[Leaving LTRANS /tmp/ccuOMpMydebugobjtem]

$ readelf -s --wide /tmp/ccF0RcA1debugobj
Symbol table '.symtab' contains 8 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 SECTION LOCAL  DEFAULT1 
 2:  0 SECTION LOCAL  DEFAULT3 
 3:  0 SECTION LOCAL  DEFAULT4 
 4:  0 FILELOCAL  DEFAULT  ABS lto-17a.c
 5:  0 NOTYPE  GLOBAL DEFAULT  UND __gnu_lto_slim
 6:  0 NOTYPE  GLOBAL DEFAULT  UND __gnu_lto_v1
 7:  0 NOTYPE  WEAK   HIDDEN 1 lto_17a.c.4af7515b

$ readelf -s --wide /tmp/ccuOMpMydebugobjtem
...
22:  0 NOTYPE  GLOBAL DEFAULT  UND __gnu_lto_v1
23:  0 NOTYPE  GLOBAL DEFAULT  UND __gnu_lto_slim

These references in LTO *output* files result in __gnu_lto_slim appearing as a
dynamic symbol in liblto-17a.so and liblto-17b.so.  nm doesn't like that, and
you get a complaint about missing plugins.  I don't believe the linker is doing
anything wrong here..

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw  ---
Confirmed, I can see that tests have started passing on my side. Thanks!

[Bug c++/82593] Internal compiler error: in process_init_constructor_array, at cp/typeck2.c:1294

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
 Ever confirmed|0   |1

[Bug sanitizer/82545] [7/8 Regression] -O2: ICE in gimple_split_edge, at tree-cfg.c:2838, during GIMPLE pass sanopt

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Wed Oct 18 08:14:47 2017
New Revision: 253845

URL: https://gcc.gnu.org/viewcvs?rev=253845=gcc=rev
Log:
Do not put gimple stmt on an abnormal edge (PR sanitizer/82545).

2017-10-18  Martin Liska  

PR sanitizer/82545
* asan.c (asan_expand_poison_ifn): Do not put gimple stmt
on an abnormal edge.
2017-10-18  Martin Liska  

PR sanitizer/82545
* gcc.dg/asan/pr82545.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr82545.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/82545] [7 Regression] -O2: ICE in gimple_split_edge, at tree-cfg.c:2838, during GIMPLE pass sanopt

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] -O2: ICE   |[7 Regression] -O2: ICE in
   |in gimple_split_edge, at|gimple_split_edge, at
   |tree-cfg.c:2838, during |tree-cfg.c:2838, during
   |GIMPLE pass sanopt  |GIMPLE pass sanopt

--- Comment #9 from Martin Liška  ---
Fixed on trunk, queued for backports.

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
 Ever confirmed|0   |1

[Bug c++/82600] [8 Regression] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase:
void *b[10];

template 
void **
foo (int x)
{
  void **a = b;
  return [x];
}

void **
bar (int x)
{
  return foo <0> (x);
}

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-18
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I'll have a look.

[Bug c++/79474] Multiple definitions of user-defined conversion operator cause ICE (internal compiler error)

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Oct 18 07:24:50 2017
New Revision: 253841

URL: https://gcc.gnu.org/viewcvs?rev=253841=gcc=rev
Log:
2017-10-18  Paolo Carlini  

PR c++/79474
* g++.dg/cpp1y/auto-fn44.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn44.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68884] template of value template crashes the compiler

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Oct 18 07:43:06 2017
New Revision: 253843

URL: https://gcc.gnu.org/viewcvs?rev=253843=gcc=rev
Log:
2017-10-18  Paolo Carlini  

PR c++/68884
* g++.dg/cpp0x/variadic-crash4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash4.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68884] template of value template crashes the compiler

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #7 from Paolo Carlini  ---
Fixed for 6.2.0.

[Bug c++/82600] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[sylvestre at debian dot org]

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

--- Comment #2 from Sylvestre Ledru  ---
the command line:
/usr/bin/g++-8 -std=gnu++11 -o Unified_cpp_memory_build0.o -c
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include
/root/firefox-gcc-last/config/gcc_hidden.h -DDEBUG=1 -DMOZ_MEMORY_IMPL
-DMOZ_HAS_MOZGLUE -I/root/firefox-gcc-last/memory/build
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/memory/build
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/nspr
-I/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/dist/include/nss  -fPIC 
-DMOZILLA_CLIENT -include
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/mozilla-config.h -MD -MP -MF
.deps/Unified_cpp_memory_build0.o.pp  -Wall -Wc++11-compat -Wempty-body
-Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare
-Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof
-Wc++14-compat -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat
-Wformat-overflow=2 -fno-exceptions -fno-strict-aliasing -fno-rtti
-fno-exceptions -fno-math-errno -pthread -pipe  -g -freorder-blocks -Os
-fno-omit-frame-pointer  -Werror -Wno-unused-function -Wno-error=uninitialized 
-fdiagnostics-color 
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/memory/build/Unified_cpp_memory_build0.cpp

[Bug tree-optimization/82591] [8 Regression] [graphite] Compile-time hog w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
 CC||skimo at kotnet dot org,
   ||spop at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
With GCC 7 we have zero SCOPs detected, with GCC 8 we detect one SCOP.  What
takes all the time is code generation(!), namely
isl_ast_build_node_from_schedule.  The
schedule isn't that complicated:

domain: "[P_32] -> { S_6[i1, i2] : 0 <= P_32 <= 65535 and 0 <= i1 <= 127 and 0
<= i2 <= 2 and 65536*floor((-513 + P_32 - 1539i1 - 513i2)/65536) >= -514 + P_32
- 1539i1 - 513i2 }"
child:
  schedule: "[P_32] -> [{ S_6[i1, i2] -> [(floor((i1)/51))] }, { S_6[i1, i2] ->
[(floor((i2)/51))] }]"
  permutable: 1
  coincident: [ 1, 1 ]
  options: "{ separate[0] }"
  child:
schedule: "[P_32] -> [{ S_6[i1, i2] -> [(i1 - 51*floor((i1)/51))] }, {
S_6[i1, i2] -> [(i2 - 51*floor((i2)/51))] }]"
permutable: 1
coincident: [ 1, 1 ]
options: "{ separate[0] }"

note there's no limiting in place on the AST generator.

I don't immediately see what we can do about this - it looks like a bug in ISL
to me.  Sven?  It looks like the above might be enough to turn this into a
ISL testcase for test_inputs/codegen?  The separate option is not necessary to
trigger the problem.  The AST generated is

for (int c0 = 0; c0 <= 2; c0 += 1)
  for (int c2 = 0; c2 <= min(50, -51 * c0 + 127); c2 += 1)
for (int c3 = 0; c3 <= 2; c3 += 1)
  if ((-P_32 + 78489 * c0 + 1539 * c2 + 513 * c3 + 66048) % 65536 >= 65534)
S_6(51 * c0 + c2, c3);

The AST generated for the original schedule (before ISL optimizing and
blocking) is

for (int c0 = 0; c0 <= 127; c0 += 1)
  for (int c1 = 0; c1 <= 2; c1 += 1)
if ((-P_32 + 1539 * c0 + 513 * c1 + 66048) % 65536 >= 65534)
  S_6(c0, c1);

and the corresponding schedule is

domain: "[P_32] -> { S_6[i1, i2] : 0 <= P_32 <= 65535 and 0 <= i1 <= 127 and 0
<= i2 <= 2 and 65536*floor((-513 + P_32 - 1539i1 - 513i2)/65536) >= -514 + P_32
- 1539i1 - 513i2 }"
child:
  schedule: "[P_32] -> L_1[{ S_6[i1, i2] -> [(i1)] }]"
  child:
schedule: "[P_32] -> L_2[{ S_6[i1, i2] -> [(i2)] }]"

On the GCC side we can avoid the slowness with --param loop-block-tile-size=0
thus turn off forced blocking (we're doing quite stupid blocking by 51 even on
loops that we know iterate less...).

Our tiling code is doing

  long tile_size = PARAM_VALUE (PARAM_LOOP_BLOCK_TILE_SIZE);
  if (dims <= 1
  || tile_size == 0
  || !isl_schedule_node_band_get_permutable (node))
{
  if (dump_file && dump_flags)
fprintf (dump_file, "not tiled\n");
  return node;
}

  /* Tile loops.  */
  space = isl_schedule_node_band_get_space (node);
  isl_multi_val *sizes = isl_multi_val_zero (space);
  isl_ctx *ctx = isl_schedule_node_get_ctx (node);

  for (unsigned i = 0; i < dims; i++)
{
  sizes = isl_multi_val_set_val (sizes, i,
 isl_val_int_from_si (ctx, tile_size));
  if (dump_file && dump_flags)
fprintf (dump_file, "tiled by %ld\n", tile_size);
}

  node = isl_schedule_node_band_tile (node, sizes);
  node = isl_schedule_node_child (node, 0);

any hint where we can avoid tiling with obviously too big tiles?

[Bug c++/82600] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[sylvestre at debian dot org]

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

--- Comment #3 from Sylvestre Ledru  ---
Created attachment 42389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42389=edit
preprocessed file

[Bug middle-end/82601] missing uninitialized warning with -O0 / -Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
The warning is issued because we inline sub.

As we do not know whether 'o' is used we don't issue a warning in sub() that
o is not initialized (does intent(out) mean it comes in uninitialized?).
Just looking at the program sub has intent(out) q and thus we can reasonably
expect it to be initialized.

So - is 'o' uninitialized in

subroutine test(o)
 integer, intent(out) :: o
 print *, o
end subroutine

?  It doesn't seem so (we don't warn but I also think we have no way to
annotate sth as uninitalized that is passed by reference).

[Bug target/82445] ARM target generates unaligned STRD instruction

[petrcvekcz at gmail dot com]

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

Petr Cvek  changed:

   What|Removed |Added

 CC||petrcvekcz at gmail dot com

--- Comment #5 from Petr Cvek  ---
Get the same bug with: gcc version 7.1.0 (crosstool-NG
crosstool-ng-1.23.0-88-gfae66ae3) 

Bug free version: gcc version 6.3.0 (crosstool-NG
crosstool-ng-1.22.0-452-gc7b1e295) 

Testing program: just main() with "helloworld" calling the example code
(strd.c) compiled as object file.

march/mtune combinations which are OK:

-march=armv5te -mtune=xscale
-march=armv5te -mtune=iwmmxt
-march=iwmmxt
-march=armv5t (actually less opcodes than variants above)
-march=armv5

march/mtune combinations which generate an unaligned access in STRD (even with
-mno-unaligned-access):

-march=armv5te (tested on a real HW, generating alignment exceptions in
/proc/cpu/alignment)
-march=armv5tej (not existing on gcc 6.3.0)
-march=armv5te -mtune=arm1020e
-march=armv5te -mtune=arm926ej-s

[Bug c++/82600] New: Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[andi at mozilla dot com]

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

Bug ID: 82600
   Summary: Address of local variable returned
[-Werror=return-local-addr] when building
mozilla-central
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi at mozilla dot com
  Target Milestone: ---

Building firefox with gcc8 trunk i get this error:

In file included from
/root/firefox-gcc-last/obj-x86_64-pc-linux-gnu/memory/build/Unified_cpp_memory_build0.cpp:2:0:
 /root/firefox-gcc-last/memory/build/mozjemalloc.cpp: In member function
'void** AddressRadixTree::GetSlot(void*, bool)':
 /root/firefox-gcc-last/memory/build/mozjemalloc.cpp:1695:10: error: address of
local variable 'node' returned [-Werror=return-local-addr]
void** node;
   ^~~~
 cc1plus: all warnings being treated as errors

The entire context can be found here:
[1]
http://searchfox.org/mozilla-central/rev/a984558fa2bbde6492d3fb918496fc0b0835b2ce/memory/build/mozjemalloc.cpp#1721
[2]
http://searchfox.org/mozilla-central/rev/a984558fa2bbde6492d3fb918496fc0b0835b2ce/memory/build/mozjemalloc.cpp#1698
It can easily be seen that by just analysing [2] 'node' only points somewhere
in 'mRoot'.

[Bug c++/69057] [C++14] constexpr static variable template assertion segmentation fault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed in 5.4.0.

[Bug sanitizer/82595] bootstrap fails in libsanitizer on powerpc64-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Well, lsan_preinit.o shouldn't be linked into liblsan.so.*, either we should
just ignore it completely, or install and link in like asan_preinit.o or
tsan_preinit.o is.

[Bug rtl-optimization/82597] [8 Regression] ICE at -O2 and -O3 x86_64-linux-gnu in the 32-bit mode: in extract_constrain_insn, at recog.c:2207

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug target/69888] ICE: SIGSEGV in decide_alg (i386.c:26169) due to infinite (?) recursion with -minline-all-stringops -mmemset-strategy=no_stringop:-1:noalign

[zsojka at seznam dot cz]

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

--- Comment #9 from Zdenek Sojka  ---
I think this bug can be closed now: it was fixed for gcc 6+ and gcc 5.4+.

[Bug c++/80991] ICE with __is_trivially_constructible in template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Seems easy.

[Bug c/82599] Assignments from statically initialized flexible arrays copy too much

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
Version|5.4.0   |7.2.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I think the issue is that we make the new type created by
constructing the object compatible (or the same) as the second.  Then we get to
invalid GIMPLE
being simply

  second = first;

which ends up using expr_size from the source.  Iff the C FE wants to support
this kind of assignments (not sure if it really should!) then it needs to
tack appropriate WITH_SIZE_EXPRs on the decls.

[Bug c++/82600] [8 Regression] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|Address of local variable   |[8 Regression] Address of
   |returned|local variable returned
   |[-Werror=return-local-addr] |[-Werror=return-local-addr]
   |when building   |when building
   |mozilla-central |mozilla-central

--- Comment #4 from Jakub Jelinek  ---
Seems to have started with r253599.  Will try to reduce it now.

[Bug c++/69698] [meta-bug] flexible array members

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Depends on||82599
  Alias||flexmembers

--- Comment #2 from Eric Gallager  ---
alias flexmembers


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82599
[Bug 82599] Assignments from statically initialized flexible arrays copy too
much

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[david at westcontrol dot com]

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

David Brown  changed:

   What|Removed |Added

 CC||david at westcontrol dot com

--- Comment #2 from David Brown  ---
For reference, the issue is also discussed here:

https://bugs.launchpad.net/gcc-arm-embedded/+bug/1722849

For this particular case, there are usable workarounds (with extra dependencies
or memory clobbers).  But "asm volatile" statements should not be moveable
across other asm volatile statements, volatile memory accesses, or other
observable behaviour.  (It is fine that they can be moved across other code,
just like other volatile accesses.)

[Bug tree-optimization/65461] -Warray-bounds warnings in the linux kernel (free_area_init_nodes)

[slash.tmp at free dot fr]

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

Mason  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org,
   ||slash.tmp at free dot fr

--- Comment #3 from Mason  ---
Here is a reduced test case:

extern void foo(int *p);
extern int array[2];
void func(void)
{
int i;

for (i = 1; i < 2; i++) {
if (i == 1) continue;
array[i-1] = 0;
}

foo();
}

$ gcc-7 -O3 -Wall -S testcase5.c 
testcase5.c: In function 'func':
testcase5.c:9:14: warning: array subscript is below array bounds
[-Warray-bounds]
 array[i-1] = 0;
 ~^

It is obvious that the loop is a NOP (other than setting i to 2)
(start at 1, skip that index, move to 2, exit loop)
And gcc figures it out, but only after issuing a spurious warning.

func:
subq$24, %rsp   # allocate space on the stack
leaq12(%rsp), %rdi  # copy  to rdi
movl$2, 12(%rsp)# i = 2
callfoo # foo()
addq$24, %rsp   # clean up stack
ret

[Bug c++/82600] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-10-18
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Can you please attach preprocessed source + full g++ command line?  Thanks.

[Bug rtl-optimization/73650] powerpc: -mcpu=e500mc hits ICE: insn does not satisfy its constraints

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #13 from Segher Boessenkool  ---
Yes, thanks Arseny.  Fixed.

[Bug rtl-optimization/82602] New: IRA considers volatile asm to be moveable

[segher at gcc dot gnu.org]

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

Bug ID: 82602
   Summary: IRA considers volatile asm to be moveable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42390=edit
testcase

https://gcc.gnu.org/ml/gcc-help/2017-10/msg00061.html reports a problem
where volatile asm statements (without output) are moved around incorrectly.

Testcase attached, build with
  arm-eabi-gcc -Wall -W -O1 -mcpu=cortex-m0plus -mthumb
and see the asm statements reordered (on GCC 5 at least, it does
not seem to trigger the bug with trunk).

I have a patch.

[Bug lto/82598] [8 Regression] lto debugobj lacks .note.GNU-stack

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Oct 18 09:20:31 2017
New Revision: 253851

URL: https://gcc.gnu.org/viewcvs?rev=253851=gcc=rev
Log:
PR lto/82598
* simple-object.c (handle_lto_debug_sections): Copy over also
.note.GNU-stack section with unchanged name.
* simple-object-elf.c (SHF_EXECINSTR): Define.
(simple_object_elf_copy_lto_debug_section): Drop SHF_EXECINSTR bit
on .note.GNU-stack section.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/simple-object-elf.c
trunk/libiberty/simple-object.c

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

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

[Bug c++/82600] [8 Regression] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 42392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42392=edit
gcc8-pr82600.patch

Untested fix.  The problem is that the -Wreturn-local-addr implementation
requires full folding of the expressions such that it will actually not see
an ARRAY_REF if the corresponding DECL isn't an array, but a pointer.
Such folding isn't performed if processing_template_decl though (no folding is
done, cp_fully_fold just returns the passed argument immediately).

[Bug c++/55189] enable -Wreturn-type by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
cc-ing Martin Liska because I think he fixed this recently

[Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails

[amodra at gmail dot com]

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

--- Comment #3 from Alan Modra  ---
Patch now bootstrapped and regression tested powerpc64le-linux.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
Summary|[meta-bug] bogus/missing|[meta-bug] bogus/missing
   |warning (when inlining or   |-Warray-bounds
   |unrolling): "array  |
   |subscript is above array|
   |bounds" [-Warray-bounds]|

--- Comment #7 from Martin Sebor  ---
Now that this bug has become a tracker for both false positives and false
negatives the inlining/unrolling part is not relevant anymore so adjusting the
Summary.

[Bug tree-optimization/82612] New: missing -Warray-bounds on a non-zero offset from the address of a non-array object

[msebor at gcc dot gnu.org]

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

Bug ID: 82612
   Summary: missing -Warray-bounds on a non-zero offset from the
address of a non-array object
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

More testing of my -Warray-bounds patch for pr82588 et al. exposed a missing
warning on the following corner case (and similar cases like it).

$ cat a.c && gcc -O2 -S -Warray-bounds a.c
int g (int i)
{
  int *p = 

  return p[2];
}

To detect this the implementation could check the operand of the address-of
operator and trigger if it's a non-array object.  It should even be possible to
detect the out-of-bounds index in the following:

int a[3];
int b[5];

int f (int i)
{
  int *p = i < 0 ? a : b;

  return p[7];
}

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

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

--- Comment #27 from Chris Johns  ---
(In reply to Jack Howarth from comment #25)
> (In reply to Chris Johns from comment #24)
> Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local
> is set to install-freestanding-headers instead of install-headers in
> libstdc++-v3/include/Makefile.in? Perhaps you need...
> 
> .NOTPARALLEL: install-freestanding-headers
> 
> as well?

I tried a number of options when looking and also I thought all that was needed
was .NOTPARALLEL:. I will boot up the Mac and take look soon.

I looked over the include's Makefile.in and I am still a little confused about
the race-condition being patched with .NOTPARALLEL. I could not see one, which
is not unusual with this type of issue. The failure for me is always in a
header the massive 'ln -s' as I stated before and this is part of the 'all'
target being invoked at this point in time yet it is a C++ file being built by
some other Makefile that is seeing the file not present and when I inspect the
directory after the failure the link is present. Is the race condition or
failure somewhere else?

[Bug inline-asm/81890] asm memory constraints are difficult and not well documented

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #1 from Alan Modra  ---
Fixed with git b184df229c (svn r253700) and git a486310e37 (svn r253701). 
Forgot to add the bug number to the ChangeLog.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[glisse at gcc dot gnu.org]

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

--- Comment #28 from Marc Glisse  ---
I am also failing to see how this can happen without a bug in make or macos.
The failing command is the recipe for ${pch1b_output}. That rule has
${allstamped} as a dependency, which includes stamp-bits-sup, whose recipe does
link the header. At least, disabling precompiled headers should work around it
(--disable-libstdcxx-pch IIRC)

You could always remove the @ sign on the $(STAMP) lines (and the ones before)
so it gets printed in the output, maybe that would show something suspicious.
If you are building in a clean directory (the headers aren't there yet), you
could also remove '-' at the beginning of the $(LN_S) lines, to make sure that
no error occurs. Running make in verbose mode might also hint at something.
Maybe print the date in the pch rule (or use the creation date of
${pch1_output_builddir}), and compare it to the creation date of the symlinks,
etc.

If the issue was with make, you could try replacing
all-local: ${allstamped} ${allcreated}

with
all-local:
$(MAKE) ${allstamped}
$(MAKE) ${allcreated}

Generally, I don't understand why we are linking sources in the build directory
instead of passing -I flags pointing directly to the source directory.

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
cc-ing Martin Liska since he made -Wreturn-type enabled by default now.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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

--- Comment #25 from Jack Howarth  ---
(In reply to Chris Johns from comment #24)
> I would welcome a patch attached to this ticket. 
> 
> My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to
> build. I have seen a build work however most fail with a range of headers
> that can vary from build to build. I can see the massive `ln -s` happening
> and after the build fails and stops all the links are present.

Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local is
set to install-freestanding-headers instead of install-headers in
libstdc++-v3/include/Makefile.in? Perhaps you need...

.NOTPARALLEL: install-freestanding-headers

as well?

[Bug go/82607] SPARC Linux: go frontend runs infinitely on 5.4.0, 6.4.0 and 7.2.0

[i at jsteward dot moe]

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

--- Comment #1 from i at jsteward dot moe ---
Seems like a simple Hello world directly compiled with gccgo will work as
normal.

[Bug tree-optimization/82585] missing -Warray-bounds calling strlen on a member at out-of-bounds offfset

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
(In reply to Richard Biener from comment #1)
> Probably one form is folded to [4] and p->a + 4 is not folded to >a[4].

That's right.  (a + 4) is MEM_REF (char[3], ADDR_EXPR (char[3], VAR_DECL (a)))
and (p->a + 4 is) MEM_REF (char[3], SSA_NAME (p), 4).  The latter makes it
impossible to tell the invalid (p->a + 10) from the valid (p[1].a + 2).

But maybe it's not completely hopeless.  Even if we can't tell whether the
result of the pointer addition is derived from a pointer to the same subobject,
it should be possible to determine whether or not the resulting pointer points
to the same subobject (or at least one of the same type) as the original
pointer.  That doesn't detect all kinds of problems but it detects the worst
kind: using a pointer to T to access a subobject of type U.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
No, cross-compiles are not automatically freestanding, and .NOTPARALLEL ignores
any prerequisites, so it makes no difference whether you say

.NOTPARALLEL: install-freestanding-headers

or

.NOTPARALLEL: install-headers

or

.NOTPARALLEL:

they all have the same effect.

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
BTW, perhaps powerpc64, aarch64 or other targets could benefit from similar
approach.  Shall we clone this PR for those?

[Bug c++/82600] [8 Regression] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[andi at mozilla dot com]

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

--- Comment #8 from Andi  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Andi from comment #0)
> > Building firefox with gcc8 trunk i get this error:
> 
> This is a warning, not an error. 
> 
> If you use -Werror to cause compilation to fail that's your choice, but it's
> still just a warning as far as we're concerned.
> 
> If you can't build because you choose to use -Werror then don't use -Werror.
Indeed the build was ran with -Werror since we wanted to see what are our
blockers.

[Bug tree-optimization/82603] [8 Regression] ICE in ifcvt_local_dce w/ -O2 -ftree-loop-vectorize

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/82591] [8 Regression] [graphite] Compile-time hog w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 18 14:35:26 2017
New Revision: 253856

URL: https://gcc.gnu.org/viewcvs?rev=253856=gcc=rev
Log:
2017-10-18  Richard Biener  

PR tree-optimization/82591
* graphite.c (graphite_transform_loops): Move code gen message
printing ...
* graphite-isl-ast-to-gimple.c (graphite_regenerate_ast_isl):
Here.  Handle scop_to_isl_ast failing.
(scop_to_isl_ast): Limit the number of ISL operations.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/graphite.c

[Bug middle-end/66031] Spurious array bounds warning

[slash.tmp at free dot fr]

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

Mason  changed:

   What|Removed |Added

 CC||slash.tmp at free dot fr

--- Comment #2 from Mason  ---
FWIW, the following code looks somewhat fishy to me:

unsigned char f = 10;
extern unsigned char p[1];
char check(unsigned int n)
{
   if (n - 1 >= f) return p[n];
   return 1;
}

p[n] is well-defined iff n = 0

If n = 0, n - 1 = UINT_MAX, thus the test is true for any f
No other value of n is allowed as an index into p.

Thus I would expect gcc to turn the code into

  return (n == 0) ? p[0] : 1;

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|uros at gcc dot gnu.org|ubizjak at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)
> Or, it is yours then.
> Does it handle all of:

Yes, all.

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
The fact that flags is live is the reason why the
(define_peephole2
  [(parallel [(set (reg FLAGS_REG) (match_operand 0))
  (match_operand 4)])
   (set (match_operand:QI 1 "register_operand")
(match_operator:QI 2 "ix86_comparison_operator"
  [(reg FLAGS_REG) (const_int 0)]))
   (parallel [(set (match_operand 3 "any_QIreg_operand")
   (zero_extend (match_dup 1)))
  (clobber (reg:CC FLAGS_REG))])]
  "(peep2_reg_dead_p (3, operands[1])
|| operands_match_p (operands[1], operands[3]))
   && ! reg_overlap_mentioned_p (operands[3], operands[0])
   && ! reg_set_p (operands[3], operands[4])
   && peep2_regno_dead_p (0, FLAGS_REG)"
  [(parallel [(set (match_dup 5) (match_dup 0))
  (match_dup 4)])
   (set (strict_low_part (match_dup 6))
(match_dup 2))]
{
  operands[5] = gen_rtx_REG (GET_MODE (operands[0]), FLAGS_REG);
  operands[6] = gen_lowpart (QImode, operands[3]);
  ix86_expand_clear (operands[3]);
})
peephole doesn't trigger.  What I meant is another peephole that would emit
xorl%eax, %eax
cmpq%rdi, %rdx
sbbq%rsi, %rcx
setb%al
i.e. like the above peephole, but with yet another instruction.  Let me try to
write it...

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #42393|0   |1
is obsolete||

--- Comment #11 from Uroš Bizjak  ---
Created attachment 42395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42395=edit
Prototype patch in testing

[Bug tree-optimization/82591] [8 Regression] [graphite] Compile-time hog w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

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  ---
Looks like we have to set max-operations around AST generation as well (I'll
allow it another share of the same param).

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 42394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42394=edit
gcc8-pr82580-peephole2.patch

Untested incremental patch with the 2 peepholes.

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)
> I'll have a look.

Oh, I already have a patch...

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Nice.  I wonder about one further thing.
With your patch, we generate e.g. in f0:
xorq%rdx, %rdi
xorq%rcx, %rsi
xorl%eax, %eax
orq %rsi, %rdi
sete%al
i.e. for the flags we first clear %eax and then setX %al, but for f2
cmpq%rdi, %rdx
sbbq%rsi, %rcx
setb%al
movzbl  %al, %eax
Seems this is done in
;; Convert setcc + movzbl to xor + setcc if operands don't overlap.
peephole2s, do we need a peephole for this as well, or some more general
peephole2 or other means of optimizing this?

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #4 from Xi Ruoyao  ---
By the way, in kernel code (compiler-gcc.h) there is a comment:

/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

So the developer(s) actually think "volatile" is unnecessary, instead of the
"memory" clobber.

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Or, it is yours then.
Does it handle all of:
#ifdef __SIZEOF_INT128__
typedef unsigned __int128 U;
typedef signed __int128 S;
#else
typedef unsigned long long U;
typedef signed long long S;
#endif
void bar (void);
int f0 (U x, U y) { return x == y; }
int f1 (U x, U y) { return x != y; }
int f2 (U x, U y) { return x > y; }
int f3 (U x, U y) { return x >= y; }
int f4 (U x, U y) { return x < y; }
int f5 (U x, U y) { return x <= y; }
int f6 (S x, S y) { return x == y; }
int f7 (S x, S y) { return x != y; }
int f8 (S x, S y) { return x > y; }
int f9 (S x, S y) { return x >= y; }
int f10 (S x, S y) { return x < y; }
int f11 (S x, S y) { return x <= y; }
void f12 (U x, U y) { if (x == y) bar (); }
void f13 (U x, U y) { if (x != y) bar (); }
void f14 (U x, U y) { if (x > y) bar (); }
void f15 (U x, U y) { if (x >= y) bar (); }
void f16 (U x, U y) { if (x < y) bar (); }
void f17 (U x, U y) { if (x <= y) bar (); }
void f18 (S x, S y) { if (x == y) bar (); }
void f19 (S x, S y) { if (x != y) bar (); }
void f20 (S x, S y) { if (x > y) bar (); }
void f21 (S x, S y) { if (x >= y) bar (); }
void f22 (S x, S y) { if (x < y) bar (); }
void f23 (S x, S y) { if (x <= y) bar (); }

?  For == and != we already generate good code, better than LLVM or ICC, but
for the rest we don't.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
So maybe somebody should submit the patch to the mailing lists.

[Bug c++/82600] [8 Regression] Address of local variable returned [-Werror=return-local-addr] when building mozilla-central

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #7 from Jonathan Wakely  ---
(In reply to Andi from comment #0)
> Building firefox with gcc8 trunk i get this error:

This is a warning, not an error. 

If you use -Werror to cause compilation to fail that's your choice, but it's
still just a warning as far as we're concerned.

If you can't build because you choose to use -Werror then don't use -Werror.

[Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-18
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
At some point I had those "removed" symbols unnamed but Solaris ld didn't like
that.

I'm intentionally not rewriting the symbol table but replacing removed entries
with stubs to not need to touch relocation section data.

Any suggestion for a better "stub" for globals?

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #5 from Bernd Edlinger  ---
(In reply to Xi Ruoyao from comment #3)
> I'm still not convinced this is a bug.  For example, all kernel code
> uses `asm volatile ("" ::: "memory")` as barrier to stop GCC to reorder code
> through it, not `asm volatile ("" :::)`.  So the developers have been aware
> a "asm volatile" does NOT mean a barrier. If we change this behaviour and
> stop reordering through all "asm volatile"s, the generated code could be
> slower.

Yes, spin locks need to have a "memory" clobber.
I agree it will only work by chance without.

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Xi Ruoyao from comment #3)
> I'm still not convinced this is a bug.  For example, all kernel code
> uses `asm volatile ("" ::: "memory")` as barrier to stop GCC to reorder code
> through it, not `asm volatile ("" :::)`.  So the developers have been aware
> a "asm volatile" does NOT mean a barrier. If we change this behaviour and
> stop reordering through all "asm volatile"s, the generated code could be
> slower.

The bug in IRA is that it would move volatile asm statements to wherever
else it felt like, including for example over another volatile asm.  That
is the bug, which my patch fixes.  Making volatile asm a "barrier" (what
does that even _mean_?!) is a bad idea, I certainly agree.

[Bug tree-optimization/82603] [8 Regression] ICE in ifcvt_local_dce w/ -O2 -ftree-loop-vectorize

[rguenth at gcc dot gnu.org]

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

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  ---
Mine.

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Oct 18 17:54:18 2017
New Revision: 253865

URL: https://gcc.gnu.org/viewcvs?rev=253865=gcc=rev
Log:
2017-10-18  Thomas Koenig  

PR libfortran/82233
* gfortran.dg/execute_command_line_3.f90:  Remove unneeded output.
Move test with wait=.false. before the last test.


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

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
(In reply to Christophe Lyon from comment #14)

> Removing the last
>call execute_command_line(command , wait=.false., exitstat=i)
> or moving it before
>call execute_command_line(command ,   exitstat=i, cmdstat=j)
> seems to workaround the issue for me.

I have done the latter in the commit just now. Hopefully, this
will the reduce the amount of noise in your test log.

[Bug c++/82609] New: missing -Warrray-bounds on an argument in parentheses

[msebor at gcc dot gnu.org]

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

Bug ID: 82609
   Summary: missing -Warrray-bounds on an argument in parentheses
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing my C/C++ patch for pr82588 I noticed the following rather bizarre
bug where a -Warray-bound warning for an out-of-bounds index is suppressed by
enclosing the invalid array reference in parentheses.

$ cat a.c && gcc -O2 -S -Wall -Warray-bounds -Wextra -xc++ a.c
extern char a[2];
extern char b[2];

int f (void)
{
  return a[-1];   // -Warray-bounds (good)
}

int g (void)
{
  return (b[-1]);   // missing -Warray-bounds in C++ only
}


a.c: In function ‘int f()’:
a.c:6:14: warning: array subscript is below array bounds [-Warray-bounds]
   return a[-1];   // -Warray-bounds (good)
  ^

[Bug tree-optimization/82608] New: missing -Warray-bounds on an out-of-bounds VLA index

[msebor at gcc dot gnu.org]

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

Bug ID: 82608
   Summary: missing -Warray-bounds on an out-of-bounds VLA index
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't diagnose out-of-bounds indices into VLAs even in cases where it
could.  For instance, in the program below the upper bound of the VLA is at
most 32 while the index is greater.  This information is available in the VRP
pass and so it should be possible to detect this bug.

$ cat a.c && gcc -O2 -S -Wall -Warray-bounds -Wextra a.c
void sink (void*);

int f (unsigned n)
{
  if (n < 1 || n > 32)
n = 32;

  char vla[n];

  sink (vla);

  return vla[97];   // missing -Warray-bounds
}

[Bug fortran/82605] ICE in insert_parameter_exprs, at fortran/decl.c:3154

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug fortran/82606] ICE in gfc_extract_int, at fortran/expr.c:641

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-18
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Created attachment 42393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42393=edit
Prototype patch

Attached patch generates:

foobar:
cmpq%rdx, %rdi
sbbq%rcx, %rsi
setb%al
ret

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #6)

> i.e. for the flags we first clear %eax and then setX %al, but for f2
> cmpq%rdi, %rdx
> sbbq%rsi, %rcx
> setb%al
> movzbl  %al, %eax
> Seems this is done in
> ;; Convert setcc + movzbl to xor + setcc if operands don't overlap.
> peephole2s, do we need a peephole for this as well, or some more general
> peephole2 or other means of optimizing this?
No, this would break carry flag propagation from cmp to sbb.

[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-18
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #3 from Xi Ruoyao  ---
I'm still not convinced this is a bug.  For example, all kernel code
uses `asm volatile ("" ::: "memory")` as barrier to stop GCC to reorder code
through it, not `asm volatile ("" :::)`.  So the developers have been aware
a "asm volatile" does NOT mean a barrier. If we change this behaviour and
stop reordering through all "asm volatile"s, the generated code could be
slower.

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[david at westcontrol dot com]

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

--- Comment #7 from David Brown  ---
(In reply to Xi Ruoyao from comment #3)
There is no intention to make "asm volatile" a barrier, as you get with a
memory clobber.  The intention is to stop it moving past other volatile code
(such as other asm volatiles, and volatile memory accesses).  An "asm volatile"
statement should still be moveable across other "normal" code.

(In reply to Xi Ruoyao from comment #4)
As for the comment in the kernel code, the gcc documentation says that an "asm"
statement with no output is automatically considered as though it were "asm
volatile".  So it should not be necessary to write "volatile" in the memory
barrier here, as the compiler should treat it that way anyway.  If there is a
compiler bug there, it should be fixed - or the documentation could be changed.
 There is certainly no harm in having the "volatile" explicit in the barrier()
definition.

[Bug tree-optimization/82603] [7/8 Regression] ICE in ifcvt_local_dce w/ -O2 -ftree-loop-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.3
Summary|[8 Regression] ICE in   |[7/8 Regression] ICE in
   |ifcvt_local_dce w/ -O2  |ifcvt_local_dce w/ -O2
   |-ftree-loop-vectorize   |-ftree-loop-vectorize

--- Comment #3 from Richard Biener  ---
The rev. was also backported.

[Bug fortran/82605] New: ICE in insert_parameter_exprs, at fortran/decl.c:3154

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

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

Bug ID: 82605
   Summary: ICE in insert_parameter_exprs, at fortran/decl.c:3154
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a missing attribute allocatable or pointer :


$ cat z1.f90
program p
   type t(a, b)
  integer, kind :: a
  integer, len :: b
  real(a) :: r(b)
   end type
   type(t(8, :)) :: x
   real(x%a) :: y
end


$ gfortran-8-20171015 -c z1.f90
z1.f90:9:0:

 end

internal compiler error: Segmentation fault
0xb5a08f crash_signal
../../gcc/toplev.c:326
0x677a7c insert_parameter_exprs
../../gcc/fortran/decl.c:3154
0x693c49 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
../../gcc/fortran/expr.c:4636
0x73c8d2 structure_alloc_comps
../../gcc/fortran/trans-array.c:9041
0x73df30 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
../../gcc/fortran/trans-array.c:9301
0x751a7f gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4300
0x7540c3 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6525
0x6e6580 translate_all_program_units
../../gcc/fortran/parse.c:6088
0x6e6580 gfc_parse_file()
../../gcc/fortran/parse.c:6291
0x72a6bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82606] New: ICE in gfc_extract_int, at fortran/expr.c:641

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

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

Bug ID: 82606
   Summary: ICE in gfc_extract_int, at fortran/expr.c:641
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With reversed declaration order :


$ cat z1.f90
program p
   type t(a, b)
  integer, len :: b
  integer, kind :: a
  real(a) :: r(b)
   end type
   type(t(8, :)), allocatable :: x
   real(x%a) :: y
end



$ gfortran-8-20171015 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb5a08f crash_signal
../../gcc/toplev.c:326
0x68e96d gfc_extract_int(gfc_expr*, int*, int)
../../gcc/fortran/expr.c:641
0x67980d gfc_match_kind_spec(gfc_typespec*, bool)
../../gcc/fortran/decl.c:2754
0x67faa2 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:4053
0x68115c gfc_match_data_decl()
../../gcc/fortran/decl.c:5605
0x6dbac9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6df17e match_word
../../gcc/fortran/parse.c:376
0x6df17e decode_statement
../../gcc/fortran/parse.c:376
0x6e0fb4 next_free
../../gcc/fortran/parse.c:1225
0x6e0fb4 next_statement
../../gcc/fortran/parse.c:1457
0x6e289c parse_spec
../../gcc/fortran/parse.c:3831
0x6e4d93 parse_progunit
../../gcc/fortran/parse.c:5634
0x6e6354 gfc_parse_file()
../../gcc/fortran/parse.c:6174
0x72a6bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug middle-end/82556] [7/8 Regression] internal compiler error in curr_insn_transform, at lra-constraints.c:4307

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Oct 18 16:47:38 2017
New Revision: 253863

URL: https://gcc.gnu.org/viewcvs?rev=253863=gcc=rev
Log:
2017-10-18  Vladimir Makarov  

PR middle-end/82556
* lra-constraints.c (curr_insn_transform): Use non-input operand
instead of output one for matched reload.

2017-10-18  Vladimir Makarov  

PR middle-end/82556
* gcc.target/i386/pr82556.c: New.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr82556.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/lra-constraints.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
Yes, and moreover foo() could access non-volatile memory.
And only a memory clobber can prevent the compiler from
using cached values.

[Bug fortran/82606] ICE in gfc_extract_int, at fortran/expr.c:641

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

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

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

BTW, with an invalid modification (--> fortran/decl.c:3244) :


$ cat z4.f90
program p
   type t(a, b, *)
  integer, kind :: a
  integer, len :: b
  real(a) :: r(b)
   end type
   type(t(8, 3)) :: x
   real(x%a) :: y
end


$ gfortran-8-20171015 -c z4.f90
f951: internal compiler error: Segmentation fault
0xb5a08f crash_signal
../../gcc/toplev.c:326
0x679fa3 gfc_get_pdt_instance(gfc_actual_arglist*, gfc_symbol**,
gfc_actual_arglist**)
../../gcc/fortran/decl.c:3244
0x680221 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3787
0x68115c gfc_match_data_decl()
../../gcc/fortran/decl.c:5605
0x6dbac9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6df17e match_word
../../gcc/fortran/parse.c:376
0x6df17e decode_statement
../../gcc/fortran/parse.c:376
0x6e0fb4 next_free
../../gcc/fortran/parse.c:1225
0x6e0fb4 next_statement
../../gcc/fortran/parse.c:1457
0x6e289c parse_spec
../../gcc/fortran/parse.c:3831
0x6e4d93 parse_progunit
../../gcc/fortran/parse.c:5634
0x6e6354 gfc_parse_file()
../../gcc/fortran/parse.c:6174
0x72a6bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug go/82607] New: SPARC Linux: go frontend runs infinitely on 5.4.0, 6.4.0 and 7.2.0

[i at jsteward dot moe]

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

Bug ID: 82607
   Summary: SPARC Linux: go frontend runs infinitely on 5.4.0,
6.4.0 and 7.2.0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: i at jsteward dot moe
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 42396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42396=edit
strace of `go-7 env`

The command go-{5,6,7} (for version 5.4.0, 6.4.0, 7.2.0) all run infinitely
even without any arguments passed (i.e. simply calling `go-7`) on sparc on
linux, and utilizes entire processor thread to 100%. The strace is attached.

I'm using Gentoo with Linux kernel 4.9.49 (Linux sparc 4.9.49-gentoo-r1 #2 SMP
Sat Oct 7 04:48:20 CST 2017 sparc64 sun4v UltraSparc T2 (Niagara2) GNU/Linux).
The userland is 32 bit if that matters. Below is `gccgo -v`.

$ gccgo -v
Using built-in specs.
COLLECT_GCC=/usr/sparc-unknown-linux-gnu/gcc-bin/7.2.0/gccgo
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc-unknown-linux-gnu/7.2.0/lto-wrapper
Target: sparc-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure
--host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu --prefix=/usr
--bindir=/usr/sparc-unknown-linux-gnu/gcc-bin/7.2.0
--includedir=/usr/lib/gcc/sparc-unknown-linux-gnu/7.2.0/include
--datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/7.2.0
--mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/7.2.0/man
--infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/7.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/sparc-unknown-linux-gnu/7.2.0/include/g++-v7
--with-python-dir=/share/gcc-data/sparc-unknown-linux-gnu/7.2.0/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 7.2.0 p1.1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point
--enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap
--disable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify
--disable-libvtv --enable-lto --without-isl --enable-libsanitizer
--disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (Gentoo 7.2.0 p1.1)

[Bug middle-end/82556] [7/8 Regression] internal compiler error in curr_insn_transform, at lra-constraints.c:4307

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Oct 18 16:44:27 2017
New Revision: 253862

URL: https://gcc.gnu.org/viewcvs?rev=253862=gcc=rev
Log:
2017-10-18  Vladimir Makarov  

PR middle-end/82556
* lra-constraints.c (curr_insn_transform): Use non-input operand
instead of output one for matched reload.

2017-10-18  Vladimir Makarov  

PR middle-end/82556
* gcc.target/i386/pr82556.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr82556.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
(In reply to Bernd Edlinger from comment #10)
> Yes, and moreover foo() could access non-volatile memory.
> And only a memory clobber can prevent the compiler from
> using cached values.

But you *want* the compiler to use cached values if it can.

It is valid for the compiler to move all of foo (or part of it) to
outside the asm's, if the compiler can see the body of foo, e.g.
with LTO or if it is defined in this translation unit.  That's what
makes this code not so super.  There should _not_ be a memory clobber
in these asm statements.  Memory clobbers do not prevent using cached
values, btw.; not in the general case, anyway.  A memory clobber says
"this asm may write to some memory, and I'm not saying what".  It does
not force things to live in memory, and it does do nothing to things
in registers.

[Bug c++/82235] Copy ctor is not found for copying array of an object when it's marked explicit

[mukesh.kapoor at oracle dot com]

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

Mukesh Kapoor  changed:

   What|Removed |Added

 CC||mukesh.kapoor at oracle dot com

--- Comment #1 from Mukesh Kapoor  ---
The problem occurs only when initializing arrays.
I am working on this.

[Bug tree-optimization/82591] [8 Regression] [graphite] Compile-time hog w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed by limiting on the GCC side.  AST generation is still oddly slow.

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

[clyon at gcc dot gnu.org]

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

--- Comment #14 from Christophe Lyon  ---
I think I understand the problem better now, after a few experiments, and a
discussion with proot's author.

The testcase finishes with a call to execute_command_line with wait=.false, so
the main process may complete before the child (execute_command_line) does.

In such a case, proot returns the exit code of the last living process, the
child in our case, so 127 (command not found). And sometimes it can return 0,
depending on the process scheduling on the host.

Forcing qemu to dump traces seems to hide the problem, probably because it does
change the process schedule.

FWIW, I can live with this by flagging this test as 'random' in my
GCC-regression testing.

Removing the last
   call execute_command_line(command , wait=.false., exitstat=i)
or moving it before
   call execute_command_line(command ,   exitstat=i, cmdstat=j)
seems to workaround the issue for me.