[Bug rtl-optimization/63315] -fcompare-debug bootstrap issue in libjava (fixup_abnormal_edges related)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-debug

--- Comment #2 from Andrew Pinski  ---
Does this work now>

[Bug c/66825] RFE: Add attributes for symbol versioning.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-17
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #5 from peien luo  ---
(In reply to Dmitry Vyukov from comment #4)
> Unkillable processed in D state usually mean kernel bugs (and there are lots
> of them: https://github.com/google/syzkaller/wiki/Found-Bugs).
> 
> Please post results of 'cat /proc/PID/task/*/stack` and `cat
> /proc/PID/task/*/status`. Sometimes hangs happen due to secondary threads in
> the process. Maybe we will be able to figure out something from that info.
> However, I am not sure what we can do about a process hanged in D state,
> generally user must not be able to create them.

It can be killed by kill -9.

I have updated my centos 7 to the latest. Problem still occurs. The kernel
stack output is:

$ cat task/*/stack
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x
[] pipe_wait+0x70/0xc0
[] pipe_write+0x236/0x5b0
[] do_sync_write+0x8d/0xd0
[] dump_write+0x52/0x70
[] dump_seek+0xa4/0xe0
[] elf_core_dump+0x896/0x950
[] do_coredump+0x882/0xb10
[] get_signal_to_deliver+0x1c7/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] retint_signal+0x48/0x8c
[] 0x
[god@localhost 12987]$ ls task
12987  12988  12989  12990  12991  12992  12993  12994


and status:
$ cat task/*/status
Name:   test_metaserver
State:  D (disk sleep)
Tgid:   12987
Ngid:   0
Pid:12987
PPid:   11646
TracerPid:  0
Uid:1000100010001000
Gid:1000100010001000
FDSize: 256
Groups: 1000 
VmPeak: 104153197488 kB
VmSize: 104153197488 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM:265724 kB
VmRSS:265724 kB
VmData: 104153051792 kB
VmStk:   136 kB
VmExe: 18492 kB
VmLib:  5992 kB
VmPTE:  1288 kB
VmSwap:0 kB
Threads:8
SigQ:   0/63365
SigPnd: 
ShdPnd: 
SigBlk: 
SigIgn: 1000
SigCgt: 00018000
CapInh: 
CapPrm: 
CapEff: 
CapBnd: 001f
Seccomp:0
Cpus_allowed:   ,,,
Cpus_allowed_list:  0-127
Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
Mems_allowed_list:  0
voluntary_ctxt_switches:96
nonvoluntary_ctxt_switches: 8
Name:   test_metaserver
State:  D (disk sleep)
Tgid:   12987
Ngid:   0
Pid:12988
PPid:   11646
TracerPid:  0
Uid:1000100010001000
Gid:1000100010001000
FDSize: 256
Groups: 1000 
VmPeak: 104153197488 kB
VmSize: 104153197488 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM:265724 kB
VmRSS:265724 kB
VmData: 104153051792 kB
VmStk:   136 kB
VmExe: 18492 kB
VmLib:  5992 kB
VmPTE:  1288 kB
VmSwap:0 kB
Threads:8
SigQ:   0/63365
SigPnd: 
ShdPnd: 
SigBlk: fffbfeff
SigIgn: 1000
SigCgt: 00018000
CapInh: 
CapPrm: 
CapEff: 
CapBnd: 001f
Seccomp:0
Cpus_allowed:   ,,,
Cpus_allowed_list:  0-127
Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
Mems_allowed_list:  0
voluntary_ctxt_switches:6
nonvoluntary_ctxt_switches: 0
Name:   test_metaserver
State:  

[Bug libfortran/58020] Code for handling IEEE exceptions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
Bug 58020 depends on bug 59015, which changed state.

Bug 59015 Summary: I/O of PARAMETER derived type with private component is 
forbidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59015

   What|Removed |Added

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

[Bug fortran/59015] I/O of PARAMETER derived type with private component is forbidden

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #4 from Jerry DeLisle  ---
This is now fixed on trunk with DTIO implentation. See PR48298.

[Bug c++/77625] New: go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type ‘std::ofstr eam {aka std::basic_ofstream}’ with extended alignment 16

[danglin at gcc dot gnu.org]

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

Bug ID: 77625
   Summary: go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type
‘std::ofstr eam {aka std::basic_ofstream}’ with
extended alignment 16
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-7/hppa-linux-gnu/bin/ -nostdinc++ -B/home/dave/gn
u/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/obj
dir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdi
r/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu 
-I/home/dave/gnu/gcc/
objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstd
c++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtt
i -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qu
al -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno
-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H
-I
. -Igo -I../../gcc/gcc -I../../gcc/gcc/go -I../../gcc/gcc/../include
-I../../gcc
/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libde
cnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o
go/ast-dump.o
 -MT go/ast-dump.o -MMD -MP -MF go/.deps/ast-dump.TPo -I ../../gcc/gcc/go -I
../
../gcc/gcc/go/gofrontend ../../gcc/gcc/go/gofrontend/ast-dump.cc
../../gcc/gcc/go/gofrontend/ast-dump.cc: In member function ‘void
Ast_dump_context::dump(Gogo*, const char*)’:
../../gcc/gcc/go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type
‘std::ofstream {aka std::basic_ofstream}’ with extended alignment 16
[-Werror=aligned-new=]
   std::ofstream* out = new std::ofstream();
  ^
../../gcc/gcc/go/gofrontend/ast-dump.cc:169:42: note: uses ‘void* operator
new(std::size_t)’, which does not have an alignment parameter
../../gcc/gcc/go/gofrontend/ast-dump.cc:169:42: note: use ‘-faligned-new’ to
enable C++17 over-aligned new support
cc1plus: all warnings being treated as errors
../../gcc/gcc/go/Make-lang.in:232: recipe for target 'go/ast-dump.o' failed
make[3]: *** [go/ast-dump.o] Error 1

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[doko at gcc dot gnu.org]

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

--- Comment #7 from Matthias Klose  ---
yes, you are right about the old linker versions, I forgot about these cases.
But it doesn't help the case when you enable the push/pop for a bfd default
linker, and the fail with gold.

[Bug c/77624] New: ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[chengniansun at gmail dot com]

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

Bug ID: 77624
   Summary: ICE on x86_64-linux-gnu (internal compiler error: in
fold_builtin_atomic_always_lock_free, at
builtins.c:5583)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

This is a regression. gcc-4.9 does not ICE.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160916 (experimental) [trunk revision 240207] (GCC) 
$ gcc-trunk -c small.c 
small.c: In function ‘main’:
small.c:3:28: warning: passing argument 2 of ‘__atomic_is_lock_free’ makes
pointer from integer without a cast [-Wint-conversion]
   __atomic_is_lock_free(2, a);
^
small.c:3:28: note: expected ‘const volatile void *’ but argument is of type
‘int’
small.c:3:3: internal compiler error: in fold_builtin_atomic_always_lock_free,
at builtins.c:5583
   __atomic_is_lock_free(2, a);
   ^
0x75875e fold_builtin_atomic_always_lock_free
../../gcc-source-trunk/gcc/builtins.c:5583
0x758b44 fold_builtin_atomic_always_lock_free
../../gcc-source-trunk/gcc/builtins.c:5644
0x758b44 fold_builtin_atomic_is_lock_free
../../gcc-source-trunk/gcc/builtins.c:5640
0x769b9b fold_builtin_2
../../gcc-source-trunk/gcc/builtins.c:8440
0x769b9b fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool)
../../gcc-source-trunk/gcc/builtins.c:8548
0x8eb2f9 fold(tree_node*)
../../gcc-source-trunk/gcc/fold-const.c:11910
0x6bc6f2 c_fully_fold_internal
../../gcc-source-trunk/gcc/c/c-fold.c:556
0x6c019a c_fully_fold(tree_node*, bool, bool*)
../../gcc-source-trunk/gcc/c/c-fold.c:90
0x657e0c c_process_expr_stmt(unsigned int, tree_node*)
../../gcc-source-trunk/gcc/c/c-typeck.c:10342
0x6581fd c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc-source-trunk/gcc/c/c-typeck.c:10387
0x6a5fc8 c_parser_statement_after_labels
../../gcc-source-trunk/gcc/c/c-parser.c:5347
0x6a7f2b c_parser_compound_statement_nostart
../../gcc-source-trunk/gcc/c/c-parser.c:4921
0x6a881e c_parser_compound_statement
../../gcc-source-trunk/gcc/c/c-parser.c:4756
0x6a9d48 c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:2155
0x6b3446 c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1570
0x6b3f59 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1450
0x6b3f59 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:18090
0x71e332 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1073
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ gcc-4.9 small.c  -c
small.c: In function ‘main’:
small.c:3:28: warning: passing argument 2 of ‘__atomic_is_lock_free’ makes
pointer from integer without a cast
   __atomic_is_lock_free(2, a); 
^
small.c:3:28: note: expected ‘const volatile void *’ but argument is of type
‘int’
$ 
$ cat small.c 
int a;
int main() { 
  __atomic_is_lock_free(2, a); 
  return 0;
}
$

[Bug lto/67111] ld -plugin segmentation fault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
So closing as invalid then ...

[Bug c++/77620] Generic compile time regression of 7.0

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to petschy from comment #2)
> Thanks, --enable-checking=release did the trick. Those unreleased checks
> definitely have some runtime cost :)

Yes in some cases there are O(n^2) checking functions which hurt compile time. 
Plus running more and more checking hurts cache locality too.

[Bug testsuite/77623] [7 regression] test cases gcc.target/powerpc/warn-1.c and warn-2.c fail starting with r239994

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
  Component|middle-end  |testsuite
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Yes the testcases need to be changed to do the correct thing.  The other target
testcases have changed already.

Since this warning is about options supplied on the command line, the file name
should not be reported which is exactly what that change did.

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

[roland at gnu dot org]

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

--- Comment #3 from roland at gnu dot org ---
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00981.html

[Bug c++/77620] Generic compile time regression of 7.0

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Closing as invalid then.  That is --enable-checking=release gets us to where
6.2.1 was.

[Bug c++/77620] Generic compile time regression of 7.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
.

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[ienkovich at gcc dot gnu.org]

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

--- Comment #6 from Ilya Enkovich  ---
(In reply to Matthias Klose from comment #5)
> I think it's wrong to have HAVE_LD_PUSHPOPSTATE_SUPPORT baked into the
> driver while it can be easily changed with -fuse-ld=bfd.  It would be very
> nice to have these push/pop options implemented in gold as well and avoid
> this kind of work arounds.

Should we really not allow gold for MPX?  Also having this feature in gold
wouldn't allow us to get rid of this macro because users may use old linker
versions.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

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

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Sep 16 21:28:52 2016
New Revision: 240199

URL: https://gcc.gnu.org/viewcvs?rev=240199=gcc=rev
Log:
[gcc]

2016-09-16  Bill Schmidt  

PR target/77613
* config/rs6000/rs6000.c (rtx_is_swappable_p): Add support for
splat with truncate.

[gcc/testsuite]

2016-09-16  Bill Schmidt  

PR target/77613
* gcc.target/powerpc/swaps-p8-25.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/swaps-p8-25.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[pthaugen at gcc dot gnu.org]

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

--- Comment #9 from Pat Haugen  ---
(In reply to Vladimir Makarov from comment #8)
> 
> The attached patch should solve the problem.  If it works for you.  I'll
> commit it on the next week.

I verified the patch fixes the problem. Thanks.

[Bug middle-end/77623] New: [7 regression] test cases gcc.target/powerpc/warn-1.c and warn-2.c fail starting with r239994

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 77623
   Summary: [7 regression] test cases gcc.target/powerpc/warn-1.c
and warn-2.c fail starting with r239994
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: gcc.target/powerpc/warn-1.c  (test for warnings, line 1)
FAIL: gcc.target/powerpc/warn-1.c (test for excess errors)
FAIL: gcc.target/powerpc/warn-2.c  (test for warnings, line 1)
FAIL: gcc.target/powerpc/warn-2.c (test for excess errors)

The failures are probably because the messages changed.

Before r239994:

/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/warn-1.c:1:0:
warning: -mvsx and -mno-altivec are incompatible


After r239994:

cc1: warning: -mvsx and -mno-altivec are incompatible


If the error message change was intentional then the test cases will need to
change.

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #5)
> Tim, can you grab a clean copy of trunk (from a Linux box or from
> whereever), cooy that to your Windows machine and try again?

Thomas, do you have bootstrap working?

I have it building without bootstrap, but I am totally unclear about some of
the configure parameters, when I tried some of the odd ones used by the Cygwin
released 5.4 I could not get through stage 1

[Bug c++/77482] [6/7 Regression] Segfault when compiling ill-formed constexpr code

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 20:25:17 2016
New Revision: 240198

URL: https://gcc.gnu.org/viewcvs?rev=240198=gcc=rev
Log:
PR c++/77482
* error.c (dump_simple_decl): Only check DECL_DECLARED_CONCEPT_P
if DECL_LANG_SPECIFIC is non-NULL.  Fix up formatting.

* g++.dg/cpp0x/constexpr-77482.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77379] incorrect mangling for non-virtual adjustor thunk (missing abi tag)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 20:23:15 2016
New Revision: 240197

URL: https://gcc.gnu.org/viewcvs?rev=240197=gcc=rev
Log:
PR c++/77379
* g++.dg/abi/abi-tag23.C: Adjust scan-assembler regex for differing
thunk offsets.
* g++.dg/abi/abi-tag23a.C: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/abi/abi-tag23.C
trunk/gcc/testsuite/g++.dg/abi/abi-tag23a.C

[Bug c++/77338] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 20:22:35 2016
New Revision: 240196

URL: https://gcc.gnu.org/viewcvs?rev=240196=gcc=rev
Log:
PR c++/77338
* constexpr.c (cxx_eval_constant_expression) : Only
call is_really_empty_class on complete types.

* g++.dg/cpp0x/decltype-77338.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-77338.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77375] [5/6/7 Regression] constant object with mutable subobject allocated in read-only memory

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 20:21:29 2016
New Revision: 240195

URL: https://gcc.gnu.org/viewcvs?rev=240195=gcc=rev
Log:
PR c++/77375
* class.c (check_bases): Set CLASSTYPE_HAS_MUTABLE if any
TYPE_HAS_MUTABLE_P
for any bases.

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

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/mutable1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Sorry for delay with the answer.  I had a long vacation.

LRA remat sub-pass did not check relation between the hard coded insn
registers.  It checked only relations between operand registers and other
operands and hard coded insn registers.

The attached patch should solve the problem.  If it works for you.  I'll commit
it on the next week.

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
Created attachment 39637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39637=edit
A patch candidate

[Bug c++/77620] Generic compile time regression of 7.0

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
Thanks, --enable-checking=release did the trick. Those unreleased checks
definitely have some runtime cost :)

My project was built in 3m35 with -O3, and the gcc master branch:

 7.0.0
-O0  7m30
-O1  7m00
-O2  8m23
-O3  9m02

These are effectively the same as with 6.2.1.

Sorry for the noise.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 19:17:47 2016
New Revision: 240193

URL: https://gcc.gnu.org/viewcvs?rev=240193=gcc=rev
Log:
PR libgcc/71744
* unwind-dw2-fde.c (ATOMIC_FDE_FAST_PATH): Define if __register_frame*
is not the primary registry and atomics are available.
(any_objects_registered): New variable.
(__register_frame_info_bases, __register_frame_info_table_bases):
Atomically store 1 to any_objects_registered after registering first
unwind info.
(_Unwind_Find_FDE): Return early if any_objects_registered is 0.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/unwind-dw2-fde.c

[Bug lto/67111] ld -plugin segmentation fault

[dilyan.palauzov at aegee dot org]

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

--- Comment #2 from Дилян Палаузов  ---
I do not have the environment anymore.

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

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #2)
> The only bug is in the testcase, using __builtin_object_size (, 2) for this
> is just wrong

Unless the manual does a better job explaining things it's hard to guess how to
use the feature, even for someone who has been working with this feature for
years.  Here's what I see there now:

  The intended use can be e.g.

 #undef memcpy
 #define bos0(dest) __builtin_object_size (dest, 0)
 #define memcpy(dest, src, n) \
   __builtin___memcpy_chk (dest, src, n, bos0 (dest))

Given this example of intended use it seems that another such example is one
where the bos macro is defined like so:

 #define bos2(dest) __builtin_object_size (dest, 2)
 #define memcpy(dest, src, n) \
   __builtin___memcpy_chk (dest, src, n, bos2 (dest))

If this isn't meant to be a valid example then the manual needs to be clarified
and explain what some of the other examples might be (and also what would not
be valid examples).  I can appreciate that passing 0 as the object size to
__builtin___memcpy_chk and interpreting it as "unknown size" in the absence of
any other information is tricky.  But that's a problem with (defect in) the
design of the builti-ins that needs to highlighted in the manual so users know
to avoid it.  This was also one point of the test case in comment #0.  My bad
for not articulating it more clearly.

> 0 is completely valid return value for that builtin, it is
> the "don't know" value that is returned whenever the code doesn't figure it
> out.

Exactly.  Overloading the return value this way is the problem that either
needs to be solved or that needs to be documented in the manual (i.e., the
manual needs to explain that the use of the bos2() macro may lead to false
positives in some cases and give examples of some of them).

> __builtin_object_size (, 0) in this case also returns -1, "don't know" value.
> 
> So, if anything, this can be treated as an enhancement request.  Right now
> for malloc-like calls, including calls with alloc_size argument, we do:
>   if (arg1 < 0 || arg1 >= (int)gimple_call_num_args (call)
>   || TREE_CODE (gimple_call_arg (call, arg1)) != INTEGER_CST
>   || (arg2 >= 0
>   && (arg2 >= (int)gimple_call_num_args (call)
>   || TREE_CODE (gimple_call_arg (call, arg2)) != INTEGER_CST)))
> return unknown[object_size_type];
> So, the enhancement request would be for gimple_call_arg (call, argN) here
> being an SSA_NAME instead of INTEGER_CST to try to prove some range instead
> (and for the multiplication case do it with extra care because of possible
> overflows).

I haven't studied the implementation in enough detail to comment on the
suggestion above but I can say what my expectation is from a user's point of
view: since there is no practical difference between an object allocated by
'__builtin_malloc (1 < argc ? 40 : 80)' and one allocated by '1 < argc ?
__builtin_malloc (40) : __builtin_malloc (80)', then since writing past the end
of one such object is detected so should be writing past the end of the other. 
When it isn't, users don't care if it's due to some inherent limitation in the
GCC representation of the two expressions, or what changes in GCC might be
required to make it so.  To them, the feature simply doesn't work the way they
expect and the way it's documented to.  In most users' minds that's also not an
enhancement but a deficiency.

> I have reservations about using get_range_info for that though, the VRP
> stuff is computed from many sources, including assumptions that undefined
> behavior will not happen etc.  But, these builtins are primarily used for
> security purposes, and the stuff it is guarding is also undefined behavior,
> so if anything, it should do some cheap short walk of the operands and
> compute range more conservatively (perhaps only allow SSA_NAME copies,
> perhaps casts, and PHIs with all constant arguments or something similar?).

I don't necessarily insist on using VRP here.  If there's a different/better
way to do it I'm all for it.  But if there isn't, I don't think that just
because VRP assumes the absence of undefined behavior it can't or shouldn't be
used to help detect its absence in calls to memcpy et al., unless it causes
false positives.

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #5 from Matthias Klose  ---
I think it's wrong to have HAVE_LD_PUSHPOPSTATE_SUPPORT baked into the driver
while it can be easily changed with -fuse-ld=bfd.  It would be very nice to
have these push/pop options implemented in gold as well and avoid this kind of
work arounds.

[Bug fortran/77612] [5/6 Regression] ICE on invalid character len in contained procedure

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|5.5 |7.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/77612] [5/6 Regression] ICE on invalid character len in contained procedure

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep 16 17:55:38 2016
New Revision: 240191

URL: https://gcc.gnu.org/viewcvs?rev=240191=gcc=rev
Log:
2016-09-16  Steven G. Kargl  

PR fortran/77612
* decl.c (char_len_param_value): Check parent namespace for 
seen_implicit_none.


2016-09-16  Steven G. Kargl  

PR fortran/77612
* gfortran.dg/pr77612.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77612.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/77622] New: __builtin_object_size incorrect for an out-of-bounds pointer prior to destination object

[msebor at gcc dot gnu.org]

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

Bug ID: 77622
   Summary: __builtin_object_size incorrect for an out-of-bounds
pointer prior to destination object
   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: ---

When the __builtin_object_size intrinsic is passed a pointer that's derived
from the address of an object but points past its end it returns zero in all
types.  This makes it possible for _FORTIFY_SOURCE to detect writing past the
end of the destination buffer.

However, when the function is passed a similarly derived pointer that points
before the beginning of the object it instead returns a positive value,
preventing GCC from emitting the checking calls, and allowing buffer overflows
to go undetected.

The test case below shows these two cases.

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

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

int main (void)
{
  char d [3];
  int i = 10;
  char *p;

  {
p = [3] - i;

P (p);

memcpy (p, "abcdef", 5);

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

  { 
p = [3] + i;

P (p);

memcpy (p, "abcdef", 5);

__builtin_printf ("%.0s", p);
  }
}
x.c: In function ‘main’:
x.c:19:7: warning: array subscript is below array bounds [-Warray-bounds]
 p = [3] - i;
 ~~^~~
x.c:19:7: warning: array subscript is below array bounds [-Warray-bounds]
x.c:29:7: warning: array subscript is above array bounds [-Warray-bounds]
 p = [3] + i;
 ~~^~~
x.c:29:7: warning: array subscript is above array bounds [-Warray-bounds]

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

main ()
{
  char d[3];

  :
  __builtin_printf ("%2zd %2zd %2zd %2zd\n", 10, 10, 10, 10);
  __builtin_memcpy ([(void *) + -7B], "abcdef", 5);
  __builtin_printf ("%.0s", [(void *) + -7B]);
  __builtin_printf ("%2zd %2zd %2zd %2zd\n", 0, 0, 0, 0);
  __builtin___memcpy_chk ([(void *) + 13B], "abcdef", 5, 0);
  __builtin_printf ("%.0s", [(void *) + 13B]);
  d ={v} {CLOBBER};
  return 0;

}


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

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Tim, can you grab a clean copy of trunk (from a Linux box or from whereever),
cooy that to your Windows machine and try again?

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #4 from Dmitry Vyukov  ---
Unkillable processed in D state usually mean kernel bugs (and there are lots of
them: https://github.com/google/syzkaller/wiki/Found-Bugs).

Please post results of 'cat /proc/PID/task/*/stack` and `cat
/proc/PID/task/*/status`. Sometimes hangs happen due to secondary threads in
the process. Maybe we will be able to figure out something from that info.
However, I am not sure what we can do about a process hanged in D state,
generally user must not be able to create them.

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug c++/77621] New: Internal compiler error for mtune=atom + msse2

[marcin.bajor at gmail dot com]

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

Bug ID: 77621
   Summary: Internal compiler error for mtune=atom + msse2
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.bajor at gmail dot com
  Target Milestone: ---

Created attachment 39634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39634=edit
Preprocessed rawimage.cc

Hi,
I'm a maintainer of Rawtherapee packages. I'm using Open Build Service
(https://build.opensuse.org/package/show/home:rawtherapee/rawtherapee)
I have a problem with build the project for Fedora 24 (i686 + msse2) (gcc
6.1.1) with standard set of CXX flags recommended for building packages on OBS:

-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables

+ flag added by me: -msse2

Build finished with "internal compiler error: Segmentation fault"

There is no problem with build for Fedora 23 (gcc 5.1.1) where the same flags
are used.

I've noticed too that there is no problem if I remove -mtune=atom.

To build the project locally use Open Build Service commander:
$ osc co home:rawtherapee rawtherapee
$ cd home\:rawtherapee/rawtherapee/
(optional) modify rawherapee.spec file
$ osc build  --no-verify Fedora_24 i586 rawtherapee.spec --clean

Regards
Marcin Bajor

[Bug c++/77621] Internal compiler error for mtune=atom + msse2

[marcin.bajor at gmail dot com]

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

--- Comment #1 from Marcin Bajor  ---
Created attachment 39635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39635=edit
Build log with Q flag

[Bug c++/77621] Internal compiler error for mtune=atom + msse2

[marcin.bajor at gmail dot com]

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

--- Comment #2 from Marcin Bajor  ---
Created attachment 39636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39636=edit
Build log

[Bug bootstrap/70838] internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
No feedback in 3 months and this works for many other people so closing as
works for me.

[Bug libgcc/66939] build error gcc-5.2.0/libgcc/libgcc2.c:1955:6 internal compiler error: in real_from_string, at real.c:2078

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does this work now?  Also have you tried a newer version of GMP/MPFR to make
sure it is not a bug in those?

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/77349] AIX DWARF debugging offset in 64 bit mode

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Author: dje
Date: Fri Sep 16 14:42:54 2016
New Revision: 240188

URL: https://gcc.gnu.org/viewcvs?rev=240188=gcc=rev
Log:
2016-09-16  David Edelsohn  

Backported from mainline
2016-08-26  David Edelsohn  

PR target/77349
* config/rs6000/xcoff.h (DWARF_OFFSET_SIZE): Define as PTR_SIZE.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/xcoff.h

[Bug bootstrap/68663] Build failure on AIX 7.1

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
Group Bull, Perzl, and I have been able to build it.  Are you using an up to
date AIX Assembler?

[Bug c++/77620] Generic compile time regression of 7.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What happens if you configure gcc trunk with --enable-checking=release ?  The
released versions default to that already and when GCC 7 is released, it will
also be that default too.

[Bug target/66947] [5 only] Bootstrap error: Extraneous text after `else' directive

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
  Component|bootstrap   |target
   Target Milestone|--- |5.5
Summary|Bootstrap error: Extraneous |[5 only] Bootstrap error:
   |text after `else' directive |Extraneous text after
   ||`else' directive

[Bug c++/77620] New: Generic compile time regression of 7.0

[petschy at gmail dot com]

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

Bug ID: 77620
   Summary: Generic compile time regression of 7.0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

I noticed that compiling my C++ project with 7.0 at -O3 took twice as much time
as before with earlier major versions. First I thought that it might be that
7.0 used more optimizations, but a significant time difference remained even
with -O0:

 5.4.1  6.2.1  7.0.0
-O0  2m10   2m18   3m43
-O1  2m45   2m51   5m38
-O2  3m24   3m26   6m46
-O3  3m25   3m34   7m05

Also did measurements with the gcc source, compiling the master branch
(b55f1f4) with

for o in 0 1 2 3; do for v in 4.9.2 5.4.1 6.2.1 7.0.0; do rm -Rf *;
../configure CC=gcc-$v CXX=g++-$v --enable-languages=c,c++ --disable-multilib
--program-suffix=-`cat ../gcc/BASE-VER` --disable-bootstrap CFLAGS="-O$o
-march=native" CXXFLAGS="-O$o -march=native"; time make -j8; echo "-O$o $v";
echo hit enter to continue; read x; done; done

 4.9.2   5.4.1   6.2.1   7.0.0
-O0  7m157m127m28 8m18
-O1  7m117m137m02 9m11
-O2  8m198m178m2410m57
-O3  8m538m579m0512m03

The tests were done on a PC with Debian Jessie 64bit, AMD FX-8150 @ 4GHz, 16GB
RAM, XFS on SSD.

$ gcc-4.9.2 -v
Using built-in specs.
COLLECT_GCC=gcc-4.9.2
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-4.9.2
Thread model: posix
gcc version 4.9.2 20140808 (prerelease) (GCC)

$ gcc-5.4.1 -v
Using built-in specs.
COLLECT_GCC=gcc-5.4.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.4.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 5.4.1 20160829 (GCC)

$ gcc-6.2.1 -v
Using built-in specs.
COLLECT_GCC=gcc-6.2.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-6.2.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 6.2.1 20160831 (GCC)

$ gcc-7.0.0 -v
Using built-in specs.
COLLECT_GCC=gcc-7.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-7.0.0 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 7.0.0 20160831 (experimental) (GCC)

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #3 from peien luo  ---
The process stuck can be reproduced, the kernel call trace is like:

Sep 16 09:38:37 localhost kernel: test_metaserver D 8803f9307300 0 
4250   3896 0x0080
Sep 16 09:38:37 localhost kernel: 880424b4bcd0 0082
8803f9307300 880424b4bfd8
Sep 16 09:38:37 localhost kernel: 880424b4bfd8 880424b4bfd8
8803f9307300 8803f9307300
Sep 16 09:38:37 localhost kernel: 880421c29f40 880421c29fb8
8803faf06c40 8803f9307300
Sep 16 09:38:37 localhost kernel: Call Trace:
Sep 16 09:38:37 localhost kernel: [] schedule+0x29/0x70
Sep 16 09:38:37 localhost kernel: [] do_exit+0x1e4/0xa60
Sep 16 09:38:37 localhost kernel: [] ? update_curr+0xcc/0x150
Sep 16 09:38:37 localhost kernel: [] ?
account_entity_dequeue+0xae/0xd0
Sep 16 09:38:37 localhost kernel: [] do_group_exit+0x3f/0xa0
Sep 16 09:38:37 localhost kernel: []
get_signal_to_deliver+0x1d0/0x6d0
Sep 16 09:38:37 localhost kernel: [] do_signal+0x57/0x6c0
Sep 16 09:38:37 localhost kernel: [] ? ktime_get+0x4c/0xd0
Sep 16 09:38:37 localhost kernel: [] ?
hrtimer_nanosleep+0xd3/0x170
Sep 16 09:38:37 localhost kernel: [] ?
hrtimer_get_res+0x50/0x50
Sep 16 09:38:37 localhost kernel: []
do_notify_resume+0x5f/0xb0
Sep 16 09:38:37 localhost kernel: [] int_signal+0x12/0x17

[Bug tree-optimization/77605] [5/6/7 Regression] wrong code at -O3 on x86_64-linux-gnu

[spop at gcc dot gnu.org]

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

--- Comment #6 from Sebastian Pop  ---
The proposed change looks good to me.

"last_conflicts" is the max index in the conflicting functions for which there
is a dependence:

mem_access_a (conflicting_iterations_in_a (last_conflicts)) is in dependence
with
mem_access_b (conflicting_iterations_in_b (last_conflicts)).

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

[greenc at fnal dot gov]

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

--- Comment #4 from Chris Green  ---
(In reply to Jakub Jelinek from comment #3)
> Ah, maybe I'm wrong what S6_ stands for.  Anyway:
> https://llvm.org/bugs/show_bug.cgi?id=30401#c1
> has more details.  So NOTABUG?

See particularly https://llvm.org/bugs/show_bug.cgi?id=30401#c1. While the
c++filt provided with binutils on Ubuntu 16.04 demangles both symbols to the
same (correct) function, LLVM's libc++abi demangler demonstrates an apparent
erroneous backreference in LLVM's mangled symbol name. Until new evidence
suggests otherwise, I'd be willing to accept a determination that this is
LLVM's bug, not GCC's.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
This is simple enough.  We have code to allow splats in pure-SIMD ranges, but
we are missing a pattern that performs a splat and a truncate in the same
operation.  Should have a patch to submit today.

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

[vogt at linux dot vnet.ibm.com]

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

--- Comment #16 from Dominik Vogt  ---
There's nothing wrong with applying that change, but it does not fix the
problem.  I'm still debugging this and have it narrowed down to being related
with functions that use alloca() and call another function using varargs.

This code extracted from gencfn-macros:
--
#include 
#include 
#include 

char *gs;

char * concat_copy2 (const char *first, ...)
{
  va_list args;
  va_start (args, first);
  {
char *end = gs;
const char *arg;

for (arg = first; arg ; arg = va_arg (args, const char *))
  {
unsigned long length = strlen (arg);
memcpy (end, arg, length);
end += length;
  }
*end = '\000';
  }
  va_end (args);

  return gs;
}

bool contains (char *k)
{
  fprintf(stderr, "!!!contains: %p '%s'\n", (void *), (char *)k);
  return false;
}

int main(int argc, char **argv)
{
  char *tmp;

  gs = (char *) __builtin_alloca(14);
  tmp = concat_copy2 ("BUILT_IN_", "blab", 0);

  return contains(tmp) ? 0 : 1;
}
--

This somehow overwrites the string concatenated in tmp/gs with some pointer.

[Bug libstdc++/77619] New: uninitialized_meow_construct and friends not exception safe

[rs2740 at gmail dot com]

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

Bug ID: 77619
   Summary: uninitialized_meow_construct and friends not exception
safe
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

The new uninitialized_{default,value}_construct(_n)? and
uninitialized_move(_n)? implementations are not exception safe: previously
constructed objects are leaked if a subsequent construction throws.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
And confirmed.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #1 from Bill Schmidt  ---
Mine.

[Bug c/65452] strcmp (foo, foo) could give a warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
This warning could have prevented .

Hopefully I'll get to this in this stage1.

[Bug c/65452] strcmp (foo, foo) could give a warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
strncmp, memcmp, strcasecmp, strncasecmp are other functions we should treat
similarly.

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

[dje at gcc dot gnu.org]

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

--- Comment #15 from David Edelsohn  ---
The AIX Subroutine Linkage Convention states:

"The address value in the stack pointer must be quadword-aligned. (The address
value must be a multiple of 16.)" - Stack Layout, Note 2.

https://www.ibm.com/support/knowledgecenter/en/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/linkage_convent.htm

http://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.alangref/idalangref_stack_layout.htm

I believe that requires the change that I proposed to STACK_DYNAMIC_OFFSET in
comment #10.  I will push that patch.

I'm not sure how this should be addressed for the SVR4 ELF ABI when Altivec is
not enabled.

[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/77617] Miscompilation n &= 0x1F ? x+n : x;

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
The &= operator has the same precedence as the ternary operator.
So you have to use parentheses in this case.

[Bug c/77617] Miscompilation n &= 0x1F ? x+n : x;

[obilaniu at yahoo dot com]

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

Olexa Bilaniuk  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |x86_64-suse-linux   |x86_64-linux-gnu,
   ||x86_64-suse-linux
   Host|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |x86_64-suse-linux   |x86_64-linux-gnu,
   ||x86_64-suse-linux
  Known to fail||4.9.2
  Build|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |x86_64-suse-linux   |x86_64-linux-gnu,
   ||x86_64-suse-linux

--- Comment #1 from Olexa Bilaniuk  ---
Confirmed with -m32 flag on all situations above I've tested so far.
Confirmed on a Debian system with distro stock GCC 4.9.2 and Linux kernel
3.6.7:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--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-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --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 4.9.2 (Debian 4.9.2-10)

Just like everything else: Same flags, no warnings and silent miscompilation of
function fail() but no miscompilation of function good().

[Bug c++/77509] [5/6/7 Regression] ICE on invalid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|ICE on invalid C++ code: in |[5/6/7 Regression] ICE on
   |finish_class_member_access_ |invalid C++ code: in
   |expr, at cp/typeck.c:2783   |finish_class_member_access_
   ||expr, at cp/typeck.c:2783

--- Comment #2 from Jakub Jelinek  ---
Started with r154223, before that it has been rejected without ICE:
pr77509.C:3:17: warning: direct base ‘A’ inaccessible in ‘C’ due to ambiguity
pr77509.C: In function ‘void foo()’:
pr77509.C:8:8: error: request for member ‘m’ is ambiguous
pr77509.C:1:40: error: candidates are: template void A::m()
pr77509.C:1:40: error: template void A::m()
pr77509.C:8:12: error: expected primary-expression before ‘int’
pr77509.C:8:12: error: expected ‘;’ before ‘int’

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #2 from peien luo  ---
(In reply to Dmitry Vyukov from comment #1)
> Hello,
> 
> Shadow stack size was increased several times, and as far as I remember we
> now have a guard page at the end. Please retest with latest gcc/clang, or
> provide a reproducer.

I moved to another box (a virtual machine) to test the new gcc 4.9.4 (because
the other environment is a shared server I can't make many changes on it.)

What I observed is: without tsan, the process runs fine. With tsan turned on,
then it got fully stuck at some point. (D state, cannot attach or trace). I
haven't yet figured out what caused that. Here is a /proc stack when it got
stuck:

$ cat syscall 
35 0x7ffca05f77e0 0x7ffca05f77e0 0x0 0x8 0x7ffca05f78f0 0x7ffca05f7730
0x7ffca05f77d0 0x7f24ff6f349d

$ cat stack 
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x

[Bug tree-optimization/77605] [5/6/7 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
And the reason is IMHO

/* Determines the overlapping elements due to accesses CHREC_A and
   CHREC_B, that are affine functions.  This function cannot handle
   symbolic evolution functions, ie. when initial conditions are
   parameters, because it uses lambda matrices of integers.  */

static void
analyze_subscript_affine_affine (tree chrec_a,
 tree chrec_b,
 conflict_function **overlaps_a,
 conflict_function **overlaps_b,
 tree *last_conflicts)
{
...
  if (i1 > 0 && j1 > 0)
{
  HOST_WIDE_INT niter_a
= max_stmt_executions_int (get_chrec_loop (chrec_a));
  HOST_WIDE_INT niter_b
= max_stmt_executions_int (get_chrec_loop (chrec_b));
  HOST_WIDE_INT niter = MIN (niter_a, niter_b);
^^^
...
  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
  if (x1 >= niter || y1 >= niter)

we compute the conflict iteration pair to 0, 6 but niter is two here
(minimum of two and eight).

Changing the above tests to use niter_a and niter_b fixes the issue but we have
other niter uses above that.  And the question is of course how to represent
"last_conflict" here -- it is supposed to be an iteration number which
hopefully is in-range for both loops (fixing the above code to properly
use niter_a/b makes it so for _this_ case).  "last_conflicts" is not very
well documented ("This field stores the information about the iteration domain
validity of the dependence relation.").

Patch that needs testing (and a 2nd eye):

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 240176)
+++ gcc/tree-data-ref.c (working copy)
@@ -2686,13 +2682,13 @@ analyze_subscript_affine_affine (tree ch

  if (niter > 0)
{
- HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter - i0, i1),
-   FLOOR_DIV (niter - j0, j1));
+ HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter_a - i0, i1),
+   FLOOR_DIV (niter_b - j0, j1));
  HOST_WIDE_INT last_conflict = tau2 - (x1 - i0)/i1;

  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
- if (x1 >= niter || y1 >= niter)
+ if (x1 >= niter_a || y1 >= niter_b)
{
  *overlaps_a = conflict_fn_no_dependence ();
  *overlaps_b = conflict_fn_no_dependence ();


with this patch we get

(compute_affine_dependence
  stmt_a: _2 = c[b.5_22][_1];
  stmt_b: c[b.5_22][a.7_23] = _3;
(analyze_overlapping_iterations
  (chrec_a = {6, +, 1}_2)
  (chrec_b = {0, +, 1}_1)
(analyze_miv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = [0 + 1 * x_1])
  (overlaps_b = [6 + 1 * x_1]))
)
  (overlap_iterations_a = [0 + 1 * x_1])
  (overlap_iterations_b = [6 + 1 * x_1]))
(analyze_overlapping_iterations
  (chrec_a = {0, +, 1}_2)
  (chrec_b = {0, +, 1}_2)
  (overlap_iterations_a = [0])
  (overlap_iterations_b = [0]))
(Dependence relation cannot be represented by distance vector.)
)


The issue was likely introduced by r129797 (not sure if we vectorized the loop
immediately after that change).

[Bug tree-optimization/77605] [5/6/7 Regression] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r145494.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Fixed for 6.3+ so far.

[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.1, 7.0
 Resolution|--- |FIXED
  Known to fail|6.2.1, 7.0  |6.2.0

--- Comment #5 from Jakub Jelinek  ---
Fixed for 6.3+.

[Bug fortran/77516] ICE in is_gimple_min_invariant, at gimple-expr.c:706

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Fixed for 6.3+ so far.

[Bug fortran/77500] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Fixed for 6.3+ so far.

[Bug target/69255] ICE on x86_64-linux-gnu in "emit_move_insn"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/77605] [5/6/7 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.2.4
   Target Milestone|--- |5.5
Summary|wrong code at -O3 on|[5/6/7 Regression] wrong
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
  Known to fail||4.3.6, 4.5.4

--- Comment #3 from Richard Biener  ---
Non-surprisingly found a working version.  This is outer loop vectorization at
play and it looks like a dependence analysis issue to me:

  :
  # a.1_26 = PHI <0(2), _14(7)>
  # ivtmp_32 = PHI <8(2), ivtmp_7(7)>

  :
  # b.0_27 = PHI <0(3), _12(5)>
  # ivtmp_34 = PHI <2(3), ivtmp_33(5)>
  _8 = b.0_27 + 6;
  _9 = c[b.0_27][_8];
  _10 = _9 ^ 1;
  c[b.0_27][a.1_26] = _10;
  _12 = b.0_27 + 1;
  ivtmp_33 = ivtmp_34 - 1;
  if (ivtmp_33 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  _14 = a.1_26 + 1;
  ivtmp_7 = ivtmp_32 - 1;
  if (ivtmp_7 != 0)
goto ;
  else
goto ;

  :
  goto ;

(compute_affine_dependence
  stmt_a: _9 = c[b.0_27][_8];
  stmt_b: c[b.0_27][a.1_26] = _10;
(analyze_overlapping_iterations
  (chrec_a = {6, +, 1}_2)
  (chrec_b = {0, +, 1}_1)
(analyze_miv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = no dependence)
  (overlaps_b = no dependence))
)
  (overlap_iterations_a = no dependence)
  (overlap_iterations_b = no dependence))
) -> no dependence

[Bug c++/77618] warn for explicit instantiation that occurs after an explicit specialization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug c++/77618] New: warn for explicit instantiation that occurs after an explicit specialization

[trippels at gcc dot gnu.org]

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

Bug ID: 77618
   Summary: warn for explicit instantiation that occurs after an
explicit specialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

clang has a nice warning:

 % cat foo.ii
template  void foo() {}
template <> void foo() {}
template void foo();

 % clang++ -c foo.ii
foo.ii:3:15: warning: explicit instantiation of 'foo' that occurs after an
explicit specialization has no effect [-Winstantiation-after-specialization]
template void foo();
  ^
foo.ii:2:18: note: previous template specialization is here
template <> void foo() {}
 ^
1 warning generated.

Would be nice to have in gcc, too.

[Bug c/77617] New: Miscompilation n &= 0x1F ? x+n : x;

[obilaniu at yahoo dot com]

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

Bug ID: 77617
   Summary: Miscompilation n &= 0x1F ? x+n : x;
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: obilaniu at yahoo dot com
  Target Milestone: ---

Created attachment 39633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39633=edit
Demonstration file minimal.c

GCC has been miscompiling on Linux, since at least 4.8.5, the following
function fail():


static   unsigned good(unsigned x, unsigned n){
n &= 0x1F;
return n ? x+n : x;
}
static   unsigned fail(unsigned x, unsigned n){
return n &= 0x1F ? x+n : x;
}


int main(){
return fail(0xDEADBEEFU, 16U) == 0xDEADBEFFU;
}


The program should return an exit status of 1. When main() calls good() it does
return an exit code of 1, but when it calls fail() it returns an exit code of
0.

The program exhibits no UB; A sequence point occurs after the evaluation of the
condition of the ternary operator and before the evaluation of either of its
arms.


My system is OpenSuSE 42.1 Leap with Linux kernel 4.4.5 and the CPU is an Intel
Haswell Core i7. I am using the stock compilers and an SVN checkout.


The miscompilation occurs for the following GCC versions I have access to:
- GCC 4.8.5
- GCC 5.3.1
- GCC 7.0.0 20160916 (svn r240176)



They were configured as follows:

> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux)

> gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran,ada,go --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp
--disable-libvtv --enable-libmpx --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-5 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)

> ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/tmp/ramdisk/build/lib/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/tmp/ramdisk/build
--disable-bootstrap --disable-nls --enable-languages=c
Thread model: posix
gcc version 7.0.0 20160916 (experimental) (GCC)



The program minimal.c was compiled at both -O0 and -O3 and using both gcc and
g++ with identical effects:
  gcc   minimal.c -o minimal
  gcc   -O3 minimal.c -o minimal
  g++   minimal.c -o minimal
  g++   -O3 minimal.c -o minimal
  gcc-5 minimal.c -o minimal
  gcc-5 -O3 minimal.c -o minimal
  g++-5 minimal.c -o minimal
  g++-5 -O3 minimal.c -o minimal
  ./gcc minimal.c -o minimal
  ./gcc -O3 minimal.c -o minimal
No compilations gave any warnings whatsoever during compilation. All
compilations above exhibit the bug when the fail() function is called and don't
when the good() function is called.

An ideone link to a related problem is here:
https://ideone.com/djOB6g

[Bug c++/77615] Template specialization is resolved differently with and without optimizations turned on

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
The compiler only sees single compilation units and it doesn't keep 
a database of previously seen units. 
When it compiles usage.cc it doesn't know anything about specialization.cc.

So there really is nothing that the compiler could do here.
And clang and other compilers also don't warn and behave exactly like
gcc once you use -O2.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The only bug is in the testcase, using __builtin_object_size (, 2) for this is
just wrong, 0 is completely valid return value for that builtin, it is the
"don't know" value that is returned whenever the code doesn't figure it out.
__builtin_object_size (, 0) in this case also returns -1, "don't know" value.

So, if anything, this can be treated as an enhancement request.  Right now for
malloc-like calls, including calls with alloc_size argument, we do:
  if (arg1 < 0 || arg1 >= (int)gimple_call_num_args (call)
  || TREE_CODE (gimple_call_arg (call, arg1)) != INTEGER_CST
  || (arg2 >= 0
  && (arg2 >= (int)gimple_call_num_args (call)
  || TREE_CODE (gimple_call_arg (call, arg2)) != INTEGER_CST)))
return unknown[object_size_type];
So, the enhancement request would be for gimple_call_arg (call, argN) here
being an SSA_NAME instead of INTEGER_CST to try to prove some range instead
(and for the multiplication case do it with extra care because of possible
overflows).
I have reservations about using get_range_info for that though, the VRP stuff
is computed from many sources, including assumptions that undefined behavior
will not happen etc.  But, these builtins are primarily used for security
purposes, and the stuff it is guarding is also undefined behavior, so if
anything, it should do some cheap short walk of the operands and compute range
more conservatively (perhaps only allow SSA_NAME copies, perhaps casts, and
PHIs with all constant arguments or something similar?).

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

[nicolas.cavallari at lri dot fr]

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

--- Comment #8 from nicolas.cavallari at lri dot fr ---
While your minimal test case seems to be fixed, my test case still fails on GCC
6.2.0 (Debian):

The output is now:

Base ctor is called at 0x7fff79b27a14
A1::Base is at 0x7fff79b27a14
B1::Base is at 0x7fff79b27a14
Base ctor is called at 0x7fff79b27a10
A2::Base is at 0x7fff79b27a10
C::Base is at 0x7fff79b27a14
2 2 3


There is one less base constructor call, so we are getting there.

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[petschy at gmail dot com]

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

--- Comment #5 from petschy at gmail dot com ---
Some more details, hope this helps. Preprocessed one of the oddly behaving
files with 5.4.1, 6.2.1 and 7.0.0, then tried to compile each preprocessed file
with each compiler version. 5.4.1 warned for all preprocessed files, 6.2.1 and
7.0.0 didn't warn for any of them. This doesn't mean that 6.2.1 and 7.0.0 is
not affected, just for this particular file they didn't warn. 

Diffing the files revealed that there is no difference in the user code, only
in the system headers included, eg  comes from
/usr/local/include/c++/5.4.1/string for 5.4.1, etc.

All of the problematic lines are assignments of the form
  var = NULL;
or
  var1 = var2 = NULL;

ALL of the NULL assignments in the file are reported.
NONE of the == or != tests are reported.

Eg: this code warns:

AbstractImage::AbstractImage()
{
 pixels=
# 124 "common/src/AbstractImage.cpp" 3 4
   __null
# 124 "common/src/AbstractImage.cpp"
   ;
 channels_n=0;
 mode=255;
 width=-1;
 height=-1;
}

But if I replace 'pixels =' with 'bool b = pixels ==' above, the warning
disappears, which is strange, I think.

The flags are the same for the != and == tests, ie 
#  "common/src/AbstractImage.cpp" 3 4
is everywhere.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug c++/77616] New: A variadic polymorphic lambda call fails with zero arguments

[ville.voutilainen at gmail dot com]

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

Bug ID: 77616
   Summary: A variadic polymorphic lambda call fails with zero
arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test:

int main()
{
[](auto...){}();
}

prog.cc: In function 'int main()':
prog.cc:3:19: error: no match for call to '(main()::) ()'
 [](auto...){}();
   ^
prog.cc:3:15: note: candidate: template main()::::operator decltype (((const main()::*)((const
main()::*
const)0u))->operator()(static_cast())) (*)(auto:1, ...)()
const 
 [](auto...){}();
   ^
prog.cc:3:15: note:   template argument deduction/substitution failed:
prog.cc:3:19: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^
prog.cc:3:15: note: candidate: template main()::
 [](auto...){}();
   ^
prog.cc:3:15: note:   template argument deduction/substitution failed:
prog.cc:3:19: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:38:31 2016
New Revision: 240183

URL: https://gcc.gnu.org/viewcvs?rev=240183=gcc=rev
Log:
PR middle-end/77594
* internal-fn.c (expand_arith_overflow) : Don't fall
through into expand_addsub_overflow after expand_neg_overflow.

* gcc.target/i386/pr77594.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77594.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/internal-fn.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:37:50 2016
New Revision: 240182

URL: https://gcc.gnu.org/viewcvs?rev=240182=gcc=rev
Log:
Backported from mainline
2016-09-14  Jakub Jelinek  

PR sanitizer/68260
* tsan.c: Include target.h.
(enum tsan_atomic_action): Add bool_clear and bool_test_and_set.
(BOOL_CLEAR, BOOL_TEST_AND_SET): Define.
(tsan_atomic_table): Add BUILT_IN_ATOMIC_CLEAR and
BUILT_IN_ATOMIC_TEST_AND_SET entries.
(instrument_builtin_call): Handle bool_clear and bool_test_and_set.

* c-c++-common/tsan/pr68260.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/tsan/pr68260.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tsan.c

[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:37:08 2016
New Revision: 240181

URL: https://gcc.gnu.org/viewcvs?rev=240181=gcc=rev
Log:
Backported from mainline
2016-09-13  Jakub Jelinek  

PR c++/77553
* constexpr.c (cxx_fold_pointer_plus_expression): New function.
(cxx_eval_binary_expression): Use it for POINTER_PLUS_EXPR.
(cxx_eval_pointer_plus_expression): Remove.
(cxx_eval_constant_expression) : Don't
call cxx_eval_pointer_plus_expression.

* g++.dg/cpp1y/constexpr-77553.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-77553.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/77500] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:36:05 2016
New Revision: 240180

URL: https://gcc.gnu.org/viewcvs?rev=240180=gcc=rev
Log:
Backported from mainline
2016-09-08  Jakub Jelinek  

PR fortran/77500
* trans-openmp.c (gfc_trans_omp_atomic): For atomic write or
swap, don't try to look through GFC_ISYM_CONVERSION.  In other cases,
check that value.function.isym is non-NULL before dereferencing it.

* gfortran.dg/gomp/pr77500.f90: New test.

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

[Bug fortran/77516] ICE in is_gimple_min_invariant, at gimple-expr.c:706

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:35:23 2016
New Revision: 240179

URL: https://gcc.gnu.org/viewcvs?rev=240179=gcc=rev
Log:
Backported from mainline
2016-09-08  Jakub Jelinek  

PR fortran/77516
* omp-low.c (lower_rec_simd_input_clauses): Use max_vf for non-positive
OMP_CLAUSE_SAFELEN_EXPR.

* gfortran.dg/gomp/pr77516.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr77516.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/77615] Template specialization is resolved differently with and without optimizations turned on

[jan.bujak at nokia dot com]

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

--- Comment #2 from Jan Bujak  ---
(In reply to Markus Trippelsdorf from comment #1)
> Please read: https://isocpp.org/wiki/faq/templates
> 
> * Why can’t I separate the definition of my templates class from its
> declaration and put it inside a .cpp file?

Yes, I was aware of that, and it does make sense from a *technical* standpoint,
but I reported the bug anyway because this is a potential landmine waiting to
go off. You'll probably disagree, but for me changing the optimization level
should *not* subtly change the behavior of the code without even a warning!

If doing this is incorrect then the compiler should at least generate a warning
instead of silently generating wrong code. The compiler knows that the template
was defined in a header file, and it knows that the specialization was defined
in a .cpp file, so it could tell the user that "hey, that probably won't work
as you think it should; if you know what you're doing then feel free to silence
this warning".

[Bug target/69255] ICE on x86_64-linux-gnu in "emit_move_insn"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:34:44 2016
New Revision: 240178

URL: https://gcc.gnu.org/viewcvs?rev=240178=gcc=rev
Log:
Backported from mainline
2016-09-06  Jakub Jelinek  

PR target/69255
* config/i386/i386.c (ix86_expand_builtin): For builtin with
unsupported or unknown ISA, use expand_call.

* gcc.target/i386/pr69255-1.c: New test.
* gcc.target/i386/pr69255-2.c: New test.
* gcc.target/i386/pr69255-3.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr69255-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr69255-3.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:34:02 2016
New Revision: 240177

URL: https://gcc.gnu.org/viewcvs?rev=240177=gcc=rev
Log:
Backported from mainline
2016-09-05  Jakub Jelinek  

PR sanitizer/77396
* asan/asan_globals.cc: Cherry-pick upstream r280657.

* g++.dg/asan/pr77396-2.C: New test.

2016-09-02  Jakub Jelinek  

PR sanitizer/77396
* g++.dg/asan/pr77396.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/asan/pr77396-2.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/asan/pr77396.C
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libsanitizer/ChangeLog
branches/gcc-6-branch/libsanitizer/asan/asan_globals.cc

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 56625, which changed state.

Bug 56625 Summary: After if-conversion vectorizer doesn't recognize similar 
loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56625

   What|Removed |Added

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

[Bug tree-optimization/56625] After if-conversion vectorizer doesn't recognize similar loads

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Ah, maybe I'm wrong what S6_ stands for.  Anyway:
https://llvm.org/bugs/show_bug.cgi?id=30401#c1
has more details.  So NOTABUG?

[Bug tree-optimization/71354] [7 Regression] gcc.dg/vect/vect-23.c FAILs

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
If I read the mangled names correctly, the difference is in the compression of
the arguments of
art::ExceptionDetail::translate[abi:cxx11]
from which the address is taken, and the demangling doesn't show those
arguments at all.
GCC encodes them as S5_, i.e. 7th substitution, which is I belive
N3art6errors10ErrorCodesE
while LLVM emits
NS6_6errors10ErrorCodesE
where S6_ stands for I belive
3art
so those two are equivalent in what they expand to after substitution
expansion.
So the question is what the ABI exactly says, if different implementations have
to agree, I'd thought it should have chosen longest matching substitution, so
GCC would be correct.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #6 from Ramana Radhakrishnan  ---
Confirmed then.



Ramana

[Bug c++/77615] Template specialization is resolved differently with and without optimizations turned on

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Please read: https://isocpp.org/wiki/faq/templates

* Why can’t I separate the definition of my templates class from its
declaration and put it inside a .cpp file?