[Bug fortran/77900] Compile time errors/warning for IO statements appear wrong

[jvdelisle at gcc dot gnu.org]

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

--- Comment #1 from Jerry DeLisle  ---
This goes way back to at least 4.0 so maybe we chose to do this?

[Bug fortran/77900] New: Compile time errors/warning for IO statements appear wrong

[jvdelisle at gcc dot gnu.org]

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

Bug ID: 77900
   Summary: Compile time errors/warning for IO statements appear
wrong
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

While looking at something else I stumbled on this with iomesg_1.f90.

$ gfc -std=gnu iomsg_1.f90 
iomsg_1.f90:25:121:

 sg=ch) ! { dg-warning "STATUS specifier in CLOSE statement.*has invalid value"
}
   
1
Warning: STATUS specifier in CLOSE statement at (1) has invalid value ‘no_idea’

I think the above should be a compile error no matter what.

The line in questions is:

  close(23,status="no_idea", err=500, iomsg=ch) ! { dg-warning "STATUS
specifier in CLOSE statement.*has invalid value" }

It gives the expected error when changed to:

  close(23,status="no_idea") ! { dg-warning "STATUS specifier in CLOSE
statement.*has invalid value" }

Compile time errors vs warning should have nothing to do with the absence or
presence of err= or iomsg=

The wrong logic is in fortran/io.c. Probably other statements involved here.

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Basically what I am trying to say is there is a lot of analysis needed to
determine if the lifetime of object does not end during a call to a virtual
function.

> Altering the test case to trigger speculative devirtualization as follows:

This is a dup of another bug which says once it has been speculative to a
specific function which does not change the lifetime of the object, we can
split the loop.  That is a dup of bug 67886 really.

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Ryan Johnson from comment #1)
> Given that an object's vtable is fixed over its lifetime,

Yes but functions including virtual functions can deconstruct the object and
then call inplacement new on the same object and change what the type is for
that object.  So saying the object's vtable is fixed is correct but the
lifetime of the object is not fixed.

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[scovich at gmail dot com]

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

--- Comment #1 from Ryan Johnson  ---
It appears that multiple calls to different virtual functions of the same
object are not optimized, either (each performs the same load-load-jump
operation).

[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||lkrupp at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  ---
> AFAICT this PR has been fixed between revisions r240781 and r240870.

Likely by r240850.

[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
AFAICT this PR has been fixed between revisions r240781 and r240870.

[Bug fortran/64947] ICE in gimplify_expr, at gimplify.c:8425 with arrays of type(C_PTR)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
Duplicate of pr50892.

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

[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||bugs at stellardeath dot org

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 64947 has been marked as a duplicate of this bug. ***

[Bug c++/77887] -Wimplicit-fallthrough fails to trigger in an unused function template specialisation

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Created attachment 39772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39772=edit
Expanded version of test-case for 77886, adding an unused inline non-template
overload of the function template

Findings:

  l.30 \ l.29   template specialisation  overload
  inline - doesn"t warn  - doesn't warn
  non-inline + warns + warns

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The offset is this in plus_stmt_object_size() in tree-object-size.c:

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x70da41f8 precision
64 min  max >
static visited
def_stmt _1 = (sizetype) i_3(D);
version 1
ptr-info 0x70ec8f20>

I can work around it there by checking the type of i_3(D) (which is signed
char) and using its range to bound _1.  I wonder if this same workaround could
be put in get_range_info until POINTER_PLUS_EXPR is changed to take a signed
offset as you suggest.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

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

--- Comment #10 from Marc Mutz  ---
I can confirm patch fixes my Qt build, ie. not just bug.cpp.

Thanks!

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
So to fix this in reality is to change how POINTER_PLUS_EXPR takes an unsigned
integer to be a signed integer.  But this will take many extra issues and need
to be done though out the compiler.

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is the complex part because size_type is unsigned so the range converting
from signed [-127, 128] to unsigned is ~[128, 18446744073709551487]

[Bug tree-optimization/77899] New: incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

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

Bug ID: 77899
   Summary: incorrect VR_RANGE for a signed char function argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 77898 but with different and more wide-ranging symptoms (it
persists past even the last invocation of the VRP pass), in the following
program the range of the variable i is bounded by its type to [-128, 127]. 
Thus the result of the (p += i) expression is guaranteed to be in the range [d
+ 2, d + 257] and the if expression always false.  However, GCC represents the
range of the signed char offset by the VR_ANTI_RANGE ~[128,
18446744073709551487] and fails to optimize the if statement away.

This is another case that popped up during the testing of my patch for bug
77608 where it affects the result of __builtin_object_size.

$ cat x.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -S
-Wall -Wextra -Wpedantic -fdump-tree-vrp=/dev/stdout x.c
void f (signed char i)
{
  char d [260];

  const char *p = [130];

  p += i;

  if (p < d + 2 || d + 257 < p)
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5
;; 2 succs { 4 3 }
;; 3 succs { 4 5 }
;; 4 succs { }
;; 5 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_7 -> { p_3 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)



Value ranges after VRP:

_1: ~[128, 18446744073709551487]
i_2(D): VARYING
p_3: VARYING
p_7: VARYING


f (signed char i)
{
  const char * p;
  char d[260];
  sizetype _1;

  :
  _1 = (sizetype) i_2(D);
  p_3 = [130] + _1;
  if ([(void *) + 2B] > p_3)
goto ;
  else
goto ;

  :
  if ([(void *) + 257B] < p_3)
goto ;
  else
goto ;

  :
  __builtin_abort ();

  :
  d ={v} {CLOBBER};
  return;

}



;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { }
;; 4 succs { 1 }

Value ranges after VRP:

_1: ~[128, 18446744073709551487]
i_2(D): VARYING
p_3: VARYING
_7: [0, +INF]
_8: [0, +INF]
_9: [0, +INF]


f (signed char i)
{
  const char * p;
  char d[260];
  sizetype _1;
  _Bool _7;
  _Bool _8;
  _Bool _9;

  :
  _1 = (sizetype) i_2(D);
  p_3 = [130] + _1;
  _7 = [(void *) + 257B] < p_3;
  _8 = [(void *) + 2B] > p_3;
  _9 = _8 | _7;
  if (_9 != 0)
goto ;
  else
goto ;

  :
  __builtin_abort ();

  :
  d ={v} {CLOBBER};
  return;

}

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

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

--- Comment #8 from Marc Mutz  ---
#c3 is also in a template, indeed.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

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

--- Comment #7 from Marc Mutz  ---
Version:

  $ g++ -v
  Using built-in specs.
  COLLECT_GCC=g++
 
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
  Target: x86_64-pc-linux-gnu
  Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
  Thread model: posix
  gcc version 7.0.0 20161005 (experimental) (GCC) 

Specifically:

  $ git log -10 --online
  c7b01e7 PR sanitizer/77823  * c-ubsan.c (ubsan_instrument_shift):
Return NULL_TREE if type0 is not integral.
  d20 Fix pr69941.c test failure for avr
  ea55eab 2016-10-05  Jerry DeLisle  
  9ce1157 PR bootstrap/77819 - undefined reference to
gnu_libc_printf_pointer_format with uClibc
  5c176eb * c-common.c (c_common_reswords): Update comment for C++11.
  4ef2832 [fold-const] Fix native_encode_real for HFmode constants
  59deb1a 70564 fix newly-added tests for not_fn
  c375ef0 libcpp/ChangeLog:
  77a1a89 Move all existing strchr and strrchr folding from builtins.c to
gimple-fold.c.
  ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Created attachment 39770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39770=edit
Test case

Result:

  $ g++ -Wextra -std=c++1z -O2 bug.cpp
  bug.cpp: In function ‘void qt_memfill(T*, T, int) [with T = int]’:
  bug.cpp:10:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 0: do { *dest++ = value;
  ^
  bug.cpp:12:7: note: here
 case 7:  *dest++ = value;
 ^~~~
  bug.cpp:12:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 7:  *dest++ = value;
  ^
  bug.cpp:14:7: note: here
 case 6:  *dest++ = value;
 ^~~~
  bug.cpp:14:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 6:  *dest++ = value;
  ^
  bug.cpp:16:7: note: here
 case 5:  *dest++ = value;
 ^~~~
  bug.cpp:16:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 5:  *dest++ = value;
  ^
  bug.cpp:18:7: note: here
 case 4:  *dest++ = value;
 ^~~~
  bug.cpp:18:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 4:  *dest++ = value;
  ^
  bug.cpp:20:7: note: here
 case 3:  *dest++ = value;
 ^~~~
  bug.cpp:20:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 3:  *dest++ = value;
  ^
  bug.cpp:22:7: note: here
 case 2:  *dest++ = value;
 ^~~~

iow: only the attribute helps.

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

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

--- Comment #5 from Marc Mutz  ---
It's in a function template, in case that helps. I'll try to trim it down now.

[Bug tree-optimization/77898] New: VR_RANGE with inverted bounds after evrp and before vrp1

[msebor at gcc dot gnu.org]

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

Bug ID: 77898
   Summary: VR_RANGE with inverted bounds after evrp and before
vrp1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following problem was uncovered during the testing of a patch for bug 77608
and briefly discussed in the thread Re: VR_RANGE with inverted bounds at
https://gcc.gnu.org/ml/gcc/2016-10/msg00054.html.

Given the code below, a call to the get_range_info() function made in
plus_stmt_object_size() in tree-object-size.c yields the VR_RANGE [2147483648,
-2147483649] for the offset i in the (p += i) expression even though the
correct range is [0, 1].

void f (int i)
{
  const char *p = "ab";

  if (i < 0 || 1 < i)
i = 0;

  p += i;

  unsigned long n = __builtin_object_size (p, 2);

  if (n < 2 || 3 < n)
__builtin_abort ();
}


The .evrp dump for the function shows what looks like an incorrect anti-range. 
The .vrp1 dump, however, shows the correct range.

Value ranges after Early VRP:

i.0_1: [0, +INF]
_2: ~[2147483648, 18446744071562067967]
_3: [0, +INF]
i_4: VARYING
i_6(D): VARYING
p_8: VARYING
n_10: VARYING


f (int i)
{
  int i_6(D) = i;
  long unsigned int n;
  const char * p;
  unsigned int i.0_1;
  sizetype _2;
  long unsigned int _3;

  :
  # RANGE [0, 4294967295]
  i.0_1 = (unsigned int) i_6(D);
  if (i.0_1 > 1)
goto ;
  else
goto ;

  :

  :
  # i_4 = PHI 
  # RANGE ~[2147483648, 18446744071562067967]
  _2 = (sizetype) i_4;
  # PT = 
  p_8 = "ab" + _2;
  ...

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

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

--- Comment #14 from Marc Mutz  ---
More examples (incl. ones with .Lubsan_type3) available on request.

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #13 from Marc Mutz  ---
Created attachment 39769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39769=edit
Preprocessed source for a TU that fails

Command line for a TU that fails:

  g++ -c -include .pch/Qt5Core -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-o .obj/qlibraryinfo.o \
/home/marc/Qt/qt5/qtbase/src/corelib/global/qlibraryinfo.cpp

Fails with:
  {standard input}: Assembler messages:
  {standard input}:22992: Error: symbol `.Lubsan_type1' is already defined

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

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

--- Comment #12 from Marc Mutz  ---
Created attachment 39768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39768=edit
Preprocessed source for PCH

Command line for PCH file:

  g++ -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-x c++-header \
-c /home/marc/Qt/qt5/qtbase/src/corelib/global/qt_pch.h \
-o .pch/Qt5Core.gch/c++

  g++ -v
   Using built-in specs.
   COLLECT_GCC=g++
  
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
   Target: x86_64-pc-linux-gnu
   Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
   Thread model: posix
   gcc version 7.0.0 20161005 (experimental) (GCC) 

  git log -10 --oneline
   c7b01e7 PR sanitizer/77823  * c-ubsan.c
(ubsan_instrument_shift): Return NULL_TREE if type0 is not integral.
   d20 Fix pr69941.c test failure for avr
   ea55eab 2016-10-05  Jerry DeLisle  
   9ce1157 PR bootstrap/77819 - undefined reference to
gnu_libc_printf_pointer_format with uClibc
   5c176eb * c-common.c (c_common_reswords): Update comment for C++11.
   4ef2832 [fold-const] Fix native_encode_real for HFmode constants
   59deb1a 70564 fix newly-added tests for not_fn
   c375ef0 libcpp/ChangeLog:
   77a1a89 Move all existing strchr and strrchr folding from builtins.c to
gimple-fold.c.
   ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue

[Bug c++/66443] [DR 1611] Virtual inheritance vs. non-default constructors

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed in r240874.

[Bug c++/64433] Segmentation fault while compiling

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Fri Oct  7 20:01:17 2016
New Revision: 240874

URL: https://gcc.gnu.org/viewcvs?rev=240874=gcc=rev
Log:
cp/
PR c++/64433
DR1658, DR1611
* init.c (emit_mem_initializers): Don't construct vbases of
abstract classes.
(push_base_cleanups): Don't push vbase cleanups for abstract class
when in C++14 mode.
* method.c (synthethesized_method_walk): Don't walk vbases of
abstract classes when in C++14 mode.

testsuite/
PR c++/66443
* g++.dg/cpp0x/pr66443-cxx11.C: New.
* g++.dg/cpp0x/pr66443-cxx11-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14.C: New
* g++.dg/cpp1y/pr66443-cxx14-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-2.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-3.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66443] [DR 1611] Virtual inheritance vs. non-default constructors

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Fri Oct  7 20:01:17 2016
New Revision: 240874

URL: https://gcc.gnu.org/viewcvs?rev=240874=gcc=rev
Log:
cp/
PR c++/64433
DR1658, DR1611
* init.c (emit_mem_initializers): Don't construct vbases of
abstract classes.
(push_base_cleanups): Don't push vbase cleanups for abstract class
when in C++14 mode.
* method.c (synthethesized_method_walk): Don't walk vbases of
abstract classes when in C++14 mode.

testsuite/
PR c++/66443
* g++.dg/cpp0x/pr66443-cxx11.C: New.
* g++.dg/cpp0x/pr66443-cxx11-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14.C: New
* g++.dg/cpp1y/pr66443-cxx14-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-2.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-3.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 6 and 7. Closing.

[Bug fortran/38592] eliminate some string comparisons

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
Sometime between 4.8.4 and 4.9.4, the _gfortran_compare_string
has been replaced by a memcmp().

% gfc48 -O3 -fdump-tree-optimized -S -fdump-tree-original a.f90
% grep compare a.s
call_gfortran_compare_string
% gfc49 -O3 -fdump-tree-optimized -S -fdump-tree-original a.f90
% grep compare a.s


With gcc7, the -fdump-tree-original gives

  __builtin_memmove ((void *) , (void *) &"yes"[1]{lb: 1 sz: 1}, 3);
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (_parm.0);
{
  logical(kind=4) D.3408;

  D.3408 = __builtin_memcmp ((void *) &"yes"[1]{lb: 1 sz: 1},
 (void *) , 3) == 0;
  _gfortran_transfer_logical_write (_parm.0, , 4);
}
_gfortran_st_write_done (_parm.0);

and -fdump-tree-optimized shows

  :
  MEM[(c_char * {ref-all})] = "yes";
  dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
  dt_parm.0.common.line = 4;
  dt_parm.0.common.flags = 128;
  dt_parm.0.common.unit = 6;
  _gfortran_st_write (_parm.0);
  _1 = __builtin_memcmp_eq (&"yes"[1]{lb: 1 sz: 1}, , 3);
  _2 = _1 == 0;
  D.3408 = _2;
  _gfortran_transfer_logical_write (_parm.0, , 4);
  D.3408 ={v} {CLOBBER};
  _gfortran_st_write_done (_parm.0);
  dt_parm.0 ={v} {CLOBBER};
  a ={v} {CLOBBER};
  return;

I personally think this is non-issue now and the bug can be
closed.

[Bug c/38295] Support pointer difference as constant in static initializer

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||fw at gcc dot gnu.org
 Resolution|WONTFIX |---

--- Comment #10 from Florian Weimer  ---
This is already implemented for differences between C && label addresses.  I
think there is no compelling reason why this would not work for the addresses
of static functions, too.

[Bug fortran/77897] Compile error with KNL & -O3 for GTC code

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
Compiling these files appears to have a problem when the target is set to Intel
KNL.  The compiler appears to be generating incorrect register and instruction
names, leading to assembler messages.  See with gfortran 6.2.

Compiles OK with any of these changes:

1) Change target to Sandybridge
2) Remove the -O3 option
3) Use a different vendor compiler (Cray)

[Bug fortran/77897] New: Compile error with KNL & -O3 for GTC code

[longb at cray dot com]

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

Bug ID: 77897
   Summary: Compile error with KNL & -O3 for GTC code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

Created attachment 39767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39767=edit
Source files module.F90 and pushe.f90 (in bug.tar)

As a basic sanity check:

> ftn -c module.F90
> ftn -c pushe.f90 
> module swap PrgEnv-cray PrgEnv-gnu
> ftn -c module.F90
> ftn -c pushe.f90 
> ftn -c -O3 module.F90
> ftn -c -O3 pushe.f90 
> 
> module list
Currently Loaded Modulefiles:
...
 12) gcc/6.2.0
 13) craype-network-aries
 14) craype-sandybridge


Now checking KNL target:

> module swap craype-sandybridge craype-mic-knl
> ftn -c -O3 module.F90
> ftn -c -O3 pushe.f90 
/tmp/cc4TRnzd.s: Assembler messages:
/tmp/cc4TRnzd.s:61: Error: bad register name `%xmm24'
/tmp/cc4TRnzd.s:63: Error: bad register name `%xmm24'
/tmp/cc4TRnzd.s:65: Error: bad register name `%xmm16'
...
[many more lines of messages]

[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct  7 18:57:45 2016
New Revision: 240871

URL: https://gcc.gnu.org/viewcvs?rev=240871=gcc=rev
Log:
2016-10-07  Steven G. Kargl  

PR fortran/77406
* interface.c (gfc_compare_interfaces): Fix detection of ambiguous
interface involving alternate return.
(check_interface1): Improve error message and loci.

2016-10-07  Steven G. Kargl  

PR fortran/77406
* gfortran.dg/pr77406.f90: New test.
* gfortran.dg/assumed_type_3.f90: Update error messages.
* gfortran.dg/defined_operators_1.f90: Ditto.
* gfortran.dg/generic_26.f90: Ditto.
* gfortran.dg/generic_7.f90: Ditto.
* gfortran.dg/gomp/udr5.f90: Ditto.
* gfortran.dg/gomp/udr7.f90: Ditto.
* gfortran.dg/interface_1.f90: Ditto.
* gfortran.dg/interface_37.f90: Ditto.
* gfortran.dg/interface_5.f90: Ditto.
* gfortran.dg/interface_6.f90: Ditto.
* gfortran.dg/interface_7.f90
* gfortran.dg/no_arg_check_3.f90
* gfortran.dg/operator_5.f90
* gfortran.dg/proc_ptr_comp_20.f90: Ditto.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77406.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/assumed_type_3.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/generic_26.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/generic_7.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/udr5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/udr7.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_37.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_6.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_7.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/no_arg_check_3.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/operator_5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90

[Bug c++/77896] New: Object vtable lookups are not hoisted out of loops

[scovich at gmail dot com]

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

Bug ID: 77896
   Summary: Object vtable lookups are not hoisted out of loops
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com
  Target Milestone: ---

C++ virtual function calls normally require two memory loads followed by an
indirect jump: one load fetches the vtable from the object, another to fetch
the function address from the vtable, and the indirect call to invoke the
function. 

Given that an object's vtable is fixed over its lifetime, and the contents of a
given vtable are compile-time constant, I would expect the vtable lookups to be
hoisted out of loops when appropriate. For example:

 foo.cpp ===
struct Foo { virtual void frob(int i)=0; };
void frobN(Foo* f, int n) {
   for (int i=0; i < n; i++)
  f->frob(i);
}


Compiles at -O2 to substantially the same x86 assembly code for gcc-4.9,
gcc-5.2 and gcc-6.2:

_Z5frobNP3Fooi:
testl   %esi, %esi
jle .L10
pushq   %r12
movl%esi, %r12d
pushq   %rbp
movq%rdi, %rbp
pushq   %rbx
xorl%ebx, %ebx
.L5:
movq0(%rbp), %rax
movl%ebx, %esi
addl$1, %ebx
movq%rbp, %rdi
call*(%rax)
cmpl%ebx, %r12d
jne .L5
popq%rbx
popq%rbp
popq%r12
.L10:
rep ret

I would have expected to see something more like this (obtained using the bound
member function extension):

_Z5frobNP3Fooi:
.LFB12:
pushq   %r13
pushq   %r12
pushq   %rbp
pushq   %rbx
subq$8, %rsp
movq(%rdi), %rax
testl   %esi, %esi
movq(%rax), %r13
jle .L1
movq%rdi, %r12
movl%esi, %ebp
xorl%ebx, %ebx
.L5:
movl%ebx, %esi
addl$1, %ebx
movq%r12, %rdi
call*%r13
cmpl%ebx, %ebp
jne .L5
.L1:
addq$8, %rsp
popq%rbx
popq%rbp
popq%r12
popq%r13
ret

Altering the test case to trigger speculative devirtualization as follows:

 bug2.cpp ===
#include 
struct Foo { virtual void frob(int i)=0; };
void frobN(Foo* f, int n)
{
   for (int i=0; i < n; i++)
  f->frob(i);
}
struct Bar : Foo { 
   void frob(int i) { printf("Bar:%d\n", i); }
};
int main()
{
   Bar b;
   frobN(, 10);
}
=

Shows that even the speculative devirtualization is stuck inside the loop body:

_Z5frobNP3Fooi:
testl   %esi, %esi
jle .L13
pushq   %r12
movl%esi, %r12d
pushq   %rbp
movq%rdi, %rbp
pushq   %rbx
xorl%ebx, %ebx
jmp .L8
.L16:
xorl%eax, %eax
movl$.LC0, %edi
addl$1, %ebx
callprintf
cmpl%ebx, %r12d
je  .L15
.L8:
movq0(%rbp), %rax
movl%ebx, %esi
movq(%rax), %rax
cmpq$_ZN3Bar4frobEi, %rax
je  .L16
addl$1, %ebx
movq%rbp, %rdi
call*%rax
cmpl%ebx, %r12d
jne .L8
.L15:
popq%rbx
popq%rbp
popq%r12
.L13:
rep ret

If the vtable lookup could be hoisted, the speculative de-virt could become
very powerful by replicating the loop, something like this:

_Z5frobNP3Fooi:
testl   %esi, %esi
jle .L10
pushq   %r12
movl%esi, %r12d
pushq   %rbp
movq%rdi, %rbp
pushq   %rbx
xorl%ebx, %ebx
movq0(%rbp), %rax
pushq   %r12
movq(%rax), %r13
cmpq$_ZN3Bar4frobEi, %r13
je  .L16
.L5:
movl%ebx, %esi
addl$1, %ebx
movq%rbp, %rdi
call*%r13
cmpl%ebx, %r12d
jne .L5
jmp .L10
.L16:
xorl%eax, %eax
movl$.LC0, %edi
movl%ebx, %esi
addl$1, %ebx
callprintf
cmpl%ebx, %r12d
jne .L16
popq%r13
.L10:
popq%rbx
popq%rbp
popq%r12
rep ret

[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct  7 18:18:03 2016
New Revision: 240870

URL: https://gcc.gnu.org/viewcvs?rev=240870=gcc=rev
Log:
2016-10-07  Steven G. Kargl  

PR fortran/77406
* interface.c (gfc_compare_interfaces): Fix detection of ambiguous
interface involving alternate return.
(check_interface1): Improve error message and loci.

2016-10-07  Steven G. Kargl  

PR fortran/77406
* gfortran.dg/pr77406.f90: New test.
* gfortran.dg/assumed_type_3.f90: Update error messages.
* gfortran.dg/defined_operators_1.f90: Ditto.
* gfortran.dg/generic_26.f90: Ditto.
* gfortran.dg/generic_7.f90: Ditto.
* gfortran.dg/gomp/udr5.f90: Ditto.
* gfortran.dg/gomp/udr7.f90: Ditto.
* gfortran.dg/interface_1.f90: Ditto.
* gfortran.dg/interface_37.f90: Ditto.
* gfortran.dg/interface_5.f90: Ditto.
* gfortran.dg/interface_6.f90: Ditto.
* gfortran.dg/interface_7.f90
* gfortran.dg/no_arg_check_3.f90
* gfortran.dg/operator_5.f90
* gfortran.dg/proc_ptr_comp_20.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77406.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/assumed_type_3.f90
trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90
trunk/gcc/testsuite/gfortran.dg/generic_26.f90
trunk/gcc/testsuite/gfortran.dg/generic_7.f90
trunk/gcc/testsuite/gfortran.dg/gomp/udr5.f90
trunk/gcc/testsuite/gfortran.dg/gomp/udr7.f90
trunk/gcc/testsuite/gfortran.dg/interface_1.f90
trunk/gcc/testsuite/gfortran.dg/interface_37.f90
trunk/gcc/testsuite/gfortran.dg/interface_5.f90
trunk/gcc/testsuite/gfortran.dg/interface_6.f90
trunk/gcc/testsuite/gfortran.dg/interface_7.f90
trunk/gcc/testsuite/gfortran.dg/no_arg_check_3.f90
trunk/gcc/testsuite/gfortran.dg/operator_5.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90

[Bug c++/77700] suspicios code in cp/parser.c

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Bernd Edlinger  ---
fixed on trunk.

[Bug c++/77700] suspicios code in cp/parser.c

[edlinger at gcc dot gnu.org]

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

--- Comment #1 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Oct  7 17:10:38 2016
New Revision: 240867

URL: https://gcc.gnu.org/viewcvs?rev=240867=gcc=rev
Log:
2016-10-07  Bernd Edlinger  

PR c++/77700
* c-common.c (c_common_truthvalue_conversion): Warn also for
suspicious enum values in boolean context.

cp:
2016-10-07  Bernd Edlinger  

PR c++/77700
* parser.c (cp_parser_base_specifier): Fix a warning.

testsuite:
2016-10-07  Bernd Edlinger  

PR c++/77700
* c-c++-common/Wint-in-bool-context.c: Update test.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wint-in-bool-context.c

[Bug middle-end/77889] missing optimization on strlen(p + offset) with a bounded offset

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
(In reply to Richard Biener from comment #2)
> So you are complaining that VRP doesn't compute a range for n?  Because I
> can't see the tree-ssa-strlen pass computing ranges.
> 
> Confirmed for VRP.  It seems to ignore most builtins completely.

I wasn't suggesting the problem is in VRP but rather in tree-ssa-strlen.  My
patch for bug 77608 makes it work by having the plus_stmt_object_size function
call get_range_info to obtain the range for the offset so it seems that the
same approach should work for strlen.

(Please note this isn't meant to be a complaint. I'm pointing out an
opportunity for improvement.)

[Bug c++/69733] -Wignored-qualifiers points to wrong const

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bernd Schmidt  ---
Fixed.

[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Bernd Schmidt  ---
Fixed.

[Bug c++/69733] -Wignored-qualifiers points to wrong const

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Fri Oct  7 12:21:55 2016
New Revision: 240863

URL: https://gcc.gnu.org/viewcvs?rev=240863=gcc=rev
Log:
c/
PR c++/69733
* c-decl.c (smallest_type_quals_location): New static function.
(grokdeclarator): Try to find the correct location for an ignored
qualifier.
cp/
PR c++/69733
* decl.c (grokdeclarator): Try to find the correct location for an
ignored qualifier.
testsuite/
PR c++/69733
* c-c++-common/pr69733.c: New test.
* gcc.dg/pr69733.c: New test.
* gcc.target/i386/pr69733.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/pr69733.c
trunk/gcc/testsuite/gcc.dg/pr69733.c
trunk/gcc/testsuite/gcc.target/i386/pr69733.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Author: bernds
Date: Fri Oct  7 12:16:55 2016
New Revision: 240862

URL: https://gcc.gnu.org/viewcvs?rev=240862=gcc=rev
Log:
PR tree-optimization/77880
* expr.c (by_pieces_ninsns): Use unsigned HOST_WIDE_INT where
necessary.

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

[Bug c++/77892] local function declarations don't match namespace scope declarations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Without line-wrapping:

struct S{friend void f(){}};
void f();
int main()
{
  void f();
  f(); 
}

/tmp/cchVsieq.o: In function `main':
/tmp/f.cc:8: undefined reference to `f()'
collect2: error: ld returned 1 exit status


The local redeclaration prevents the inline definition being emitted.

[Bug c++/77803] [7 Regression] Bogus implicit-fallthrough warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/77803] [7 Regression] Bogus implicit-fallthrough warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Oct  7 11:45:50 2016
New Revision: 240861

URL: https://gcc.gnu.org/viewcvs?rev=240861=gcc=rev
Log:
PR c++/77803
* gimplify.c (last_stmt_in_scope): Add check for FALLTHROUGH ().

* g++.dg/warn/Wimplicit-fallthrough-1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77894] Enable GNU indirect function support by default as it will be used in glibc.

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
currently --enable-gnu-indirect-function enables its use in gcc target libs
like libatomic which breaks if the libc has no support for it.
(In reply to Florian Weimer from comment #2)
> (In reply to nsz from comment #1)
> > the ifunc abi still has many problems and i don't think it's possible to
> > detect
> > dynamic linker support for cross compilation so if it is enabled do it only
> > if
> > the default libc is glibc (e.g. on linux musl, bionic and uclibc does not
> > plan to implement it).
> 
> Will GCC generate IFUNCs although the attribute is never used?
> 
> If it is harmless to enable it, I'd suggest to do so unconditionally, so
> that people can cross-build glibc on any Linux system using the system
> compiler.

currently --enable-gnu-indirect-function enables ifuncs
in gcc target libs like libatomic, which breaks if the
libc has no support for it (i think this is a significant
abi commitment between gcc and libc which is not justified).

[Bug target/77894] Enable GNU indirect function support by default as it will be used in glibc.

[fw at gcc dot gnu.org]

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

--- Comment #2 from Florian Weimer  ---
(In reply to nsz from comment #1)
> the ifunc abi still has many problems and i don't think it's possible to
> detect
> dynamic linker support for cross compilation so if it is enabled do it only
> if
> the default libc is glibc (e.g. on linux musl, bionic and uclibc does not
> plan to implement it).

Will GCC generate IFUNCs although the attribute is never used?

If it is harmless to enable it, I'd suggest to do so unconditionally, so that
people can cross-build glibc on any Linux system using the system compiler.

[Bug tree-optimization/77895] Unaligned movdqa generated by GCC 6.2.0 with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
   *((unsigned int*)dst) = *((unsigned int*)src);

this requires dst and src to be aligned as 'unsigned int'.  Thus vectorization
will peel until it reaches alignment (which it can't for your 1-byte aligned
src/dst).

[Bug tree-optimization/77895] New: Unaligned movdqa generated by GCC 6.2.0 with -O3

[jack.d.whitham at gmail dot com]

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

Bug ID: 77895
   Summary: Unaligned movdqa generated by GCC 6.2.0 with -O3
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jack.d.whitham at gmail dot com
  Target Milestone: ---

Created attachment 39766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39766=edit
Test case to reproduce bug

A strange custom implementation of "memcpy" from a data compression library is
badly vectorized by GCC 6.2.0 when using "-O3", or alternatively "-O1
-fvect-cost-model -ftree-loop-vectorize". The vectorizer seems to assume that
the "src" address is word-aligned, but there is no reason to assume so (it's an
"unsigned char*"). The program segfaults at the "movdqa" instruction.

Bug can be reproduced with GCC 6.2.0 on Debian "sid" AMD64:

$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-5'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160927 (Debian 6.2.0-5)
$ gcc-6 -O3 example.c -o example
$ ./example
Segmentation fault

This bug is also in GCC 5.4.1 and GCC 4.9.4, but apparently not in GCC 4.8.
This bug occurs with x86 code as well as AMD64.

Please accept my apologies for guessing about the component and if this issue
is already known. I searched for duplicates and found a number of
similar-sounding bugs, but all were marked as "resolved" in earlier versions of
GCC.

[Bug c++/77890] class template type deduction fails for lambda functions

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

[Bug tree-optimization/77664] Missed optimization: signed int >= 0 && < unsigned short

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/77894] Enable GNU indirect function support by default as it will be used in glibc.

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #1 from nsz at gcc dot gnu.org ---
the ifunc abi still has many problems and i don't think it's possible to detect
dynamic linker support for cross compilation so if it is enabled do it only if
the default libc is glibc (e.g. on linux musl, bionic and uclibc does not plan
to implement it).

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
You haven't provided complete testcase, but #c2 certainly doesn't warn for me
with -Wimplicit-fallthrough and current trunk.

[Bug tree-optimization/77664] Missed optimization: signed int >= 0 && < unsigned short

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Oct  7 09:33:47 2016
New Revision: 240858

URL: https://gcc.gnu.org/viewcvs?rev=240858=gcc=rev
Log:
PR tree-optimization/77664
* tree-ssa-reassoc.c (update_range_test): Also clear low and high
for the other ranges.
(optimize_range_tests_diff): Fix up formatting.
(optimize_range_tests_var_bound): New function.
(optimize_range_tests): Use it.

* gcc.dg/tree-ssa/pr77664.c: New test.
* gcc.dg/pr77664.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr77664.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr77664.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug other/77894] New: Enable GNU indirect function support by default as it will be used in glibc.

[stli at linux dot vnet.ibm.com]

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

Bug ID: 77894
   Summary: Enable GNU indirect function support by default as it
will be used in glibc.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stli at linux dot vnet.ibm.com
  Target Milestone: ---

Starting with glibc-commits "Add configure check to test if gcc supports
attribute ifunc."
(https://sourceware.org/git/?p=glibc.git;a=commit;h=022dfdce000374b60aadfb0a5ed9a5c4c1dbd29b),
"Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to
false... "
(https://sourceware.org/git/?p=glibc.git;a=commit;h=00980d845f8f2ec3ed4ad161a1e5b97704be1929)
and further, for glibc with multi-arch support it is recommended to use a GCC
which has been built with support for GNU indirect functions. This ensures that
correct debugging information is generated for functions selected by IFUNC
resolvers. This support can either be enabled by configuring GCC with
'--enable-gnu-indirect-function', or by enabling it by default by setting
'default_gnu_indirect_function' variable for a particular architecture in the
GCC source file 'gcc/config.gcc'.

Currently GNU indirect function support is only enabled by default for few
configurations like intel and s390. Please enable it by default for other
architectures, too. E.g. according to the rpm-spec file fedora/rhel is
configuring gcc with --enable-gnu-indirect-function for the following
architectures: %{ix86} x86_64 ppc ppc64 ppc64le ppc64p7 s390 s390x %{arm}
aarch64.

Perhaps a configure check could test the presence of the non-standard gnu ifunc
support in the assembler, linker and dynamic linker and could automatically
dis/enable the support. But this behaviour should be discussed by the gcc
maintainers.

[Bug fortran/77884] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The tests compiles with '-fcoarray=single' for gfortran configured with
'--enable-checking=release'.

[Bug fortran/77885] ICE in gfc_add_class_array_ref, at fortran/class.c:259

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
The change occurred between revisions r192440 (2012-10-14, compiles) and
r192525 (2012-10-17, ICE), likely r192495 (pr50981 and pr54618).

If I replace 'class' with 'type' I get the error

call s(x)
  1
Error: Actual argument to 'x' at (1) must be a coarray

[Bug testsuite/39774] New: FAIL: g++/g++.dg-struct-layout-1//t004_x.C on arm target

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
No feedback in over 7 years.

[Bug tree-optimization/77893] New: VRP simplify_bit_ops_using_ranges should be applied during propagation

[rguenth at gcc dot gnu.org]

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

Bug ID: 77893
   Summary: VRP simplify_bit_ops_using_ranges should be applied
during propagation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: easyhack, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

A redundant

 _3 = _2 & _1;

that is replaced by _3 = _2; should instead produce a [_2, _2] range for _3
during propagation.

[Bug target/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.2.2

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

[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
 Status|WAITING |NEW

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
.

[Bug bootstrap/33070] Bootstrap comparison failure between stage2/3 but no objdump differences

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
No feedback in over 4 years so closing.

[Bug bootstrap/23198] AC_PROG_INSTALL (autoconf 2.13) does not detect bad install program

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Andrew Pinski  ---
No feedback in over 4 years so closing.

[Bug pending/55996] [meta-bug] GCC 4.9 pending patches

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
.

[Bug driver/63869] gcc-4.9.2 make failed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-07
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does this work now?

Also can you supply the exact command sequence you used to configure/invoke
make?

[Bug driver/26686] ../../../gcc/libgfortran/mk-kinds-h.sh: Unknown type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-07
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Does this work now?

[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit), at least with MacPorts

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-07
 Ever confirmed|0   |1

--- Comment #11 from Andrew Pinski  ---
Does this happen with newer versions of GCC?

[Bug driver/56244] -O3 should imply -funroll-loops

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
No longer working on it.  It was suggested unrolling should be not be used in
itself but rather a tool for other passes to use it.

[Bug driver/58505] jv-convert fails to compile with gcj-4.8.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
Won't fix java has been removed from GCC 7.

[Bug fortran/77885] ICE in gfc_add_class_array_ref, at fortran/class.c:259

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.0

--- Comment #1 from Martin Liška  ---
Confirmed, 4.7.x accepts the code.

[Bug fortran/77884] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, however I can see ICEs on all releases that support -fcoarray
(4.7.0+).

[Bug web/32927] Online installation instructions only for mainline

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||schnetter at gmail dot com

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

[Bug web/53919] Version-specific install instructions not available

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #12 from Andrew Pinski  ---
Dup of bug 32927.

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

[Bug web/45778] Append summary information instead of prepending the information

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> I like the fact that the bugzilla URL is topmost, that no longer requires
> me scrolling down.

Me too.  I was looking at older emails from bugzilla and compared them to the
newer ones, I had harder time dealing with the olders.  Note this was just
recently I have been looking at ones older than 2010.

[Bug c/69356] compound literals for scalar types are still lvalues unlike casts

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
Summary|Wrong description of|compound literals for
   |compound literals for   |scalar types are still
   |scalar types|lvalues unlike casts
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Christian Brauner from comment #0)
> In section 6.26 Compound Literals of the gcc manual it is stated that
> 
> "Compound literals for scalar types and union types are also allowed, but
> then the compound literal is equivalent to a cast."
> 
> Which is either wrong or at least misleading. A cast does not yield an
> lvalue 

It did in older versions of GCC as an extension (maybe undocumented).  So I
suspect when that extension was removed; this wording was not changed.

[Bug c/69356] Wrong description of compound literals for scalar types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/onlined |
   |ocs/gcc/Compound-Literals.h |
   |tml |
  Component|web |c

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html

[Bug c/77883] ice with -Wall flag

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from David Binderman  ---
(In reply to Richard Biener from comment #3)
> Me neither.

I tried again with a later copy of gcc trunk (revision 240853)
and am not able to reproduce here.

My apologies for wasting your times. I've reported over 300 bugs
in gcc over the last six years and this is one of very few false reports.

[Bug sanitizer/77891] Signed overflow sanitizer doesn't catch multiplication overflows due to promotion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
(In reply to Andrew Pinski from comment #1)
> Convert.c comes into play again.

In particular its "premature" optimization performing narrowing of the
integer multiplication to unsigned short multiplication.

[Bug middle-end/77889] missing optimization on strlen(p + offset) with a bounded offset

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
So you are complaining that VRP doesn't compute a range for n?  Because I can't
see the tree-ssa-strlen pass computing ranges.

Confirmed for VRP.  It seems to ignore most builtins completely.

unsigned f (int i)
{
  if (i >= 0 && i < 2)
{
  const char *p = "abc";
  p += i;
  return __builtin_strlen (p);
}
  return 0;
}

Found new range for _2: [0, 1]
marking stmt to be not simulated again

Visiting statement:
p_6 = "abc" + _2;
Found new range for p_6: VARYING

Visiting statement:
_3 = __builtin_strlen (p_6);
Found new range for _3: VARYING


p_6 would be [&"abc", &"abc"+1] not sure if we have a useful way to represent
it.  I guess ["abc"], ["abc" + 1] with the same _CST would be
it.

[Bug testsuite/67958] The tests changed by r223498 now FAILs on darwin

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---

On Darwin, PIE implies PIC (all executables that can be PIE are 'dynamic') -
(the case of mdynamic-no-pic is not combinable with pie).

so, on Darwin, the output of -1 should be the same as -2; (likewise -3 & -4; -5
& -6; -7 & -8).

So, for 1,3,5,7 the current tests could be conditionalised on ! *-*-darwin* and
the checks from 2,4,6,8 copied in and made conditional on *-*-darwin*.

[Bug c/77883] ice with -Wall flag

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-07
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Me neither.

[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Oct  7 07:44:47 2016
New Revision: 240854

URL: https://gcc.gnu.org/viewcvs?rev=240854=gcc=rev
Log:
2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.0 |5.5

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar (will backport - this is a latent issue in other ways as
well).