[Bug rtl-optimization/79125] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Arseny Solokha  ---
aqluuplt.c: In function 'hl':
aqluuplt.c:32:1: error: in basic block 2:
 }
 ^
aqluuplt.c:32:1: error: flow control insn inside a basic block
(insn 79 22 78 2 (trap_if (const_int 1 [0x1])
(const_int 0 [0])) 824 {trap}
 (nil))
aqluuplt.c:32:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.c:2661
0x3174763ed05 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/rtl-error.c:108
0x317472018c7 rtl_verify_bb_insns
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/cfgrtl.c:2661
0x317472018c7 rtl_verify_flow_info_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/cfgrtl.c:2747
0x317471eda1d verify_flow_info()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/cfghooks.c:258
0x317475c8161 execute_function_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/passes.c:1977
0x317475c8fab execute_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/passes.c:2015

[Bug rtl-optimization/79125] New: [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[asolokha at gmx dot com]

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

Bug ID: 79125
   Summary: [7 Regression] ICE in rtl_verify_bb_insns, at
cfgrtl.c:2661 (error: flow control insn inside a basic
block)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20170115 snapshot ICEs when compiling the following snippet w/
-O2 or -O3:

int za;

void
hl (void)
{
  short int o8 = 0;
  short int m6 = 1;
  short int *ni = 

  for (;;)
{
  int af;
  short int *fd = (short int *)

  if (ni != 0)
{
  if (m6 != 0)
*ni = 0;
  else
za = 0;
  af = (o8 * o8) || o8;
  if (af == 0)
m6 /= 0;
  while (za != 0)
{
}
}
  *fd = 
  for (af = 0; af < 2; ++af)
af = za;
}
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20170115 -O2 -w -c aqluuplt.c

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
See also PR29838.

[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode

[tschwinge at gcc dot gnu.org]

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

--- Comment #12 from Thomas Schwinge  ---
See also PR78875.

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
So, just to record some thoughts.

There's about a half-dozen patches, mostly from the August timeframe that will
make this bug go latent.  The general theme across them is they change the
order in which we visit statements in sccvn/vrp, twiddle the set of SSA_NAMEs
live ever so slightly prior to ccp & vrp or avoid setting ranges to names that
we're going to full propagate away.

The last has been the most fruitful in terms of starting to understand what's
going on.  Essentially by avoiding setting ranges on SSA_NAMES we're going to
propagate away in evrp, we're changing the behavior of ccp!  That (of course)
doesn't seem right.

I do know that we end up equating two SSA_NAMEs in the sccvn code.  It
*appears* that we don't undo the sharing of range info between them.  EVRP
comes along and stomps on the (now shared) range info (particularly the mask
used by bitcpp).  That in turn appears to be causing bitcpp to incorrectly
simplify some integer arithmetic that presumably causes things to go awry
later.

I'm going to try and reduce the testcase tomorrow looking for the dump file
differences in ccp2.  While that won't produce a working executable, it ought
to make the analysis phase of how/why we're sharing range info, why the info
gets overwritten, etc a bit easier to follow (not to mention faster).

Anyway, just recording thoughts from last night's late debugging session.

[Bug c++/79124] New: Internal compiler error under certain cases where __attribute__((target("avx2"))) presents

[weiming at megvii dot com]

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

Bug ID: 79124
   Summary: Internal compiler error under certain cases where
__attribute__((target("avx2"))) presents
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weiming at megvii dot com
  Target Milestone: ---

Created attachment 40532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40532=edit
The failed code snippet

Compiling the attached code snippet can trigger an internal compiler error.
Note that -mavx2 option is not passed through the command line; instead, we use
__attribute__((target("avx2"))) to enable avx2 support for the designated
function.

Command line:
g++-5 main.cpp -O2 -g -Wall -Wextra

Output:
main.cpp: In function ‘__m256 log256_ps(__m256)’:
main.cpp:4:8: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5118
 __m256 log256_ps(__m256 x)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output of g++-v:
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-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 5.4.1 20161202 (Debian 5.4.1-4)

[Bug go/79122] go test -race reports import cycles with gccgo

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
Note that the race detector doesn't work at all with gccgo.  So while this is a
pretty bad error message, the only fix for this bug is going to be to produce a
better error message.

[Bug middle-end/79123] New: incorrect -Walloca-larger-than: alloca may be too large due to conversion from long int to long unsigned int

[msebor at gcc dot gnu.org]

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

Bug ID: 79123
   Summary: incorrect -Walloca-larger-than: alloca may be too
large due to conversion from long int to long unsigned
int
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Walloca-larger-than option issues an incorrect/misleading warning for the
following valid test case.

I think there are two problems here: one is that the range information isn't
available for the alloca argument, and the other is the false positive warning
pointing the finger at the conversion.  The latter seems to be caused by the
cast_from_signed_p() function in gimple-ssa-warn-alloca.c being based solely on
the type of the right hand side expression of a SSA_NAME_DEF_STMT without
considering that the SSA_NAME may be subsequently bounded.

$ cat z.C && gcc -O2 -S -Walloca-larger-than=100 -xc
-fdump-tree-vrp=/dev/stdout z.C
typedef __SIZE_TYPE__ size_t;

void f (void*);

void g (int *p, int *q)
{
  size_t n = (size_t)(p - q);

  if (n < 10)
f (__builtin_alloca (n));
}

...
z.C: In function ‘g’:
z.C:10:5: warning: argument to ‘alloca’ may be too large due to conversion from
‘long int’ to ‘long unsigned int’ [-Walloca-larger-than=]
 f (__builtin_alloca (n));
 ^~~~

;; Function g (g, funcdef_no=0, decl_uid=1799, 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 }
;; 4 succs { 1 }

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

n_13 -> { n_9 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 5
Number of blocks to update: 2 ( 40%)



Value ranges after VRP:

p.0_1: VARYING
q.1_2: VARYING
_3: VARYING
_4: [-2305843009213693952, 2305843009213693951]
_5: ~[0B, 0B]
.MEM_6: VARYING
p_7(D): VARYING
q_8(D): VARYING
n_9: ~[2305843009213693952, 16140901064495857663]
n_13: [0, 9]  EQUIVALENCES: { n_9 } (1 elements)


g (int * p, int * q)
{
  size_t n;
  long int p.0_1;
  long int q.1_2;
  long int _3;
  long int _4;
  void * _5;

   [100.00%]:
  p.0_1 = (long int) p_7(D);
  q.1_2 = (long int) q_8(D);
  _3 = p.0_1 - q.1_2;
  _4 = _3 /[ex] 4;
  n_9 = (size_t) _4;
  if (n_9 <= 9)
goto ; [36.64%]
  else
goto ; [63.36%]

   [36.64%]:
  _5 = __builtin_alloca (n_9);
  f (_5);

   [100.00%]:
  return;

}

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #8 from Michael Meissner  ---
Fixed in subversion ids 244386 and 244561.

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Author: meissner
Date: Wed Jan 18 00:35:29 2017
New Revision: 244561

URL: https://gcc.gnu.org/viewcvs?rev=244561=gcc=rev
Log:
2017-01-17  Michael Meissner  

PR target/79004
* gcc.target/powerpc/pr79004.c: Add -mfloat128 to the test
options.  Fix up the syntax for using \m and \M.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr79004.c

[Bug target/79112] [SH] libgo/go/exp/terminal/util.go:70:23: error: integer constant overflow

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
It seems that the error message says all.  TIOCGWINSZ is defined as

#define TIOCGWINSZ0x80087468  /* _IOR('t', 104, struct winsize) */

in the SH kernel header asm/ioctls.h.  Perhaps you could change it to

#define TIOCGWINSZ (int)0x80087468 /* _IOR('t', 104, struct winsize) */

so to avoid that error.  I'm not sure that this is go problem or
usual SH kernel header problem.  And I'm not sure that go can work
well on SH even if it can be built.  I guess 32-bit ports without
split stack can run small go applications only.  The patch is welcome,
of course.

[Bug go/79122] go test -race reports import cycles with gccgo

[aconway at redhat dot com]

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

--- Comment #1 from Alan  ---
Reported as:
https://github.com/golang/go/issues/18696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79122

[Bug go/79122] New: go test -race reports import cycles with gccgo

[aconway at redhat dot com]

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

Bug ID: 79122
   Summary: go test -race reports import cycles with gccgo
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: aconway at redhat dot com
CC: cmang at google dot com
  Target Milestone: ---

### What version of Go are you using (`go version`)?
go version go1.6.1 gccgo (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) linux/amd64

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/aconway/go:/home/aconway/proton/proton-c/bindings/go"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/libexec/gcc/x86_64-redhat-linux/6.3.1"
GO15VENDOREXPERIMENT="1"
CC="/usr/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="/usr/bin/g++"
CGO_ENABLED="1"

### What did you do?
Create a package "tmp" containing a single "tmp.go" source file with one line:
`package tmp`
go test -race tmp

### What did you expect to see?
go test -race tmp
?   tmp [no test files]

### What did you see instead?
go test -race tmp
import cycle not allowed
package tmp
imports runtime
imports runtime/internal/atomic
imports runtime/race
imports syscall
imports internal/race
imports runtime/race

I do not have this  problem if I use golang's go compiler, only with gccgo. I
can see the problem on a real codebase, but the above reproducer shows it
doesn't require any actual code to exhibit the problem, in particular you don't
need `import "runtime"`. 

I have been seeing this problem since Go 1.4. I'm not sure whether it is a gcc
problem or a go tools problem, I am reporting on both sites.

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #16 from seurer at gcc dot gnu.org ---
One of the new tests fails on powerpc (both LE and BE):

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/pr77445-2.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2
-fdump-tree-thread1-details-blocks-stats -S   -o pr77445-2.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/pr77445-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-thread1-details-blocks-stats -S -o pr77445-2.s
PASS: gcc.dg/tree-ssa/pr77445-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr77445-2.c scan-tree-dump thread1 "Jumps threaded: 16"
PASS: gcc.dg/tree-ssa/pr77445-2.c scan-tree-dump-times thread1 "Invalid sum" 2
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
completed in 0 seconds

=== gcc Summary ===

# of expected passes2
# of unexpected failures1

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Tue Jan 17 22:02:42 2017
New Revision: 244556

URL: https://gcc.gnu.org/viewcvs?rev=244556=gcc=rev
Log:
-mstack-protector-guard and friends (PR78875)

Currently, on PowerPC, code compiled with -fstack-protector will load
the canary from -0x7010(13) (for -m64) or from -0x7008(2) (for -m32)
if GCC was compiled against GNU libc 2.4 or newer or some other libc
that supports -fstack-protector, and from the global variable
__stack_chk_guard otherwise.

This does not work well for Linux and other OS kernels and similar.
For such non-standard applications, this patch creates a few new
command-line options.  The relevant new use cases are:

-mstack-protector-guard=global
Use the __stack_chk_guard variable, no matter how this GCC was
configured.

-mstack-protector-guard=tls
Use the canary from TLS.  This will error out if this GCC was built
with a C library that does not support it.

-mstack-protector-guard=tls -mstack-protector-register=
-mstack-protector-offset=
Load the canary from offset  from base register .


PR target/78875
* config/rs6000/rs6000-opts.h (stack_protector_guard): New enum.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Handle
the new options.
* config/rs6000/rs6000.md (stack_protect_set): Handle the new more
flexible settings.
(stack_protect_test): Ditto.
* config/rs6000/rs6000.opt (mstack-protector-guard=,
mstack-protector-guard-reg=, mstack-protector-guard-offset=): New
options.
* doc/invoke.texi (Option Summary) [RS/6000 and PowerPC Options]:
Add -mstack-protector-guard=, -mstack-protector-guard-reg=, and
-mstack-protector-guard-offset=.
(RS/6000 and PowerPC Options): Ditto.

gcc/testsuite/
* gcc.target/powerpc/ssp-1.c: New testcase.
* gcc.target/powerpc/ssp-2.c: New testcase.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-opts.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/rs6000.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug debug/78839] [6 Regression] DWARF output different between GCC 5 and 6

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:34:58 2017
New Revision: 244555

URL: https://gcc.gnu.org/viewcvs?rev=244555=gcc=rev
Log:
PR debug/78839
* dwarf2out.c (field_byte_offset): Restore the
PCC_BITFIELD_TYPE_MATTERS behavior for INTEGER_CST DECL_FIELD_OFFSET
and DECL_FIELD_BIT_OFFSET.  Use fold_build2 instead of build2 + fold.
(analyze_variants_discr, gen_variant_part): Use fold_build2 instead
of build2 + fold.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/dwarf2out.c

[Bug libstdc++/69600] [5 Regression] Incorrect use of copy-assignment instead of move assignment from function

[sshannin at gmail dot com]

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

--- Comment #6 from sshannin at gmail dot com ---
Thanks for the update : )

[Bug c++/78341] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_parser_std_attribute_spec, at cp/parser.c:24597)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:34:17 2017
New Revision: 244554

URL: https://gcc.gnu.org/viewcvs?rev=244554=gcc=rev
Log:
Backported from mainline
2017-01-11  Jakub Jelinek  

PR c++/78341
* parser.c (cp_parser_std_attribute_spec): Remove over-eager
assertion.  Formatting fix.

* g++.dg/cpp0x/pr78341.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/pr78341.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/50199] [5/6 Regression] wrong code with -flto -fno-merge-constants

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:33:16 2017
New Revision: 244553

URL: https://gcc.gnu.org/viewcvs?rev=244553=gcc=rev
Log:
Backported from mainline
2017-01-11  Jakub Jelinek  

PR middle-end/50199
* lto-lang.c (lto_post_options): Force flag_merge_constants = 1
if it was 0.

* gcc.dg/lto/pr50199_0.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr50199_0.c
Modified:
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto-lang.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/78949] incorrect "unused variable" warning with SSE2

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:32:27 2017
New Revision: 244552

URL: https://gcc.gnu.org/viewcvs?rev=244552=gcc=rev
Log:
Backported from mainline
2017-01-04  Jakub Jelinek  

PR c++/78949
* typeck.c (cp_build_unary_op): Call mark_rvalue_use on arg if it has
vector type.

* c-c++-common/Wunused-var-16.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/Wunused-var-16.c
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/typeck.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/78693] [6 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:31:40 2017
New Revision: 244551

URL: https://gcc.gnu.org/viewcvs?rev=244551=gcc=rev
Log:
Backported from mainline
2017-01-04  Jakub Jelinek  

PR c++/78693
* parser.c (cp_parser_simple_declaration): Only complain about
inconsistent auto deduction if auto_result doesn't use auto.

* g++.dg/cpp0x/pr78693.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/pr78693.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71182] [6 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:30:25 2017
New Revision: 244550

URL: https://gcc.gnu.org/viewcvs?rev=244550=gcc=rev
Log:
Backported from mainline
2017-01-04  Jakub Jelinek  

PR c++/71182
* parser.c (cp_lexer_previous_token): Use vec_safe_address in the
assertion, as lexer->buffer may be NULL.

* g++.dg/cpp0x/pr71182.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/pr71182.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 20:29:19 2017
New Revision: 244549

URL: https://gcc.gnu.org/viewcvs?rev=244549=gcc=rev
Log:
Backported from mainline
2016-12-21  Jakub Jelinek  

PR fortran/78866
* openmp.c (resolve_omp_clauses): Diagnose assumed size arrays in
OpenMP map, to and from clauses.
* trans-openmp.c: Include diagnostic-core.h, temporarily redefining
GCC_DIAG_STYLE to __gcc_tdiag__.
(gfc_omp_finish_clause): Diagnose implicitly mapped assumed size
arrays.

* gfortran.dg/gomp/map-1.f90: Add expected error.
* gfortran.dg/gomp/pr78866-1.f90: New test.
* gfortran.dg/gomp/pr78866-2.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr78866-1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr78866-2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/openmp.c
branches/gcc-6-branch/gcc/fortran/trans-openmp.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/map-1.f90

[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
That's right.  I believe printing the contents of the translation unit and not
even opening the files referenced by the #line directives in it like Clang does
is the expected and correct behavior.  Not just to avoid printing the contents
of unrelated files but to print the contents at all.  When the local header
referenced from the translation unit isn't a close match to what is in the TU
GCC won't print any context in the diagnostics.  I don't know what all it
considers to decide.

I'm not at all familiar with the GCC preprocessor implementation so I have no
idea how feasible it is to change it to behave that way.

[Bug c++/78488] [7 Regression] P0136R1 ICE when building call to inherited default constructor.

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Now we get seg fault

[Bug driver/69361] Nonsensical suggestion for misspelled command-line option "-help"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
More recent gcc (e.g. today's) is saner:

$ gcc -help
gcc: error: unrecognized command line option ‘-h’
gcc: fatal error: no input files
compilation terminated.

In particular, it doesn't print the bogus suggestion, presumably due to
r242965.

Closing this one out.

[Bug c++/62314] Fix-it Hints

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #9 from David Malcolm  ---
(In reply to David Malcolm from comment #4)
> Keeping this bug open, since it has lots of examples of fix-it hints that we
> could provide.

Closing this one out; other ideas for fix-it hints should be tracked
individually as separate bugs.

[Bug c++/71497] Warning text for -Wmisleading-indentation

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed in trunk by r244536; marking as resolved.

[Bug c++/78469] [7 Regression] defaulted default constructor causes bogus requirement for accessible destructor

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/77629] [7 Regression] internal compiler error: same canonical type node for different types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Nathan Sidwell  ---
duplicate.  These two bugs seem to point to each other

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

[Bug c++/69481] ICE with C++11 alias using with templates

[nathan at gcc dot gnu.org]

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

--- Comment #15 from Nathan Sidwell  ---
*** Bug 77629 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/79121] [6/7 Regression] invalid expansion of sign-extend unsigned plus left shift

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-17
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from wilco at gcc dot gnu.org ---
Confirmed. This also fails on 64-bit targets, eg. on AArch64:

__int128 f2(unsigned long x) { return (__int128)x << 4; }

mov x1, x0
lsl x0, x0, 4
asr x1, x1, 60
ret

[Bug c++/77629] [7 Regression] internal compiler error: same canonical type node for different types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to amker from comment #9)
> Root cause should be in VRP, looks like the iterative algorithm depends on
> order of ssa operands and computes different range.

Testing a patch, though is kind of a workaround.

[Bug fortran/78983] [7 Regression] ICE with CAF-DT with allocatable member

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #3 from Damian Rouson  ---
Here's a simpler demonstration of two problems this bug report identifies:

module node_module
  implicit none
  type node
integer, allocatable :: storage
  end type
contains
  subroutine reallocate_node_storage(some_node)
type(node) :: some_node
allocate(some_node%storage)  ! needs to generate a call to caf_register
  end subroutine
end module

module caf_module
  use node_module
  type caf
type(node), allocatable :: array[:]
  end type
contains
  subroutine allocate_storage(this)
class(caf) :: this
allocate(this%array[*]) !ICE: no token member initialized for node storage
call reallocate_node_storage(this%array)
  end subroutine
end module

[Bug rtl-optimization/79121] [6/7 Regression] invalid expansion of sign-extend unsigned plus left shift

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|[6, 7 regression] invalid   |[6/7 Regression] invalid
   |expansion of sign-extend|expansion of sign-extend
   |unsigned plus left shift|unsigned plus left shift

[Bug target/78478] Compile Error for i386-rtems

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
The problem is config/i386/rtemself.h has

#define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)

XFmode isn't available with -msoft-float even when -mlong-double-80 is used.
IA MCU defaults long double to double and XFmode is available with
-mlong-double-80.

[Bug rtl-optimization/79121] New: [6, 7 regression] invalid expansion of sign-extend unsigned plus left shift

[rearnsha at gcc dot gnu.org]

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

Bug ID: 79121
   Summary: [6, 7 regression] invalid expansion of sign-extend
unsigned plus left shift
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
CC: jiwang at gcc dot gnu.org
  Target Milestone: ---
Target: arm-* mips-*

In the following, the conversion to long long requires a zero extend, however
the expanders use an arithmetic right shift to generate the high-part word.

long long dohash(unsigned x) {
return ((long long)x) << 4;
}

On ARM this generates 

mov r1, r0
lsl r0, r0, #4
asr r1, r1, #28   // Should be lsr
bx  lr

Similarly on MIPS:

sll $3,$4,4
.setnoreorder
.setnomacro
jr  $31
sra $2,$4,28// should be srl


Possibly introduced by this patch:
r227018 
Author: jiwang 
Date:   Wed Aug 19 22:55:28 2015 +

[Patch][expand] Check gimple statement to improve LSHIFT_EXP expand

This patch improves LSHIFT_EXP expand if the shift operand comes from sign
extension and the shift result across word_mode_size boundary. See code
comments for details.

2015-08-19  Jiong.Wang  

gcc/
  * expr.c (expand_expr_real_2): Check gimple statement during
  LSHIFT_EXPR expand.

[Bug bootstrap/79052] bootstrap-ubsan failures due to warnings

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Here's a complete set of warnings from a bootstrap configured with
--with-build-config=bootstrap-ubsan and --disable-werror.  I think GCC builds
libraries without -Werror so those are probably not causing any trouble.  I
don't know what else it builds without it.  Those might be worth reviewing. 
I'll try to look into the -Wformat-{truncation,overflow}, -Wnonnull, and
-Walloc-size-larger-than instances when I have a chance.

DiagnosticCount   UniqueFiles
-Wmaybe-uninitialized   327   82   41
-Wimplicit-fallthrough=  58   114
-Wunused-parameter   2032
-Wimplicit-function-declaration  1852
-Wformat-truncation= 1453
-Wunused-but-set-variable1232
-Wnonnull1242
-Wformat-overflow=844
-Wsign-compare633
-Wcpp 411
-Wstringop-overflow=  211
-Walloc-size-larger-than= 211

-Walloc-size-larger-than Instances: 
  gcc/../include/libiberty.h:356

-Wcpp Instances: 
  /usr/include/features.h:148

-Wformat-overflow Instances: 
  gcc/ada/env.c:193
  gcc/c/c-typeck.c:7022
  gcc/c-family/c-cppbuiltin.c:848
  gcc/stmt.c:670

-Wformat-truncation Instances: 
  libgfortran/intrinsics/date_and_time.c:165
  libgfortran/intrinsics/date_and_time.c:168
  libgfortran/intrinsics/date_and_time.c:172
  libiberty/simple-object-coff.c:571
  libiberty/simple-object-xcoff.c:655

-Wimplicit-fallthrough Instances: 
  gengtype-lex.c:365
  libgcc/soft-fp/op-common.h:900
  libgcc/soft-fp/op-common.h:913
  libgcc/soft-fp/soft-fp.h:213
  libgfortran/io/list_read.c:1032
  libgfortran/io/list_read.c:1400
  libgfortran/io/list_read.c:1523
  libgfortran/io/list_read.c:1645
  libgfortran/io/list_read.c:1704
  libgfortran/io/list_read.c:851
  libgfortran/io/list_read.c:974

-Wimplicit-function-declaration Instances: 
  libmpx/mpxrt/mpxrt.c:255
  socket.c:127
  socket.c:137
  socket.c:147
  socket.c:155

-Wmaybe-uninitialized Instances: 
  g-comlin.adb:583
  g-debpoo.adb:1418
  gcc/ada/atree.adb:2568
  gcc/ada/checks.adb:8117
  gcc/ada/checks.adb:8326
  gcc/ada/checks.adb:8414
  gcc/ada/exp_attr.adb:1342
  gcc/ada/exp_attr.adb:1413
  gcc/ada/exp_ch4.adb:4026
  gcc/ada/exp_ch7.adb:8289
  gcc/ada/exp_ch7.adb:8686
  gcc/ada/exp_ch7.adb:8866
  gcc/ada/exp_ch9.adb:3292
  gcc/ada/exp_ch9.adb:6147
  gcc/ada/exp_ch9.adb:9955
  gcc/ada/exp_disp.adb:1060
  gcc/ada/exp_disp.adb:1561
  gcc/ada/exp_disp.adb:1577
  gcc/ada/exp_disp.adb:1687
  gcc/ada/exp_disp.adb:5186
  gcc/ada/exp_dist.adb:10036
  gcc/ada/exp_dist.adb:1533
  gcc/ada/exp_dist.adb:1538
  gcc/ada/exp_dist.adb:1555
  gcc/ada/exp_dist.adb:1574
  gcc/ada/freeze.adb:1177
  gcc/ada/inline.adb:3471
  gcc/ada/par-ch3.adb:3854
  gcc/ada/par-ch9.adb:125
  gcc/ada/par-ch9.adb:471
  gcc/ada/put_spark_xrefs.adb:167
  gcc/ada/put_spark_xrefs.adb:174
  gcc/ada/sem.adb:760
  gcc/ada/sem_aggr.adb:4651
  gcc/ada/sem_case.adb:488
  gcc/ada/sem_ch12.adb:13652
  gcc/ada/sem_ch12.adb:4678
  gcc/ada/sem_ch12.adb:5692
  gcc/ada/sem_ch13.adb:13421
  gcc/ada/sem_ch13.adb:13450
  gcc/ada/sem_ch13.adb:1842
  gcc/ada/sem_ch13.adb:6674
  gcc/ada/sem_ch3.adb:6515
  gcc/ada/sem_ch4.adb:1070
  gcc/ada/sem_ch4.adb:1489
  gcc/ada/sem_ch4.adb:400
  gcc/ada/sem_ch4.adb:8937
  gcc/ada/sem_ch5.adb:1446
  gcc/ada/sem_ch5.adb:2174
  gcc/ada/sem_ch6.adb:1140
  gcc/ada/sem_ch6.adb:445
  gcc/ada/sem_ch9.adb:3527
  gcc/ada/sem_ch9.adb:651
  gcc/ada/sem_ch9.adb:692
  gcc/ada/sem_ch9.adb:835
  gcc/ada/sem_disp.adb:772
  gcc/ada/sem_eval.adb:2334
  gcc/ada/sem_eval.adb:6699
  gcc/ada/sem_intr.adb:170
  gcc/ada/sem_prag.adb:10786
  gcc/ada/sem_prag.adb:27743
  gcc/ada/sem_prag.adb:5671
  gcc/ada/sem_res.adb:1520
  gcc/ada/sem_res.adb:4679
  gcc/ada/sem_util.adb:15639
  gcc/ada/sem_util.adb:15640
  gcc/ada/sem_util.adb:2814
  gcc/ada/sem_util.adb:9838
  gcc/ada/xref_lib.adb:1039
  gcc/ada/xref_lib.adb:1143
  gcc/ada/xref_lib.adb:770
  gcc/ada/xr_tabls.adb:1015
  gcc/ada/xr_tabls.adb:1065
  gcc/fortran/error.c:1084
  libsanitizer/asan/asan_interceptors.cc:57
  libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2746
  libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2795
  libsanitizer/sanitizer_common/sanitizer_posix.cc:213
  libsanitizer/tsan/tsan_interceptors.cc:2185
  libsanitizer/ubsan/ubsan_handlers_cxx.cc:109
  s-stoele.adb:82
  s-stusta.adb:228

-Wnonnull Instances: 
  adaint.c:2837
  adaint.c:2839
  gcc/ada/adaint.c:2837
  gcc/ada/adaint.c:2839

-Wsign-compare Instances: 
  gcc/config/i386/i386.c:12415
  gcc/dwarf2out.c:2060
  gcc/varasm.c:2703

-Wstringop-overflow Instances: 
  gcc/ada/adaint.c:3405

-Wunused-but-set-variable 

[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.8.5
Version|unknown |7.0
Summary|std::search with binary |[5/6/7 Regression]
   |comparison predicate uses   |std::search with binary
   |invalid reference   |comparison predicate uses
   ||invalid reference
  Known to fail||4.9.4, 5.4.0, 6.3.0, 7.0

--- Comment #3 from Jonathan Wakely  ---
Actually, std::includes() doesn't use the problematic function objects that
store a reference, so there's no bug.

We do have a regression for this standalone testcase, which violates the
ForwardIterator requirements, but worked previously:

#include 

struct bad_iterator
{
  typedef std::forward_iterator_tag iterator_category;
  typedef int value_type;
  typedef value_type const* pointer;
  typedef value_type const& reference;
  typedef std::ptrdiff_t difference_type;

  bad_iterator() : ptr(), stash() { }
  bad_iterator(pointer p) : ptr(p), stash() { update(); }
  bad_iterator(const bad_iterator& i) : ptr(i.ptr), stash() { update(); }
  ~bad_iterator() { ptr = 0; update(); }

  bad_iterator& operator=(const bad_iterator& i)
  {
ptr = i.ptr;
update();
return *this;
  }

  bad_iterator& operator++() { ++ptr; update(); return *this; }
  bad_iterator operator++(int) { bad_iterator i = *this; ++*this; return i; }
  reference operator*() const { return *stash; }
  pointer operator->() const { return stash; }

  bool operator==(const bad_iterator& i) const { return ptr == i.ptr; }
  bool operator!=(const bad_iterator& i) const { return !(*this == i); }

private:
  void update()
  {
#ifdef VALID_FWD_ITER
stash = ptr;
#else
pointer p = 0;
if (ptr)
  p = new value_type(*ptr);
delete stash;
stash = p;
#endif
  }

  pointer ptr;
  pointer stash;
};

int main() {
  int s[] = { 0, 1, 2, 3, 4, 5 };
  std::search(s, s+3, bad_iterator(s), bad_iterator(s+4));
}

This stopped working with GCC 4.9.0 when we added the __iter_comp_iter stuff
that stores the reference.

Technically this is invalid, but I think we can support it without too much
difficulty. That's reasonable given that std::filesystem::path::iterator also
violates the ForwardIterator requirements, and the Ranges TS removes the
reference-quality requirement anyway.

[Bug sanitizer/79096] [7 Regression] address sanitizer and jni does not work

[physiker at toast2 dot net]

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

--- Comment #2 from physiker at toast2 dot net ---
> Am 16.01.2017 um 15:18 schrieb m.ostapenko at samsung dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096
> 
> Maxim Ostapenko  changed:
> 
>   What|Removed |Added
> 
> CC||m.ostapenko at samsung dot com
> 
> --- Comment #1 from Maxim Ostapenko  ---
> Not sure it really worked, because dlopening ASan'ed library from 
> non-sanitized
> binary without preloading libasan is a bad idea. For GCC versions 5 and 6 
> there
> wasn't any check against this for Darwin, GCC 7 pulled it with last
> libsanitizer merge from LLVM (corresponding commit in LLVM:
> http://reviews.llvm.org/D18212). Have you tried to compile your library with
> clang btw?
> 

For previous version of gcc setting DYLD_INSERT_LIBRARIES is not necessary.
Setting DYLD_INSERT_LIBRARIES as suggested for current versions of gcc 7 on the
x86_64-apple-darwin15.6.0 target does not solve the issue. On linux, preloading
libasan has always been necessary for getting the example to work. I do not
know how to successfully preload libasan on darwin. It does not seem to work
for the version of clang shipped with the operating system (Apple LLVM version
8.0.0 (clang-800.0.42.1)), either:

gcc -v -dynamiclib -fPIC -fsanitize=address
-I/System/Library/Frameworks/JavaVM.framework/Headers libTasan.c -o
libTasan.jnilib -fno-inline -fno-omit-frame-pointer -g
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple
x86_64-apple-macosx10.11.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name libTasan.c
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 274.2 -v
-dwarf-column-info -debug-info-kind=standalone -dwarf-version=2
-debugger-tuning=lldb -resource-dir
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0 -I
/System/Library/Frameworks/JavaVM.framework/Headers -fdebug-compilation-dir
/Users/Peter/Devel/jni/asan -ferror-limit 19 -fmessage-length 75
-fsanitize=address
-fsanitize-blacklist=/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/asan_blacklist.txt
-fno-assume-sane-operator-new -stack-protector 1 -fblocks -fno-inline
-fobjc-runtime=macosx-10.11.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T/libTasan-2e658d.o -x c
libTasan.c
clang -cc1 version 8.0.0 (clang-800.0.42.1) default target
x86_64-apple-darwin15.6.0
#include "..." search starts here:
#include <...> search starts here:
 /System/Library/Frameworks/JavaVM.framework/Headers
 /usr/local/include
 /Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/include
 /Library/Developer/CommandLineTools/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
libTasan.c:7:3: warning: array index 10 is past the end of the array (which
  contains 10 elements) [-Warray-bounds]
  stack_array[10] = 0;
  ^   ~~
libTasan.c:6:3: note: array 'stack_array' declared here
  int stack_array[10];
  ^
1 warning generated.
 "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -dynamic -dylib
-arch x86_64 -macosx_version_min 10.11.0 -o libTasan.jnilib
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T/libTasan-2e658d.o
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
-rpath @executable_path -rpath
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/lib/darwin
-lc++abi -lSystem
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/lib/darwin/libclang_rt.osx.a
 "/Library/Developer/CommandLineTools/usr/bin/dsymutil" -o libTasan.jnilib.dSYM
libTasan.jnilib

bash-3.2$ java Tasan
==915==ERROR: Interceptors are not working. This may be because
AddressSanitizer is loaded too late (e.g. via dlopen). Please launch the
executable with:
DYLD_INSERT_LIBRARIES=/Library/Developer/CommandLineTools/usr/lib/clang/8.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
==915==AddressSanitizer CHECK failed:
/Library/Caches/com.apple.xbs/Sources/clang_compiler_rt/clang-800.0.42.1/src/projects/compiler-rt/lib/sanitizer_common/sanitizer_mac.cc:690
"(("interceptors not installed" && 0)) != (0)" (0x0, 0x0)


Abort trap: 6

bash-3.2$
DYLD_INSERT_LIBRARIES=/Library/Developer/CommandLineTools/usr/lib/clang/8.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
java Tasan
==918==ERROR: Interceptors are not working. 

[Bug target/78478] Compile Error for i386-rtems

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Joel Sherrill from comment #9)
> 
> > I could pursue this but is soft-float on the x86 target really worth the
> > investment of any effort? AFAIK we would be looking at a very old CPU at
> > this point. 
> > 
> > I only see soft-float listed as a multilib in t-rtems. 
> > 
> > Is there any reason to keep it? :)
> 
> Intel MCU probably trips at the same place. CC added.

IA MCU has

i[34567]86-*-elfiamcu)
tmake_file="$tmake_file i386/t-crtstuff t-softfp-sfdftf
i386/32/t-softfp
 i386/32/t-iamcu i386/t-softfp t-softfp t-dfprules"
;;

without any problems in libgcc.

[Bug bootstrap/79120] New: lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1747

[joel at gcc dot gnu.org]

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

Bug ID: 79120
   Summary: lm32 ICE in dwarf2out_frame_debug_expr, at
dwarf2cfi.c:1747
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Target: lm32-rtems
GCC git master: acb9fddd8093a3f623837ac25f6d50f52d9a80eb
Newlib git master: e02866a1b43fae39d6842bd182de79e54d8e74cd

The ICE occurs when compiling libgfortran.

libtool: compile:  /home/joel/test-gcc/b-lm32-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-lm32-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-lm32-rtems4.12-gcc/lm32-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-lm32-rtems4.12-gcc/lm32-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/lm32-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/lm32-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/lm32-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/lm32-rtems4.12/sys-include -DHAVE_CONFIG_H
-I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -ffast-math -ftree-vectorize -funroll-loops
--param max-unroll-times=4 -g -O2 -MT matmul_i1.lo -MD -MP -MF
.deps/matmul_i1.Tpo -c ../../../gcc/libgfortran/generated/matmul_i1.c -o
matmul_i1.o
../../../gcc/libgfortran/generated/matmul_i1.c: In function 'matmul_i1':
../../../gcc/libgfortran/generated/matmul_i1.c:2835:1: internal compiler error:
in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1747
 }
 ^
0x62fc69 dwarf2out_frame_debug_expr
../../gcc/gcc/dwarf2cfi.c:1745
0x630354 dwarf2out_frame_debug
../../gcc/gcc/dwarf2cfi.c:2119
0x630354 scan_insn_after
../../gcc/gcc/dwarf2cfi.c:2463
0x631f86 scan_trace
../../gcc/gcc/dwarf2cfi.c:2620
0x632b46 create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2659
0x632b46 execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:3022
0x632b46 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.
See  for instructions.

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

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

--- Comment #9 from Joel Sherrill  ---
See previous comment. Appears to be fixed.

[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  ---
We are using gcc 4.9.3 for RTEMS 4.11 and gcc 6.3.0 on RTEMS 4.12. This doesn't
happen on either GCC. So closing.

[Bug tree-optimization/79119] absolute value of a pointer difference can be assumed to be less than or equal to PTRDIFF_MAX

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/79119] New: absolute value of a pointer difference can be assumed to be less than or equal to PTRDIFF_MAX

[msebor at gcc dot gnu.org]

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

Bug ID: 79119
   Summary: absolute value of a pointer difference can be assumed
to be less than or equal to PTRDIFF_MAX
   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: ---

C and C++ guarantee that the difference between two pointers into the same
array must be representable in ptrdiff_t.  In addition, the absolute value of
the difference must be less than or equal to PTRDIFF_MAX / sizeof (T) where T
is the type of the array element.  The test case below shows that GCC doesn't
make use of the guarantee.  If it did, it should be able to determine that the
condition guarding the abort() statement in each of the functions below can
never evaluate to true.

$ cat t.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout t.c
void f (int *a, __SIZE_TYPE__ i, __SIZE_TYPE__ j)
{
  int *p = a + i;
  int *q = a + j;

  __SIZE_TYPE__ n = p < q ? q - p : p - q;

  if (n > __PTRDIFF_MAX__ / sizeof (int))
__builtin_abort ();
}

void g (int *a, __SIZE_TYPE__ i, __SIZE_TYPE__ j)
{
  int *p = a + i;
  int *q = a + j;

  __SIZE_TYPE__ n = p < q ? q - p : p - q;

  if (n > __PTRDIFF_MAX__)
__builtin_abort ();
}


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

f (int * a, long unsigned int i, long unsigned int j)
{
  int * q;
  int * p;
  long unsigned int _1;
  long unsigned int _2;
  long int _3;
  long int _4;
  long int _5;
  long int _6;
  long unsigned int iftmp.0_7;
  long unsigned int iftmp.0_13;
  long unsigned int iftmp.0_14;
  long int _21;
  long int _22;

   [100.00%]:
  _1 = i_8(D) * 4;
  p_10 = a_9(D) + _1;
  _2 = j_11(D) * 4;
  q_12 = a_9(D) + _2;
  _21 = (long int) _1;
  _22 = (long int) _2;
  if (p_10 < q_12)
goto ; [50.00%]
  else
goto ; [50.00%]

   [50.00%]:
  _3 = _22 - _21;
  _4 = _3 /[ex] 4;
  iftmp.0_14 = (long unsigned int) _4;
  goto ; [100.00%]

   [50.00%]:
  _5 = _21 - _22;
  _6 = _5 /[ex] 4;
  iftmp.0_13 = (long unsigned int) _6;

   [100.00%]:
  # iftmp.0_7 = PHI 
  if (iftmp.0_7 > 536870911)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1453, cgraph_uid=1, symbol_order=1)

g (int * a, long unsigned int i, long unsigned int j)
{
  int * q;
  int * p;
  long unsigned int _1;
  long unsigned int _2;
  long int _3;
  long int _4;
  long int _5;
  long int _6;
  signed int n.10_7;
  long unsigned int iftmp.5_8;
  long unsigned int iftmp.5_14;
  long unsigned int iftmp.5_15;
  long int _22;
  long int _23;

   [100.00%]:
  _1 = i_9(D) * 4;
  p_11 = a_10(D) + _1;
  _2 = j_12(D) * 4;
  q_13 = a_10(D) + _2;
  _22 = (long int) _1;
  _23 = (long int) _2;
  if (p_11 < q_13)
goto ; [50.00%]
  else
goto ; [50.00%]

   [50.00%]:
  _3 = _23 - _22;
  _4 = _3 /[ex] 4;
  iftmp.5_15 = (long unsigned int) _4;
  goto ; [100.00%]

   [50.00%]:
  _5 = _22 - _23;
  _6 = _5 /[ex] 4;
  iftmp.5_14 = (long unsigned int) _6;

   [100.00%]:
  # iftmp.5_8 = PHI 
  n.10_7 = (signed int) iftmp.5_8;
  if (n.10_7 < 0)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

}

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
The original preprocessed file started ICEing with -Wall -std=gnu++14 with 
r219268:

In file included from
/mnt/g/boostish/outcome/test/../include/boost/outcome/v1.0/monad.hpp:98:0,
 from
/mnt/g/boostish/outcome/test/../include/boost/outcome/outcome.hpp:15,
 from /mnt/g/boostish/outcome/test/unittests.cpp:41:
/mnt/g/boostish/outcome/test/../include/boost/outcome/v1.0/value_storage.hpp:181:123:
internal compiler error: in retrieve_specialization, at cp/pt.c:1050
0x713f4d retrieve_specialization
../../gcc/cp/pt.c:1047
0x762268 instantiate_template_1
../../gcc/cp/pt.c:15859
0x76293a instantiate_template(tree_node*, tree_node*, int)
../../gcc/cp/pt.c:15972
0x892805 finish_template_variable(tree_node*)
../../gcc/cp/semantics.c:2457
0x896b60 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc/cp/semantics.c:3570
0x7f02ed cp_parser_primary_expression
../../gcc/cp/parser.c:4766
0x7f2d8e cp_parser_postfix_expression
../../gcc/cp/parser.c:6120
0x7f5569 cp_parser_unary_expression
../../gcc/cp/parser.c:7401
0x7f60af cp_parser_cast_expression
../../gcc/cp/parser.c:8034
0x7f6148 cp_parser_binary_expression
../../gcc/cp/parser.c:8136
0x7f6892 cp_parser_assignment_expression
../../gcc/cp/parser.c:8378
0x7f6d28 cp_parser_constant_expression
../../gcc/cp/parser.c:8624
0x80941a cp_parser_initializer_clause
../../gcc/cp/parser.c:19288
0x8092b1 cp_parser_initializer
../../gcc/cp/parser.c:19229
0x805527 cp_parser_init_declarator
../../gcc/cp/parser.c:17192
0x811c3a cp_parser_single_declaration
../../gcc/cp/parser.c:23755
0x8111de cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:23550
0x7fe9c7 cp_parser_template_declaration
../../gcc/cp/parser.c:13199
0x80c68e cp_parser_member_declaration
../../gcc/cp/parser.c:20672
0x80c582 cp_parser_member_specification_opt
../../gcc/cp/parser.c:20599
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/78952] Combine does not convert 8-bit sign-extract to a zero-extract for QImode operations

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Note avr has an "any_extract" code_iterator for this.  That of course
is a crutch but could be a workaround for you for now.

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
Root cause should be in VRP, looks like the iterative algorithm depends on
order of ssa operands and computes different range.

[Bug debug/78839] [6 Regression] DWARF output different between GCC 5 and 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] DWARF  |[6 Regression] DWARF output
   |output different between|different between GCC 5 and
   |GCC 5 and 6 |6

--- Comment #13 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 18:32:13 2017
New Revision: 244545

URL: https://gcc.gnu.org/viewcvs?rev=244545=gcc=rev
Log:
PR debug/78839
* dwarf2out.c (field_byte_offset): Restore the
PCC_BITFIELD_TYPE_MATTERS behavior for INTEGER_CST DECL_FIELD_OFFSET
and DECL_FIELD_BIT_OFFSET.  Use fold_build2 instead of build2 + fold.
(analyze_variants_discr, gen_variant_part): Use fold_build2 instead
of build2 + fold.

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

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #25 from Nathan Sidwell  ---
Fixed.  We capture this if we find at least one non-static member function. 
This agrees with Clang's implementation, after discussion with Richard Smith.


Need to raise DR.

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

[nathan at gcc dot gnu.org]

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

--- Comment #24 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 17 18:22:34 2017
New Revision: 244544

URL: https://gcc.gnu.org/viewcvs?rev=244544=gcc=rev
Log:
PR c++/61636
* cp-tree.h (maybe_generic_this_capture): Declare.
* lambda.c (resolvable_dummy_lambda): New, broken out of ...
(maybe_resolve_dummy): ... here.  Call it.
(maybe_generic_this_capture): New.
* parser.c (cp_parser_postfix_expression): Speculatively capture
this in generic lambda in unresolved member function call.
* pt.c (tsubst_copy_and_build): Force hard error from failed
member function lookup in generic lambda.

PR c++/61636
* g++.dg/cpp1y/pr61636-1.C: New.
* g++.dg/cpp1y/pr61636-2.C: New.
* g++.dg/cpp1y/pr61636-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr61636-1.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr61636-2.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr61636-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/lambda.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/78346] std::search with binary comparison predicate uses invalid reference

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-01-17
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
There is a related bug though, because we make use of that __iter_comp_iter
helper function in the implementation if std::includes() which is required to
work with InputIterator arguments, so the ForwardIterator requirements don't
need to be met.

I have a fix ...

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #11 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #9)

> I could pursue this but is soft-float on the x86 target really worth the
> investment of any effort? AFAIK we would be looking at a very old CPU at
> this point. 
> 
> I only see soft-float listed as a multilib in t-rtems. 
> 
> Is there any reason to keep it? :)

Intel MCU probably trips at the same place. CC added.

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Ah, g++ 6 ICEs with -Wall.

[Bug libstdc++/78346] std::search with binary comparison predicate uses invalid reference

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to reagentoo from comment #0)
> boost::filesystem::path::iterator::dereference returns reference to a local
> member:

This means boost::filesystem::path::iterator fails to meet the ForwardIterator
requirements, see 24.2.5 [forward.iterators] paragraph 6 in the C++14 standard.

> http://melpon.org/wandbox/permlink/58aIbfJWeGgMKMdF
> 
> As a proposed solution, _Iter_equals_iter might store copy of iterator
> rather than dereferenced
> value.

That is not necessary for a type that meets the ForwardIterator requirements.

[Bug ada/67205] eliminate No_Implicit_Dynamic_Code restriction violations

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Botcazou  ---
The ARM patch is waiting for approval at:
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01254.html

[Bug ada/67205] eliminate No_Implicit_Dynamic_Code restriction violations

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Jan 17 18:02:55 2017
New Revision: 244543

URL: https://gcc.gnu.org/viewcvs?rev=244543=gcc=rev
Log:
PR ada/67205
* config/aarch64/aarch64.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Define

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug tree-optimization/70754] [5/6/7 Regression] ICE during predictive commoning

[vp at gcc dot gnu.org]

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

--- Comment #9 from Vidya Praveen  ---
(In reply to Martin Liška from comment #8)
> I've got patch for that.

If you would like, I can test it for aarch64-none-linux-gnu.

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #29 from Jeffrey A. Law  ---
Fixed on the trunk by Vlad's patch.

[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #5 from David Malcolm  ---
It seems you want the diagnostic to read:

FILENAME-FROM-DIRECTIVE.c: some message
(content from .i file goes here)

We're encoding file/line information into location_t values.  Currently we
encode the filename given by the line directive.

Maybe it's implementable.  line_table_dump shows the LC_RENAME_VERBATIM for the
# line directive:

Map #0 [0x7189e000] - LOC: 32 - REASON: LC_ENTER - SYSP: no
File: a.i:1
Included from: [-1] None

Map #1 [0x7189e020] - LOC: 4128 - REASON: LC_RENAME_VERBATIM - SYSP: no
File: a.c:1
Included from: [-1] None

Perhaps the LC_RENAME_VERBATIM linemap could store the location of the
directive that created it, and we could then map back and apply an offset,
giving the line and column within the .i file.   Though am not sure exactly how
we'd encode it (e.g. what if there are very wide lines? etc).

Maybe some kind of variant of expand_location that ignores directives like
this?  (and then diagnostic_show_locus would use it).

[Bug libstdc++/69600] [5 Regression] Incorrect use of copy-assignment instead of move assignment from function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
This is a duplicate of Bug 77334 which is fixed for 5.5, 6.3 and 7.

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

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||sshannin at gmail dot com

--- Comment #6 from Jonathan Wakely  ---
*** Bug 69600 has been marked as a duplicate of this bug. ***

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #9)

> > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> > time as enabling usage of TFmode.  The TFmode functions should be kept in 
> > libgcc while disabling the conversions between XFmode and TFmode for this 
> > case.
> 
> Any thoughts on how to fix this? I would love a proper fix. 

Can you just remove xftf and tfxf from libgcc/config/t-softfp-sfdftf? We will
figure a proper fix later, if this hack works OK.

> But ... My initial reaction is that soft-float on the x86 is of marginal
> utility anymore and that removing the soft-float multilib on this target for
> at least rtems is an acceptable solution. Soft float seems to be the thing
> that breaks on x86 and I don't know that there is really a CPU that needs it
> anymore.

Well, if all it takes is the above hack, we can keep it at life support some
more.

[Bug debug/71669] DW_AT_data_bit_offset is not emitted for dwarf4 and above

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk (if you use -gdwarf-5).

[Bug debug/71669] DW_AT_data_bit_offset is not emitted for dwarf4 and above

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 17:42:06 2017
New Revision: 244542

URL: https://gcc.gnu.org/viewcvs?rev=244542=gcc=rev
Log:
PR debug/71669
* dwarf2out.c (add_data_member_location_attribute): For constant
offset bitfield emit for -gdwarf-5 DW_AT_data_bit_offset attribute
instead of DW_AT_data_member_location, DW_AT_bit_offset and
DW_AT_byte_size attributes.

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

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0

--- Comment #10 from Jonathan Wakely  ---
A rejects-valid example that Tim Song provided in Bug 68869:

According to the standard ([map.modifiers]), 

template  pair insert(P&& x);

is equivalent to return emplace(std::forward(x)), provided that
std::is_constructible::value is true.

The following code does not compile when insert() is used, but does compile
when emplace() is used. The same issue also affects multimap.

#include 
#include 
#include 
#include 

struct S {
operator std::pair() const && { return {}; }
};

static_assert(std::is_constructible::value,
"!!");
static_assert(std::is_constructible, std::pair&&>::value, "!!");

int main(){
std::map m;
std::map m2;
m.insert(std::make_pair(std::make_unique(), 1));  // Error
m2.insert(S());  // Error

m.emplace(std::make_pair(std::make_unique(), 1)); // OK
m2.emplace(S()); // OK
}

[Bug libstdc++/68869] map::insert(P&&) broken in some cases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
Oh, this is the same underlying problem as discussed in PR 78595 which I
rediscovered myself. Marking as a dup because that has more details.

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

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #9 from Jonathan Wakely  ---
*** Bug 68869 has been marked as a duplicate of this bug. ***

[Bug jit/69435] Truncated lines in jit.log

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to David Malcolm from comment #6)
> Am still seeing "random" truncation, even with the DejaGnu patch in comment
> #4.

Which Linux kernel version?  there has been some bugs in some newer kernels.  I
found so far only 4.10rc2 has the right fix.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #9 from Joel Sherrill  ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> > 
> > --- Comment #2 from Uroš Bizjak  ---
> > For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
> > use t-softfp-sfdftf. Please test the following patch:
> 
> The change was by design meant to ensure that _Float128 was always 
> available on x86, so that __float128 can always be aliased to _Float128.  
> Making _Float128 always available means making libgcc support for TFmode 
> always available.
> 
> I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> time as enabling usage of TFmode.  The TFmode functions should be kept in 
> libgcc while disabling the conversions between XFmode and TFmode for this 
> case.

Any thoughts on how to fix this? I would love a proper fix. 

But ... My initial reaction is that soft-float on the x86 is of marginal
utility anymore and that removing the soft-float multilib on this target for at
least rtems is an acceptable solution. Soft float seems to be the thing that
breaks on x86 and I don't know that there is really a CPU that needs it
anymore.(In reply to Uroš Bizjak from comment #8)
> (In reply to jos...@codesourcery.com from comment #7)
> > On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:
> > 
> > > > I.e., the bug was enabling unintended soft-fp usage of XFmode at the 
> > > > same 
> > > > time as enabling usage of TFmode.  The TFmode functions should be kept 
> > > > in 
> > > > libgcc while disabling the conversions between XFmode and TFmode for 
> > > > this 
> > > > case.
> > > 
> > > Any thoughts on how to fix this? I would love a proper fix. 
> > 
> > Well, you need to distinguish a genuine sfdftf case from sfdfxftf which it 
> > appears this t- file really is.  Distinguish by some configure test that 
> > determines whether there is XFmode support for the multilib being 
> > compiled, I suppose (look at the other tmake_file settings in config.host 
> > based on variables set by configure tests).
> 
> Maybe just add a new t-file without any XFmode and add it to
> i[34567]86-*-rtems*) instead of t-sfdftf.

I could pursue this but is soft-float on the x86 target really worth the
investment of any effort? AFAIK we would be looking at a very old CPU at this
point. 

I only see soft-float listed as a multilib in t-rtems. 

Is there any reason to keep it? :)

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-17
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|internal compiler error: in |[7 Regression] internal
   |cxx_eval_bit_field_ref, at  |compiler error: in
   |cp/constexpr.c:2258 |cxx_eval_bit_field_ref, at
   ||cp/constexpr.c:2258
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with
commit 5157eff877f9491e7c0fc9231ac2b686983eaa41
Author: jason 
Date:   Thu Jul 21 06:05:33 2016 +

PR c++/71121 - -Waddress, constexpr, and PMFs.

* cp-gimplify.c (cp_fully_fold): First call maybe_constant_value.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238559
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan 17 17:03:00 2017
New Revision: 244540

URL: https://gcc.gnu.org/viewcvs?rev=244540=gcc=rev
Log:
PR target/76731
* config/i386/avx512fintrin.h
(_mm512_i32gather_ps): Change __addr type to void const*.
(_mm512_mask_i32gather_ps): Ditto.
(_mm512_i32gather_pd): Ditto.
(_mm512_mask_i32gather_pd): Ditto.
(_mm512_i64gather_ps): Ditto.
(_mm512_mask_i64gather_ps): Ditto.
(_mm512_i64gather_pd): Ditto.
(_mm512_mask_i64gather_pd): Ditto.
(_mm512_i32gather_epi32): Ditto.
(_mm512_mask_i32gather_epi32): Ditto.
(_mm512_i32gather_epi64): Ditto.
(_mm512_mask_i32gather_epi64): Ditto.
(_mm512_i64gather_epi32): Ditto.
(_mm512_mask_i64gather_epi32): Ditto.
(_mm512_i64gather_epi64): Ditto.
(_mm512_mask_i64gather_epi64): Ditto.
(_mm512_i32scatter_ps): Change __addr type to void*.
(_mm512_mask_i32scatter_ps): Ditto.
(_mm512_i32scatter_pd): Ditto.
(_mm512_mask_i32scatter_pd): Ditto.
(_mm512_i64scatter_ps): Ditto.
(_mm512_mask_i64scatter_ps): Ditto.
(_mm512_i64scatter_pd): Ditto.
(_mm512_mask_i64scatter_pd): Ditto.
(_mm512_i32scatter_epi32): Ditto.
(_mm512_mask_i32scatter_epi32): Ditto.
(_mm512_i32scatter_epi64): Ditto.
(_mm512_mask_i32scatter_epi64): Ditto.
(_mm512_i64scatter_epi32): Ditto.
(_mm512_mask_i64scatter_epi32): Ditto.
(_mm512_i64scatter_epi64): Ditto.
(_mm512_mask_i64scatter_epi64): Ditto.
* config/i386/avx512pfintrin.h
(_mm512_mask_prefetch_i32gather_pd): Change __addr type to void const*.
(_mm512_mask_prefetch_i32gather_ps): Ditto.
(_mm512_mask_prefetch_i64gather_pd): Ditto.
(_mm512_mask_prefetch_i64gather_ps): Ditto.
(_mm512_prefetch_i32scatter_pd): Change __addr type to void*.
(_mm512_prefetch_i32scatter_ps): Ditto.
(_mm512_mask_prefetch_i32scatter_pd): Ditto.
(_mm512_mask_prefetch_i32scatter_ps): Ditto.
(_mm512_prefetch_i64scatter_pd): Ditto.
(_mm512_prefetch_i64scatter_ps): Ditto.
(_mm512_mask_prefetch_i64scatter_pd): Ditto.
(_mm512_mask_prefetch_i64scatter_ps): Ditto.
* config/i386/avx512vlintrin.h
(_mm256_mmask_i32gather_ps): Change __addr type to void const*.
(_mm_mmask_i32gather_ps): Ditto.
(_mm256_mmask_i32gather_pd): Ditto.
(_mm_mmask_i32gather_pd): Ditto.
(_mm256_mmask_i64gather_ps): Ditto.
(_mm_mmask_i64gather_ps): Ditto.
(_mm256_mmask_i64gather_pd): Ditto.
(_mm_mmask_i64gather_pd): Ditto.
(_mm256_mmask_i32gather_epi32): Ditto.
(_mm_mmask_i32gather_epi32): Ditto.
(_mm256_mmask_i32gather_epi64): Ditto.
(_mm_mmask_i32gather_epi64): Ditto.
(_mm256_mmask_i64gather_epi32): Ditto.
(_mm_mmask_i64gather_epi32): Ditto.
(_mm256_mmask_i64gather_epi64): Ditto.
(_mm_mmask_i64gather_epi64): Ditto.
(_mm256_i32scatter_ps): Change __addr type to void*.
(_mm256_mask_i32scatter_ps): Ditto.
(_mm_i32scatter_ps): Ditto.
(_mm_mask_i32scatter_ps): Ditto.
(_mm256_i32scatter_pd): Ditto.
(_mm256_mask_i32scatter_pd): Ditto.
(_mm_i32scatter_pd): Ditto.
(_mm_mask_i32scatter_pd): Ditto.
(_mm256_i64scatter_ps): Ditto.
(_mm256_mask_i64scatter_ps): Ditto.
(_mm_i64scatter_ps): Ditto.
(_mm_mask_i64scatter_ps): Ditto.
(_mm256_i64scatter_pd): Ditto.
(_mm256_mask_i64scatter_pd): Ditto.
(_mm_i64scatter_pd): Ditto.
(_mm_mask_i64scatter_pd): Ditto.
(_mm256_i32scatter_epi32): Ditto.
(_mm256_mask_i32scatter_epi32): Ditto.
(_mm_i32scatter_epi32): Ditto.
(_mm_mask_i32scatter_epi32): Ditto.
(_mm256_i32scatter_epi64): Ditto.
(_mm256_mask_i32scatter_epi64): Ditto.
(_mm_i32scatter_epi64): Ditto.
(_mm_mask_i32scatter_epi64): Ditto.
(_mm256_i64scatter_epi32): Ditto.
(_mm256_mask_i64scatter_epi32): Ditto.
(_mm_i64scatter_epi32): Ditto.
(_mm_mask_i64scatter_epi32): Ditto.
(_mm256_i64scatter_epi64): Ditto.
(_mm256_mask_i64scatter_epi64): Ditto.
(_mm_i64scatter_epi64): Ditto.
(_mm_mask_i64scatter_epi64): Ditto.
* config/i386/i386-builtin-types.def (V16SF_V16SF_PCFLOAT_V16SI_HI_INT)
(V8DF_V8DF_PCDOUBLE_V8SI_QI_INT, V8SF_V8SF_PCFLOAT_V8DI_QI_INT)
(V8DF_V8DF_PCDOUBLE_V8DI_QI_INT, V16SI_V16SI_PCINT_V16SI_HI_INT)
(V8DI_V8DI_PCINT64_V8SI_QI_INT, V8SI_V8SI_PCINT_V8DI_QI_INT)
(V8DI_V8DI_PCINT64_V8DI_QI_INT, V2DF_V2DF_PCDOUBLE_V4SI_QI_INT)
(V4DF_V4DF_PCDOUBLE_V4SI_QI_INT, V2DF_V2DF_PCDOUBLE_V2DI_QI_INT)
(V4DF_V4DF_PCDOUBLE_V4DI_QI_INT, 

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to jos...@codesourcery.com from comment #7)
> On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:
> 
> > > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> > > time as enabling usage of TFmode.  The TFmode functions should be kept in 
> > > libgcc while disabling the conversions between XFmode and TFmode for this 
> > > case.
> > 
> > Any thoughts on how to fix this? I would love a proper fix. 
> 
> Well, you need to distinguish a genuine sfdftf case from sfdfxftf which it 
> appears this t- file really is.  Distinguish by some configure test that 
> determines whether there is XFmode support for the multilib being 
> compiled, I suppose (look at the other tmake_file settings in config.host 
> based on variables set by configure tests).

Maybe just add a new t-file without any XFmode and add it to
i[34567]86-*-rtems*) instead of t-sfdftf.

[Bug c++/79118] New: internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[s_gccbugzilla at nedprod dot com]

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

Bug ID: 79118
   Summary: internal compiler error: in cxx_eval_bit_field_ref, at
cp/constexpr.c:2258
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

Created attachment 40531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40531=edit
preprocessed source

ned@KATE:/mnt/g/boostish/outcome/build_posix$ g++ --version
g++ (Ubuntu 6.2.0-3ubuntu11~14.04) 6.2.0 20160901


ned@KATE:/mnt/g/boostish/outcome/build_posix$ /usr/bin/c++  
-DBOOST_OUTCOME_ENABLE_ADVANCED=1 -isystem
/mnt/g/boostish/.use_boostish_siblings  -fPIE   -fstack-protector-strong -Wall
-Wextra -std=gnu++14 -o
CMakeFiles/outcome_hl--unittests.dir/test/unittests.cpp.o -c
/mnt/g/boostish/outcome/test/unittests.cpp --save-temps
/mnt/g/boostish/outcome/test/unittests.cpp: In function ‘void
boostlite_auto_test_suite0::boostlite_auto_test_case5()’:
/mnt/g/boostish/outcome/test/unittests.cpp:497:25:   in constexpr expansion of
‘boost::outcome::_1_0_std_std_f724e3c2::basic_monad(false).boost::outcome::_1_0_std_std_f724e3c2::basic_monad::.boost::outcome::_1_0_std_std_f724e3c2::detail::option_policy_base::get, bool, void, void>()’
/mnt/g/boostish/outcome/test/../include/boost/outcome/v1.0/detail/monad_policy.ipp:137:21:
  in constexpr expansion of
boost::outcome::_1_0_std_std_f724e3c2::detail::option_policy_base::_pre_get_value, bool, void, void>()’
/mnt/g/boostish/outcome/test/../include/boost/outcome/v1.0/detail/monad_policy.ipp:66:34:
  in constexpr expansion of ‘((const
boost::outcome::_1_0_std_std_f724e3c2::detail::option_policy_base, bool, void,
void>*)this)->boost::outcome::_1_0_std_std_f724e3c2::detail::option_policy_base, bool, void,
void>::.boost::outcome::_1_0_std_std_f724e3c2::detail::basic_monad_storage<_implementation_policy>::is_ready()’
/mnt/g/boostish/outcome/test/unittests.cpp:497:31: internal compiler error: in
cxx_eval_bit_field_ref, at cp/constexpr.c:2258
   BOOST_CHECK(option(false).get() == false);
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/78384] [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)

[matz at gcc dot gnu.org]

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

--- Comment #4 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #3)
> Any progress with this?

It fell through the cracks over christmas vacation, I'll get to it this week.

[Bug target/79079] [6/7] Wrong code gen for __builtin_mul_overflow when TRULY_NOOP_TRUNCATION (32, 64) == false

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 16:56:30 2017
New Revision: 244539

URL: https://gcc.gnu.org/viewcvs?rev=244539=gcc=rev
Log:
PR target/79079
* internal-fn.c (expand_mul_overflow): Use convert_modes instead of
gen_lowpart.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c

[Bug c++/70565] [5/6 Regression] ICE at gimplify.c:8832 (cilkplus array extension)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE at   |[5/6 Regression] ICE at
   |gimplify.c:8832 (cilkplus   |gimplify.c:8832 (cilkplus
   |array extension)|array extension)

--- Comment #5 from Aldy Hernandez  ---
Fixed in trunk.  Removing GCC7 regression marker.

[Bug c++/70565] [5/6/7 Regression] ICE at gimplify.c:8832 (cilkplus array extension)

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez  ---
Author: aldyh
Date: Tue Jan 17 16:54:55 2017
New Revision: 244538

URL: https://gcc.gnu.org/viewcvs?rev=244538=gcc=rev
Log:
PR c++/70565
* cp-array-notation.c (expand_array_notation_exprs): Handle
OMP_PARALLEL.

Added:
trunk/gcc/testsuite/g++.dg/cilk-plus/pr70565.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-array-notation.c

[Bug target/78478] Compile Error for i386-rtems

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:

> > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> > time as enabling usage of TFmode.  The TFmode functions should be kept in 
> > libgcc while disabling the conversions between XFmode and TFmode for this 
> > case.
> 
> Any thoughts on how to fix this? I would love a proper fix. 

Well, you need to distinguish a genuine sfdftf case from sfdfxftf which it 
appears this t- file really is.  Distinguish by some configure test that 
determines whether there is XFmode support for the multilib being 
compiled, I suppose (look at the other tmake_file settings in config.host 
based on variables set by configure tests).

[Bug target/62254] [5/6/7 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Nick Clifton  ---
Hi Guys,

I am closing this bug.

None of the test cases reproduce using the gcc 6 branch sources or the current
mainline sources, and I do not want this PR to hold up the gcc 7 branch.  If
the problem resurfaces then the PR can always be reopened, again.

Cheers
  Nick

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> > 
> > --- Comment #2 from Uroš Bizjak  ---
> > For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
> > use t-softfp-sfdftf. Please test the following patch:
> 
> The change was by design meant to ensure that _Float128 was always 
> available on x86, so that __float128 can always be aliased to _Float128.  
> Making _Float128 always available means making libgcc support for TFmode 
> always available.
> 
> I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
> time as enabling usage of TFmode.  The TFmode functions should be kept in 
> libgcc while disabling the conversions between XFmode and TFmode for this 
> case.

Any thoughts on how to fix this? I would love a proper fix. 

But ... My initial reaction is that soft-float on the x86 is of marginal
utility anymore and that removing the soft-float multilib on this target for at
least rtems is an acceptable solution. Soft float seems to be the thing that
breaks on x86 and I don't know that there is really a CPU that needs it
anymore.

[Bug c/79117] __builtin_isfinite edge case incorrect on i386

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
If you use -fexcess-precision=standard, the classification built-in 
functions should convert values with excess range and precision to their 
semantic types as required by ISO C (see c-typeck.c:convert_arguments).  
Without -fexcess-precision=standard, the front end can't do that because 
the excess range and precision is all hidden by the back end.

[Bug testsuite/79115] FAIL: gcc.dg/pr78768.c execution test on arm, aarch64

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
Fixed in r244537.

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vmakarov at gcc dot gnu.org]

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

--- Comment #28 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #27)
> (In reply to Vladimir Makarov from comment #26)
> > (In reply to Dominik Vogt from comment #24)
> > > While you're at it ... does it have the same or a similar cause as the Avr
> > > bug?
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
> > > 
> > > (A HImode quantity got allocated to r31+r32 (r31 is the last hardreg), in
> > > presence of a paradoxical subreg of memory.)
> > 
> > It might be.
> 
> Sorry, I was wrong.  The problem is still present for AVR.  I'll look at the
> AVR PR.  It seems an IRA problem too.

AVR still uses the old reload pass and this is its problem (I wrongly jumped to
the conclusion of about the IRA problem when I saw no output from LRA with
-fira-verbose=12).  I am not an expert of the old reload to be a help with this
AVR PR.

[Bug testsuite/79115] FAIL: gcc.dg/pr78768.c execution test on arm, aarch64

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Tue Jan 17 16:36:55 2017
New Revision: 244537

URL: https://gcc.gnu.org/viewcvs?rev=244537=gcc=rev
Log:
PR testsuite/79115 - FAIL: gcc.dg/pr78768.c execution test on arm, aarch64

gcc/testsuite/ChangeLog
* gcc.dg/pr78768.c: Make it a link-only test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr78768.c

[Bug c/79117] __builtin_isfinite edge case incorrect on i386

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
You can use __builtin_isinf here, so:

if (__builtin_isinf(c)) {
puts("finite");
}
else {
puts("not finite");
}

The expansion of __builtin_isinf performs value truncation automatically when
x87 is involved.

Alternatively, you should use --ffloat-store, or -msse2 -mfpmath=sse.

[Bug c++/71497] Warning text for -Wmisleading-indentation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Tue Jan 17 16:33:44 2017
New Revision: 244536

URL: https://gcc.gnu.org/viewcvs?rev=244536=gcc=rev
Log:
Fix wording of -Wmisleading-indentation (PR c++/71497)

gcc/c-family/ChangeLog:
PR c++/71497
* c-indentation.c (warn_for_misleading_indentation): Use the past
subjunctive in the note.

gcc/testsuite/ChangeLog:
PR c++/71497
* c-c++-common/Wmisleading-indentation-3.c: Update wording of
expected messages.
* c-c++-common/Wmisleading-indentation.c: Likewise.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-indentation.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation-3.c
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation.c

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to amker from comment #7)
> I think it's not PRE's fault.  The input to PRE is already sub-optimal to be
> handled.
> Look at the source code:
> 
> for( i = 0 ; i < ( I - 1 ) ; i++ )
> {
> if( ( L < pL[i+1] ) && ( L >= pL[i] ) ) 
>   break ; 
> }
> 
> if( i == ( I - 1 ) ) 
>   L = pL[i] ; 
> LD = (float)( L - pL[i] ) /
> (float)( pL[i + 1] - pL[i] ) ; 
> 
> Following path from the "break" statement, we know i < (I - 1) must be
> satisfied, so control flow can go from "break" directly to assignment to LD.
> This is the case before the change.
> After r235817, all paths from the loop (including the break edge) go to if
> (i == ( I - 1) ) statement.  Because in if-then branch, L was assigned, and
> we don't know if pL[i] is modified or not by this assignment by aliasing
> rule, there is no redundancy for load of pL[i].
And maybe that's why -fwhole-program is helpful, because we know L and pL don't
alias with each other.

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vmakarov at gcc dot gnu.org]

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

--- Comment #27 from Vladimir Makarov  ---

(In reply to Vladimir Makarov from comment #26)
> (In reply to Dominik Vogt from comment #24)
> > While you're at it ... does it have the same or a similar cause as the Avr
> > bug?
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
> > 
> > (A HImode quantity got allocated to r31+r32 (r31 is the last hardreg), in
> > presence of a paradoxical subreg of memory.)
> 
> It might be.

Sorry, I was wrong.  The problem is still present for AVR.  I'll look at the
AVR PR.  It seems an IRA problem too.

[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #4 from Martin Sebor  ---
I don't know of such an option nor can I find one in the manual.  I also don't
agree that this is a useful feature (if it is, in fact, a feature).  If it is
one, it should be documented because its behavior is both surprising and
different from what other compilers do.

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vmakarov at gcc dot gnu.org]

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

--- Comment #26 from Vladimir Makarov  ---
(In reply to Dominik Vogt from comment #24)
> While you're at it ... does it have the same or a similar cause as the Avr
> bug?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
> 
> (A HImode quantity got allocated to r31+r32 (r31 is the last hardreg), in
> presence of a paradoxical subreg of memory.)

It might be.

As for the current PR, the problem was in wrong IRA (not LRA) assignment.

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
I think it's not PRE's fault.  The input to PRE is already sub-optimal to be
handled.
Look at the source code:

for( i = 0 ; i < ( I - 1 ) ; i++ )
{
if( ( L < pL[i+1] ) && ( L >= pL[i] ) ) 
  break ; 
}

if( i == ( I - 1 ) ) 
  L = pL[i] ; 
LD = (float)( L - pL[i] ) /
(float)( pL[i + 1] - pL[i] ) ; 

Following path from the "break" statement, we know i < (I - 1) must be
satisfied, so control flow can go from "break" directly to assignment to LD. 
This is the case before the change.
After r235817, all paths from the loop (including the break edge) go to if (i
== ( I - 1) ) statement.  Because in if-then branch, L was assigned, and we
don't know if pL[i] is modified or not by this assignment by aliasing rule,
there is no redundancy for load of pL[i].

Thanks.

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vmakarov at gcc dot gnu.org]

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

--- Comment #25 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Jan 17 16:11:55 2017
New Revision: 244535

URL: https://gcc.gnu.org/viewcvs?rev=244535=gcc=rev
Log:
2017-01-17  Vladimir Makarov  

PR target/79058
* ira-conflicts.c (ira_build_conflicts): Update total conflict
hard regs for inner regno.

2017-01-17  Vladimir Makarov  

PR target/79058
* gcc.target/arm/pr79058.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr79058.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-conflicts.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug jit/69435] Truncated lines in jit.log

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Am still seeing "random" truncation, even with the DejaGnu patch in comment #4.

[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 15:50:24 2017
New Revision: 244534

URL: https://gcc.gnu.org/viewcvs?rev=244534=gcc=rev
Log:
PR tree-optimization/71854
* gcc.dg/vect/pr71854.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr71854.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
This has been fixed with r244218.  I'll commit the testcase and close this.