[Bug bootstrap/69310] New: [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

Bug ID: 69310
   Summary: [6 Regression] Revision r232454 breaks bootstrap on
x86_64-apple-darwin15
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: torvald at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: x86_64-apple-darwin15
 Build: x86_64-apple-darwin15

Revision r232454 breaks bootstrap on x86_64-apple-darwin15

...
libtool: compile:  /opt/gcc/build_c/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_c/./gcc -nostdinc++
-L/opt/gcc/build_c/x86_64-apple-darwin15.2.0/libstdc++-v3/src
-L/opt/gcc/build_c/x86_64-apple-darwin15.2.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_c/x86_64-apple-darwin15.2.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc6c/x86_64-apple-darwin15.2.0/bin/
-B/opt/gcc/gcc6c/x86_64-apple-darwin15.2.0/lib/ -isystem
/opt/gcc/gcc6c/x86_64-apple-darwin15.2.0/include -isystem
/opt/gcc/gcc6c/x86_64-apple-darwin15.2.0/sys-include
-I/opt/gcc/_clean/libstdc++-v3/../libgcc
-I/opt/gcc/build_c/x86_64-apple-darwin15.2.0/libstdc++-v3/include/x86_64-apple-darwin15.2.0
-I/opt/gcc/build_c/x86_64-apple-darwin15.2.0/libstdc++-v3/include
-I/opt/gcc/_clean/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c
../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc  -fno-common
-DPIC -D_GLIBCXX_SHARED -o cow-stdexcept.o
../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc: In function
'void _txnal_cow_string_C1_for_exceptions(void*, const char*, void*)':
../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70: warning:
unused parameter 'exc' [-Wunused-parameter]
 _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc)
  ^~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc: At global scope:
../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:380:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##C2EPKc (CLASS*, const char*)\
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:414:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(11logic_error, std::logic_error, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:393:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##C2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE( \
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:414:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(11logic_error, std::logic_error, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:401:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##D2Ev(CLASS*)  \
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:414:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(11logic_error, std::logic_error, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:380:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##C2EPKc (CLASS*, const char*)\
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:423:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(12domain_error, std::domain_error, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:393:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##C2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE( \
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:423:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(12domain_error, std::domain_error, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:401:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##D2Ev(CLASS*)  \
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:423:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(12domain_error, std::domain_error, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:380:1: error:
only weak aliases are supported in this configuration
 _ZGTtNSt##NAME##C2EPKc (CLASS*, const char*)\
 ^

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:424:1: note: in
expansion of macro 'CTORDTOR'
 CTORDTOR(16invalid_argument, std::invalid_argument, logic_error)
 ^~~~

../../../../../_clean/libstdc++-v3/src/c++11/cow-stdexcept.cc:393:1: error:
only weak aliases are supported 

[Bug fortran/61147] Incorrect behavior using function that returns deferred length character pointer

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
Fixed on trunk. I will wait a few weeks before fixing on 5-branch.

Paul

[Bug fortran/64324] Deferred character specific functions not permitted in generic operator interface

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
Fixed on trunk. I will wait a few weeks before fixing on 5-branch.

Paul

[Bug target/69311] [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
sorry, that should be -O3:

s390x-linux-gnu-gcc -std=c99 -Wall -march=zEC12 -O3 -c  tiny_psnr.i

[Bug target/69311] New: [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 69311
   Summary: [5 Regression] ICE (cc1 killed) on s390x-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen with the current gcc-5-branch, as well with a cross compiler, -O2 works,
4.9 and trunk work as well.

$ s390x-linux-gnu-gcc -std=c99 -Wall -march=zEC12 -O2 -c  tiny_psnr.i

[Bug fortran/60795] [4.9/5/6 Regression] Wrong length when allocating character array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #11 from Paul Thomas  ---
Fixed on trunk. I will wait a few weeks before fixing on 5-branch.

Paul

[Bug fortran/60593] ICE with deferred length variable in FORALL

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
Fixed on trunk. I will wait a few weeks before fixing on 5-branch.

Paul

[Bug fortran/39230] ASSOCIATED & undefined pointers

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Sorry for the noise - I didn't mean to touch this one!

Paul

[Bug target/69311] [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Killed just means you don't have enough memory.  So, if there is some
regression, it would be only if compiling the same preprocessed source takes
unreasonably more memory compared to older (or in this case also newer) gcc.

[Bug tree-optimization/69270] DOM should exploit range information to create more equivalences

[sch...@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab  ---
FAIL: gcc.target/aarch64/tst_3.c scan-assembler tst\t(x|w)[0-9]*.*1

[Bug fortran/39230] ASSOCIATED & undefined pointers

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
Fixed on trunk. I will wait a few weeks before fixing on 5-branch.

Paul

[Bug bootstrap/69312] [6 Regression] libstdc++ unconditionally refers to TM symbols

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix*
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-16
  Component|libstdc++   |bootstrap
 CC||jason at gcc dot gnu.org,
   ||torvald at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |6.0
   Severity|normal  |critical

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/69312] [6 Regression] libstdc++ unconditionally refers to TM symbols

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
stage1 libstdc++ builds, but stage2 configure fails because conftest programs
cannot link and run due to missing ITM_xxx symbols.

[Bug c++/69313] Compilation of gcc 5.3.0 has failed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Also due to environment variables:
https://gcc.gnu.org/ml/gcc-help/2015-06/msg00060.html

Please try cleaning your environment of any relevant variables. If that doesn't
help, please paste the output of "env" here.

[Bug c++/69313] Compilation of gcc 5.3.0 has failed

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
There have been a few reports of this error on the gcc-help mailing list. The
only person who reported solving it (as far as I know) said it was due to bad
values in the environment, see
https://gcc.gnu.org/ml/gcc-help/2015-09/msg00078.html

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug libstdc++/69293] scoped_allocator_adaptor::construct calls wrong function

[forever14 at bk dot ru]

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

--- Comment #5 from ForEveR  ---
Nice, thanks for fix and for defect report.

[Bug ipa/65076] [5/6 Regression] 16% tramp3d-v4.cpp compile time regression

[trippels at gcc dot gnu.org]

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

--- Comment #62 from Markus Trippelsdorf  ---
Well, to be fair one should compare -std=c++14 for all versions, else
you just measure the well known C++11 libstdc++ allocator overhead.

gcc-49(-std=c++14): 23.242 sec
gcc-5 (-std=c++14): 26.246
gcc-6 (-std=c++14): 27.306
clang-3.9 (-std=c++14): 41.636

gcc-49(-std=c++98): 22.574
gcc-5 (-std=c++98): 25.465
gcc-6 (-std=c++98): 26.799
clang-3.9 (-std=c++98): 35.816

[Bug tree-optimization/69292] [6 Regression][graphite] ICE with -floop-nest-optimize

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug libstdc++/69312] New: [6 Regression] libstdc++ unconditionally refers to TM symbols

[dje at gcc dot gnu.org]

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

Bug ID: 69312
   Summary: [6 Regression] libstdc++ unconditionally refers to TM
symbols
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

r232454 broke bootstrap on AIX, which does not include TM support.

[Bug tree-optimization/69292] [6 Regression][graphite] ICE with -floop-nest-optimize

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[graphite] ICE with |[6 Regression][graphite]
   |-floop-nest-optimize|ICE with
   ||-floop-nest-optimize

--- Comment #4 from vries at gcc dot gnu.org ---
passes with gcc-5-branch, marking as 6 regression.

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #7 from Paul Thomas  ---
Fixed on trunk. I will wait a few weeks before fixing on 5-branch.

Paul

[Bug c++/69313] New: Compilation of gcc 5.3.0 has failed

[aaahaaah at yandex dot ru]

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

Bug ID: 69313
   Summary: Compilation of gcc 5.3.0 has failed
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaahaaah at yandex dot ru
  Target Milestone: ---

(***) Compilation of gcc 5.3.0 has failed on two systems with the same error:
RedHat 7.1, 64-bit, Power 7, compiler gcc-4.8.3
Ubuntu 14.04, 64-bit, x64-86, compiler gcc-4.8.4
(***) Build commands:
tar xjf gcc-5.3.0.tar.bz2
cd gcc-5.3.0
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
(../gcc-5.3.0/configure --prefix=${HOME}/localsoftppc/mygcc  \
--disable-multilib   \
--disable-bootstrap  \
--with-system-zlib   \
--enable-languages=c,c++,fortran) && \
(make) && \
(make install)
I tried with and without "--disable-bootstrap" and "--with-system-zlib" - the
same behaviour.
(***) Error:
...
rm -f include-fixed/README
cp /home/albert/tmp/objdir/../gcc-5.3.0/gcc/../fixincludes/README-fixinc
include-fixed/README
chmod a+r include-fixed/README
echo timestamp > stmp-int-hdrs
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET " \
/bin/sh /home/albert/tmp/objdir/../gcc-5.3.0/gcc/mkconfig.sh tconfig.h
g++ -c  -DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/home/albert/localsoftppc/mygcc/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/home/albert/localsoftppc/mygcc/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"5.3.0\"
-DDEFAULT_REAL_TARGET_MACHINE=\"powerpc64-unknown-linux-gnu\"
-DDEFAULT_TARGET_MACHINE=\"powerpc64-unknown-linux-gnu\"
-DSTANDARD_BINDIR_PREFIX=\"/home/albert/localsoftppc/mygcc/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\" -DACCEL_DIR_SUFFIX=\"\" 
-DENABLE_SHARED_LIBGCC -DCONFIGURE_SPECS="\"\"" -DIN_GCC_FRONTEND -g -O2
-DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Icp
-I/home/albert/tmp/objdir/../gcc-5.3.0/gcc
-I/home/albert/tmp/objdir/../gcc-5.3.0/gcc/cp
-I/home/albert/tmp/objdir/../gcc-5.3.0/gcc/../include
-I/home/albert/tmp/objdir/../gcc-5.3.0/gcc/../libcpp/include
-I/home/albert/tmp/objdir/./gmp -I/home/albert/tmp/gcc-5.3.0/gmp
-I/home/albert/tmp/objdir/./mpfr -I/home/albert/tmp/gcc-5.3.0/mpfr
-I/home/albert/tmp/gcc-5.3.0/mpc/src 
-I/home/albert/tmp/objdir/../gcc-5.3.0/gcc/../libdecnumber
-I/home/albert/tmp/objdir/../gcc-5.3.0/gcc/../libdecnumber/dpd
-I../libdecnumber -I/home/albert/tmp/objdir/../gcc-5.3.0/gcc/../libbacktrace
-I/home/albert/tmp/objdir/./isl/include
-I/home/albert/tmp/gcc-5.3.0/isl/include  -o cp/g++spec.o -MT cp/g++spec.o -MMD
-MP -MF cp/.deps/g++spec.TPo
/home/albert/tmp/objdir/../gcc-5.3.0/gcc/cp/g++spec.c
g++   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H  -o xg++ \
  gcc.o gcc-main.o ggc-none.o cp/g++spec.o driver-rs6000.o  libcommon-target.a
\
   libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
g++: fatal error: braced spec
‘%:sanitize(address):%{!shared:libasan_preinit%O%s}
%{static-libasan:%{!shared:-Bstatic --whole-archive -lasan --no-whole-archive
-Bdynamic}}%{!static-libasan:-lasan}}
%{%:sanitize(thread):%{static-libtsan:%{!shared:-Bstatic --whole-archive -ltsan
--no-whole-archive -Bdynamic}}%{!static-libtsan:-ltsan}}
%{%:sanitize(leak):%{static-liblsan:%{!shared:-Bstatic --whole-archive -llsan
--no-whole-archive -Bdynamic}}%{!static-liblsan:-llsan}}’ is invalid at ‘%’
compilation terminated.
make[2]: *** [xg++] Error 4
make[2]: Leaving directory `/home/albert/tmp/objdir/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/albert/tmp/objdir'
make: *** [all] Error 2

[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-16
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from Martin Sebor  ---
I suspect the problem was introduced in r228017 which temporarily sets
flag_abi_version to warn_abi_version to determine if the mangling of the entity
is different in the version specified by -Wabi=.

The change below seems to fix it.  Let me add a test and post a patch for
review.

@@ -3658,13 +3670,13 @@ mangle_decl (const tree decl)
"the mangled name of %qD changed between "
"-fabi-version=%d (%D) and -fabi-version=%d (%D)",
G.entity, warn_abi_version, id2,
-   flag_abi_version, id);
+   save_ver, id);
  else
warning_at (DECL_SOURCE_LOCATION (G.entity), OPT_Wabi,
"the mangled name of %qD changes between "
"-fabi-version=%d (%D) and -fabi-version=%d (%D)",
G.entity, flag_abi_version, id,
-   warn_abi_version, id2);
+   save_ver, id2);
}

   flag_abi_version = save_ver;

[Bug c++/69323] [4.9/5/6 Regression] Segmentation fault when instantiating class template with inner class which declares itself as a friend

[bd at jollyrogerlabs dot com]

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

--- Comment #3 from Brian Davis  ---
I just ran downstairs and used this to break g++ 4.9.2 running on Ubuntu 15.04
as well, using my original source file.  Here's the compiler version string,
and I'll attach the preprocessed file:

$ g++ --version
g++ (Ubuntu 4.9.2-10ubuntu13) 4.9.2

[Bug c++/69323] [4.9/5/6 Regression] Segmentation fault when instantiating class template with inner class which declares itself as a friend

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-17
   Target Milestone|--- |4.9.4
Summary|Segmentation fault when |[4.9/5/6 Regression]
   |instantiating class |Segmentation fault when
   |template with inner class   |instantiating class
   |which declares itself as a  |template with inner class
   |friend  |which declares itself as a
   ||friend
 Ever confirmed|0   |1
  Known to fail||4.7.0, 6.0

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
template
struct Outer
{
  struct StupidValueTrick
  {
template friend struct Outer::StupidValueTrick;
  };
};
typedef Outer<42>::StupidValueTrick GoodValue;
GoodValue good;
---CUT ---
Confirmed.

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #10 from Marc Glisse  ---
With -fno-trapping-math, the replacement && -> & is done while gimplifying.
-ftrapping-math (the default) disables it there, but the transformation is
still performed later by ifcombine. That's not consistent.

By the way, we seem to be missing an optimization (x ord x) & (x > 0.0) => x >
0.0.

[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/69311] [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
4.9 and 6 build within under a second, I didn't even look at the memory usage. 
5 was killed automatically on a VM with 8G RAM + 6G swap; killed the cross
build manually when reaching 16GB.

[Bug c++/69315] New: ICE in finish_function with constexpr and templates

[gerrit.los at gmail dot com]

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

Bug ID: 69315
   Summary: ICE in finish_function with constexpr and templates
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerrit.los at gmail dot com
  Target Milestone: ---

Created attachment 37373
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37373=edit
reduced test case (27 lines)

The attached reduced test case fails with an ICE in finish_function
with current GCC.
G++ gcc version 5.3.1 20160101 (Debian 5.3.1-5) works fine.



GNU C++11 (GCC) version 6.0.0 20160116 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20160116 (experimental), GMP version
6.0.0, MPFR version 3.1.3-p5, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (GCC) version 6.0.0 20160116 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20160116 (experimental), GMP version
6.0.0, MPFR version 3.1.3-p5, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 902ad622abb081912322ce9873f62a84
iter.C.i: In instantiation of ‘constexpr bool operator==(Iter, Iter)
[with bool C1 = true; bool C2 = true; bool  = true]’:
iter.C.i:27:1:   required from ‘constexpr bool operator!=(Iter, Iter)
[with bool C1 = true; bool C2 = true; bool  = true]’
iter.C.i:16:18:   required from here
iter.C.i:23:1: internal compiler error: in finish_function, at cp/decl.c:14508

[Bug c++/69302] Using bswap in template function with -ftrack-macro-expansion=0 results in a false compiler error

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||manu at gcc dot gnu.org
  Known to fail||6.0

--- Comment #3 from Manuel López-Ibáñez  ---
./test.cc:4:124: error: address requested for ‘__x’, which is declared
‘register’ [-Werror=extra]
   return (__extension__ ({ register unsigned int __v, __x = (0x0FFF); if
(__builtin_constant_p (__x)) __v = __x) & 0xff00) >> 24) | (((__x) &
0x00ff) >> 8) | (((__x) & 0xff00) << 8) | (((__x) & 0x00ff) <<
24)); else __asm__ ("bswap %0"\
 : "=r" (__v) : "0" (__x)); __v; }));
   
^~

;; Function unsigned int foo() [with BLAH = int] (null)
;; enabled by -tree-original


{
  < = {
register unsigned int __v;
register unsigned int __x = 4095;

register unsigned int __v;
<>;
if (0)
  {
<> 24 | *(unsigned int &) &__x >> 8 &
65280) | *(unsigned int &) &__x << 8 & 16711680) | *(unsigned int &) &__x <<
24) >;
  }
else
  {
<>;
  }
__v
  }>>;
}

[Bug fortran/66094] Handle transpose(A) in inline matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Created attachment 37371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37371=edit
Patch to handle matmul(a, transpose(b))

This very straightforward patch handles matmul(a, transpose(b)).

I wonder if it would still be suitable for the current status on trunk...

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37364|0   |1
is obsolete||

--- Comment #5 from H.J. Lu  ---
Created attachment 37372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37372=edit
An updated patch

This patch also changes LRA to skip bad MEM.  Although there are no
regressions on x86-64, there could be latent issues.  Someone should
exam IRA/LRA to see if it is OK.

[Bug fortran/66094] Handle transpose(A) in inline matmul

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #3)
> Created attachment 37371 [details]
> Patch to handle matmul(a, transpose(b))
> 
> This very straightforward patch handles matmul(a, transpose(b)).
> 
> I wonder if it would still be suitable for the current status on trunk...

I think it is important enough and the patch is narrow in scope and relatively
safe, so I vote it in as soon as possible.

[Bug other/69314] New: Use of uninitialised value in libbacktrace/pecoff.c

[ranma42 at gmail dot com]

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

Bug ID: 69314
   Summary: Use of uninitialised value in libbacktrace/pecoff.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ranma42 at gmail dot com
  Target Milestone: ---

In coff_add(), str_size is declared as a size_t, but if there is a symbol
table, only 4 bytes of it are initialised:

memcpy (_size, syms_view.data + syms_size, 4);

str_size should probably be declared as a uint32_t.

The bug at https://github.com/rust-lang/rust/issues/28447 was caused by this.
It was fixed in Rust local copy of libbacktrace:
https://github.com/rust-lang/rust/commit/55e2b7e1b4606ae0bc684293f011b7006d1f1258

[Bug tree-optimization/69292] [6 Regression][graphite] ICE with -floop-nest-optimize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug fortran/66094] Handle transpose(A) in inline matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Additional comment. I hope Toon could test this on real world code and confirm.

[Bug c++/69317] New: [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

Bug ID: 69317
   Summary: [6 regression] wrong ABI version in -Wabi warnings
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While adding an ABI warning in the patch for bug 69277 I noticed that the text
of the -Wabi diagnostics issued by GCC 6.0 has changed from that of 5.1.0 in an
unexpected way.  While 5.1.0 prints the versions of the ABI before and after
the the change, 6.0 seems to print the same version for both, sometimes zero,
sometimes not.  This doesn't seem correct so I'm marking this a regression.

The "both zero" example can be seen in the GCC output on the
g++.dg/abi/mangle3.C test shown below where 6.0 prints:

warning: the mangled name of ‘...’ changes between -fabi-version=0 (...)
and -fabi-version=0 (...) [-Wabi]

$ (f=/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle3.C; set -x &&
cat $f && ~/bin/gcc-5.1.0/bin/g++ -S -Wall -Wabi -fabi-version=2 $f &&
/home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wabi -fabi-version=2 $f)
+ cat /home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle3.C
// Test mangling of type casts
// { dg-options "-fabi-version=2 -Wabi" }
// { dg-do compile }

template class A {};
template class B {};

template void f(A &, B &) {}
template void g(A &, B &) {} // { dg-warning
"mangle" }

int main()
{
  A<1> a;
  B b;
  f(a, b);
  g(a, b);
}

// { dg-final { scan-assembler "\n_?_Z1fILi1EEvR1AIXT_EER1BIXcvbT_EE\[: \t\n\]"
} }
// { dg-final { scan-assembler "\n_?_Z1gILi1EEvR1AIXT_EER1BIXcvbT_EE\[: \t\n\]"
} }
+ /home/msebor/bin/gcc-5.1.0/bin/g++ -S -Wall -Wabi -fabi-version=2
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle3.C
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle3.C:9:22: warning:
the mangled name of ‘void g(A&, B&) [with int i = 1]’
changes between -fabi-version=2 (_Z1gILi1EEvR1AIXT_EER1BIXcvbT_EE) and
-fabi-version=0 (_Z1gILi1EEvR1AIXT_EER1BIXscbT_EE) [-Wabi]
 template void g(A &, B &) {} // { dg-warning
"mangle" }
  ^
+ /home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wabi -fabi-version=2
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle3.C
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle3.C:9:22: warning:
the mangled name of ‘void g(A&, B&) [with int i = 1]’
changes between -fabi-version=0 (_Z1gILi1EEvR1AIXT_EER1BIXcvbT_EE) and
-fabi-version=0 (_Z1gILi1EEvR1AIXT_EER1BIXscbT_EE) [-Wabi]
 template void g(A &, B &) {} // { dg-warning
"mangle" }
  ^

An example where the warning is similarly incorrect but where the ABI version
is non-zero is the following where 6.0 prints:

warning: the mangled name of ‘...’ changed between -fabi-version=4 (...)
and -fabi-version=4 (...) [-Wabi]

$ (f=/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle45.C; set -x
&& cat $f && ~/bin/gcc-5.1.0/bin/g++ -S -Wall -Wabi=4 -fabi-version=5
-std=c++11 $f && /home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wabi=4 -fabi-version=5
-std=c++11 $f)
+ cat /home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle45.C
// Testcase for mangling of parameters used other than in a trailing return
type
// { dg-do compile { target c++11 } }
// { dg-options "-fabi-version=5 -Wabi=4" }

template void f(T p, decltype(p)) { }   // L = 1 { dg-warning
"mangle" }
template void g(T p, decltype(p) (*)()) { } // L = 1 { dg-warning
"mangle" }
// G++ incorrectly rejects these currently.
// template void h(T p, auto (*)()->decltype(p));// L = 1
// template void i(T p, auto (*)(T q)->decltype(q)); // L = 0
// template void j(T p, auto (*)(decltype(p))->T);   // L = 2
template void k(T p, int (*(*)(T* p))[sizeof(p)]) {} // L = 1 {
dg-warning "mangle" }

int garg();
int (*karg (int*))[sizeof(int)];
int main()
{
  // { dg-final { scan-assembler  "\n_?_Z1fIiEvT_DtfL0p_E\[: \t\n\]" } }
  f (1,0);
  // { dg-final { scan-assembler  "\n_?_Z1gIiEvT_PFDtfL0p_EvE\[: \t\n\]" } }
  g (1,garg);
  // h (1,0);
  // i (1,0);
  // j (1,0);
  // { dg-final { scan-assembler  "\n_?_Z1kIiEvT_PFPAszfL0p__iPS0_E\[: \t\n\]"
} }
  k (1,karg);
}
+ /home/msebor/bin/gcc-5.1.0/bin/g++ -S -Wall -Wabi=4 -fabi-version=5
-std=c++11 /home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle45.C
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle45.C:11:24:
warning: the mangled name of ‘void k(T, int (* (*)(T*))[sizeof (p)]) [with T =
int’ changed between -fabi-version=4 (_Z1kIiEvT_PFPAszfp__iPS0_E) and
-fabi-version=5 (_Z1kIiEvT_PFPAszfL0p__iPS0_E) [-Wabi]
 template void k(T p, int (*(*)(T* 

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

[bugzil...@reto-schneider.ch]

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

--- Comment #8 from bugzil...@reto-schneider.ch ---
(In reply to bugzillas from comment #7)
> I did some bisecting. r219770 is the commit which breaks my example.

...or just exposes an already existing failure.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to bugzillas from comment #8)
> (In reply to bugzillas from comment #7)
> > I did some bisecting. r219770 is the commit which breaks my example.
> 
> ...or just exposes an already existing failure.

No it just exposes the problem of using futex system calls with TSAN.

[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[torvald at gcc dot gnu.org]

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

--- Comment #2 from torvald at gcc dot gnu.org ---
(In reply to İsmail Dönmez from comment #1)
> r232454 also breaks bootstrap for mingw-w64:
> 
> libtool: compile:  x86_64-w64-mingw32-c++
> -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
> -L/havana/mingw-w64-6.0.0/mingw/lib -isystem
> /havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
> /havana/mingw-w64-6.0.0/mingw/include
> -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
> -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/
> include/x86_64-w64-mingw32
> -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/
> include -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++
> -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
> -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
> -ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c
> ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc -o
> cow-stdexcept.o
> ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70:
> warning: unused parameter 'exc' [-Wunused-parameter]
>  _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc)
>   ^
> ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc: In
> function 'void* txnal_read_ptr(void* const*)':
> ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
> error: expected ',' before ')' token
>|| sizeof(uint32_t) == sizeof(void*));
>^
> ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
> error: expected string-literal before ')' token

is mingw's static_assert any different?  Right now, I can't see how this could
produce this error:

  static_assert(sizeof(uint64_t) == sizeof(void*)
|| sizeof(uint32_t) == sizeof(void*));

[Bug tree-optimization/69320] New: wrong code generation at -O2 and higher

[jamrial at gmail dot com]

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

Bug ID: 69320
   Summary: wrong code generation at -O2 and higher
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 37377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37377=edit
Assembly and preprocessed output of miscompiled file

http://fate.ffmpeg.org/report.cgi?time=20160116195307=x86_64-archlinux-gcc-experimental
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/svq1enc.c;h=1e1745e7b10ed24e8a600d643b5aa951317f2aba;hb=HEAD

FFmpeg's svq1 encoder is being miscompiled by GCC 6 starting with revision
r232361. I'm attaching example assembly of the last good commit and the first
bad, alongside the preprocessed output.

To reproduce the issue you can download ffmpeg and run the fate svq1 tests (no
external samples needed to run), which will fail and create output video files
full of artifacts from the revision mentioned above onward:
git clone https://git.videolan.org/git/ffmpeg.git && cd ffmpeg && ./configure
&& make fate-vsynth{1,2,3}-svq1

[Bug c++/69302] parentheses cause address of register variable to be requested

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
C++14 changes parentheses slightly.  In that it causes them to be a lvalue
still if it was a lvalue.

[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[ismail at i10z dot com]

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

İsmail Dönmez  changed:

   What|Removed |Added

 CC||ismail at i10z dot com

--- Comment #1 from İsmail Dönmez  ---
r232454 also breaks bootstrap for mingw-w64:

libtool: compile:  x86_64-w64-mingw32-c++
-L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
-L/havana/mingw-w64-6.0.0/mingw/lib -isystem
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
/havana/mingw-w64-6.0.0/mingw/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++ -std=gnu++11
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c
../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc -o
cow-stdexcept.o
../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70:
warning: unused parameter 'exc' [-Wunused-parameter]
 _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc)
  ^
../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc: In
function 'void* txnal_read_ptr(void* const*)':
../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
error: expected ',' before ')' token
   || sizeof(uint32_t) == sizeof(void*));
   ^
../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
error: expected string-literal before ')' token

[Bug target/68609] PowerPC reciprocal estimate missed opportunities

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
Author: dje
Date: Sat Jan 16 20:04:33 2016
New Revision: 232468

URL: https://gcc.gnu.org/viewcvs?rev=232468=gcc=rev
Log:
PR target/68609
* gcc.target/powerpc/recip-6.c: Enable on AIX.
* gcc.target/powerpc/recip-7.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/recip-6.c
trunk/gcc/testsuite/gcc.target/powerpc/recip-7.c

[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[ismail at i10z dot com]

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

--- Comment #3 from İsmail Dönmez  ---
(In reply to torvald from comment #2)
> (In reply to İsmail Dönmez from comment #1)
> > r232454 also breaks bootstrap for mingw-w64:
> > 
> > libtool: compile:  x86_64-w64-mingw32-c++
> > -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
> > -L/havana/mingw-w64-6.0.0/mingw/lib -isystem
> > /havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
> > /havana/mingw-w64-6.0.0/mingw/include
> > -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
> > -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/
> > include/x86_64-w64-mingw32
> > -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/
> > include -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++
> > -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
> > -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
> > -ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c
> > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc -o
> > cow-stdexcept.o
> > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70:
> > warning: unused parameter 'exc' [-Wunused-parameter]
> >  _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc)
> >   ^
> > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc: In
> > function 'void* txnal_read_ptr(void* const*)':
> > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
> > error: expected ',' before ')' token
> >|| sizeof(uint32_t) == sizeof(void*));
> >^
> > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
> > error: expected string-literal before ')' token
> 
> is mingw's static_assert any different?  Right now, I can't see how this
> could produce this error:
> 
>   static_assert(sizeof(uint64_t) == sizeof(void*)
>   || sizeof(uint32_t) == sizeof(void*));

g++-5 on Linux does not compile that either, clang is more helpful to why:

t.cpp:5:85: warning: static_assert with no message is a C++1z extension
[-Wc++1z-extensions]

So, just adding a message to static_assert fixes the issue here.

[Bug c++/69318] New: [6 regression] ICE in symtab_node::verify with -fabi-version=7 -Wabi=8 -m32

[msebor at gcc dot gnu.org]

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

Bug ID: 69318
   Summary: [6 regression] ICE in symtab_node::verify with
-fabi-version=7 -Wabi=8 -m32
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing the -fabi-version= and -Wabi options for a patch for bug 69277 I
came across the following ICE.  5.1.0 compiles the code successfully so I'm
marking this a regression.

For reference, the since resolved bug 65531 reported against 5.0 points out
another problem triggered by the function but for a different test case and
with slightly different symptoms and stack trace.

$ (f=/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle-regparm.C;
cat $f && /home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -fabi-version=7 -Wabi=8 -m32 -o
/dev/null -xc++ $f)
// { dg-do run { target { { i?86-*-* x86_64-*-* } && ia32 } } }
// { dg-options "-Wabi=8 -save-temps" }
// { dg-final { scan-assembler
"_Z18IndirectExternCallIPU7stdcallU7regparmILi3EEFviiEiEvT_T0_S3_" } }

typedef __SIZE_TYPE__ size_t;

template 
void IndirectExternCall(F f, T t1, T t2) { // { dg-warning "mangled name" }
  typedef F (*WrapF)(F);
  f (t1, t2);
}

__attribute__((regparm(3), stdcall))
void regparm_func (int i, int j)
{
  if (i != 24 || j != 42)
__builtin_abort();
}

void normal_func (int i, int j)
{
  if (i != 24 || j != 42)
__builtin_abort();
}

int main()
{
  IndirectExternCall (regparm_func, 24, 42);
  IndirectExternCall (normal_func, 24, 42);
}
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle-regparm.C: In
function ‘void IndirectExternCall(F, T, T)’:
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle-regparm.C:9:15:
warning: typedef ‘WrapF’ locally defined but not used [-Wunused-local-typedef]
   typedef F (*WrapF)(F);
   ^

/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle-regparm.C: At
global scope:
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle-regparm.C:30:1:
error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
 }
 ^

_Z18IndirectExternCallIPFviiEiEvT_T0_S3_/4 (void IndirectExternCall(F, T, T)
[with F = void (*)(int, int); T = int]) @0x7f0eb93585c0
  Type: function definition analyzed
  Visibility: public weak comdat
comdat_group:_Z18IndirectExternCallIPFviiEiEvT_T0_S3_ one_only
  previous sharing asm name: 3
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: main/2 (1.00 per call) (can throw external) 
  Calls: 
   Indirect call(1.00 per call) (can throw external) 
_Z18IndirectExternCallIPFviiEiEvT_T0_S3_/3 (void IndirectExternCall(F, T, T)
[with F = void (__attribute__((stdcall, regparm(3))) *)(int, int); T = int])
@0x7f0eb9358450
  Type: function definition analyzed
  Visibility: public weak comdat
comdat_group:_Z18IndirectExternCallIPFviiEiEvT_T0_S3_ one_only
  next sharing asm name: 4
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: main/2 (1.00 per call) (can throw external) 
  Calls: 
   Indirect call(1.00 per call) (can throw external) 
/home/msebor/scm/fsf/gcc-svn/gcc/testsuite/g++.dg/abi/mangle-regparm.C:30:1:
internal compiler error: symtab_node::verify failed
0xb5e535 symtab_node::verify_symtab_nodes()
/home/msebor/scm/fsf/gcc-svn/gcc/symtab.c:1212
0xb7c4a0 symtab_node::checking_verify_symtab_nodes()
/home/msebor/scm/fsf/gcc-svn/gcc/cgraph.h:602
0xb7bb4e symbol_table::compile()
/home/msebor/scm/fsf/gcc-svn/gcc/cgraphunit.c:2371
0xb7bfb1 symbol_table::finalize_compilation_unit()
/home/msebor/scm/fsf/gcc-svn/gcc/cgraphunit.c:2553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/69003] [4.9/5/6 Regression] Undefined reference with gcc -r incremental linking

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Looks like a pasto in rename_statics.  I am testing:
Index: lto/lto-partition.c
===
--- lto/lto-partition.c (revision 232466)
+++ lto/lto-partition.c (working copy)
@@ -1077,8 +1077,8 @@ rename_statics (lto_symtab_encoder_t enc
  IDENTIFIER_POINTER
(DECL_ASSEMBLER_NAME (s->get_alias_target()->decl
&& ((s->real_symbol_p ()
- && !DECL_EXTERNAL (node->decl)
-&& !TREE_PUBLIC (node->decl))
+ && !DECL_EXTERNAL (s->decl)
+&& !TREE_PUBLIC (s->decl))
|| may_need_named_section_p (encoder, s))
&& (!encoder
|| lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_FOUND))

[Bug c/69319] New: Suspect compiler bug

[freddy77 at gmail dot com]

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

Bug ID: 69319
   Summary: Suspect compiler bug
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddy77 at gmail dot com
  Target Milestone: ---

Created attachment 37374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37374=edit
test program, single C file with only system includes

Hi, I found a strange problem with optimized code.
The code uses an hand written dynamic double linked list (circular).
There are some trick to make see the list as an item of the list.
After some work I manage to get a small test program.
I don't really understand why this specific code crash.
Trying to read the assembly code (x86_64) looks like the compiler is assuming
some value on first iteration of the a "check" loop causing an assertion to
fail.
I tested the program with Ubuntu 15.10 compiler (5.2.1) and a Fedora 22
(5.3.1), all x86_64.

Test program is really small. I manage to get a single C file only with system
includes.

[Bug c/69319] Suspect compiler bug

[freddy77 at gmail dot com]

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

--- Comment #1 from Frediano Ziglio  ---
Created attachment 37375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37375=edit
.i file of the single source program

[Bug c/69319] Suspect compiler bug

[freddy77 at gmail dot com]

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

--- Comment #3 from Frediano Ziglio  ---
Created attachment 37376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37376=edit
original file split into pure C + main

I don't know if may help (I hope so).
I split the file into a pure C (no extra include beside a member.h that does
not include anything) and a main.c file which just include some standard
header.
Included the small Makefile and the .i file for member.c.
The options are just "-Wall -Wstrict-aliasing -O2 -Wextra", no warning are
produced.
Note: removing the noreturn attribute or the malloc attribute make the program
work correctly. I suspect is some aliasing problem (perhaps I don't consider
something and is just my fault).

[Bug middle-end/61199] [trans-mem] _cxa_free_exception is not transaction safe

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c/69319] Suspect compiler bug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Frediano Ziglio from comment #4)
> -O0, -O1 or -fno-strict-aliasing all works.
> 
> But I don't understand how gcc can generate such code.
> What am I missing?

member and members struct access cannot alias.  Please read up about C aliasing
rules.

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|wrong code generation at|[6 Regression] wrong code
   |-O2 and higher  |generation at -O2 and
   ||higher

[Bug c++/69302] parentheses cause address of register variable to be requested

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jason at redhat dot com
Summary|Using bswap in template |parentheses cause address
   |function with   |of register variable to be
   |-ftrack-macro-expansion=0   |requested
   |results in a false compiler |
   |error   |

--- Comment #4 from Manuel López-Ibáñez  ---
template 
unsigned int foo()
{
  register unsigned int __x = 0x0FFF;
  return (__x) & 0xff00 ;
}

The parentheses are significant!

[Bug c++/69302] parentheses cause address of register variable to be requested (c++1y)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|parentheses cause address   |parentheses cause address
   |of register variable to be  |of register variable to be
   |requested   |requested (c++1y)

--- Comment #6 from Manuel López-Ibáñez  ---
Related: Bug 59681

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

[bugzil...@reto-schneider.ch]

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

--- Comment #7 from bugzil...@reto-schneider.ch ---
I did some bisecting. r219770 is the commit which breaks my example.

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

[bugzil...@reto-schneider.ch]

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

--- Comment #10 from bugzil...@reto-schneider.ch ---
Which is a known limitation or something that can/will be fixed?

[Bug c/69319] Suspect compiler bug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
>   item->next = (member *) idle_members;


I want to bet there is an alias violation in the code.

Does this code work at -O0 and -O1 but not at -O2?  Try -fno-strict-aliasing.

[Bug middle-end/61199] [trans-mem] _cxa_free_exception is not transaction safe

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from torvald at gcc dot gnu.org ---
Fixed in 230634.

[Bug lto/69003] [4.9/5/6 Regression] Undefined reference with gcc -r incremental linking

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
incremental linking is supposed to work in GCC 6. I will take a look.

[Bug c/69319] Suspect compiler bug

[freddy77 at gmail dot com]

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

--- Comment #4 from Frediano Ziglio  ---
-O0, -O1 or -fno-strict-aliasing all works.

But I don't understand how gcc can generate such code.
What am I missing?

[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[torvald at gcc dot gnu.org]

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

--- Comment #4 from torvald at gcc dot gnu.org ---
(In reply to İsmail Dönmez from comment #3)
> (In reply to torvald from comment #2)
> > (In reply to İsmail Dönmez from comment #1)
> > > r232454 also breaks bootstrap for mingw-w64:
> > > 
> > > libtool: compile:  x86_64-w64-mingw32-c++
> > > -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
> > > -L/havana/mingw-w64-6.0.0/mingw/lib -isystem
> > > /havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
> > > /havana/mingw-w64-6.0.0/mingw/include
> > > -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
> > > -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/
> > > include/x86_64-w64-mingw32
> > > -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/
> > > include -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++
> > > -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
> > > -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
> > > -ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 
> > > -c
> > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc -o
> > > cow-stdexcept.o
> > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70:
> > > warning: unused parameter 'exc' [-Wunused-parameter]
> > >  _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc)
> > >   ^
> > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc: In
> > > function 'void* txnal_read_ptr(void* const*)':
> > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
> > > error: expected ',' before ')' token
> > >|| sizeof(uint32_t) == sizeof(void*));
> > >^
> > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39:
> > > error: expected string-literal before ')' token
> > 
> > is mingw's static_assert any different?  Right now, I can't see how this
> > could produce this error:
> > 
> >   static_assert(sizeof(uint64_t) == sizeof(void*)
> > || sizeof(uint32_t) == sizeof(void*));
> 
> g++-5 on Linux does not compile that either, clang is more helpful to why:
> 
> t.cpp:5:85: warning: static_assert with no message is a C++1z extension
> [-Wc++1z-extensions]
> 
> So, just adding a message to static_assert fixes the issue here.

Ah, right.

See https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01203.html
(Not linked to this bug because this bug is about the darwin breakage.)

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Created attachment 37378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37378=edit
A followup patch to call constraint_satisfied_p to check memory operand

[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Slightly tweaked patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01206.html

[Bug libstdc++/69321] New: Error on use of non-copyable type with any_cast

[kaballo86 at hotmail dot com]

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

Bug ID: 69321
   Summary: Error on use of non-copyable type with any_cast
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaballo86 at hotmail dot com
  Target Milestone: ---

The following snippet fails with an error due to use of a deleted function:

#include 

struct noncopyable {
  noncopyable(noncopyable const&) = delete;
};

int main() {
  std::experimental::any a;
  std::experimental::any_cast();
}

The `any_cast` overloads taking pointers have no requirements, so this should
compile and return `nullptr` instead.

[Bug tree-optimization/69322] New: wrong code at -O3 on x86-64-linux-gnu (in 32- and 64-bit modes)

[chengniansun at gmail dot com]

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

Bug ID: 69322
   Summary: wrong code at -O3 on x86-64-linux-gnu (in 32- and
64-bit modes)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code is miscompiled by the gcc trunk at -O3 in both 32-bit and
32-bit modes on x86_64-linux-gnu. 



$: 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160116 (experimental) [trunk revision 232466] (GCC) 
$: 
$: 
$: gcc-trunk small.c -O3 -m32 ; ./a.out
g_620=0
$: gcc-trunk small.c -O3 -m64 ; ./a.out
g_620=0
$: gcc-trunk small.c -O0 ; ./a.out
g_620=1
$: 
$: cat small.c
int printf(const char*, ...);

int a;
char b, d;
short c;
short fn1(int p1, int p2) { return p2 >= 2 ? p1 : p1 > p2; }

int main() {
  int *e = , *f = 
  b = 1;
  for (; b <= 9; b++) {
c = *e != 5 || d;
*f = fn1(c || b, a);
  }
  printf("g_620=%lld\n", (long long)a);
  return 0;
}
$:

[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286

[kugan at gcc dot gnu.org]

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

--- Comment #6 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sun Jan 17 02:44:26 2016
New Revision: 232481

URL: https://gcc.gnu.org/viewcvs?rev=232481=gcc=rev
Log:
2016-01-17  Kugan Vivekanandarajah  

Backport from mainline
2016-01-12  Kugan Vivekanandarajah  
Jim Wilson  

PR target/69194
* config/arm/arm-builtins.c (arm_expand_neon_args): Call
copy_to_mode_reg instead of force_reg.

2016-01-17  Kugan Vivekanandarajah  

Backport from mainline
2016-01-12  Kugan Vivekanandarajah  
Jim Wilson  

PR target/69194
* gcc.target/arm/pr69194.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr69194.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm-builtins.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/69318] [6 regression] ICE in symtab_node::verify with -fabi-version=7 -Wabi=8 -m32

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|c++ |target

--- Comment #1 from Martin Sebor  ---
This is a target-specific bug, not a C++ specific one.  Changed Component to
target.

[Bug c++/69323] New: Segmentation fault when instantiating class template with inner class which declares itself as a friend

[bd at jollyrogerlabs dot com]

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

Bug ID: 69323
   Summary: Segmentation fault when instantiating class template
with inner class which declares itself as a friend
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bd at jollyrogerlabs dot com
  Target Milestone: ---

Created attachment 37379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37379=edit
Preprocessed file, generated by adding "-save-temps" immediately after "g++" on
the command line.

Playing around with some template tricks (thus the filename) and produced a
segmentation fault.  Additionally, the error was generated from a program that
was very similar to one already working correctly, to which I attempted to have
an inner class of a class template (actually struct in both cases but whatever)
make a static member function private and then declare itself as its own
friend.  So in addition to the preprocessed source generated with -save-temps,
I will attach the original source file with instructions on how to switch the
error on and off.

Finally, I will report this on Ubuntu launchpad as well and reference this
upstream bug ID in case this turns out to be some issue in how they are
packaging for release.



GCC version:
$ g++ --version
g++ (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04) 4.6.4



System type:
Ubuntu 12.04 LTS 64 bit
$ uname -a
Linux apocalypse-ranch-office 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul
15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/debian_version 
wheezy/sid



Compiler command line plus output:
$ g++ -Wall -std=c++0x -g -O0 -o /tmp/stupid_template_tricks
/tmp/stupid_template_tricks.cpp 
/tmp/stupid_template_tricks.cpp: In instantiation of
‘Outer<42>::StupidValueTrick’:
/tmp/stupid_template_tricks.cpp:62:13:   instantiated from here
/tmp/stupid_template_tricks.cpp:13:3: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccO1MHdE.out file, please attach this to
your bugreport.

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

[Bug c++/69323] Segmentation fault when instantiating class template with inner class which declares itself as a friend

[bd at jollyrogerlabs dot com]

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

--- Comment #1 from Brian Davis  ---
Created attachment 37380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37380=edit
Original source file

Please note line 7 of this file:
#define SHOW_GCC_BUG 1

If this line is commented out, the program compiles and runs normally on my
machine; if it is left in, the compiler generates a segmentation fault as
indicated in the bug description.

There are two conditional groups in the code related to this macro which
control inclusion of exactly two line of code: a friend declaration, and the
declaration of a private section of a struct which is enclosed within a struct
template.

Perhaps of additional note is that the template parameter is non-type ("int" in
this case).

[Bug c++/69323] [4.9/5/6 Regression] Segmentation fault when instantiating class template with inner class which declares itself as a friend

[bd at jollyrogerlabs dot com]

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

--- Comment #4 from Brian Davis  ---
Created attachment 37381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37381=edit
Preprocessed file generated by g++ 4.9.2 on the same source file

Here's the preprocessed file used on 4.9.2; the compiler error message was
similar or exactly the same.

[Bug c++/69324] New: non-constexpr function cannot be called in a constexpr initializer even if the full-expression is a constexpr

[dreifachstein at gmail dot com]

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

Bug ID: 69324
   Summary: non-constexpr function cannot be called in a constexpr
initializer even if the full-expression is a constexpr
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dreifachstein at gmail dot com
  Target Milestone: ---

I think g++ incorrectly assumes a constexpr cannot be created from a
non-constexpr function call.
Here is a test case:

struct T {
  static constexpr auto Create() { return 0; }
};

void test()
{
  auto v0 = ([](){ return T(); })(); // not a constexpr
  static_assert(0 == v0.Create(), ""); // pass

  constexpr auto v1 = ([](){ return T(); })().Create(); // error
}

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #35 from Joshua Kinard  ---
(In reply to rguent...@suse.de from comment #34)
> On Thu, 14 Jan 2016, kumba at gentoo dot org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> > 
> > --- Comment #33 from Joshua Kinard  ---
> > The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
> > (Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from 
> > building,
> > and it ended up completing.  Difference between that script (which builds
> > inside a chroot) is I used saner CFLAGS.
> > 
> > The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
> > CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
> > -fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
> > LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"
> > 
> > So I'll look at dropping one flag at a time, along with trimming LDFLAGS, 
> > and
> > see if I can pin down which one causes ./genmatch --gimple to segfault 
> on N32.
> 
> -fforce-addr is a no-op and -fivopts is enabled at -O2 by default, so
> you can omit those without testing.

It looks like it's my LDFLAGS, specifically with -Wl,-z,now.  I let the build
proceed after removing LDFLAGS from my environment, and once it built genmatch
and ran it w/o a SIGSEGV, I interrupted the build, copied the linking command
for genmatch, and then tested with both -Wl,-z,now and -Wl,-z,relro, and the
relro version runs fine.

# mips64-unknown-linux-gnu-g++ -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-z,now -o
build/genmatchZ3 build/genmatch.o
../build-mips64-unknown-linux-gnu/libcpp/libcpp.a build/errors.o build/vec.o
build/hash-table.o ../build-mips64-unknown-linux-gnu/libiberty/libiberty.a

# build/genmatchZ3 --gimple
Segmentation fault


# mips64-unknown-linux-gnu-g++ -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-z,relro
-o build/genmatchZ4 build/genmatch.o
../build-mips64-unknown-linux-gnu/libcpp/libcpp.a build/errors.o build/vec.o
build/hash-table.o ../build-mips64-unknown-linux-gnu/libiberty/libiberty.a

# build/genmatchZ4 --gimple
(null):0:0 error: --gimple: No such file or directory


Currently using binutils-2.25.1.  Can provide strace runs if needed.

[Bug tree-optimization/69325] New: wrong code at -O3 on x86-64-linux-gnu (in 32- and 64-bit modes)

[chengniansun at gmail dot com]

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

Bug ID: 69325
   Summary: wrong code at -O3 on x86-64-linux-gnu (in 32- and
64-bit modes)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code is miscompiled by the gcc trunk at -O2 and -O3 in both
32-bit and 64-bit modes. 

$: 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160116 (experimental) [trunk revision 232466] (GCC) 
$: 
$: gcc-trunk small.c -O3 -m32 ; ./a.out
$: gcc-trunk small.c -O3 -m64 ; ./a.out
$: gcc-trunk small.c -O2 -m32 ; ./a.out
$: gcc-trunk small.c -O2 -m64 ; ./a.out
$: gcc-trunk small.c -O0 -m64 ; ./a.out
g_302=4
$: cat small.c
int printf(const char*, ...);
int a, b, d, f;
char c;
static int *e = 
int main() {
  int g = -1L;
  *e = g;
  c = 4;
  for (; c >= 14; c++)
*e = 1;
  f = a == 0;
  *e ^= f;
  int h = ~d;
  if (d)
b = h;
  if (h)
printf("g_302=%llu\n", (unsigned long long)c);
  return 0;
}
$:

[Bug libstdc++/51960] [DR 2127] Missing move-assignment operator in raw_storage_iterator

[webrown.cpp at gmail dot com]

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

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #4 from W E Brown  ---
LWG2127 now has DR status: 
http://cplusplus.github.io/LWG/lwg-defects.html#2127

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #1 from Jeffrey A. Law  ---
THanks for the .i and .s files.  The one thing that is missing that would help
a lot is the compiler flags used.  Without that information we have to guess
and with the number of flags, it's easy to guess wrong.

Thankfully something seems to have recorded the flags and embedded them into
your assembly output files.  So was able to use those.  Please if you file
future reports make sure to include the compiler flags too.

Anyway, it's a mis-compilation of svq1`_encode_plane.  It's quite strange
though.

So we have:


  _373 = _370 <= _372;
  best_374 = (int) _373;

That establishes best_374 as having a boolean range, even though it's an
integer variable.

That's important because later we see a conditional on best_374 and infer its
value on both arms of the conditional.

So if we look further we have:

;;   basic block 444, loop depth 2, count 0, freq 1, maybe hot
;;prev block 443, next block 445, flags: (NEW, REACHABLE)
;;pred:   441 [71.0%]  (FALSE_VALUE,EXECUTABLE)
;;440 [50.0%]  (FALSE_VALUE,EXECUTABLE)
  if (best_374 == 1)
goto ;
  else
goto ;

If we follow the TRUE arm where we know best_374 will have the value 1 we have
this path (there's others, this is just one):

445->445->446->461->451->462->453

Where BB453 looks like:

  # best_3287 = PHI <0(443), best_374(462), 0(429)>


After my patch that statement looks like:

  # best_3287 = PHI <0(443), 0(461), 0(429)>


Yow!  That's clearly not right.

Still digging, but that looks like a real problem, and hopefully it's the
mis-compilation we're looking for.  Certainly if I block the propagation of
best_374 via a dbg-counter the resulting code passes its internal tests.

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
Ha!  Got it.

On the path noted in the earlier comment we have the following:

:
pred_x ={v} {CLOBBER};
pred_y ={v} {CLOBBER};
_423 = s_46(D)->rd_total;
_424 = score[best_374];
_425 = (long int) _424;
_426 = _423 + _425;
s_46(D)->rd_total = _426;
if (best_374 != 2)
  goto ;
else
  goto ;



I'd looked at that block a few times and even traced where that test came from,
the propagation of best_374 into that test and determined that while
suboptimal, it was correct (the test originally used a different variable, one
which had the range [0..2].  The path by which the "2" appears in that range
eventually gets proved unexecutable and removed.  Once that happens the
original object becomes equivalent to best_374 and the copy propagation occurs
in copyprop (which AFAICT doesn't try to use range information to simplify
things).

Anyway, all that is irrelevant to the problem.  ssa_name_has_boolean_range does
something like this

edge_info->rhs = (integer_zerop (op1) ? true_val : false_val);

When it only had to deal with booleans, that was fine because op1 in this
context would always be the constant 0 or 1 (it's the RHS of the conditional).

But once we start handling integers with a narrow range, that test is wrong.

Fixing is trivial.  It'll probably take longer to boil down a suitable testcase
-- it's late.  I'll poke at this further over the weekend.

[Bug c++/69316] New: Implement CWG 393

[colu...@gmx-topmail.de]

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

Bug ID: 69316
   Summary: Implement CWG 393
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

void f(int(&)[]);

This fails, although made well-formed as of core issue 393. Note that a fix
should presumably take EWG 118 into account.