[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #15 from Jerry DeLisle  ---
Closing, Fixed

[Bug fortran/77612] New: ICE on invalid character len in contained procedure

[spam.brian.taylor at gmail dot com]

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

Bug ID: 77612
   Summary: ICE on invalid character len in contained procedure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spam.brian.taylor at gmail dot com
  Target Milestone: ---

The following code causes gfortran 6.2.0 to ICE:

user@host $ cat bad_len.f90 
program bad_len
  implicit none

contains

  subroutine sub()
character(len = make_gfortran_ICE) :: line
  end subroutine

end program

user@host $ gfortran bad_len.f90
bad_len.f90:6:0:

   subroutine sub()

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064

bad_len.f90:6:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.

user@host $ gfortran --version
GNU Fortran (Homebrew gcc 6.2.0 --without-multilib) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If "implicit none" is commented out, gfortran stops with a reasonable error
message:

bad_len.f90:7:19:

 character(len = make_gfortran_ICE) :: line
   1
Error: Variable 'make_gfortran_ice' cannot appear in the expression at (1)

[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||4.9.3, 5.3.0, 6.2.0, 7.0

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00988.html

[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-16
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Created attachment 39627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39627=edit
Lightly tested patch.

The attached patch extends __builtin_object_size to handle non-constant offsets
in POINTER_PLUS expressions.  It also adds handling of ranges although to
benefit from those the VRP pass needs to run before the object size pass.  (It
doesn't handle the test case in comment #0 because of the volatile qualifier.)

[Bug inline-asm/77607] Aarch64 LDP operand rejected incorrectly

[hyc at symas dot com]

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

hyc at symas dot com changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from hyc at symas dot com ---
(In reply to Andrew Pinski from comment #1)
> You want %qN.
> Some something like:
> {uint8x16_t _a, _b, _c, _d;
> __asm__("ldp %q0, %q1, %4\n\t"
> "ldp %q2, %q3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d)
> : "Ump"(state.k) :);
> 
> Oh by the way you really not need this.  GCC should be able to use ldp in
> these cases if wanted by the target; though ldp for q registers is not yet
> implemented as most processors don't want them right now.

Thanks.
> 
> Also your inline-asm is incorrect as you modify state.k.

Oh? That's not my intention at this point. Just want to load from it.

> So really it should be something like:
> {uint8x16_t _a, _b, _c, _d;
> __asm__("ldp %q0, %q1, %4\n\t"
> "ldp %q2, %q3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d)
> , "+Ump"(state.k) :);

[Bug lto/66835] C++ openMP test failed after switching to C++14

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
I think this has been fixed, can you try again?

[Bug fortran/69963] ICE out of memory on displaced implicit character

[lkrupp at gcc dot gnu.org]

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

lkrupp at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lkrupp at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from lkrupp at gcc dot gnu.org ---
Fixed in revision 240168.

The problem: 

In this example, 

subroutine s
  real x
  implicit character (a)

  a1 = 'z'
end subroutine s

the implicit statement is processed, the default typespec corresponding to the
letter 'a' has its component charlen pointer set.  When the implicit statement
is then rejected as being out of order, all of the charlen structures it
created are freed, default_type['a']->u.cl is left dangling, and bad things
happen when 'a1' is parsed.

This patch clears any default typespecs pointing to charlen structures that are
about to be freed.

[Bug fortran/69963] ICE out of memory on displaced implicit character

[lkrupp at gcc dot gnu.org]

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

--- Comment #3 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Thu Sep 15 23:54:40 2016
New Revision: 240168

URL: https://gcc.gnu.org/viewcvs?rev=240168=gcc=rev
Log:
2016-09-15  Louis Krupp  
PR fortran/69963
* parse.c (reject_statement): Clear charlen pointers in implicit
character typespecs before those charlen structures are freed.

2016-09-15  Louis Krupp  

PR fortran/69963
* gfortran.dg/misplaced_implicit_character.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77610] New: [sh] memcpy is wrongly inlined even for large copies

[bugdal at aerifal dot cx]

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

Bug ID: 77610
   Summary: [sh] memcpy is wrongly inlined even for large copies
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

The logic in sh-mem.cc does not suppress inlining of memcpy when the size is
constant but large. This suppresses use of a library memcpy which may be much
faster than the inline version once the threshold of function call overhead is
passed.

At present the reason this is problematic on J2 is that the cache is direct
mapped, so that when source and dest are aligned mod large powers of two
(typical when page-aligned), each write to dest evicts src from the cache,
making memcpy 4-5x slower than it should be. A library memcpy can handle this
by copying cache line size or larger at a time, but the inline memcpy can't.

Even if we have a set-associative cache on J-core in the future, I plan to have
Linux provide a vdso memcpy function that can use DMA transfers, which are
several times faster than what you can achieve with any cpu-driven memcpy and
which free up the cpu for other work. However it's impossible to for such a
function to get called as long as gcc is inlining it.

Using -fno-builtin-memcpy is not desirable because we certainly want inline
memcpy for small transfers that would be dominated by function call time (or
where the actual memory accesses can be optimized out entirely and the copy
performed in registers, like memcpy for type punning), just not for large
copies.

[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE

[roland at gnu dot org]

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

--- Comment #1 from roland at gnu dot org ---
Created attachment 39626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39626=edit
trunk fix

This is the fix that shows the behavior difference reported above.

[Bug other/77609] New: __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE

[roland at gnu dot org]

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

Bug ID: 77609
   Summary: __attribute__((section(".note.foo"))) forces
SHT_PROGBITS though the assembler would use SHT_NOTE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at gnu dot org
  Target Milestone: ---

When __attribute__((section("name"))) is used, GCC insists on setting the
section type explicitly.  For various special section names, the assembler
would use a special type, but GCC doesn't know about those rules and forces
SHT_PROGBITS instead.  An example is section names starting with ".note",
which the assembler gives type SHT_NOTE but GCC fails to.  This makes it
impossible (without heinous shenanigans) to use an initialized C variable
declaration to emit an (allocated) ELF note.

GCC already has special cases for ".init_array", ".fini_array", and
".preinit_array", but that is a small subset of the full set of names (and
name patterns) for which the assembler uses a special type.  The existing
special cases already rely on the assembler to choose the actual type.  The
default type of SHT_PROGBITS that GCC forces on all others is already the
assembler's default for sections whose name is not special.  So just
letting the assembler choose in all cases does the right thing now and will
do so in the future if any new types or special name patterns are added to
the assembler.

I'll attach a patch that does this.

Test case:

$ cat note.c
#define VENDOR "foobar"

struct mynote {
struct Elf32_Nhdr {
unsigned int n_namesz, n_descsz, n_type;
} hdr;
char name[sizeof(VENDOR)];
_Alignas(4) struct mynote_payload {
short int x;
} payload;
};

__attribute__((used, section(".note.foo")))
static const struct mynote foonote = {
.hdr = {
.n_namesz = sizeof(VENDOR),
.n_descsz = sizeof(struct mynote_payload),
.n_type = 17,
},
.name = VENDOR,
.payload = {
.x = 23,
},
};
$ ./gcc/xgcc -Bgcc/ -c -save-temps ../../gcc/note.c
$ cat note.s
.file   "note.c"
==> .section.note.foo,"a",@progbits
.align 16
.type   foonote, @object
.size   foonote, 24
foonote:
.long   7
.long   2
.long   17
.string "foobar"
.zero   1
.value  23
.zero   2
.ident  "GCC: (GNU) 7.0.0 20160915 (experimental)"
.section.note.GNU-stack,"",@progbits
$ readelf -WSn note.o
There are 10 section headers, starting at offset 0xd8:

Section Headers:
  [Nr] Name  TypeAddress  OffSize  
ES Flg Lk Inf Al
  [ 0]   NULL 00 00
00  0   0  0
  [ 1] .text PROGBITS 40 00
00  AX  0   0  1
  [ 2] .data PROGBITS 40 00
00  WA  0   0  1
  [ 3] .bss  NOBITS   40 00
00  WA  0   0  1
==>   [ 4] .note.foo PROGBITS 40 18
00   A  0   0 16
  [ 5] .comment  PROGBITS 58 2a
01  MS  0   0  1
  [ 6] .note.GNU-stack   PROGBITS 82 00
00  0   0  1
  [ 7] .shstrtab STRTAB   82 4f
00  0   0  1
  [ 8] .symtab   SYMTAB   000358 d8
18  9   9  8
  [ 9] .strtab   STRTAB   000430 10
00  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x
(unknown)
  O (extra OS processing required) o (OS specific), p (processor
specific)
$

After my fix:

$ ./gcc/xgcc -Bgcc/ -c -save-temps ../../gcc/note.c
$ cat note.s
.file   "note.c"
==> .section.note.foo,"a"
.align 16
.type   foonote, @object
.size   foonote, 24
foonote:
.long   7
.long   2
.long   17
    .string "foobar"
 

[Bug inline-asm/77607] Aarch64 LDP operand rejected incorrectly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You want %qN.
Some something like:
{uint8x16_t _a, _b, _c, _d;
__asm__("ldp %q0, %q1, %4\n\t"
"ldp %q2, %q3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d) :
"Ump"(state.k) :);

Oh by the way you really not need this.  GCC should be able to use ldp in these
cases if wanted by the target; though ldp for q registers is not yet
implemented as most processors don't want them right now.

Also your inline-asm is incorrect as you modify state.k.


So really it should be something like:
{uint8x16_t _a, _b, _c, _d;
__asm__("ldp %q0, %q1, %4\n\t"
"ldp %q2, %q3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d) ,
"+Ump"(state.k) :);

[Bug bootstrap/11660] libffi only builds when java is selected as language

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |WONTFIX

--- Comment #12 from Ian Lance Taylor  ---
I don't think there is anything to fix here, so I'm going to close this.  GCC
is not the master source for libffi.

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

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

--- Comment #15 from PeteVine  ---
@amker Thanks!

[Bug middle-end/70090] add non-constant variant of __builtin_object_size for _FORTIFY_SOURCE and -fsanitize=object-size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  I'm changing the component from C to middle-end since this
limitation affects C++ as well and the solution involves changing the middle
end.

__builtin_object_size suffers from other limitations as well.  Not all of those
require introducing a runtime form of the intrinsic (though the most general
cases do).  An example where the built-in gives up too easily is bug 77608.

[Bug middle-end/77608] New: missing protection on trivially detectable runtime buffer overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 77608
   Summary: missing protection on trivially detectable runtime
buffer overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The __builtin_object_size function is documented to return the size of the
smallest or largest, respectively, object referenced by its first argument,
ptr,  depending on its second argument.  When the size of the object ptr points
to is known at compile time but ptr is the result of pointer arithmetic such
the addition expression where the integer operand is not known,
__builtin_object_size fails instead of returning the (maximum or minimum) size
of the object.  This failure in turn disables the protection even in otherwise
obvious cases of buffer overflow.

For example, the call to memcpy in the following program clearly overflows the
destination buffer regardless of the value of i, yet because of the
__builtin_object_size failure, GCC fails to instrument the call and the
overflow is allowed to go undetected.

$ cat x.c && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -O2
-Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout x.c && ./a.out
#define bos(dest) __builtin_object_size (dest, 0)
#define memcpy(dest, src, n)\
  __builtin___memcpy_chk (dest, src, n, bos (dest))

#define P(x) \
__builtin_printf ("%2zd %2zd %2zd %2zd\n", \
  __builtin_object_size (x, 0), \
  __builtin_object_size (x, 1), \
  __builtin_object_size (x, 2), \
  __builtin_object_size (x, 3)) \

volatile unsigned i;

int main (void)
{
  {
char d [3];

P (d + i);

memcpy (d + i, "abcdef", 5);

__builtin_printf ("%.0s", d);
  }
}

;; Function main (main, funcdef_no=0, decl_uid=1792, cgraph_uid=0,
symbol_order=1) (executed once)

main ()
{
  char d[3];
  unsigned int i.0_1;
  sizetype _2;
  void * _3;

  :
  __builtin_printf ("%2zd %2zd %2zd %2zd\n", 18446744073709551615,
18446744073709551615, 0, 0);
  i.0_1 ={v} i;
  _2 = (sizetype) i.0_1;
  _3 =  + _2;
  __builtin_memcpy (_3, "abcdef", 5);
  __builtin_printf ("%.0s", );
  d ={v} {CLOBBER};
  return 0;

}


-1 -1  0  0

[Bug middle-end/77606] abort in __memcpy_chk on an in-bounds copy with type-2 builtin_object_size

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The following test case reduces the problem to __builtin_object_size failing
for pointers to objects that are the result of a __builtin_malloc call (or VLA
definition) with an argument that's a runtime conditional expression.

$ cat z.c && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -O2
-Wall -Wextra -Wpedantic z.c && ./a.out 
#define P(x) \
__builtin_printf ("%2zd %2zd %2zd %2zd\n", \
  __builtin_object_size (x, 0), \
  __builtin_object_size (x, 1), \
  __builtin_object_size (x, 2), \
  __builtin_object_size (x, 3)) \

int main (int argc, char *argv[])
{
  (void)argv;

  {
char b [1 < argc ? 13 : 17 ];
P (b);
  }

  {
char a [13];
char b [17];
char *p = 1 < argc ? a : b;
P (p);
  }

  {
char *p = 1 < argc ? __builtin_malloc (13) : __builtin_malloc (17);
P (p);
  }

  {
char *p = __builtin_malloc (1 < argc ? 13 : 17);
P (p);
  }
}
-1 -1  0  0
17 17 13 13
17 17 13 13
-1 -1  0  0

[Bug inline-asm/77607] New: Aarch64 LDP operand rejected incorrectly

[hyc at symas dot com]

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

Bug ID: 77607
   Summary: Aarch64 LDP operand rejected incorrectly
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hyc at symas dot com
  Target Milestone: ---

This sequence:

{uint8x16_t _a, _b, _c, _d;
__asm__("ldp %0, %1, %4\n\t"
"ldp %2, %3, %4, #32\n\t" : "=w"(_a), "=w"(_b), "=w"(_c), "=w"(_d) :
"Ump"(state.k) :);

Generates this code:

ldp v1, v4, [x0]
ldp v0, v2, [x0], #32

And gets this error:

/tmp/ccQYB8nY.s:172: Error: operand 1 should be a floating-point register --
`ldp v1,v4,[x0]'
/tmp/ccQYB8nY.s:173: Error: operand 1 should be a floating-point register --
`ldp v0,v2,[x0],#32'

According to the docs, "w" is the correct constraint character to use for FP or
SIMD register. So either gas is rejecting this incorrectly, or gcc is
generating the wrong register name for this constraint.

[Bug fortran/77602] ICE with cyclic length declaration: Killed (program f951)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
"cyclic" is the wrong word.

subroutine s(x)! line 1
   implicit character (a-z)! line 2
   character(len=len(y)+1) :: x! line 3
   character(len=len(x)+1) :: y! line 4
end! line 5


line 2 causes the first reference to 'y' to 
give 'y' an implicit type of CHARACTER(1), so
'x' in line 3 has len=2.  'y' may appear in
a subsequent declaration where that declaration
confirms the type.  Hmmm, this took awhile to
find (F2003, p126):

  A variable in a specification expression shall have its type
  and type parameters, if any, specified by a previous declaration
  in the same scoping unit, by the implicit typing rules in effect
  for the scoping unit, or by host or use association. If a variable
  in a specification expression is typed by the implicit typing
  rules, its appearance in any subsequent type declaration statement
  shall confirm the implied type and type parameters.

This is not a numbered constraint.  The requirement is on the
programmer to get it right.  So, yes, the code is invalid, and
gfortran can do anything it wants including ICE.

[Bug middle-end/77606] New: abort in __memcpy_chk on an in-bounds copy with type-2 builtin_object_size

[msebor at gcc dot gnu.org]

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

Bug ID: 77606
   Summary: abort in __memcpy_chk on an in-bounds copy with type-2
builtin_object_size
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The Object Size Checking Built-in Functions page of the manual shows an example
of using the __builtin_object_size intrinsic to implement a checking memcpy. 
The example makes use of "type-0" __builtin_object_size documented to return
the size of largest "whole variables."  This is the most permissive mode that
allows the checked functions to overflow the destination in cases where there
are a set of destination buffers known at compile time, some big enough and
some smaller than the number of bytes to write, and the smaller one ends up
being used as the destination at runtime.

The second argument to __builtin_object_size is documented to make it possible
to determine the size of the smallest object instead:

If there are multiple objects ptr can point to and all of them are known at
compile time, the returned number is the maximum of remaining byte counts in
those objects if type & 2 is 0 and minimum if nonzero. 

The test case below changes the example to use __builtin_object_size in this
less permissive mode expected to return the size of the smaller of the two
objects it may refer to at runtime.  The example shows that in this mode, the
intrinsic fails to return the size of the smaller object as documented (in this
case 40) and instead returns 0, causing the memcpy function to abort, even
though no overflow would happen.

Note that this problem doesn't seem to affect destinations that point to one of
two or more statically allocated objects, or when the destination is a VLA
defined as 'char d [1 < argc ? 40 : 80]', but only when the destination points
to a dynamically allocated object with a runtime-size.

$ cat x.c && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -O2
-Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout x.c && ./a.out 
#define bos(dest) __builtin_object_size (dest, 2)
#define memcpy(dest, src, n) \
  __builtin___memcpy_chk (dest, src, n, bos (dest))

int main (int argc, char *argv[])
{
  char *d = __builtin_malloc (1 < argc ? 40 : 80);

  __builtin_printf ("size of d = %zu\n", bos (d));

  memcpy (d, "abcde", 5);

  __builtin_printf ("%s\n", d);
}
x.c: In function ‘main’:
x.c:5:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
 int main (int argc, char *argv[])
   ^~~~

;; Function main (main, funcdef_no=0, decl_uid=1792, cgraph_uid=0,
symbol_order=0) (executed once)

Removing basic block 3
main (int argc, char * * argv)
{
  char * d;
  long unsigned int iftmp.0_3;

  :
  if (argc_4(D) > 1)
goto ;
  else
goto ;

  :

  :
  # iftmp.0_3 = PHI <40(2), 80(3)>
  d_7 = __builtin_malloc (iftmp.0_3);
  __builtin_printf ("size of d = %zu\n", 0);
  __builtin___memcpy_chk (d_7, "abcde", 5, 0);
  __builtin_puts (d_7);
  return 0;

}


x.c:3:3: warning: call to __builtin___memcpy_chk will always overflow
destination buffer
   __builtin___memcpy_chk (dest, src, n, bos (dest))
   ^
x.c:11:3: note: in expansion of macro ‘memcpy’
   memcpy (d, "abcde", 5);
   ^~
size of d = 0
*** buffer overflow detected ***: ./a.out terminated

[Bug tree-optimization/77605] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 77605
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to affect at least all versions 4.6.x and later. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160915 (experimental) [trunk revision 240161] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$ 





int a, b, c[2][8];

int main ()
{
  for (a = 0; a < 8; a++)
for (b = 0; b < 2; b++)
  c[b][a] = c[b][b + 6] ^ 1;

  if (c[0][7] != 0) 
__builtin_abort ();

  return 0; 
}

[Bug fortran/77604] ICE in get_frame_type, at tree-nested.c:208

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---


A "scalar" version works :


$ cat y1.f90
program p
   call s
contains
   function f(x, y) result(z)
  character(*), intent(in) :: x, y
  character(len(x)**len(y)) :: z
  z = x // y
   end
   subroutine g(x)
  character(*), intent(in) :: x
  print *, 'inside g :', len(x), x
   end
   subroutine s
  call g( f('ab', 'xyz') )
   end
end


$ gfortran-7-20160911 y1.f90
$ a.out
 inside g :   8 abxyz


---


Case from comment 0 also works with a simpler operation like "*" :


$ cat z2.f90
program p
   call s
contains
   elemental function f(x, y) result(z)
  character(*), intent(in) :: x, y
  character(len(x)*len(y)) :: z
  z = x // y
   end
   subroutine g(x)
  character(*), intent(in) :: x(:)
  print *, 'inside g :', len(x), size(x), x
   end
   subroutine s
  call g( f(['ab'], ['xyz']) )
   end
end


$ gfortran-7-20160911 z2.f90
$ a.out
 inside g :   6   1 abxyz

$

[Bug fortran/77604] New: ICE in get_frame_type, at tree-nested.c:208

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77604
   Summary: ICE in get_frame_type, at tree-nested.c:208
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This snippet fails with an "**" operation :


$ cat z1.f90
program p
   call s
contains
   elemental function f(x, y) result(z)
  character(*), intent(in) :: x, y
  character(len(x)**len(y)) :: z
  z = x // y
   end
   subroutine g(x)
  character(*), intent(in) :: x(:)
  print *, 'inside g :', len(x), size(x), x
   end
   subroutine s
  call g( f(['ab'], ['xyz']) )
   end
end


$ gfortran-7-20160911 -c z1.f90
z1.f90:1:0:

 program p

internal compiler error: Segmentation fault
0xc2154f crash_signal
../../gcc/toplev.c:336
0xcb88aa get_frame_type
../../gcc/tree-nested.c:208
0xcb88aa get_chain_field
../../gcc/tree-nested.c:359
0xcbadc2 get_chain_field
../../gcc/tree-nested.c:357
0xcbadc2 get_nonlocal_debug_decl
../../gcc/tree-nested.c:834
0xcbb4c8 convert_nonlocal_reference_op
../../gcc/tree-nested.c:909
0xed8162 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11690
0x9a67f0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:203
0x9a6d6c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:586
0x9a6f58 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9a6e12 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9a6f58 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9a6e12 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9a6f58 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xcb74e1 walk_body
../../gcc/tree-nested.c:573
0xcb7538 walk_function
../../gcc/tree-nested.c:584
0xcb7538 walk_all_functions
../../gcc/tree-nested.c:649
0xcbf882 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3187
0x83d546 cgraph_node::analyze()
../../gcc/cgraphunit.c:631
0x840b13 analyze_functions
../../gcc/cgraphunit.c:1086

[Bug fortran/77603] ICE: Segmentation fault (program f951)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Still invalid with -fimplicit-none (or at source level), 
but done in no time (in contrast to pr77602) :


$ time gfortran-7-20160911 -fimplicit-none -c z1.f90
z1.f90:4:29:

   implicit character(len(zfn)) (x)
 1
Error: Symbol 'zfn' is used before it is typed at (1)
z1.f90:5:29:

   implicit character(len(x)+1) (y)
 1
Error: Symbol 'x' is used before it is typed at (1)
z1.f90:6:29:

   implicit character(len(y)-1) (z)
 1
Error: Symbol 'y' is used before it is typed at (1)
z1.f90:8:20:

   character(len(y)-1) :: zfn
1
Error: Symbol 'y' is used before it is typed at (1)
z1.f90:10:32:

   zfn = achar(max(iachar(x(i:i)),iachar(y(i:i
1
Error: Syntax error in argument list at (1)
z1.f90:3:17:

function zfn(x,y)
 1
Error: Symbol 'x' at (1) has no IMPLICIT type
z1.f90:3:19:

function zfn(x,y)
   1
Error: Symbol 'y' at (1) has no IMPLICIT type
z1.f90:3:3:

function zfn(x,y)
   1
Error: Contained function 'zfn' at (1) has no IMPLICIT type

real0m0.013s
user0m0.006s
sys 0m0.005s

[Bug fortran/77603] New: ICE: Segmentation fault (program f951)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77603
   Summary: ICE: Segmentation fault (program f951)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Invalid code with a cyclic length declaration.
Related to pr77602, basically an analogous problem with a somewhat
different behaviour. Generates an ever growing file "m.mod0".
Similar to argument_checking_7.f90 from testsuite, i.e. pr31306.


$ cat z1.f90
module m
contains
   function zfn(x,y)
  implicit character(len(zfn)) (x)
  implicit character(len(x)+1) (y)
  implicit character(len(y)-1) (z)
  intent(in) :: x, y
  character(len(y)-1) :: zfn
  integer :: i = 1
  zfn = achar(max(iachar(x(i:i)),iachar(y(i:i
   end
end


$ time gfortran-7-20160911 -c z1.f90
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

real2m1.084s
user1m41.855s
sys 0m2.465s

[Bug fortran/77602] ICE with cyclic length declaration: Killed (program f951)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Adding -fimplicit-none does not help :


$ time gfortran-7-20160911 -fimplicit-none -c z1.f90
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

real0m31.259s
user0m0.431s
sys 0m3.892s

[Bug fortran/77602] New: ICE with cyclic length declaration: Killed (program f951)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77602
   Summary: ICE with cyclic length declaration: Killed (program
f951)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Invalid code with a cyclic length declaration, similar to pr47915 :


$ cat z1.f90
subroutine s(x)
   implicit character (a-z)
   character(len=len(y)+1) :: x
   character(len=len(x)+1) :: y
end


$ gfortran-7-20160911 -c z1.f90
gfortran: internal compiler error: Killed (program f951)

[Bug fortran/47915] Type declaration: Recursive specification expression not detected.

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #2 from Gerhard Steinmetz  
---
Update :


$ gfortran-7-20160911 -c pr47915.f90
$ gfortran-7-20160911 -g -O0 -Wall -fcheck=all -c pr47915.f90
pr47915.f90:1:0:

   subroutine foo(a, b)

Warning: '.a' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr47915.f90:1:0:

   subroutine foo(a, b)

note: '.a' was declared here


$ gfortran-6 -c pr47915.f90
$ gfortran-6 -g -O0 -Wall -fcheck=all -c pr47915.f90
pr47915.f90:1:0:

   subroutine foo(a, b)

Warning: '.a' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr47915.f90:1:0:

   subroutine foo(a, b)

note: '.a' was declared here


$ gfortran-5 -c pr47915.f90
$ gfortran-5 -g -O0 -Wall -fcheck=all -c pr47915.f90
pr47915.f90:1:0:

   subroutine foo(a, b)
 ^
Warning: '.a' may be used uninitialized in this function
[-Wmaybe-uninitialized]


$ gfortran-4.9 -c pr47915.f90
$ gfortran-4.9 -g -O0 -Wall -fcheck=all -c pr47915.f90
pr47915.f90: In function 'foo':
pr47915.f90:1:0: warning: '.a' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   subroutine foo(a, b)
 ^
$

[Bug c++/77601] error: cannot convert 'is_same<int, Z>' to 'const bool' in initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 Ever confirmed|0   |1

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[amker at gcc dot gnu.org]

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

--- Comment #14 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Sep 15 16:31:35 2016
New Revision: 240166

URL: https://gcc.gnu.org/viewcvs?rev=240166=gcc=rev
Log:
PR tree-optimization/77503
* tree-vect-loop.c (vectorizable_reduction): Record reduction
code for CONST_COND_REDUCTION at analysis stage and use it at
transform stage.
* tree-vectorizer.h (struct _stmt_vec_info): New field.
(STMT_VINFO_VEC_CONST_COND_REDUC_CODE): New macro.
* tree-vect-stmts.c (new_stmt_vec_info): Initialize above new
field.

gcc/testsuite
* gcc.dg/vect/pr77503.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr77503.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug c++/77601] error: cannot convert 'is_same<int, Z>' to 'const bool' in initialization

[lh_mouse at 126 dot com]

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

--- Comment #1 from lh_mouse  ---
Oops, the last line in `main()` should have been

constexpr bool b3 = is_same{};

And as the comment before that line says, it works with g++.

[Bug c++/77601] New: error: cannot convert 'is_same<int, Z>' to 'const bool' in initialization

[lh_mouse at 126 dot com]

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

Bug ID: 77601
   Summary: error: cannot convert 'is_same' to 'const
bool' in initialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

The following code chokes GCC:

template
struct is_same {
constexpr operator bool() const noexcept {
return false;
}
};
template
struct is_same {
constexpr operator bool() const noexcept {
return true;
}
};

template
void foo(Z){
// This works with clang++ but does not with g++.
constexpr bool b1 = is_same{};

// This works with both.
constexpr bool b2 = is_same();
}

int main(){
foo(1);
// This works with both, too.

constexpr bool b3 = is_same();
}

[Bug target/77600] M68K: gcc generates rubbish with -mshort

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
warthog>m68k-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/m68k-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/m68k-linux-gnu/6.1.1/lto-wrapper
Target: m68k-linux-gnu
Configured with: ../gcc-6.1.1-20160427/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/m68k-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=m68k-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=m68k-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-newlib --with-plugin-ld=/usr/bin/m68k-linux-gnu-ld
--with-sysroot=/usr/m68k-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-linker-hash-style=gnu
Thread model: single
gcc version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC)

[Bug target/77599] M68K: __builtin_bswap32() isn't compiled correctly with -mshort

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
warthog>m68k-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/m68k-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/m68k-linux-gnu/6.1.1/lto-wrapper
Target: m68k-linux-gnu
Configured with: ../gcc-6.1.1-20160427/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/m68k-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=m68k-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=m68k-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-newlib --with-plugin-ld=/usr/bin/m68k-linux-gnu-ld
--with-sysroot=/usr/m68k-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-linker-hash-style=gnu
Thread model: single
gcc version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC)

[Bug target/77600] New: M68K: gcc generates rubbish with -mshort

[dhowells at redhat dot com]

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

Bug ID: 77600
   Summary: M68K: gcc generates rubbish with -mshort
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

In certain cases gcc wants to generate the equivalent of:

move.b (%a0,-1),foo

but instead of generating:

moveq #-1.%d0
moveb(%a0,%d0.l)

or similar it generates the bogus sequence:

moveq #0,%d0
not.w %d0

which would be the fast way of generating a 16-bit -1 value rather than a
32-bit value.

Compiling:

void *my_memcpy(void *d, const void *s, long sz)
{
unsigned char *dp = d;
const unsigned char *sp = s;
while (sz--)
*dp++ = *sp++;
return d;
}

with:

m68k-linux-gnu-gcc -m68000 -S /tmp/memcpy.c -o - -O2 -mshort

produces:

my_memcpy:
link.w %fp,#0
move.l %a3,-(%sp)
move.l %a2,-(%sp)
move.l 8(%fp),%a0
move.l 16(%fp),%d0
jeq .L6
move.l %a0,%a2
ext.l %d0  <--- isn't the size a 'long int'?
lea (%a0,%d0.l),%a3
move.l 12(%fp),%a1
moveq #0,%d0   <--- dodgy bit
not.w %d0  <---
.L3:
addq.l #1,%a1
move.b (%a1,%d0.l),(%a2)+  <--- should this be %d0.w as the index?
cmp.l %a2,%a3
jne .L3
.L6:
move.l %a0,%d0
move.l (%sp)+,%a2
move.l (%sp)+,%a3
unlk %fp
rts

Dropping the -mshort, I see:

my_memcpy:
link.w %fp,#0
move.l %a2,-(%sp)
move.l 8(%fp),%a0
move.l 12(%fp),%a1
tst.l 16(%fp)
jeq .L6
move.l %a0,%a2
move.l 16(%fp),%d0
add.l %a1,%d0
.L3:
move.b (%a1)+,(%a2)+
cmp.l %a1,%d0
jne .L3
.L6:
move.l %a0,%d0
move.l (%sp)+,%a2
unlk %fp
rts

which looks correct, though there's a test of sz and then sz is loaded into %d0
in two separate instructions; possibly these two could be combined since move
to data reg sets the condition flags.

I'm using a gcc-6.1.1 cross-compiler built for x86_64, but the problem also
shows up on gcc-5.3.1.  The gcc-6.1.1 compiler is svn rev 237634, dated 
20160621.

[Bug c++/77598] constexpr compilation failure on reference type casting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
Summary|consexpr compilation|constexpr compilation
   |failure on reference type   |failure on reference type
   |casting |casting

--- Comment #1 from Jakub Jelinek  ---
This error has been added for DR1188 resolution.

Slightly reduced testcase:
template 
struct A { static constexpr T a = T (); };
template 
constexpr T A::a;
struct B
{
  int b;
  constexpr int foo () const { return b; }
  constexpr B (const int ) : b(x) {};
};
struct C : public B
{
  constexpr C () : B(50) {};
};
struct D : public C
{
};
struct E
{
  static constexpr const auto  = A::a;
};
constexpr const B  = E::e;
constexpr const int g = f.foo ();

[Bug tree-optimization/77514] [6 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Started with r228471.

[Bug c++/77522] [5/6/7 Regression] ICE on invalid code C++14 code: in tsubst_decl, at cp/pt.c:12447

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE on invalid code C++14   |[5/6/7 Regression] ICE on
   |code: in tsubst_decl, at|invalid code C++14 code: in
   |cp/pt.c:12447   |tsubst_decl, at
   ||cp/pt.c:12447

--- Comment #2 from Jakub Jelinek  ---
Started with r210017.  Before that it has been rejected:
pr77522.C: In function ‘void f(T)’:
pr77522.C:3:18: error: cannot capture ‘f’ by reference
   auto g = [ = f] () {};
  ^
pr77522.C: In instantiation of ‘struct f(T) [with T = int]::’:
pr77522.C:3:25:   required from ‘void f(T) [with T = int]’
pr77522.C:8:7:   required from here
pr77522.C:3:18: error: unable to deduce ‘auto’ from ‘f’
pr77522.C:3:18: error: using invalid field ‘f(T)::::a’

[Bug target/77599] New: M68K: __builtin_bswap32() isn't compiled correctly with -mshort

[dhowells at redhat dot com]

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

Bug ID: 77599
   Summary: M68K: __builtin_bswap32() isn't compiled correctly
with -mshort
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

The following test code:

unsigned long x(unsigned long y)
{
return __builtin_bswap32(y);
}

is miscompiled for m68k when -mshort is specified.  Compiling with

m68k-linux-gnu-gcc -m68000 -S /tmp/3.c -o - -mshort

I see:

x:
link.w %fp,#0
move.l 8(%fp),%d0
ror.w #8,%d0
move.w %d0,%d0
and.l #65535,%d0
unlk %fp
rts

dropping the -mshort I see:

x:
link.w %fp,#0
move.l 8(%fp),%d0
ror.w #8,%d0
swap %d0
ror.w #8,%d0
unlk %fp
rts

I'm using a gcc-6.1.1 cross-compiler built for x86_64, but the problem also
shows up on gcc-5.3.1.  The gcc-6.1.1 compiler is svn rev 237634, dated 
20160621.

[Bug rtl-optimization/71878] ICE in cselib_record_set

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to fail||6.2.1

--- Comment #5 from Thomas Preud'homme  ---
GCC 5 and 6 still affected. Backport to 6 is clean, not to 5. Have just
requested approval for a backport to 6.

[Bug target/77526] [7 Regression] ICE: in verify_dominators, at dominance.c:1039 with -mstringop-strategy=byte_loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39625=edit
gcc7-pr77526.patch

Untested fix.

[Bug target/67904] g++ crashes and asks for bugreport

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Ramana Radhakrishnan  ---
Seems to work for 2 developers as below - if the issue persists with a later
version in the gcc-5 branch, please reopen the bug.

[Bug rtl-optimization/71878] ICE in cselib_record_set

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 CC||ramana at gcc dot gnu.org
  Known to work||7.0
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed on trunk- 

Works on trunk but not on 5.4.x but no idea about 6 branch.

[Bug rtl-optimization/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Ramana Radhakrishnan  ---
Confirmed

[Bug target/77281] [ARM] Wrong code generated for move of constant vector with mix of signed and unsigned zeros

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.3
  Known to fail||6.0, 7.0

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed for GCC 6.3 then.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[tprince at computer dot org]

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

--- Comment #4 from tprince at computer dot org ---
Same failure of f951 after checking alternate svn apps.

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

[albrecht.guendel at web dot de]

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

Albi  changed:

   What|Removed |Added

 CC||albrecht.guendel at web dot de

--- Comment #16 from Albi  ---
Here is a type safe C++ solution:

template union NBitValueUnion
{
static_assert((sizeof(T)*8) > N, "Strange Bitfield Width");
private:
const T Data;
public:
struct
{
const T Value : N;
const T : (sizeof(T)*8-N);
};
NBitValueUnion(const T& _Data): Data(_Data) {}
};
template const NBitValueUnion NBitValue(const
T& _Data)
{ return NBitValueUnion(_Data); }


Usage:
Bitfield.Member = VariableName; //Triggers -Wconversion
Bitfield.Member = NBitValue(VariableName).Value; //Silent.

Unfortnunately it triggers -Waggregate-return (which is a topic for it self
since its a type thats fits in a register, so its an aggregate.. but not in
hardware.)

Any improvements are welcome.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0, 7.0

--- Comment #3 from Ramana Radhakrishnan  ---
Confirmed then

[Bug c++/77597] GCC 6.2 / LLVM 3.9 name mangling discrepancy for function with instantiated template in signature whose template argument involves an ABI tag.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Well ABI tags are an extension on top of the IA64 C++ ABI and was first
implemented by GCC.

[Bug c++/77598] New: consexpr compilation failure on reference type casting

[bobk-off at yandex dot ru]

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

Bug ID: 77598
   Summary: consexpr compilation failure on reference type casting
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobk-off at yandex dot ru
  Target Milestone: ---

Compiler fails on type casting of reference during constexpr processing. This
bug is actual for GCC-ARM 4.8.2+ compilers, and GCC-X86-64 5.3+ compilers
(tested on gcc.godbolt.org). clang of any version which supports C++14 compile
code below successfully.

Known walkaround: change type of dtarr variable to "DataTypeBasicX_t &"

#include 
#include 

template
struct DefaultInstanceOf { static constexpr T value = T(); };

template
constexpr T DefaultInstanceOf::value;

enum class BasicDataTypeId_t : uint16_t
{
None = 0,
INTEGER16 = 0x0003,
};


struct DataTypeX_t
{
private:
uint32_t mBitSize;
public:
constexpr uint32_t BitSize() const { return mBitSize; }
constexpr DataTypeX_t(const uint32_t & bitSize) : mBitSize(bitSize) {};
};



struct DataTypeBasicX_t : public DataTypeX_t
{
constexpr DataTypeBasicX_t() : DataTypeX_t(50) {};
};


struct DataTypeBasicArrayX_t : public DataTypeBasicX_t
{
};

struct BaseDataTypes
{
static constexpr const auto & ARRAY_OF_INT =
DefaultInstanceOf::value;
};

constexpr const DataTypeX_t & dtarr10 = BaseDataTypes::ARRAY_OF_INT;
constexpr const size_t bitsz10 = dtarr10.BitSize();

int main()
{
  while (1);
}

Error message:
46 : in constexpr expansion of '(& dtarr10)->DataTypeX_t::BitSize()'
46 : error: accessing value of
'DefaultInstanceOf::value' through a 'const DataTypeX_t'
glvalue in a constant expression
constexpr const size_t bitsz10 = dtarr10.BitSize();
^
Compilation failed

Link to gcc.godbolt.org code: https://godbolt.org/g/lR0dE4

[Bug tree-optimization/77544] [6 Regression] segfault at -O0 - infinite loop in simplification

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 15 12:35:13 2016
New Revision: 240164

URL: https://gcc.gnu.org/viewcvs?rev=240164=gcc=rev
Log:
2016-09-15  Richard Biener  

PR middle-end/77544
* fold-const.c (split_tree): Do not split constant ~X.

* c-c++-common/torture/pr77544.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/torture/pr77544.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77544] [6 Regression] segfault at -O0 - infinite loop in simplification

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] segfault   |[6 Regression] segfault at
   |at -O0 - infinite loop in   |-O0 - infinite loop in
   |simplification  |simplification

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

[Bug rtl-optimization/77425] Pointer test follows dereference in sched-int.h

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 15 12:27:35 2016
New Revision: 240163

URL: https://gcc.gnu.org/viewcvs?rev=240163=gcc=rev
Log:
PR rtl-optimization/77425
* sched-int.h (sd_iterator_cond): Don't update it_ptr->linkp if list
is NULL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-int.h

[Bug middle-end/77475] unnecessary or misleading context in reporting command line problems

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 15 12:26:39 2016
New Revision: 240162

URL: https://gcc.gnu.org/viewcvs?rev=240162=gcc=rev
Log:
PR middle-end/77475
* config/i386/i386.c (ix86_parse_stringop_strategy_string): Simplify,
use %qs instead of %s where desirable, use argument instead of arg in
the diagnostic wording, add list of supported strategies and
spellcheck hint.
(ix86_option_override_internal): Emit target("m...") instead of
option("m...") in the diagnostic.  Use %qs instead of %s in invalid
-march/-mtune option diagnostic.  Add list of supported arches/tunings
and spellcheck hint.  Remove prefix, suffix and sw variables, use
main_args_p ? "..." : "..." in diagnostics to make translation
possible.

* gcc.target/i386/pr65990.c: Adjust expected diagnostics.
* gcc.dg/march-generic.c: Likewise.
* gcc.target/i386/spellcheck-options-1.c: New test.
* gcc.target/i386/spellcheck-options-2.c: New test.
* gcc.target/i386/spellcheck-options-3.c: New test.
* gcc.target/i386/spellcheck-options-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/spellcheck-options-1.c
trunk/gcc/testsuite/gcc.target/i386/spellcheck-options-2.c
trunk/gcc/testsuite/gcc.target/i386/spellcheck-options-3.c
trunk/gcc/testsuite/gcc.target/i386/spellcheck-options-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/march-generic.c
trunk/gcc/testsuite/gcc.target/i386/pr65990.c

[Bug target/77597] New: GCC 6.2 / LLVM 3.9 name mangling discrepancy for function with instantiated template in signature whose template argument involves an ABI tag.

[greenc at fnal dot gov]

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

Bug ID: 77597
   Summary: GCC 6.2 / LLVM 3.9 name mangling discrepancy for
function with instantiated template in signature whose
template argument involves an ABI tag.
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: greenc at fnal dot gov
  Target Milestone: ---

Created attachment 39624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39624=edit
Code and build script to demonstrate mangling discrepancy

The attached tar file implements a code example declaring and defining the
function:

void gallery::throwHandleWhyFailed(std::shared_ptr
whyFailed);

which, when all's said and done, expands to (according to a capable c++filt):

gallery::throwHandleWhyFailed(std::shared_ptr const>)

Despite both compilers claiming to follow the Itanium ABI and mangling standard
for x64_64 architectures, g++ 6.2 and clang++ 3.9 apparently disagree on the
mangled function name.

By using the included Dockerfile or obtaining fnalart/llvm:3.9 from dockerhub,
one obtains an Ubuntu 16.04 with the addition of G++-6.2 and LLVM 3.9.0. Then,
one can do (e.g.):

$ docker run --rm -v `pwd`:/work -w /work fnalart/llvm:3.9 ./build.sh g++-6
_ZN7gallery20throwHandleWhyFailedESt10shared_ptrIKN3cet15coded_exceptionIN3art6errors10ErrorCodesEXadL_ZNS3_15ExceptionDetail9translateB5cxx11ES5_E
gallery::throwHandleWhyFailed(std::shared_ptr const>)

and

$ docker run --rm -v `pwd`:/work -w /work fnalart/llvm:3.9 ./build.sh
clang++-3.9
_ZN7gallery20throwHandleWhyFailedESt10shared_ptrIKN3cet15coded_exceptionIN3art6errors10ErrorCodesEXadL_ZNS3_15ExceptionDetail9translateB5cxx11ENS6_6errors10ErrorCodesEE
gallery::throwHandleWhyFailed(std::shared_ptr const>)

Note that c++filt demangles the symbol in each case to the same C++ function
signature.

It is unclear to me as a non expert whether GCC or LLVM is at fault, or whether
the standard is sufficiently unclear that either mangled name is valid (which
would be bad). I'm currently waiting for permission to obtain an LLVM Bugzilla
account in order to submit this issue to them also. When I have successfully
submited same, I will provide a link to it here.

[Bug target/77587] [5/6/7 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 39623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39623=edit
gcc7-pr77587.patch

Untested fix.

[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Kostya Serebryany from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Created attachment 39612 [details]
> > pr77567-2.patch
> > 
> > Slightly larger patch, which attempts to diagnose that, but fails to do so,
> > because asan_allocator.cc only has:
> >   u32 alloc_type: 2;
> > and we now need 3 bits instead of just 2.
> > Dmitry, is there any possibility to free one bit for this in ChunkHeader?
> 
> There are no bits left. 

:(

> But do we need these new states here? 

The first patch doesn't have them, but then can't catch C++17 violations e.g.
like the one in #c0 above.

> Can't we reuse the from_memalign field? 

I've looked at it and I'm afraid it can't, while likely with the current *NEW*
alloc_type from_memalign will be likely false, because it uses minimum
alignment (though haven't verified), from_memalign is used to say if any
padding had to be inserted in between, and that might be sometimes true and
sometimes false for the overaligned allocs, depending on the exact alignment
etc.

> Also, please remember that we can not accept patches from this buganizer --
> they need to go via http://llvm.org/docs/Phabricator.html

I know, I wanted to discuss it here first.  I guess I'll just submit the first
patch and let you deal with the rest later.

[Bug target/77587] [5/6/7 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
From what I can see, this happens because expand_call does:
2736  if (fndecl)
2737{
2738  struct cgraph_rtl_info *i = cgraph_node::rtl_info (fndecl);
2739  /* Without automatic stack alignment, we can't increase preferred
2740 stack boundary.  With automatic stack alignment, it is
2741 unnecessary since unless we can guarantee that all callers
will
2742 align the outgoing stack properly, callee has to align its
2743 stack anyway.  */
2744  if (i
2745  && i->preferred_incoming_stack_boundary
2746  && i->preferred_incoming_stack_boundary <
preferred_stack_boundary)
2747preferred_stack_boundary =
i->preferred_incoming_stack_boundary;

and

1951cgraph_rtl_info *
1952cgraph_node::rtl_info (tree decl)
1953{
1954  gcc_assert (TREE_CODE (decl) == FUNCTION_DECL);
1955  cgraph_node *node = get (decl);
1956  if (!node)
1957return NULL;
1958  node = node->ultimate_alias_target ();
1959  if (node->decl != current_function_decl
1960  && !TREE_ASM_WRITTEN (node->decl))
1961return NULL;
1962  /* Allocate if it doesnt exist.  */
1963  if (node->ultimate_alias_target ()->rtl == NULL)
1964node->ultimate_alias_target ()->rtl =
ggc_cleared_alloc ();
1965  return node->ultimate_alias_target ()->rtl;

First of all, it is confusing, because it calls ultimate_alias_target up to 3
times, wouldn't one call be enough?

And the second issue is that ultimate_alias_target and its helpers return foo's
node even when the alias is a weak alias (global) to a local routine, which
could (and is in this case) be overridden with something different at link
time.

Honza, shall ultimate_alias_target ignore such aliases, something else?

[Bug testsuite/77411] object-size-9.c -fpic -m32 failure

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00923.html

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[cltang at gcc dot gnu.org]

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

--- Comment #9 from Chung-Lin Tang  ---
Author: cltang
Date: Thu Sep 15 10:00:14 2016
New Revision: 240156

URL: https://gcc.gnu.org/viewcvs?rev=240156=gcc=rev
Log:
2016-09-15  Chung-Lin Tang  

Backport from mainline
2016-09-15  Chung-Lin Tang  

PR fortran/72743
* ipa-icf.c (set_alias_uids): New function.
(sem_variable::merge): Use set_alias_uids to set DECL_PT_UID of
all the merged variable's referring aliases.

testsuite/
* gfortran.dg/goacc/pr72743.f90: New test.


Added:
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/pr72743.f90
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/ipa-icf.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[cltang at gcc dot gnu.org]

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

--- Comment #8 from Chung-Lin Tang  ---
Author: cltang
Date: Thu Sep 15 09:46:36 2016
New Revision: 240155

URL: https://gcc.gnu.org/viewcvs?rev=240155=gcc=rev
Log:
2016-09-15  Chung-Lin Tang  

PR fortran/72743
* ipa-icf.c (set_alias_uids): New function.
(sem_variable::merge): Use set_alias_uids to set DECL_PT_UID of
all the merged variable's referring aliases.

testsuite/
* gfortran.dg/goacc/pr72743.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/goacc/pr72743.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #4)
> So DW_OP_GNU_implicit_ptr doesn't work here?  Not sure
> I understand how DW_OP_GNU_implicit_ptr works fully.  That is,
> 
>   ... *(D#1 + 24)
>   DW_OP_GNU_implicit_ptr  + 0
>   DW_OP_mul
> 
> the examples in the specification always finish the dwarf expression
> with DW_OP_GNU_implicit_ptr which wouldn't be the case here.

No, it doesn't, for 2 reasons:
1) DW_OP_implicit_ptr (DWARF5) / DW_OP_GNU_implicit_ptr (GNU) is a DWARF
location description op, so can't appear in the middle of DWARF expression, but
has to appear on its own; it has a bias argument, so you can say that
int a = 5;
char *b = ((char *) ) + 2;
b has DW_AT_location DW_OP_GNU_implicit_ptr , but that is it; it is like
DW_OP_reg* or DW_OP_stack_value that can't appear in the middle, and more like
DW_OP_reg* which also has to appear on its own (or say combined through
DW_OP_piece).
2) it doesn't give you the value, but the address of the referenced DIE.  So,
if 1) wasn't a problem, you'd need ... DW_OP_implicit_ptr  DW_OP_deref
DW_OP_mul to get the value and multiply.

I've proposed DW_OP_variable_value for this, will see if I get any feedback on
that.

[Bug c/66683] Large macro with float multiplications fails

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Here is the testcase just in case github ever goes down:
#include 
#include 
#define TEST
(1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01*1.01)+
#define TEST2 TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST
#define TEST3 TEST2 TEST2 TEST2 TEST2 TEST2 TEST2 TEST2 TEST2 TEST2 TEST2
#define TEST4 TEST3 TEST3 TEST3 TEST3 TEST3 TEST3 TEST3 TEST3 TEST3 TEST3
#define TEST5 TEST4 TEST4 TEST4 TEST4 TEST4 TEST4 TEST4 TEST4 TEST4 TEST4 
#define TEST6 TEST5 TEST5 TEST5 TEST5 TEST5 TEST5 TEST5 TEST5 TEST5 TEST5
#define TEST7 TEST6 TEST6 TEST6 TEST6 TEST6 TEST6 TEST6 TEST6 TEST6 TEST6
#define TEST8 TEST7 TEST7 TEST7 TEST7 TEST7 TEST7 TEST7 TEST7 TEST7 TEST7 
#define TEST9 TEST8 TEST8 TEST8 TEST8 TEST8 TEST8 TEST8 TEST8 TEST8 TEST8
#define TEST10 TEST9 TEST9 TEST9 TEST9 TEST9 TEST9 TEST9 TEST9 TEST9 TEST9
#define TEST11 TEST10 TEST10 TEST10 TEST10 TEST10 TEST10 TEST10 TEST10 TEST10
#define TEST12 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11
TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11 TEST11

int main() {
  printf("%f", TEST7 0);
}

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 15 Sep 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||aldyh at gcc dot gnu.org,
>||rguenth at gcc dot gnu.org
> 
> --- Comment #3 from Jakub Jelinek  ---
> I'm afraid this is similar to the DW_AT_string_length troubles (but not to the
> direct reference to a DIE of some local variable, which can be besides the 
> hack
> we have now solved using DWARF extension, but to the indirect one where we 
> only
> have the hack which won't really work for LTO).
> 
> In this case, when the FE fills in the array_descr_info, it fills in:
> (gdb) p debug_generic_stmt (info->dimen[0].lower_bound)
> *(D#1 + 32);
> 
> $4 = void
> (gdb) p debug_generic_stmt (info->dimen[0].upper_bound)
> *(D#1 + 40);
> 
> $5 = void
> (gdb) p debug_generic_stmt (info->dimen[0].stride)
> *(D#1 + 24) * span.0;
> 
> The first two are representable just fine,
> .uleb128 0x4# DW_AT_lower_bound
> .byte   0x97# DW_OP_push_object_address
> .byte   0x23# DW_OP_plus_uconst
> .uleb128 0x20
> .byte   0x6 # DW_OP_deref
> and
> .uleb128 0x4# DW_AT_upper_bound
> .byte   0x97# DW_OP_push_object_address
> .byte   0x23# DW_OP_plus_uconst
> .uleb128 0x28
> .byte   0x6 # DW_OP_deref
> but the problem is with the stride, it refers to a local variable, but
> obviously during early debug we don't really have location description for 
> that
> variable.  And like for DW_AT_string_lenght, DW_OP_call{2,4,_ref} isn't the
> 100% answer here, because those expect the referenced DIE has DWARF expression
> rather than location description.  So we'd need DW_OP_variable_value or
> something similar.

So DW_OP_GNU_implicit_ptr doesn't work here?  Not sure
I understand how DW_OP_GNU_implicit_ptr works fully.  That is,

  ... *(D#1 + 24)
  DW_OP_GNU_implicit_ptr  + 0
  DW_OP_mul

the examples in the specification always finish the dwarf expression
with DW_OP_GNU_implicit_ptr which wouldn't be the case here.

[Bug fortran/77596] New: [F03] procedure pointer with implicit interface in type pointing to a function can be 'called'

[t.kondic at leeds dot ac.uk]

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

Bug ID: 77596
   Summary: [F03] procedure pointer with implicit interface in
type pointing to a function can be 'called'
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.kondic at leeds dot ac.uk
  Target Milestone: ---

Hi,

I guess that in an ideal world, the compiler should generate code to cause a
run-time error in a situation like in the following snippet:


!!*** CODE ***

module proctest
  implicit none
  type tf
 procedure(), nopass, pointer :: fp
  end type tf

contains
  function ff(x)
integer, intent(in) :: x
integer :: ff
print *, ''
  end function ff


  subroutine ass()
type(tf) :: p

p%fp=>ff
call p%fp(3)
  end subroutine ass

end module proctest


program xxx
  use proctest
  call ass()
end program xxx

!!*** END CODE ***

In subroutine 'ass', I am assigning a function to the procedure pointer. Next,
I am able to call the function pointer like a subroutine, using 'call'
statement,  with no consequences.

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm afraid this is similar to the DW_AT_string_length troubles (but not to the
direct reference to a DIE of some local variable, which can be besides the hack
we have now solved using DWARF extension, but to the indirect one where we only
have the hack which won't really work for LTO).

In this case, when the FE fills in the array_descr_info, it fills in:
(gdb) p debug_generic_stmt (info->dimen[0].lower_bound)
*(D#1 + 32);

$4 = void
(gdb) p debug_generic_stmt (info->dimen[0].upper_bound)
*(D#1 + 40);

$5 = void
(gdb) p debug_generic_stmt (info->dimen[0].stride)
*(D#1 + 24) * span.0;

The first two are representable just fine,
.uleb128 0x4# DW_AT_lower_bound
.byte   0x97# DW_OP_push_object_address
.byte   0x23# DW_OP_plus_uconst
.uleb128 0x20
.byte   0x6 # DW_OP_deref
and
.uleb128 0x4# DW_AT_upper_bound
.byte   0x97# DW_OP_push_object_address
.byte   0x23# DW_OP_plus_uconst
.uleb128 0x28
.byte   0x6 # DW_OP_deref
but the problem is with the stride, it refers to a local variable, but
obviously during early debug we don't really have location description for that
variable.  And like for DW_AT_string_lenght, DW_OP_call{2,4,_ref} isn't the
100% answer here, because those expect the referenced DIE has DWARF expression
rather than location description.  So we'd need DW_OP_variable_value or
something similar.

[Bug c++/77595] concepts: constrained member functions illegally instantiated during explicit class template instantiation

[akrzemi1 at gmail dot com]

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

--- Comment #1 from Andrzej Krzemienski  ---
I mean, the expectation is that member functions whose constraints are not
satisfied should be omitted during explicit class template instantiation.

See this discussion for more background:
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/concepts/EZZjh_kFiJY

[Bug middle-end/63743] Thumb1: big regression for float operators by r216728

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|tree-optimization   |middle-end
   Severity|critical|normal

[Bug debug/63581] undefined references in debug_info

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #3 from Andrew Pinski  ---
Fixed a long time ago.

[Bug lto/67111] ld -plugin segmentation fault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||armv6kz-hardfloat-linux-gnu
   ||eabi

--- Comment #1 from Andrew Pinski  ---
I have used the linker plugin but not with the arm target (I use it normally
with the aarch64 target).

Can you try again and see if it works now?

[Bug rtl-optimization/66890] function splitting only works with profile feedback

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 CC||jakub at gcc dot gnu.org
Summary|[56/7 Regression] fortran:  |[6/7 Regression] fortran:
   |Missing DW_AT_byte_stride   |Missing DW_AT_byte_stride
   |for an array record field   |for an array record field
   |selection   |selection
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Broken with early debug merge r224161.

[Bug c++/77588] Internal error triggered by __builtin___chkp_bndret

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

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

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Not a GCC bug.

[Bug c/71199] Support overloadable attribute in GNU C front-end

[yuxuanchiadm at 126 dot com]

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

--- Comment #10 from Yu Xuanchi  ---
So there is currently i'm working on:
-Add "OVERLOAD" tree or just use chain. So we can put all function with same
identifier overloaded in a same tree so we can obtain them use
build_external_ref.
-Find a way to handle function invoke overload resolution.
-Find a way to handle function address-of overload resolution.

[Bug middle-end/77594] double computation for __builtin_sub_overflow (0, ...)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39622=edit
gcc7-pr77594.patch

You're right, I'll bootstrap/regtest this fix.

[Bug tree-optimization/77544] [6/7 Regression] segfault at -O0 - infinite loop in simplification

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The issue is inconsistent folding done by associates split_tree when facing
~X vs -X - 1.  I have a patch.

[Bug c++/77595] New: concepts: constrained member functions illegally instantiated during explicit class template instantiation

[akrzemi1 at gmail dot com]

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

Bug ID: 77595
   Summary: concepts: constrained member functions illegally
instantiated during explicit class template
instantiation
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

The following correct program, compiled with -fconcepts, gives compilation
errors:

```
#include 
#include 

template 
struct Wrapper
{
T val;

explicit Wrapper(T && v)
  : val(std::move(v)) {}

explicit Wrapper(T const & v)
  requires std::is_copy_constructible::value
  : val(v) {}
};

template struct Wrapper;

int main() {}
```

According to p0121r0, 14.8.2 [temp.explicit]:

"An explicit instantiation that names a class template specialization is also
an explicit instantiation of the same kind (declaration or definition) of each
of its members (not including members inherited from base classes and members
that are templates) that has not been previously explicitly specialized in the
translation unit containing the explicit instantiation, and provided that
the associated constraints, if any, of that member are satisfied by the
template arguments of the explicit instantiation (14.10.2), except as described
below."

[Bug tree-optimization/77514] [6 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |VN_INFO_GET, at |VN_INFO_GET, at
   |tree-ssa-sccvn.c:406 w/ -O2 |tree-ssa-sccvn.c:406 w/ -O2
   |(and above) |(and above)

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

[Bug tree-optimization/77514] [6 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 15 07:17:45 2016
New Revision: 240153

URL: https://gcc.gnu.org/viewcvs?rev=240153=gcc=rev
Log:
2016-09-15  Richard Biener  

PR tree-optimization/77514
* tree-ssa-pre.c (create_expression_by_pieces): Handle garbage
only forced_stmts sequence.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77514.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug middle-end/77594] double computation for __builtin_sub_overflow (0, ...)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
case MINUS_EXPR:
  if (integer_zerop (arg0) && !unsr_p)
expand_neg_overflow (loc, lhs, arg1, false);
  /* FALLTHRU */
case PLUS_EXPR:
  expand_addsub_overflow (loc, code, lhs, arg0, arg1,
  unsr_p, unsr_p, unsr_p, false);
  return;

indeed contains premature optimization (handling 0 - x) and missing a return.