[Bug tree-optimization/78720] [7 Regression] Illegal instruction in generated code

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
*** Bug 78769 has been marked as a duplicate of this bug. ***

[Bug middle-end/78769] [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Dmitry Babokin from comment #2)
> I've used r243504, the latest available on git://gcc.gnu.org/git/gcc.git

Yes, the git server is stuck at the moment.

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

[Bug target/78624] [7 Regression] ICE (invalid rtl sharing) while doing a build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-11
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
The 32bit powerpc failure might have been fixed also via 78614.

Can you try again?  Also attach the preprocessed source for libgcc2.i that is
failing.

[Bug target/78624] [7 Regression] ICE (invalid rtl sharing) while doing a build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||78614

--- Comment #1 from Andrew Pinski  ---
The powerpc64 failure was PR 78614.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78614
[Bug 78614] [7 Regression] ICE error: invalid rtl sharing found in the insn
(verify_rtx_sharing) gcc/emit-rtl.c:2743

[Bug target/78624] [7 Regression] ICE (invalid rtl sharing) while doing a build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
  Component|bootstrap   |target
   Target Milestone|--- |7.0
Summary|crosstool-ng targets|[7 Regression] ICE (invalid
   |powerpc-unknown-linux-gnu   |rtl sharing) while doing a
   |and |build
   |powerpc64-unknown-linux-gnu |
   |fail to compile |

[Bug libstdc++/78717] no definition of string::find when lowered to gimple

[hiraditya at msn dot com]

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

--- Comment #2 from AK  ---
With -O3 I see only the following definition of find which calls the real find
function I was expecting to be visible in the gimple.

  D.12805 =
_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4findERKS4_mD.11635
(s1D.12794, s2D.12795, 0);

std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::find(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) const

But after I #defined _GLIBCXX_DEBUG in test.cpp (before including string), I
can see the find function.

[Bug middle-end/78769] [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[babokin at gmail dot com]

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

--- Comment #2 from Dmitry Babokin  ---
I've used r243504, the latest available on git://gcc.gnu.org/git/gcc.git

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/78769] [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0

[Bug middle-end/78769] [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This might have been just fixed by r243516 .

[Bug middle-end/78769] New: [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[babokin at gmail dot com]

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

Bug ID: 78769
   Summary: [7 Regression] Incorrect arithmetic optimization for
(a < 0) << 29 >> 1;
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

> cat bug.cpp
#include 
char a = -110;
unsigned long long int b;

void foo();

int main() {
  foo();
  printf("0x%llx\n", b);
  return 0;
}

> cat bug2.cpp
extern char a;
extern unsigned long long int b;
void foo() {
  b = (a < 0) << 29 >> 1;
}

> g++ -w -O0 -o no_opt bug.cpp bug2.cpp
> ./no_opt
0x1000

> g++ -w -O1 -o opt bug.cpp bug2.cpp
> ./opt
0x0

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/dybaboki/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_github/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,lto : (reconfigured) ../gcc_github/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161209 (experimental) (GCC)

[Bug target/78382] ICE when compiling on aarch64 in ILP32 mode with traditional thread local storage and pic

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |7.0

--- Comment #3 from Andrew Pinski  ---
Fixed.

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||csaba_22 at yahoo dot co.uk

--- Comment #12 from Andrew Pinski  ---
*** Bug 78755 has been marked as a duplicate of this bug. ***

[Bug sanitizer/78755] Thread sanitizer reports race with std::promise with -O0, works with -O{1,2,3}

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 69204.

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

[Bug lto/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71907

--- Comment #1 from Martin Sebor  ---
Bug 71907 points out a similar problem with buffer overflow warnings issued by
_FORTIFY_SOURCE.  That bug has been fixed and a test case for the
-Wstringop-overflow option works as expected:

$ (set -x && cat a.c && for o in -fno-lto -flto; do /build/gcc-svn/gcc/xgcc -B
/build/gcc-svn/gcc -O2 $o a.c; done)
+ cat a.c
char d[1];

int main (int argc, char *argv[])
{
  char *s = argc < 3 ? "12" : "123";

  __builtin_strcpy (d, s);
}
+ for o in -fno-lto -flto
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -fno-lto a.c
a.c: In function ‘main’:
a.c:7:3: warning: ‘__builtin_strcpy’ writing 3 bytes into a region of size 1
overflows the destination [-Wstringop-overflow=]
   __builtin_strcpy (d, s);
   ^~~
+ for o in -fno-lto -flto
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -flto a.c
a.c: In function ‘main’:
a.c:7:3: warning: ‘__builtin_strcpy’ writing 3 bytes into a region of size 1
overflows the destination [-Wstringop-overflow=]
   __builtin_strcpy (d, s);
   ^

[Bug lto/78768] New: -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

Bug ID: 78768
   Summary: -Walloca-larger-than and -Wformat-length warnings
disabled by -flto
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Walloca-larger-than and -Wformat-length options don't work with -flto. 
When compiling without -flto, GCC issues the two warnings for the following
program as expected.  When -flto is used, no warnings are issued.

$ (set -x && cat a.c && for o in -fno-lto -flto; do /build/gcc-svn/gcc/xgcc -B
/build/gcc-svn/gcc -O2 -Walloca-larger-than=100 -Wformat-length $o a.c; done)
+ cat a.c
char d[1];

int main (int argc, char *argv[])
{
  void *p = __builtin_alloca (1234);

  __builtin_sprintf (d, "%lx", (long)p);
}
+ for o in -fno-lto -flto
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -Walloca-larger-than=100
-Wformat-length -fno-lto a.c
a.c: In function ‘main’:
a.c:5:9: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   void *p = __builtin_alloca (1234);
 ^
a.c:5:9: note: limit is 100 bytes, but argument is 1234
a.c:7:29: warning: writing a terminating nul past the end of the destination
[-Wformat-length=]
   __builtin_sprintf (d, "%lx", (long)p);
  ~~~^
a.c:7:3: note: format output between 2 and 17 bytes into a destination of size
1
   __builtin_sprintf (d, "%lx", (long)p);
   ^
+ for o in -fno-lto -flto
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -Walloca-larger-than=100
-Wformat-length -flto a.c

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #16 from Thomas Koenig  ---
Committed the part which looks for missing location
information. Closing.

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Dec 10 22:28:32 2016
New Revision: 243520

URL: https://gcc.gnu.org/viewcvs?rev=243520=gcc=rev
Log:
2016-12-10  Thomas Koenig  

PR fortran/78226
* error.c (gfc_warning_internal):  New function.
* frontend-passes.c (gfc_run_passes):  Call check_locus if
CHECKING_P is defined.
(check_locus_code):  New function.
(check_locus_expr):  New function.
(check_locus):  New function.
* gfortran.h:  Add prototype for gfc_warning_internal.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h

[Bug c++/78765] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5708)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Keywords||error-recovery
   Last reconfirmed||2016-12-10
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE on invalid C++ code on  |[7 Regression] ICE on
   |x86_64-linux-gnu (internal  |invalid C++ code on
   |compiler error: in  |x86_64-linux-gnu (internal
   |cp_build_addr_expr_1, at|compiler error: in
   |cp/typeck.c:5708)   |cp_build_addr_expr_1, at
   ||cp/typeck.c:5708)
   Target Milestone|--- |7.0

--- Comment #1 from Jakub Jelinek  ---
ICE started with r238182.

[Bug c++/78767] New: ICE when inheriting constructor of base class

[daniel+gcc at trvx dot org]

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

Bug ID: 78767
   Summary: ICE when inheriting constructor of base class
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel+gcc at trvx dot org
  Target Milestone: ---

Created attachment 40301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40301=edit
Small self-contained snippet for reproduction

For the following small self-contained C++14 snippet GCC 6.2 crashes hard with
an internal compiler error. I tried the same with a GCC 7 snapshot and could
reproduce the issue there, too.

In the Boost IRC channel Agustín Bergé told me this might be related to
inheriting constructors with default arguments and that there might be some
quirks related to SFINAE before C++17. ICE should still not happen.

Here is the snippet for reproduction, the ICE log and LLVM's error message for
the snippet.

https://gist.github.com/daniel-j-h/12c8b7f1c59b5a76c7e75dab38eb06fe#file-crash-cc

ICE in maybe_record_trace_start, at dwarf2cfi.c:2328 (trunk@243328)

[George Spelvin]

This is avr-gcc compiled from the git mirror commit
fcdd7053da, which says it's SVN trunk@243328.

This code used to work on some earlier GCC, but I don't know which
version.

Host is Debian Linux, i686, compiled with gcc (Debian 6.2.1-5) 6.2.1 20161124.

Configured with: ../gcc/configure --target=avr --enable-languages=c,c++ 
--enable-shared --with-system-zlib --enable-long-long --disable-nls 
--disable-libssp --disable-libsanitizer --program-prefix=avr- 
--with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld

$ avr-gcc -gdwarf-4 -Os -mmcu=at90s8515 -c scanf-nul.i
scanf-nul.i: In function 'main':
scanf-nul.i:130:1: internal compiler error: in maybe_record_trace_start, at 
dwarf2cfi.c:2328
 }
 ^
0x837b20c maybe_record_trace_start
../../gcc/gcc/dwarf2cfi.c:2328
0x837b502 create_trace_edges
../../gcc/gcc/dwarf2cfi.c:2424
0x837d412 scan_trace
../../gcc/gcc/dwarf2cfi.c:2638
0x837def9 create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2664
0x837def9 execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:3022
0x837def9 execute
../../gcc/gcc/dwarf2cfi.c:3502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.


The code is straight out of the avr-libc test suite.
The version below has the header spam stripped out.

== scanf-nul.i ==
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int size_t;
struct __file {
 char *buf;
 unsigned char unget;
 uint8_t flags;
 int size;
 int len;
 int (*put)(char, struct __file *);
 int (*get)(struct __file *);
 void *udata;
};
typedef struct __file FILE;
extern FILE *fdevopen(int (*__put)(char, FILE*), int (*__get)(FILE*));
extern int fclose(FILE *__stream);
extern int fscanf(FILE *__stream, const char *__fmt, ...);
extern void exit(int __status) __attribute__((__noreturn__));
extern void *memset(void *, int, size_t);
extern int memcmp(const void *, const void *, size_t) __attribute__((__pure__));

int vrslt = 1;
struct {
int i;
int j;
char s[8];
char t[8];
} v = { 1, 1, {1}, {1} };

const char *getpnt, *getend;

int ugetc(FILE *fp)
{
(void)fp;
if (getpnt == getend)
return -2;
return *getpnt++;
}

int uread(void *cookie, char *buf, size_t size)
{
size_t n;

for (n = 0; n < size; n++) {
int i = ugetc(cookie);
if (i < 0) break;
*buf++ = i;
}
return n;
}

int uclose (void *cookie)
{
(void)cookie;
return 0;
}

static FILE * uopen(const char *buf, int size)
{
static FILE *fp;

if (fp)
fclose(fp);
fp = fdevopen(0, ugetc);
if (!fp)
exit(117);
getpnt = buf;
getend = buf + size;
return fp;
}

int main()
{
FILE *fp;
int i;

memset(, ~0, sizeof v);
fp = uopen("A\000B", 3);
vrslt = fscanf(fp, "%c%c%c", v.s, v.s + 1, v.s + 2);
if (vrslt != 3)
exit(133);
if(memcmp(v.s, "A\000B", 3))
exit(134);

memset(, ~0, sizeof v);
fp = uopen("\t \000", 3);
i = fscanf(fp, " %c", v.s);
if (i != 1) exit(140);
if (v.s[0]) exit(141);

memset(, ~0, sizeof v);
fp = uopen("123\000456", 7);
i = fscanf(fp, "%d%c%d", , v.s, );
if (i != 3) exit(147);
if (v.i != 123 || v.s[0] || v.j != 456)
exit(148);

memset(, ~0, sizeof v);
fp = uopen("A\000BC", 4);
i = fscanf(fp, "%s%s", v.s, v.t);
if (i != 1) exit(154);
if (memcmp(v.s, "A\000BC", 4))
exit(155);

return 0;
}

[Bug tree-optimization/78709] Code size is bigger at -Os than at -O3, -Os does not enable -ftree-loop-distribute-patterns

[erika.molnar at cyberthorstudios dot com]

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

--- Comment #3 from ErikaMolnar  ---
Thank you for your reply. To make it work on -Os I need to make the following
change in tree-loop-distribution.c:
-  /* Only optimize hot loops.  */
-  if (!optimize_loop_for_speed_p (loop))
-continue;

Could yo make this modification in the next release?

[Bug other/78766] New: GCC Awk scripts use the non-POSIX /^{/ regex

[sstewartgallus00 at mylangara dot bc.ca]

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

Bug ID: 78766
   Summary: GCC Awk scripts use the non-POSIX  /^{/ regex
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sstewartgallus00 at mylangara dot bc.ca
  Target Milestone: ---

When building with the latest Gawk 4.14 and POSIXLY_CORRECT set I get the error

gawk: /home/sstewartgallus/root/var/src/gcc-6.2.0/gcc/opt-functions.awk:64:
(FILENAME=- FNR=77) fatal: Invalid preceding regular expression: /^{/

[Bug fortran/78746] charlen_15.f90, charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
The issue with charlen_15.f90 was fixed here:

https://gcc.gnu.org/ml/gcc-bugs/2016-12/msg01451.html

The issues with both charlen_03.f90 and charlen_10.f90
have nothing at all to do with a charlen.  The problem
is referencing an uninitialized array bound.  For *_03.f90
we have

program p
   type t
  character(1), allocatable :: x(n)
   end type
end

The variable 'n' is used, but not defined.  The backtrace is

0x87bac2a crash_signal
/mnt/kargl/gcc/gcc/toplev.c:333
0x826ec1b resolve_variable
/mnt/kargl/gcc/gcc/fortran/resolve.c:5048
0x826ec1b gfc_resolve_expr(gfc_expr*)
/mnt/kargl/gcc/gcc/fortran/resolve.c:6492
0x81d7152 resolve_array_bound
/mnt/kargl/gcc/gcc/fortran/array.c:327
0x81d7c6d gfc_resolve_array_spec(gfc_array_spec*, int)
/mnt/kargl/gcc/gcc/fortran/array.c:368
0x826c9f0 resolve_component
/mnt/kargl/gcc/gcc/fortran/resolve.c:13629
0x826d378 resolve_fl_derived0
/mnt/kargl/gcc/gcc/fortran/resolve.c:13746
0x826d79e resolve_fl_derived0
/mnt/kargl/gcc/gcc/fortran/resolve.c:13831
0x826d79e resolve_fl_derived
/mnt/kargl/gcc/gcc/fortran/resolve.c:13823
0x826a226 resolve_symbol
/mnt/kargl/gcc/gcc/fortran/resolve.c:14146
0x82898dd do_traverse_symtree
/mnt/kargl/gcc/gcc/fortran/symbol.c:3986
0x8264f0d resolve_types
/mnt/kargl/gcc/gcc/fortran/resolve.c:15999
0x826969e gfc_resolve(gfc_namespace*)
/mnt/kargl/gcc/gcc/fortran/resolve.c:16112
0x825860b resolve_all_program_units
/mnt/kargl/gcc/gcc/fortran/parse.c:5947
0x825860b gfc_parse_file()
/mnt/kargl/gcc/gcc/fortran/parse.c:6194
0x829bc12 gfc_be_parse_file
/mnt/kargl/gcc/gcc/fortran/f95-lang.c:202

[Bug c++/78765] New: ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5708)

[chengniansun at gmail dot com]

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

Bug ID: 78765
   Summary: ICE on invalid C++ code on x86_64-linux-gnu (internal
compiler error: in cp_build_addr_expr_1, at
cp/typeck.c:5708)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ 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 20161210 (experimental) [trunk revision 243516] (GCC) 
$ 
$ gcc-trunk small.C
small.C:6:42: error: ‘v’ was not declared in this scope
   static constexpr ValueType doubleval = v;
  ^
small.C: In function ‘int main()’:
small.C:9:52: internal compiler error: in cp_build_addr_expr_1, at
cp/typeck.c:5708
 int main() { ValueTypeInfo }
^
0x7eb7d5 cp_build_addr_expr_1
../../gcc-source-trunk/gcc/cp/typeck.c:5708
0x683162 add_function_candidate
../../gcc-source-trunk/gcc/cp/call.c:2158
0x6848c7 add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5491
0x67f9e4 build_user_type_conversion_1
../../gcc-source-trunk/gcc/cp/call.c:3842
0x680a8a implicit_conversion
../../gcc-source-trunk/gcc/cp/call.c:1898
0x6890dd build_integral_nontype_arg_conv(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/call.c:4025
0x70afa5 convert_nontype_argument
../../gcc-source-trunk/gcc/cp/pt.c:6434
0x711eed convert_template_argument
../../gcc-source-trunk/gcc/cp/pt.c:7363
0x71fa63 coerce_template_parms
../../gcc-source-trunk/gcc/cp/pt.c:7823
0x72199a lookup_template_class_1
../../gcc-source-trunk/gcc/cp/pt.c:8396
0x72199a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-source-trunk/gcc/cp/pt.c:8738
0x836bed finish_template_type(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/semantics.c:3146
0x7bea14 cp_parser_template_id
../../gcc-source-trunk/gcc/cp/parser.c:15464
0x7becba cp_parser_class_name
../../gcc-source-trunk/gcc/cp/parser.c:21879
0x7af07d cp_parser_qualifying_entity
../../gcc-source-trunk/gcc/cp/parser.c:6293
0x7af07d cp_parser_nested_name_specifier_opt
../../gcc-source-trunk/gcc/cp/parser.c:5977
0x7acd20 cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16793
0x7aa261 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16464
0x7bf3d3 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:13303
0x7c9770 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12646
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ cat small.C
class ValueType {
  operator int();
  int m_ID;
};
class ValueTypeEnum {
  static constexpr ValueType doubleval = v;
};
template  class ValueTypeInfo;
int main() { ValueTypeInfo }
$

[Bug libstdc++/78717] no definition of string::find when lowered to gimple

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Did you forget to enable optimizations? At -O0, there is no point keeping those
extern templates around, so gcc saves time by dropping them. At -O1 and above,
I do see some extra functions in the gimple dump. I don't see as many as if I
change _GLIBCXX_EXTERN_TEMPLATE to 0 in bits/c++config.h, some heuristic likely
decided to keep only the functions small enough that they are good candidates
for inlining (I didn't try to tweak the inlining parameters to see if I could
get it to keep all relevant functions).
I agree that this is not nice, there are several PRs in bugzilla caused by
those extern templates not being inlined aggressively enough. My hope is that
LTO will make enough progress that we can have libstdc++ compiled with it and
inline functions from the library.

[Bug middle-end/78689] [7 Regression] ICE (segfault)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I had further look at this.  E.g. build_over_call's nargs = 2 in:
  if (ctor_omit_inherited_parms (fn))
nargs = 2;
is seen in inh-ctor23.C, inh-ctor24.C and inh-ctor28.C testcases.
Looking at these testcases and checking where the current tree-inline.c
COND_EXPR with folded to INTEGER_CST condition, I see one conditional clobber
(non-interesting), one call to some constructor with nameless PARM_DECLs and
one case where __vtt_parm parameter is used.  None of these contain user
labels, so worst case scanning for user labels in the tree-inline.c code might
work.
Anyway, what I see is that in the complete ctor during the tree-inline.c body
copying the __vtt_parm is replaced with 0 and (unexpectedly) the base ctor has
the unnamed extra params like the complete ctor.  So I don't see why things
wouldn't work with the tree-inline.c changes reverted.  Unless the extra
arguments from the base ctor are meant to be removed.

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

[jdanek at redhat dot com]

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

--- Comment #1 from Jiri Danek  ---
How reproducible: Always
Reproduction steps: docker run --rm -it jdanekrh/gcc-78763 make

(I pushed the partially built container to Docker Hub (docker.io) and the above
command fetches it from there and runs make in it.)

[Bug target/78764] New: CPU type option discarded on 32-bit powerpc

[rin at NetBSD dot org]

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

Bug ID: 78764
   Summary: CPU type option discarded on 32-bit powerpc
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rin at NetBSD dot org
  Target Milestone: ---

Created attachment 40300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40300=edit
restrict usage of ".machine" pseudo-op to 64-bit powerpc

GCC >= 4.8.5 passes ".machine ppc" pseudo-op to assembler for 32-bit
powerpc, which is introduced by this commit:

 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5379d8d457b300219d3d8eda38caaa9916f98078

This pseudo-op discards CPU type specified by compiler option
"-mcpu=XXX" or "-Wa,-mXXX". As a result, some mnemonics in inline
assembler codes are misassembled into instructions for generic ppc.
This results in broken kernel for NetBSD on IBM 405, where indices
of some special purpose registers are different from those in
generic ppc, cf. NetBSD PR port-powerpc/51366:

  http://gnats.netbsd.org/51366

The commit raised above seem to be intended for 64-bit powerpc;
without it, gas cannot assemble codes generated by GCC for 64-bit
powerpc. I therefore propose to restrict usage of ".machine" pseudo-
op to the 64-bit CPUs. Please find the attached file. This is for
GCC 5.4.0, but it can be applied to the master branch as of today.

[Bug fortran/78350] ICE in gfc_code2string(): Bad code, at fortran/misc.c:193

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sat Dec 10 18:35:47 2016
New Revision: 243517

URL: https://gcc.gnu.org/viewcvs?rev=243517=gcc=rev
Log:
2016-12-10 Paul Thomas  

PR fortran/78350
* resolve.c (resolve_structure_cons): Remove the block that
tried to remove a charlen and rely on namespace cleanup.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug go/78763] New: go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

[jdanek at redhat dot com]

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

Bug ID: 78763
   Summary: go1: internal compiler error: in do_get_backend, at
go/gofrontend/expressions.cc:8352
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: jdanek at redhat dot com
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 40299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40299=edit
Dockerfile for the failing build

I've been building the attached Dockerfile and I got the following error from
it

[ 80%] Built target reactor_send_cpp
Scanning dependencies of target go-build
# qpid.apache.org/amqp
go1: internal compiler error: in do_get_backend, at
go/gofrontend/expressions.cc:8352
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [proton-c/bindings/go/CMakeFiles/go-build] Error 2
proton-c/bindings/go/CMakeFiles/go-build.dir/build.make:49: recipe for target
'proton-c/bindings/go/CMakeFiles/go-build' failed
CMakeFiles/Makefile2:1791: recipe for target
'proton-c/bindings/go/CMakeFiles/go-build.dir/all' failed
Makefile:127: recipe for target 'all' failed
make[1]: *** [proton-c/bindings/go/CMakeFiles/go-build.dir/all] Error 2
make: *** [all] Error 2
The command '/bin/sh -c make' returned a non-zero code: 2

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[linux at carewolf dot com]

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

--- Comment #11 from Allan Jensen  ---
The think the issue I noted is completely separate from this one, so I opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762 to deal with it.

I think this one could probably be closed though.

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[linux at carewolf dot com]

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

--- Comment #3 from Allan Jensen  ---
Created attachment 40298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40298=edit
Test compiled with gcc 6

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[linux at carewolf dot com]

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

--- Comment #2 from Allan Jensen  ---
Created attachment 40297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40297=edit
Test compiled with -march=haswell

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Created attachment 40296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40296=edit
Test compiled with -mavx2

[Bug target/78762] New: Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[linux at carewolf dot com]

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

Bug ID: 78762
   Summary: Regression: Splitting unaligned AVX loads also when
AVX2 is enabled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

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

In gcc 7 when not optimizing for speed or newer Intel architectures unaligned
AVX loads are now split.

It appears this is on purpose, and the code related to it quite old, but I
haven't been able to trigger it with older versions gcc (tried 4.9, 5 and 6).

However this is a special tuning intended for Sandybridge and possibly AMD
cpus. It does not trigger on any AVX2 processor. Therefore it now causes a
universal performance degradation in code optimized for generic AVX2.

I suggest this tuning is disabled when avx2 is enabled.

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[freddie_chopin at op dot pl]

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

--- Comment #9 from Freddie Chopin  ---
Any chance for merging the fix to gcc-6 branch before gcc 6.3 would be
released?

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[cantabile.desu at gmail dot com]

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

--- Comment #8 from Bitterblue  ---
Can a fix for this bug be my Christmas present?

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[linux at carewolf dot com]

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

--- Comment #10 from Allan Jensen  ---
No I mean it triggers when you compile with -mavx2, it is solved with
-march=haswell. It appears the issue is the tune flag
X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL is set for all processors that support
avx2, but if you use generic+avx2, it still pessimistically optimizes for
pre-avx2 processors setting MASK_AVX256_SPLIT_UNALIGNED_LOAD.

Though since there are two controlling flags and the second
X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL is still set for some avx2 processors
(btver and znver) besides generic, it is harder to argue what generic+avx2
should do there.

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
(In reply to Allan Jensen from comment #7)
> This is significantly worse with integer operands.
> 
> _mm256_storeu_si256((__m256i *)[3],
> _mm256_add_epi32(_mm256_loadu_si256((const __m256i *)[0]),
>  _mm256_loadu_si256((const __m256i *)[1]))
> );

Please don't post isolated lines of code, always complete examples ready to be
copy-pasted and compiled. The declaration of data is relevant to the generated
code.

> compiles to:
> 
> vmovdqu 0x20(%rax),%xmm0
> vinserti128 $0x1,0x30(%rax),%ymm0,%ymm0
> vmovdqu (%rax),%xmm1
> vinserti128 $0x1,0x10(%rax),%ymm1,%ymm1
> vpaddd %ymm1,%ymm0,%ymm0
> vmovups %xmm0,0x60(%rax)
> vextracti128 $0x1,%ymm0,0x70(%rax)

With trunk and -march=skylake (or haswell), I can get

vmovdqu data(%rip), %ymm0
vpaddd  data+32(%rip), %ymm0, %ymm0
vmovdqu %ymm0, data+96(%rip)

so this looks fixed?

[Bug tree-optimization/78721] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in set_value_range, at tree-vrp.c:371

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/78720] [7 Regression] Illegal instruction in generated code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/78720] [7 Regression] Illegal instruction in generated code

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec 10 12:06:12 2016
New Revision: 243516

URL: https://gcc.gnu.org/viewcvs?rev=243516=gcc=rev
Log:
PR tree-optimization/78720
* match.pd (A < 0 ? C : 0): Only optimize for signed A.  If shift
is negative, sign extend to @1's type and than AND with C.

* gcc.c-torture/execute/pr78720.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr78720.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[linux at carewolf dot com]

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

--- Comment #8 from Allan Jensen  ---
Note this happens with -mavx2, but not with -march=haswell. It appears the
tuning is a bit too pessimistic when avx2 is enabled on generic x64.

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[linux at carewolf dot com]

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

Allan Jensen  changed:

   What|Removed |Added

 CC||linux at carewolf dot com

--- Comment #7 from Allan Jensen  ---
This is significantly worse with integer operands.

_mm256_storeu_si256((__m256i *)[3],
_mm256_add_epi32(_mm256_loadu_si256((const __m256i *)[0]),
 _mm256_loadu_si256((const __m256i *)[1]))
);

compiles to:

vmovdqu 0x20(%rax),%xmm0
vinserti128 $0x1,0x30(%rax),%ymm0,%ymm0
vmovdqu (%rax),%xmm1
vinserti128 $0x1,0x10(%rax),%ymm1,%ymm1
vpaddd %ymm1,%ymm0,%ymm0
vmovups %xmm0,0x60(%rax)
vextracti128 $0x1,%ymm0,0x70(%rax)

[Bug target/78222] target-tilegx: Incorrect bundle: let addli in y pipe

[gang.chen.5i5j at gmail dot com]

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

--- Comment #1 from Chen Gang  ---
The root cause is: in tilegx_gen_bundle, gcc will lose prev insn when it
deletes useless insns.

The related insns before tilegx_gen_bbundle (it is correct).

249 (insn:TI 71 68 75 4 (set (mem:DI (reg/f:DI 10 r10 [112]) [3 *rp_19(D)+8 S8
A64])
250 (reg:DI 32 r32 [orig:115 r+8 ] [115])) "test.c":25 4 {*movdi_insn}
251  (expr_list:REG_DEAD (reg:DI 32 r32 [orig:115 r+8 ] [115])
252 (expr_list:REG_DEAD (reg/f:DI 10 r10 [112])
253 (nil
254 (insn 75 71 78 4 (unspec_volatile [
255 (const_int 0 [0])
256 ] 201) "test.c":27 162 {blockage}
257  (nil))
258 (insn 78 71 160 4 (unspec_volatile [
259 (const_int 0 [0])
260 ] 201) "test.c":27 162 {blockage}
261  (nil))
262
263
264 (insn:TI 144 160 142 4 (set (reg:DI 28 r28)
265 (plus:DI (reg/f:DI 54 sp)
266 (const_int 120 [0x78]))) "test.c":27 38 {adddi3}
267  (nil))
268 (insn 142 144 79 4 (set (reg:DI 29 r29)
269 (plus:DI (reg/f:DI 54 sp)
270 (const_int 128 [0x80]))) "test.c":27 38 {adddi3}
271  (nil))


The insns after tilegx_gen_bundle (remove 2 useless insns, but forgot to
correct the prev insn)

249 (insn:SI # 0 0 4 (set (mem:DI (reg/f:DI 10 r10 [112]) [ *rp_19(D)+8 S8
A64])
250 (reg:DI 32 r32 [orig:115 r+8 ] [115])) "test.c":25# {*movdi_insn}
251  (expr_list:REG_DEAD (reg:DI 32 r32 [orig:115 r+8 ] [115])
252 (expr_list:REG_DEAD (reg/f:DI 10 r10 [112])
253 (nil
254 (insn:SI # 0 0 4 (set (reg:DI 28 r28)
255 (plus:DI (reg/f:DI 54 sp)
256 (const_int 120 [0x78]))) "test.c":27# {adddi3}
257  (nil))
258 (insn:QI # 0 0 4 (set (reg:DI 29 r29)
259 (plus:DI (reg/f:DI 54 sp)
260 (const_int 128 [0x80]))) "test.c":27# {adddi3}
261  (nil))


The correct insns after tilegx_gen_bundle should be:

220 (insn:QI # 0 0 4 (set (mem:DI (reg/f:DI 10 r10 [112]) [ *rp_19(D)+8 S8
A64])
221 (reg:DI 32 r32 [orig:115 r+8 ] [115])) "test.c":25# {*movdi_insn}
222  (expr_list:REG_DEAD (reg:DI 32 r32 [orig:115 r+8 ] [115])
223 (expr_list:REG_DEAD (reg/f:DI 10 r10 [112])
224 (nil
225 (note # 0 0 NOTE_INSN_EPILOGUE_BEG)
226 (insn:SI # 0 0 4 (set (reg:DI 28 r28)
227 (plus:DI (reg/f:DI 54 sp)
228 (const_int 120 [0x78]))) "test.c":27# {adddi3}
229  (nil))
230 (insn:QI # 0 0 4 (set (reg:DI 29 r29)
231 (plus:DI (reg/f:DI 54 sp)
232 (const_int 128 [0x80]))) "test.c":27# {adddi3}
233  (nil))
234 (insn # 0 0 4 (use (reg/i:TI 0 r0)) "test.c":27#
235  (nil))


I shall make patch for it next.

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
It seems that the function get_dtio_proc in trans-io.c needs to be fixed.

[Bug c++/78761] C++14, compiler generate mangled name that can not be demangled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

That is a demangler bug.
The mangling has been added with
https://gcc.gnu.org/ml/gcc-patches/2013-04/msg01273.html
in r198150 and matches the spec
https://mentorembedded.github.io/cxx-abi/abi.html#mangling
 ::= Da # auto
 ::= Dc # decltype(auto)

[Bug fortran/78758] [7 Regression] Warning: '__builtin_memcpy' ... overflows the destination for string assignment

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec 10 08:02:21 2016
New Revision: 243515

URL: https://gcc.gnu.org/viewcvs?rev=243515=gcc=rev
Log:
PR fortran/78758
* tree-object-size.c (compute_object_offset) : Handle
non-zero low bound or non-standard element sizes.

* gfortran.dg/pr78758.f90: New test.
* gfortran.dg/pr38868.f: Remove again bogus warning.

Added:
trunk/gcc/testsuite/gfortran.dg/pr78758.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr38868.f
trunk/gcc/tree-object-size.c

[Bug fortran/78758] [7 Regression] Warning: '__builtin_memcpy' ... overflows the destination for string assignment

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/78708] [7 Regression][ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/78708] [7 Regression][ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec 10 08:01:17 2016
New Revision: 243514

URL: https://gcc.gnu.org/viewcvs?rev=243514=gcc=rev
Log:
PR sanitizer/78708
* lto-streamer-in.c (input_function): In addition to debug stmts
without -g, remove IFN_*SAN_* calls if corresponding flag_sanitize
bit is not enabled.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c