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

2016-04-27 Thread nunya223bidness at streetwisemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70838

--- Comment #1 from nunya223bidness at streetwisemail dot com ---
Created attachment 38354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38354=edit
tar.xz of build-x86_64-unknown-linux-gnu/libiberty/*.i

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

2016-04-27 Thread nunya223bidness at streetwisemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70838

Bug ID: 70838
   Summary: internal compiler error on libiberty/floatformat.c
when bootstrapping 5.3.0 with 5.3.0
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunya223bidness at streetwisemail dot com
  Target Milestone: ---

../gcc-5.3.0/configure --prefix=/usr/local
--with-native-system-header-files=/opt/include:/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/include
--enable-bootstrap --enable-lto --with-{gmp,mpc,mpfr,isl}=/usr/local
--with-gnu-ld --enable-twoprocess --enable-gather-detailed-mem-stats
--enable-multilib --enable-multiarch --enable-decimal-float=yes
--enable-fixed-point --enable-plugin --disable-dependency-tracking
--disable-nls --disable-canonical-system-headers --with-glibc-version=2.20
--without-cuda-driver --enable-languages=c,c++
--with-build-time-tools=/usr/local --with-build-libsubdir=lib CFLAGS="-v
-save-temps" ; make

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
rm -f stage_current
make[3]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build/libiberty'
if [ x"-fpic" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../gcc-5.3.0/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
../../gcc-5.3.0/libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
GNU MP: Cannot allocate memory (size=4611686018427387859)
../../gcc-5.3.0/libiberty/floatformat.c: In function 'floatformat_to_double':
../../gcc-5.3.0/libiberty/floatformat.c:529:2: internal compiler error: Aborted
  dto = ldexp (1.0, exponent);
  ^
0x9bed4f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x93c390 real_from_mpfr(real_value*, __mpfr_struct const*, tree_node*,
mpfr_rnd_t)
../../gcc-5.3.0/gcc/realmpfr.c:92
0x939b49 real_from_string(real_value*, char const*)
../../gcc-5.3.0/gcc/real.c:2073
0x93a3bc real_from_string3(real_value*, char const*, machine_mode)
../../gcc-5.3.0/gcc/real.c:2123
0x6576a3 interpret_float
../../gcc-5.3.0/gcc/c-family/c-lex.c:897
0x65834c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-5.3.0/gcc/c-family/c-lex.c:442
0x602fef c_lex_one_token
../../gcc-5.3.0/gcc/c/c-parser.c:258
0x613d1a c_parser_peek_token
../../gcc-5.3.0/gcc/c/c-parser.c:440
0x613d1a c_parser_next_token_is
../../gcc-5.3.0/gcc/c/c-parser.c:452
0x613d1a c_parser_postfix_expression_after_primary
../../gcc-5.3.0/gcc/c/c-parser.c:7865
0x60e067 c_parser_postfix_expression
../../gcc-5.3.0/gcc/c/c-parser.c:7715
0x61031a c_parser_unary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6602
0x610e8f c_parser_cast_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6440
0x611072 c_parser_binary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6255
0x611ba5 c_parser_conditional_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6031
0x611ff0 c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5949
0x61206a c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5991
0x6124e2 c_parser_expression
../../gcc-5.3.0/gcc/c/c-parser.c:8022
0x612c99 c_parser_expression_conv
../../gcc-5.3.0/gcc/c/c-parser.c:8055
0x60c096 c_parser_statement_after_labels
../../gcc-5.3.0/gcc/c/c-parser.c:5115

sh-4.3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/volume1/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure
--with-buildtime-tools=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/bin
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--with-isl=/usr/local --disable-multilib
--with-sysroot=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot
--enable-bootstrap --disable-lto
Thread model: posix
gcc version 5.3.0 (GCC) 

sh-4.3# uname -s -r -v -m -p -i -o
Linux 3.10.77 #7321 SMP Thu Apr 21 14:35:22 CST 2016 x86_64 unknown unknown
GNU/Linux

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

2016-04-27 Thread nunya223bidness at streetwisemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70837

Bug ID: 70837
   Summary: internal compiler error on libiberty/floatformat.c
when bootstrapping 5.3.0 with 5.3.0
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunya223bidness at streetwisemail dot com
  Target Milestone: ---

../gcc-5.3.0/configure --prefix=/usr/local
--with-native-system-header-files=/opt/include:/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/include
--enable-bootstrap --enable-lto --with-{gmp,mpc,mpfr,isl}=/usr/local
--with-gnu-ld --enable-twoprocess --enable-gather-detailed-mem-stats
--enable-multilib --enable-multiarch --enable-decimal-float=yes
--enable-fixed-point --enable-plugin --disable-dependency-tracking
--disable-nls --disable-canonical-system-headers --with-glibc-version=2.20
--without-cuda-driver --enable-languages=c,c++
--with-build-time-tools=/usr/local --with-build-libsubdir=lib CFLAGS="-v
-save-temps" ; make

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
rm -f stage_current
make[3]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build/libiberty'
if [ x"-fpic" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../gcc-5.3.0/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
../../gcc-5.3.0/libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
GNU MP: Cannot allocate memory (size=4611686018427387859)
../../gcc-5.3.0/libiberty/floatformat.c: In function 'floatformat_to_double':
../../gcc-5.3.0/libiberty/floatformat.c:529:2: internal compiler error: Aborted
  dto = ldexp (1.0, exponent);
  ^
0x9bed4f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x93c390 real_from_mpfr(real_value*, __mpfr_struct const*, tree_node*,
mpfr_rnd_t)
../../gcc-5.3.0/gcc/realmpfr.c:92
0x939b49 real_from_string(real_value*, char const*)
../../gcc-5.3.0/gcc/real.c:2073
0x93a3bc real_from_string3(real_value*, char const*, machine_mode)
../../gcc-5.3.0/gcc/real.c:2123
0x6576a3 interpret_float
../../gcc-5.3.0/gcc/c-family/c-lex.c:897
0x65834c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-5.3.0/gcc/c-family/c-lex.c:442
0x602fef c_lex_one_token
../../gcc-5.3.0/gcc/c/c-parser.c:258
0x613d1a c_parser_peek_token
../../gcc-5.3.0/gcc/c/c-parser.c:440
0x613d1a c_parser_next_token_is
../../gcc-5.3.0/gcc/c/c-parser.c:452
0x613d1a c_parser_postfix_expression_after_primary
../../gcc-5.3.0/gcc/c/c-parser.c:7865
0x60e067 c_parser_postfix_expression
../../gcc-5.3.0/gcc/c/c-parser.c:7715
0x61031a c_parser_unary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6602
0x610e8f c_parser_cast_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6440
0x611072 c_parser_binary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6255
0x611ba5 c_parser_conditional_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6031
0x611ff0 c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5949
0x61206a c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5991
0x6124e2 c_parser_expression
../../gcc-5.3.0/gcc/c/c-parser.c:8022
0x612c99 c_parser_expression_conv
../../gcc-5.3.0/gcc/c/c-parser.c:8055
0x60c096 c_parser_statement_after_labels
../../gcc-5.3.0/gcc/c/c-parser.c:5115

sh-4.3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/volume1/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure
--with-buildtime-tools=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/bin
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--with-isl=/usr/local --disable-multilib
--with-sysroot=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot
--enable-bootstrap --disable-lto
Thread model: posix
gcc version 5.3.0 (GCC) 

sh-4.3# uname -s -r -v -m -p -i -o
Linux 3.10.77 #7321 SMP Thu Apr 21 14:35:22 CST 2016 x86_64 unknown unknown
GNU/Linux

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

2016-04-27 Thread nunya223bidness at streetwisemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70836

Bug ID: 70836
   Summary: internal compiler error on libiberty/floatformat.c
when bootstrapping 5.3.0 with 5.3.0
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunya223bidness at streetwisemail dot com
  Target Milestone: ---

Created attachment 38353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38353=edit
tar.xz of build-x86_64-unknown-linux-gnu/libiberty/*.i

../gcc-5.3.0/configure --prefix=/usr/local
--with-native-system-header-files=/opt/include:/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/include
--enable-bootstrap --enable-lto --with-{gmp,mpc,mpfr,isl}=/usr/local
--with-gnu-ld --enable-twoprocess --enable-gather-detailed-mem-stats
--enable-multilib --enable-multiarch --enable-decimal-float=yes
--enable-fixed-point --enable-plugin --disable-dependency-tracking
--disable-nls --disable-canonical-system-headers --with-glibc-version=2.20
--without-cuda-driver --enable-languages=c,c++
--with-build-time-tools=/usr/local --with-build-libsubdir=lib CFLAGS="-v
-save-temps" ; make

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
rm -f stage_current
make[3]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build/libiberty'
if [ x"-fpic" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../gcc-5.3.0/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
../../gcc-5.3.0/libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
GNU MP: Cannot allocate memory (size=4611686018427387859)
../../gcc-5.3.0/libiberty/floatformat.c: In function 'floatformat_to_double':
../../gcc-5.3.0/libiberty/floatformat.c:529:2: internal compiler error: Aborted
  dto = ldexp (1.0, exponent);
  ^
0x9bed4f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x93c390 real_from_mpfr(real_value*, __mpfr_struct const*, tree_node*,
mpfr_rnd_t)
../../gcc-5.3.0/gcc/realmpfr.c:92
0x939b49 real_from_string(real_value*, char const*)
../../gcc-5.3.0/gcc/real.c:2073
0x93a3bc real_from_string3(real_value*, char const*, machine_mode)
../../gcc-5.3.0/gcc/real.c:2123
0x6576a3 interpret_float
../../gcc-5.3.0/gcc/c-family/c-lex.c:897
0x65834c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-5.3.0/gcc/c-family/c-lex.c:442
0x602fef c_lex_one_token
../../gcc-5.3.0/gcc/c/c-parser.c:258
0x613d1a c_parser_peek_token
../../gcc-5.3.0/gcc/c/c-parser.c:440
0x613d1a c_parser_next_token_is
../../gcc-5.3.0/gcc/c/c-parser.c:452
0x613d1a c_parser_postfix_expression_after_primary
../../gcc-5.3.0/gcc/c/c-parser.c:7865
0x60e067 c_parser_postfix_expression
../../gcc-5.3.0/gcc/c/c-parser.c:7715
0x61031a c_parser_unary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6602
0x610e8f c_parser_cast_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6440
0x611072 c_parser_binary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6255
0x611ba5 c_parser_conditional_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6031
0x611ff0 c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5949
0x61206a c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5991
0x6124e2 c_parser_expression
../../gcc-5.3.0/gcc/c/c-parser.c:8022
0x612c99 c_parser_expression_conv
../../gcc-5.3.0/gcc/c/c-parser.c:8055
0x60c096 c_parser_statement_after_labels
../../gcc-5.3.0/gcc/c/c-parser.c:5115

sh-4.3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/volume1/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure
--with-buildtime-tools=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/bin
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--with-isl=/usr/local --disable-multilib
--with-sysroot=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot
--enable-bootstrap --disable-lto
Thread model: posix
gcc version 5.3.0 (GCC) 

sh-4.3# uname -s -r -v -m -p -i -o
Linux 3.10.77 #7321 SMP Thu Apr 21 14:35:22 CST 2016 x86_64 unknown unknown
GNU/Linux

[Bug c++/70834] New: Incorrect warning for placement new when conditionally used

2016-04-27 Thread matt at godbolt dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834

Bug ID: 70834
   Summary: Incorrect warning for placement new when conditionally
used
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

Consider some code which tries to placement-new into an internal buffer (if the
object fits), else uses the heap:

--

#include 
struct Test {
  char buf[4];

  template T *construct() {
if (sizeof(T) <= sizeof(buf))
return new ((void*))T;  // if it fits, use the buf
else return new T;  // else make it on the heap
  }
};

void t1(Test ) {
  t.construct();
}

void t2(Test ) {
  t.construct();
}

-- (also at https://godbolt.org/g/p5Lpnz)

GCC 6.1 correctly generates code in t2 to use the "new T", and placement new
code for t1.

However, there's a spurious warning: placement new constructing an object of
type 'double' and size '8' in a region of type 'char [4]' and size '4'
[-Wplacement-new=] - which is not the case in this code. In code I'm now
compiling I've been able to #pragma this warning off. I'll try and resort to
template trickery to dispatch on the sizeof(), but early attempts also caused
the warning too, so it may be the case this warning's tough to work around.

[Bug c++/56485] [cilkplus] internal compiler error: in cdtor_comdat_group, at cp/optimize.c: 186

2016-04-27 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56485

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-28
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug target/70833] All versions g++ 5.3.1 and and previous fails compiling with rpi3 and option -march=native

2016-04-27 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70833

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |target
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 70132.

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

[Bug driver/70132] ARM -mcpu=native can cause a double free abort.

2016-04-27 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132

Andrew Pinski  changed:

   What|Removed |Added

 CC||alfredo.pons at gmail dot com

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

[Bug target/70465] [4.9/5/6/7 Regression] Poor code for x87 asm

2016-04-27 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70465

--- Comment #10 from Jeffrey A. Law  ---
Coming back to Uros's c#5, the more I think about it, that's the solution. 
reg-stack ought to be able to use dependency information  to determine if it
can swap two insns rather than inserting a fxchg.  

I'm not actually working on this, but wanted to make sure anyone looking at
this in the future is aware that Uros's suggestion is, IMHO, the right way to
go.

[Bug c++/70833] New: All versions g++ 5.3.1 and and previous fails compiling with rpi3 and option -march=native

2016-04-27 Thread alfredo.pons at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70833

Bug ID: 70833
   Summary: All versions g++ 5.3.1 and  and previous fails
compiling with rpi3 and option -march=native
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alfredo.pons at gmail dot com
  Target Milestone: ---

All versions g++ 5.3.1 and previous (gcc 5.6 I don't known)  fails compiling
with Raspberry PI 3 CPU (BCM2709) and option -march=native

*** Error in `g++': double free or corruption (top): 0x001a8e30 ***

With rpi1 and rpi2 the 

With architecture i386 and CroosDebootstrap (qemu & chroot:
https://wiki.debian.org/EmDebian/CrossDebootstrap) fails too.

[Bug c++/70820] GCC incorrectly accepts code that accesses nested names in an incomplete type

2016-04-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70820

--- Comment #4 from Jonathan Wakely  ---
(In reply to Fabio Rocha from comment #3) 
> Still, it feels pretty strange that uncommenting the "First Assert" is what
> makes the code incorrect...

That's not strange at all, the assertion requires the value of the static data
member, so it causes it to be instantiated, while the type is incomplete.

Without that assertion the static data member is not instantiated until the
definition of ::k, after the types are complete.

[Bug c++/70832] New: move-assignment of lambdas calls copy-constructor for captures

2016-04-27 Thread blaffablaffa at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70832

Bug ID: 70832
   Summary: move-assignment of lambdas calls copy-constructor for
captures
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blaffablaffa at gmail dot com
  Target Milestone: ---

Created attachment 38352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38352=edit
testcase, compile with -std=c++14

Testcase attached, which compiles and produces correct output with clang++ 3.7.
Incorrect g++ diagnostic:

[pisto@localhost ~]$ g++ -std=c++14 test.cpp 
test.cpp: In function ‘int main()’:
test.cpp:18:12: error: use of deleted function ‘main()::&
main()::::operator=(const main()::&)’
 lambda = move(lambda_moved);//g++ tries to call copy constructor and
fails, clang++ 3.7 works
^
test.cpp:16:37: note: a lambda closure type has a deleted copy assignment
operator
 auto lambda = [test = move(data)]{};
 ^

[Bug c++/70832] move-assignment of lambdas calls copy-assignment for captures

2016-04-27 Thread blaffablaffa at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70832

--- Comment #1 from Lorenzo Pistone  ---
correction, it calls the copy assignment operator, not the copy constructor.

[Bug target/70799] STV pass does not convert DImode shifts and rotates

2016-04-27 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70799

--- Comment #2 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)
> I've been also surprised that the STV pass punts on moves of constants into
> DImode registers, if it is not 0, sure, it has higher cost, because it needs
> to be loaded from memory, but in the end together with enough other DImode
> operations it can be still beneficial.

This is tracked in PR 70763.

[Bug c++/68997] [cilkplus] cilk_spawn is broken for functions that return a type with a custom copy or move constructor

2016-04-27 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68997

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug other/69582] [meta-bug] Cilk+

2016-04-27 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
Bug 69582 depends on bug 68997, which changed state.

Bug 68997 Summary: [cilkplus] cilk_spawn is broken for functions that return a 
type with a custom copy or move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68997

   What|Removed |Added

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

[Bug c++/70344] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in adjust_temp_type, at cp/constexpr.c:1078

2016-04-27 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70344

Zhendong Su  changed:

   What|Removed |Added

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

--- Comment #7 from Zhendong Su  ---
The same ICE is still triggered with the current GCC trunk: 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-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 20160426 (experimental) [trunk revision 235433] (GCC) 
$ 
$ g++-trunk -O1 -c pr70344.cpp
pr70344.cpp: In instantiation of ‘constexpr int fn(T) [with T = Z]’:
pr70344.cpp:15:18:   required from here
pr70344.cpp:13:1: internal compiler error: in adjust_temp_type, at
cp/constexpr.c:1136
 }
 ^
0x89197a adjust_temp_type
../../gcc-source-trunk/gcc/cp/constexpr.c:1136
0x898797 cxx_bind_parameters_in_call
../../gcc-source-trunk/gcc/cp/constexpr.c:1210
0x898797 cxx_eval_call_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1397
0x89aa5d cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3558
0x8a10e9 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4136
0x8a3f78 maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4330
0x8a3f78 maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4354
0x87fad3 cp_fold
../../gcc-source-trunk/gcc/cp/cp-gimplify.c:2205
0x87f398 cp_fold_rvalue
../../gcc-source-trunk/gcc/cp/cp-gimplify.c:1894
0x87f398 cp_fold
../../gcc-source-trunk/gcc/cp/cp-gimplify.c:2083
0x88037e cp_fold_r
../../gcc-source-trunk/gcc/cp/cp-gimplify.c:940
0x1059734 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-source-trunk/gcc/tree.c:11531
0x6a2587 finish_function(int)
../../gcc-source-trunk/gcc/cp/decl.c:14712
0x70cf2a instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22035
0x75492b mark_used(tree_node*, int)
../../gcc-source-trunk/gcc/cp/decl2.c:5273
0x65d521 build_over_call
../../gcc-source-trunk/gcc/cp/call.c:7724
0x66ccff build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-source-trunk/gcc/cp/call.c:4169
0x808bf1 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2461
0x782a99 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6904
0x78bdec cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:7988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$

[Bug c++/69024] [cilkpus] cilk_spawn is broken for initializations with implicit conversion operators defined

2016-04-27 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69024

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug other/69582] [meta-bug] Cilk+

2016-04-27 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
Bug 69582 depends on bug 69024, which changed state.

Bug 69024 Summary: [cilkpus] cilk_spawn is broken for initializations with 
implicit conversion operators defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69024

   What|Removed |Added

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

[Bug c++/68997] [cilkplus] cilk_spawn is broken for functions that return a type with a custom copy or move constructor

2016-04-27 Thread law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68997

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Wed Apr 27 20:41:52 2016
New Revision: 235534

URL: https://gcc.gnu.org/viewcvs?rev=235534=gcc=rev
Log:
PR c++/69024
PR c++/68997
* cilk.c (cilk_ignorable_spawn_rhs_op): Change to external linkage.
(cilk_recognize_spawn): Renamed from recognize_spawn and change to
external linkage.
(cilk_detect_and_unwrap): Corresponding changes.
(extract_free_variables): Don't extract free variables from
AGGR_INIT_EXPR slot.
* c-common.h (cilk_ignorable_spawn_rhs_op): Prototype.
(cilk_recognize_spawn): Likewise.

PR c++/69024
PR c++/68997
* cp-gimplify.c (cp_gimplify_expr): Call
cilk_cp_detect_spawn_and_unwrap
instead of cilk_detect_spawn_and_unwrap.
* cp-cilkplus.c (is_conversion_operator_function_decl_p): New.
(find_spawn): New.
(cilk_cp_detect_spawn_and_unwrap): New.
* lambda.c: Include cp-cilkplus.h.
* parser.c: Include cp-cilkplus.h.
* cp-tree.h (cpp_validate_cilk_plus_loop): Move prototype into...
* cp-cilkpus.h: New file.

PR c++/69024
PR c++/68997
* g++.dg/cilk-plus/CK/pr68001.cc: Fix to not depend on broken
diagnostic.
* g++.dg/cilk-plus/CK/pr69024.cc: New test.
* g++.dg/cilk-plus/CK/pr68997.cc: New test.

Added:
trunk/gcc/cp/cp-cilkplus.h
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr68997.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr69024.cc
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/cilk.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-cilkplus.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/lambda.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc

[Bug c++/69024] [cilkpus] cilk_spawn is broken for initializations with implicit conversion operators defined

2016-04-27 Thread law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69024

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Wed Apr 27 20:41:52 2016
New Revision: 235534

URL: https://gcc.gnu.org/viewcvs?rev=235534=gcc=rev
Log:
PR c++/69024
PR c++/68997
* cilk.c (cilk_ignorable_spawn_rhs_op): Change to external linkage.
(cilk_recognize_spawn): Renamed from recognize_spawn and change to
external linkage.
(cilk_detect_and_unwrap): Corresponding changes.
(extract_free_variables): Don't extract free variables from
AGGR_INIT_EXPR slot.
* c-common.h (cilk_ignorable_spawn_rhs_op): Prototype.
(cilk_recognize_spawn): Likewise.

PR c++/69024
PR c++/68997
* cp-gimplify.c (cp_gimplify_expr): Call
cilk_cp_detect_spawn_and_unwrap
instead of cilk_detect_spawn_and_unwrap.
* cp-cilkplus.c (is_conversion_operator_function_decl_p): New.
(find_spawn): New.
(cilk_cp_detect_spawn_and_unwrap): New.
* lambda.c: Include cp-cilkplus.h.
* parser.c: Include cp-cilkplus.h.
* cp-tree.h (cpp_validate_cilk_plus_loop): Move prototype into...
* cp-cilkpus.h: New file.

PR c++/69024
PR c++/68997
* g++.dg/cilk-plus/CK/pr68001.cc: Fix to not depend on broken
diagnostic.
* g++.dg/cilk-plus/CK/pr69024.cc: New test.
* g++.dg/cilk-plus/CK/pr68997.cc: New test.

Added:
trunk/gcc/cp/cp-cilkplus.h
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr68997.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr69024.cc
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/cilk.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-cilkplus.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/lambda.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc

[Bug c++/69138] Woverflow not triggered for constexpr within template class

2016-04-27 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69138

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks||55004
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
I don't think the test case necessarily demonstrates a bug. The implicit
instantiation of B that's triggered by the definition of an object of the
specialization "causes the implicit instantiation of the declarations, but not
of the definitions, [...] of the class [...] static data members; and
it causes the implicit instantiation of the definitions of unscoped member
enumerations and member anonymous unions."

That being said, I think the bug can be reproduced by instantiating (e.g., by
virtue of using) B::small_within_templated_class, for example like so:

template 
class B {
  static constexpr uint8_t small_within_templated_class = 0x;
};

constexpr uint8_t i = B::small_within_templated_class;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug target/70763] Use SSE for DImode load/store

2016-04-27 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70763

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-27
 Ever confirmed|0   |1

[Bug lto/70831] FTBFS: Build fails with bootstrap-lto and profiledbootstrap

2016-04-27 Thread jeffbai at aosc dot xyz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70831

--- Comment #1 from Jeff Bai  ---
P.S.: Tried building with both GCC 5.3.0, and GCC 6.1.0.

[Bug lto/70831] New: FTBFS: Build fails with bootstrap-lto and profiledbootstrap

2016-04-27 Thread jeffbai at aosc dot xyz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70831

Bug ID: 70831
   Summary: FTBFS: Build fails with bootstrap-lto and
profiledbootstrap
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffbai at aosc dot xyz
  Target Milestone: ---

A build failure is observed today when I tested building GCC with both 

./configure ... \
--with-build-config=bootstrap-lto

and

make profiledboostrap

The build fails when linking libmpx/mpxwrap target, detailed error is shown
below.

/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/libmpx/mpxwrap/mpx_wrappers.c:520:1:
note: '__mpx_wrapper_strncat' was previously declared here
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/libmpx/mpxwrap/mpx_wrappers.c:520:1:
note: code may be misoptimized unless -fno-strict-aliasing is used
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/libmpx/mpxwrap/mpx_wrappers.c: In
function '__mpx_wrapper_malloc.chkp':
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/libmpx/mpxwrap/mpx_wrappers.c:35:9:
internal compiler error: in ultimate_transparent_alias_target, at varasm.c:1263
   void *p = (void *)malloc (size);
 ^
0x592d11 ultimate_transparent_alias_target
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/varasm.c:1263
0xb68514 ultimate_transparent_alias_target
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/varasm.c:1472
0xb68514 make_decl_rtl(tree_node*)
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/varasm.c:1349
0x5fc4f2 rtx_for_function_call
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/calls.c:1819
0x5fc4f2 expand_call(tree_node*, rtx_def*, int)
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/calls.c:3152
0x6d95a3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/expr.c:10589
0x6e2ae9 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/expr.c:5406
0x6e383f expand_assignment(tree_node*, tree_node*, bool)
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/expr.c:5175
0x6087bc expand_call_stmt
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/cfgexpand.c:2658
0x6087bc expand_gimple_stmt_1
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/cfgexpand.c:3548
0x6087bc expand_gimple_stmt
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/cfgexpand.c:3714
0x60a155 expand_gimple_basic_block
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/cfgexpand.c:5720
0x60f006 execute
/var/lib/abbs/build/tmp.oxb17wrLIQ/gcc-6.1.0/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/70830] New: ARM interrupt attribute: push/pop do not support {reglist}^

2016-04-27 Thread fab...@ritter-vogt.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830

Bug ID: 70830
   Summary: ARM interrupt attribute: push/pop do not support
{reglist}^
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fab...@ritter-vogt.de
  Target Milestone: ---

Using attribute((interrupt)) on a function that accesses a local and a global
variable causes gcc to emit broken assembly. It needs to be "ldm" instead of
pop.


Code:

long *a;
__attribute__((interrupt)) void fn1() {
  for (int x; x;)
*(long *)8096384 = a[20 / x];
}

Output:

> >arm-none-eabi-gcc -c -Os test.c
> test.s: Assembler messages:
> test.s:47: Error: push/pop do not support {reglist}^ -- `pop 
> {r0,r1,r2,r3,pc}^'

[Bug bootstrap/70829] New: LTO bootstrap failure

2016-04-27 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70829

Bug ID: 70829
   Summary: LTO bootstrap failure
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
LTO bootstrap fails for r235507.
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!

There are a bunch of files that are differing.
The entire build log can be seen here:
http://people.linaro.org/~prathamesh.kulkarni/err

Could someone confirm this failure with LTO ?
I configured with: --enable-languages=c,c++,fortran
--with-build-config=bootstrap-lto --disable-werror.
Bootstrap without LTO succeeds.

Thanks,
Prathamesh

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

2016-04-27 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826

--- Comment #4 from Bill Seurer  ---
From poking around in gdb it is dying on line 1078 in the code from the
VERIFY_CR macro (part of VERIFY_REGS) though "where" shows line 1070 for some
reason.  


#ifndef __NO_FPRS__
  b_all ();
  VERIFY_REGS;
  b_cvfr ();
  VERIFY_REGS;
  b_vfr ();
  VERIFY_REGS;
  b_cvf ();
  VERIFY_REGS;
  b_vf ();
  VERIFY_REGS;  // line 1078, dies here
#endif

#define VERIFY_CR ({ int tmp; __asm__ __volatile__ ("mfcr %0" : "=r" (tmp)); if
((tmp & ((15 << 20) | (15 << 16) | (15 << 12))) != ((6 << 20) | (7 << 16) | (8
<< 12))) abort (); })

(gdb) print /x tmp
$2 = 0x22278082
(gdb) print /x $cr
$4 = 0x22278082

After the bit manipulation the value in the CR comes out as 0x00278000 but it
is being compared to 0x00678000 and thus the abort.

[Bug middle-end/70828] New: broken array-type subarrays inside acc data in openacc

2016-04-27 Thread cesar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70828

Bug ID: 70828
   Summary: broken array-type subarrays inside acc data in openacc
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: cesar at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38351=edit
broken subarray

Given an array-typed subarray with a non-zero base element on an acc data
construct, the gimplifier will implicitly add a pcopy clause for any parallel
and kernels construct which uses that array. The pcopy is correct, but this
pcopy expects the entire array to be present on the accelerator. This
ultimately results in a runtime failure when the base of the subarray is not
element zero.

This problem can be reproduced with the attached test case in trunk and gcc-6.

[Bug middle-end/70807] fwprop pass ICE with incoming CDI_DOMINATORS

2016-04-27 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-27
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug middle-end/70807] fwprop pass ICE with incoming CDI_DOMINATORS

2016-04-27 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807

--- Comment #2 from H.J. Lu  ---
Created attachment 38350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38350=edit
A patch to trigger ICE in fwprop pass on x86-64

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

2016-04-27 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826

--- Comment #3 from Bernd Schmidt  ---
In theory debug_insns are updated by regrename.

[Bug target/70155] Use SSE for TImode load/store

2016-04-27 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70155

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 7.

[Bug target/70155] Use SSE for TImode load/store

2016-04-27 Thread hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70155

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Apr 27 17:32:40 2016
New Revision: 235518

URL: https://gcc.gnu.org/viewcvs?rev=235518=gcc=rev
Log:
Extend STV pass to 64-bit mode

128-bit SSE load and store instructions can be used for load and store
of 128-bit integers if they are the only operations on 128-bit integers.
To convert load and store of 128-bit integers to 128-bit SSE load and
store, the original STV pass, which is designed to convert 64-bit integer
operations to SSE2 operations in 32-bit mode, is extended to 64-bit mode
in the following ways:

1. Class scalar_chain is turned into base class.  The 32-bit specific
member functions are moved to the new derived class, dimode_scalar_chain.
The new derived class, timode_scalar_chain, is added to convert oad and
store of 128-bit integers to 128-bit SSE load and store.
2. Add the 64-bit version of scalar_to_vector_candidate_p and
remove_non_convertible_regs.  Only TImode load and store are allowed
for conversion.  If one instruction on the chain of dependent
instructions aren't TImode load or store, the chain of instructions
won't be converted.
3. In 64-bit, we only convert from TImode to V1TImode, which have the
same size.  The difference is only vector registers are allowed in
TImode so that 128-bit SSE load and store instructions will be used
for load and store of 128-bit integers.
4. Put the 64-bit STV pass before the CSE pass so that instructions
changed or generated by the STV pass can be CSEed.

convert_scalars_to_vector calls free_dominance_info in 64-bit mode to
work around ICE in fwprop pass:

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

when building libgcc on Linux/x86-64.

gcc/

PR target/70155
* config/i386/i386.c (scalar_to_vector_candidate_p): Renamed
to ...
(dimode_scalar_to_vector_candidate_p): This.
(timode_scalar_to_vector_candidate_p): New function.
(scalar_to_vector_candidate_p): Likewise.
(timode_check_non_convertible_regs): Likewise.
(timode_remove_non_convertible_regs): Likewise.
(remove_non_convertible_regs): Likewise.
(remove_non_convertible_regs): Renamed to ...
(dimode_remove_non_convertible_regs): This.
(scalar_chain::~scalar_chain): Make it virtual.
(scalar_chain::compute_convert_gain): Make it pure virtual.
(scalar_chain::mark_dual_mode_def): Likewise.
(scalar_chain::convert_insn): Likewise.
(scalar_chain::convert_registers): Likewise.
(scalar_chain::add_to_queue): Make it protected.
(scalar_chain::emit_conversion_insns): Likewise.
(scalar_chain::replace_with_subreg): Likewise.
(scalar_chain::replace_with_subreg_in_insn): Likewise.
(scalar_chain::convert_op): Likewise.
(scalar_chain::convert_reg): Likewise.
(scalar_chain::make_vector_copies): Likewise.
(scalar_chain::convert_registers): New pure virtual function.
(class dimode_scalar_chain): New class.
(class timode_scalar_chain): Likewise.
(scalar_chain::mark_dual_mode_def): Renamed to ...
(dimode_scalar_chain::mark_dual_mode_def): This.
(timode_scalar_chain::mark_dual_mode_def): New function.
(timode_scalar_chain::convert_insn): Likewise.
(dimode_scalar_chain::convert_registers): Likewise.
(scalar_chain::compute_convert_gain): Renamed to ...
(dimode_scalar_chain::compute_convert_gain): This.
(scalar_chain::replace_with_subreg): Renamed to ...
(dimode_scalar_chain::replace_with_subreg): This.
(scalar_chain::replace_with_subreg_in_insn): Renamed to ...
(dimode_scalar_chain::replace_with_subreg_in_insn): This.
(scalar_chain::make_vector_copies): Renamed to ...
(dimode_scalar_chain::make_vector_copies): This.
(scalar_chain::convert_reg): Renamed to ...
(dimode_scalar_chain::convert_reg ): This.
(scalar_chain::convert_op): Renamed to ...
(dimode_scalar_chain::convert_op): This.
(scalar_chain::convert_insn): Renamed to ...
(dimode_scalar_chain::convert_insn): This.
(scalar_chain::convert): Call convert_registers.
(convert_scalars_to_vector): Change to scalar_chain pointer to
use timode_scalar_chain in 64-bit mode and dimode_scalar_chain
in 32-bit mode.  Delete scalar_chain pointer.  Call
free_dominance_info in 64-bit mode.
(pass_stv::gate): Remove TARGET_64BIT check.
(ix86_option_override): Put the 64-bit STV pass before the CSE
pass.

gcc/testsuite/

PR target/70155
* gcc.target/i386/pr55247-2.c: Updated to check movti_internal
and movv1ti_internal patterns
* gcc.target/i386/pr70155-1.c: New test.
* gcc.target/i386/pr70155-2.c: Likewise.
* gcc.target/i386/pr70155-3.c: Likewise.
* gcc.target/i386/pr70155-4.c: Likewise.
  

[Bug c++/70820] GCC incorrectly accepts code that accesses nested names in an incomplete type

2016-04-27 Thread fdrocha at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70820

--- Comment #3 from Fabio Rocha  ---
(In reply to Jason Merrill from comment #1)
> 14.7.1:  "The implicit instantiation of a class template specialization
> causes the implicit instantiation of the declarations, but not of the
> definitions, default arguments, or exception-specifications of the class
> member functions, member classes, scoped member enumerations, static data
> members and member templates; and it causes the implicit instantiation of
> the definitions of unscoped member enumerations and member anonymous unions."
> 
> So I don't think that the instantiation of Base requires the
> instantiation of the definition of Base::i.

You may be correct, not sure this is actually bug. 
Still, it feels pretty strange that uncommenting the "First Assert" is what
makes the code incorrect...

[Bug c++/70820] GCC incorrectly accepts code that accesses nested names in an incomplete type

2016-04-27 Thread fdrocha at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70820

Fabio Rocha  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/70820] GCC incorrectly accepts code that accesses nested names in an incomplete type

2016-04-27 Thread fdrocha at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70820

Fabio Rocha  changed:

   What|Removed |Added

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

--- Comment #2 from Fabio Rocha  ---
(In reply to Jason Merrill from comment #1)
> 14.7.1:  "The implicit instantiation of a class template specialization
> causes the implicit instantiation of the declarations, but not of the
> definitions, default arguments, or exception-specifications of the class
> member functions, member classes, scoped member enumerations, static data
> members and member templates; and it causes the implicit instantiation of
> the definitions of unscoped member enumerations and member anonymous unions."
> 
> So I don't think that the instantiation of Base requires the
> instantiation of the definition of Base::i.

You may be correct, not sure this is actually bug. 
Still, it feels pretty strange that uncommenting the "First Assert" is what
makes the code incorrect...

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

2016-04-27 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826

--- Comment #2 from Bill Schmidt  ---
I don't know the register-renames code at all -- does it update debug
information when it replaces registers?  Sounds like gdb is getting stale
results for which register represents a memory value.

[Bug c++/70827] New: [6 regression] dubious use of deleted function in inherited constructor

2016-04-27 Thread lucdanton at free dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70827

Bug ID: 70827
   Summary: [6 regression] dubious use of deleted function in
inherited constructor
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

struct move_only {
move_only() = default;
move_only(move_only&&) = default;
};

struct base {
base(move_only) {}
};

struct derived: base {
// error: use of deleted function 'constexpr move_only::move_only(const
move_only&)'
using base::base;
};

int main()
{
// note: synthesized method 'derived::derived(move_only)' first required
here
derived h(move_only {});
}

=

Using GCC 6.1:

$ g++-trunk --version
g++-trunk (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-trunk -std=c++11 main.cpp 
main.cpp: In constructor 'derived::derived(move_only)':
main.cpp:12:17: error: use of deleted function 'constexpr
move_only::move_only(const move_only&)'
 using base::base;
 ^~~~
main.cpp:1:8: note: 'constexpr move_only::move_only(const move_only&)' is
implicitly declared as deleted because 'move_only' declares a move constructor
or move assignment operator
 struct move_only {
^
main.cpp: In function 'int main()':
main.cpp:18:27: note: synthesized method 'derived::derived(move_only)' first
required here 
 derived h(move_only {});

=

The program compiles fine with 5.3.1, earlier 6 snapshots, and Clang.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

2016-04-27 Thread dhowells at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244

--- Comment #6 from dhowells at redhat dot com  ---
I'm looking to implement Linux kernel atomics with C++-11 intrinsics, so being
able to reduce a CMPXCHG-loop to BTR/BTS/BTC would be really handy.

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

2016-04-27 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826

--- Comment #1 from Bernd Schmidt  ---
So the only non-guality failure is powerpc/savres.c? Is there a way to reduce
this a bit, and also provide an (ideally reduced) preprocessed version that
exhibits the failure?

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

2016-04-27 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244

Martin Sebor  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #5 from Martin Sebor  ---
*** Bug 70823 has been marked as a duplicate of this bug. ***

[Bug sanitizer/70342] g++ -fsanitize=undefined never finishes compiling (>24h) in qtxmlpatterns test suite

2016-04-27 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70342

--- Comment #8 from Marek Polacek  ---
So it seems this fixes this problem:

diff --git a/gcc/c-family/c-ubsan.c b/gcc/c-family/c-ubsan.c
index 4022bdf..b829c04 100644
--- a/gcc/c-family/c-ubsan.c
+++ b/gcc/c-family/c-ubsan.c
@@ -395,8 +395,11 @@ ubsan_maybe_instrument_reference_or_call (location_t loc,
tree op, tree ptype,
  int save_flag_delete_null_pointer_checks
= flag_delete_null_pointer_checks;
  flag_delete_null_pointer_checks = 1;
- if (!tree_single_nonzero_warnv_p (op, _overflow_p)
- || strict_overflow_p)
+ if ((!tree_single_nonzero_warnv_p (op, _overflow_p)
+  || strict_overflow_p)
+ /* Instrumenting _EXPR <...> is a waste and can result
+in compile-time hog; see PR70342.  */
+ && TREE_CODE (TREE_OPERAND (op, 0)) != TARGET_EXPR)
instrument = true;
  flag_delete_null_pointer_checks
= save_flag_delete_null_pointer_checks;

[Bug target/70823] x86_64: __atomic_fetch_and/or/xor() should perhaps use BTR/BTS/BTC if they can

2016-04-27 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70823

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Resolving as a duplicate of bug 49244.

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

[Bug rtl-optimization/70826] New: [7 regression] many test cases fail starting with r235442

2016-04-27 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826

Bug ID: 70826
   Summary: [7 regression] many test cases fail starting with
r235442
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Note:  For at least some of the guality test case failures I have some doubt
that the test cases are valid.  But there are a few non-guality ones.

New failures:
FAIL: gcc.dg/guality/nrv-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 20 a2.i[0] == 42
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 *x == (char) 25
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 18 *x == (char) 25
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 18 *x == (char) 25
FAIL: gcc.dg/guality/pr36728-1.c   -Os  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 18 *x == (char) 25
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-2.c   -Os  line 18 *x == (char) 25
FAIL: gcc.dg/guality/pr36728-3.c   -O2  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O2  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O3 -g  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O3 -g  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -Os  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -Os  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O2  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O2  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O3 -g  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -O3 -g  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -Os  line 14 y == 2
FAIL: gcc.dg/guality/pr36728-4.c   -Os  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O3 -g  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O3 -g  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -Os  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -Os  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O3 -g  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O3 -g  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -Os  line 14 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -Os  line 16 y == 2
FAIL: gcc.target/powerpc/savres.c  -O2  execution test
FAIL: gcc.target/powerpc/savres.c  -O2 -mno-multiple  execution test
FAIL: gcc.target/powerpc/savres.c  -Os  execution test
FAIL: gcc.target/powerpc/savres.c  -Os -mno-multiple  execution test

New passes:
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-2.c   -Os  line 18 y == 2
FAIL: gcc.dg/guality/sra-1.c   -O2  line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto 

[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program

2016-04-27 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pvdp.bugzilla at gmail dot com

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

[Bug fortran/70815] ICE when using read statement applied to deferred-length string pointer as derived type component

2016-04-27 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70815

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks||68241
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres  ---
Fixed on 6.1 and trunk (7.0) between revisions r228467 (2015-10-05, ICE) and
r228566 (2015-10-07, OK), likely r228551 (pr65766). Closing as duplicate.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] Deferred-length character

[Bug fortran/68241] [meta-bug] Deferred-length character

2016-04-27 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 70815, which changed state.

Bug 70815 Summary: ICE when using read statement applied to deferred-length 
string pointer as derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70815

   What|Removed |Added

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

[Bug target/70825] New: x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily

2016-04-27 Thread dhowells at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70825

Bug ID: 70825
   Summary: x86_64: __atomic_compare_exchange_n() accesses stack
unnecessarily
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 38349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38349=edit
Example code

__atomic_compare_exchange_n() stores the 'expected' value and, if not
discarded, the old value on the stack rather than in a register and then may
immediately retrieve the old value from there back into the register from
whence it just came.

For example:

   static __always_inline int atomic_cmpxchg(atomic_t *v, int old, int new)
   {
  int cur = old;
  if (__atomic_compare_exchange_n(>counter, , new, false,
  __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED))
 return cur;
  return cur;
   }

   void test_atomic_cmpxchg(atomic_t *counter)
   {
  atomic_cmpxchg(counter, 23, 42);
   }

produces:

   0:   ba 2a 00 00 00  mov$0x2a,%edx
   5:   b8 17 00 00 00  mov$0x17,%eax
   a:   c7 44 24 fc 17 00 00movl   $0x17,-0x4(%rsp)
  11:   00 
  12:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  16:   c3  retq   

Note line a where 0x17 is stored at -04(%rsp) unnecessarily (the value is
dicarded).  Note also that this value is in %eax at the time and could be saved
from there rather than using an immediate operand.

And then:

   int test_atomic_cmpxchg_2(atomic_t *counter)
   {
  return atomic_cmpxchg(counter, 23, 42);
   }

where the value is returned, we get something like:

  20:   ba 2a 00 00 00  mov$0x2a,%edx
  25:   b8 17 00 00 00  mov$0x17,%eax
  2a:   c7 44 24 fc 17 00 00movl   $0x17,-0x4(%rsp)
  31:   00 
  32:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  36:   74 04   je 3c 
  38:   89 44 24 fc mov%eax,-0x4(%rsp)
  3c:   8b 44 24 fc mov-0x4(%rsp),%eax
  40:   c3  retq   

In this case, the return value is being constructed on the stack whereas the
value we actually want to return is in %eax at the conclusion of the CMPXCHG,
so lines 2a & 36-3c are redundant.

Changing atomic_cmpxchg() slightly:

  static __always_inline int atomic_cmpxchg_B(atomic_t *v, int old, int new)
   {
  int cur = old;
  if (__atomic_compare_exchange_n(>counter, , new, false,
  __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED))
-->  return old;
  return cur;
   }

does generate code that's somewhat better:

  a0:   ba 2a 00 00 00  mov$0x2a,%edx
  a5:   b8 17 00 00 00  mov$0x17,%eax
  aa:   c7 44 24 fc 17 00 00movl   $0x17,-0x4(%rsp)
  b1:   00 
  b2:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  b6:   ba 17 00 00 00  mov$0x17,%edx
  bb:   0f 45 d0cmovne %eax,%edx
  be:   89 d0   mov%edx,%eax
  c0:   c3  retq   

However, given the fact that old == cur must hold true if the CMPXCHG
succeeded,  lines b6-be are redundant. Note that the unnecessary store (line
aa) is still there.

Note that clang does somewhat better than gcc:

  50:   b9 2a 00 00 00  mov$0x2a,%ecx
  55:   b8 17 00 00 00  mov$0x17,%eax
  5a:   f0 0f b1 0f lock cmpxchg %ecx,(%rdi)
  5e:   c3  retq   
  5f:   90  nop

See the attached example code which should be compiled to a .s file.

This is the case for all of:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)

[Bug c++/70824] New: cc1plus consumes all available memory on specific template code

2016-04-27 Thread trulsjo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70824

Bug ID: 70824
   Summary: cc1plus consumes all available memory on specific
template code
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trulsjo at gmail dot com
  Target Milestone: ---

Created attachment 38348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38348=edit
Prerocessed source for failed compile

Compiling this code with g++ 6.1.0 causes cc1plus to consume all available
memory (or at least more than 12GB):

#include 

template 
size_t 
a() {
  const int v = std::max({1});
  return v;
}

Compiled with
g++ TJOTest.cpp -c --save-temps

gcc version is 6.1.0 release, compiled on Ubuntu 16.04 system with ./configure
&& make && make install

The same code compiles successfully on stock compiler in Ubuntu 16.04 (g++
5.3.1-14ubuntu2) 5.3.1 20160413

[Bug fortran/70817] Internal compiler error coarrays -finit-real=snan

2016-04-27 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70817

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.7 up to trunk (7.0) when using -fcoarray=lib. The code
compiles when using -fcoarray=single.

[Bug libstdc++/70766] stream iterators, shared_lock, and atomic should all use addressof and not

2016-04-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70766

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/70820] GCC incorrectly accepts code that accesses nested names in an incomplete type

2016-04-27 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70820

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
14.7.1:  "The implicit instantiation of a class template specialization causes
the implicit instantiation of the declarations, but not of the definitions,
default arguments, or exception-specifications of the class member functions,
member classes, scoped member enumerations, static data members and member
templates; and it causes the implicit instantiation of the definitions of
unscoped member enumerations and member anonymous unions."

So I don't think that the instantiation of Base requires the
instantiation of the definition of Base::i.

[Bug target/70823] New: x86_64: __atomic_fetch_and/or/xor() should perhaps use BTR/BTS/BTC if they can

2016-04-27 Thread dhowells at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70823

Bug ID: 70823
   Summary: x86_64: __atomic_fetch_and/or/xor() should perhaps use
BTR/BTS/BTC if they can
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

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

If given a mask that clears, sets or flips a single bit and the result is
checked for just that bit and reduced to bool, then the __atomic_fetch_and, _or
and _xor functions should consider using BTR, BTS or BTC as appropriate.

So, something like:

   static __always_inline bool test_and_set_bit(unsigned bit, unsigned long
*ptr)
   {
  unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
  unsigned long old;

  ptr += bit / BITS_PER_LONG;

  old = __atomic_fetch_or(ptr, mask, __ATOMIC_SEQ_CST);
  return old & mask;
   }

where the mask is constructed by 1UL << bitnr.  As things stand, for the
example above, the result ends up with a CMPXCHG loop rather a BTS instruction:

   b:   89 f9   mov%edi,%ecx
   d:   ba 01 00 00 00  mov$0x1,%edx
  12:   c1 ef 06shr$0x6,%edi
  15:   48 d3 e2shl%cl,%rdx
  18:   89 f9   mov%edi,%ecx
  1a:   48 8b 04 ce mov(%rsi,%rcx,8),%rax
  1e:   49 89 c0mov%rax,%r8
  21:   48 89 c7mov%rax,%rdi
  24:   49 09 d0or %rdx,%r8
  27:   f0 4c 0f b1 04 ce   lock cmpxchg %r8,(%rsi,%rcx,8)
  2d:   75 ef   jne1e 
  2f:   48 85 fatest   %rdi,%rdx
  32:   0f 95 c0setne  %al
  35:   c3  retq   

Could we instead get something like:

bts%edi,(%rsi)
setne  %al
retq

See the attached test source which should be compiled to a .s file.

This is the case for all of:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)

[Bug c++/70822] New: bogus "error: lvalue required as unary ‘&’ operand" with C++14 parenthesized SCOPE_REF

2016-04-27 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70822

Bug ID: 70822
   Summary: bogus "error: lvalue required as unary ‘&’ operand"
with C++14 parenthesized SCOPE_REF
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat scope.cc
struct a
{
  static int b;
};

template 
void
foo ()
{
  &(a::b);
}
$ g++ -std=c++14 scope.cc
scope.cc: In function ‘void foo()’:
scope.cc:10:9: error: lvalue required as unary ‘&’ operand
   &(a::b);

[Bug target/70821] New: x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases

2016-04-27 Thread dhowells at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70821

Bug ID: 70821
   Summary: x86_64: __atomic_fetch_add/sub() uses XADD rather than
DECL in some cases
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

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

__atomic_fetch_add/sub() uses XADD rather than DECL when subtracting 1 from the
counter if the result is acted upon, but where this could be done through the
condition flags.  For instance:

   static __always_inline bool atomic_sub_and_test(int i, atomic_t *v)
   {
  return __atomic_sub_fetch(>counter, i, __ATOMIC_SEQ_CST);
   }

   const char *test_atomic_dec_and_test(atomic_t *counter)
   {
  if (atomic_sub_and_test(1, counter))
 return "foo";
  return "bar";
   }

produces:

  17:   83 c8 ffor $0x,%eax
  1a:   f0 0f c1 07 lock xadd %eax,(%rdi)
  1e:   ba 00 00 00 00  mov$0x0,%edx
  23:   ff c8   dec%eax
  25:   b8 00 00 00 00  mov$0x0,%eax
  2a:   48 0f 44 c2 cmove  %rdx,%rax
  2e:   c3  retq   

when it should produce something more like this, which I get when adding 1
instead of subtracting 1, but with a DECL rather than an INCL:

  46:   f0 ff 07lock incl (%rdi)
  49:   ba 00 00 00 00  mov$0x0,%edx
  4e:   b8 00 00 00 00  mov$0x0,%eax
  53:   48 0f 44 c2 cmove  %rdx,%rax
  57:   c3  retq   

Note that adding or subtracting 2 and testing the zeroness of the result gives
SUBL/ADDL as expected.  If the result is not tested, DECL is generated as
expected:

  13:   f0 ff 0flock decl (%rdi)
  16:   c3  retq   

See the attached test program.

This is the case for both:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)

The following version of gcc:

gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC) 

also produces XADD rather than INCL/DECL/ADDL/SUBL if the result is looked at
at all.

[Bug c++/53157] within lambda, error: lvalue required as unary ‘&’ operand

2016-04-27 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53157

Patrick Palka  changed:

   What|Removed |Added

 CC||blastrock at free dot fr

--- Comment #3 from Patrick Palka  ---
*** Bug 70121 has been marked as a duplicate of this bug. ***

[Bug c++/70121] Spurious warning and crash when returning a reference from lambda

2016-04-27 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Looks like this is a dup of PR c++/53157.

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

[Bug ipa/70760] [6 regression] wrong generated code for std::make_unique with -fipa-pta

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 regression] wrong  |[6 regression] wrong
   |generated code for  |generated code for
   |std::make_unique with   |std::make_unique with
   |-fipa-pta   |-fipa-pta
  Known to fail||6.1.0

--- Comment #17 from Richard Biener  ---
Fixed on trunk sofar.

[Bug ipa/70760] [6 regression] wrong generated code for std::make_unique with -fipa-pta

2016-04-27 Thread david.abdurachmanov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760

--- Comment #18 from David Abdurachmanov  
---
For now I will pull this change into my GCC 6.1.0 build.

Thanks!

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Wed Apr 27 14:10:04 2016
New Revision: 235511

URL: https://gcc.gnu.org/viewcvs?rev=235511=gcc=rev
Log:
2016-04-27  Richard Biener  

PR ipa/70760
* tree-ssa-structalias.c (find_func_aliases_for_call): Use
aggregate_value_p to determine if a function result is
returned by reference.
(ipa_pta_execute): Functions having their address taken are
not automatically nonlocal.

* g++.dg/ipa/ipa-pta-2.C: New testcase.
* gcc.dg/ipa/ipa-pta-1.c: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/ipa/ipa-pta-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-1.c
trunk/gcc/tree-ssa-structalias.c

[Bug ipa/70760] [6 regression] wrong generated code for std::make_unique with -fipa-pta

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 regression] wrong  |[6 regression] wrong
   |generated code for  |generated code for
   |std::make_unique with   |std::make_unique with
   |-fipa-pta   |-fipa-pta
  Known to fail||6.1.0

--- Comment #17 from Richard Biener  ---
Fixed on trunk sofar.

[Bug ada/56616] gnatmake builds SAL incorrectly if library_kind is "static"

2016-04-27 Thread simon at pushface dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56616

--- Comment #3 from simon at pushface dot org ---
This PR was down to a lack of appreciation of the resources available.

If you provide a Library_Interface and you're building a dynamic
library, gprbuild populates the include Library_Src_Dir directory with
the library interface units and builds a dynamic library with
auto-initialization.

If you provide a Library_Interface and you're building a static library,
gprbuild uses the same rule to populate the include directory; but this
mey be wrong if the non-visible units require elaboration (e.g. they
call in the tasking runtime).

The patch I provided meant that if you provided a Library_Interface for
a static library, the include directory would be populated with all the
units regardless of whether they were actually listed; I now see that
using Interfaces and naming all the source files achieves the same
effect! so no need for a patch (but maybe a blog posting?)

For the BCs this would mean

   case Library_Type is
  when "relocatable" =>
 for Library_Src_Dir use "./include";
 for Library_Interface use Source_Units;
  when "static" =>
 for Library_Src_Dir use "./include";
 for Interfaces use Sources;
   end case;

where I already have

   Source_Units :=
 (
  "BC.Containers.Bags.Bounded",
  "BC.Containers.Bags.Dynamic",
  ...

and

   Sources :=
 (
  "bc-containers-bags-bounded.adb",
  "bc-containers-bags-bounded.ads",
  "bc-containers-bags-dynamic.adb",
  "bc-containers-bags-dynamic.ads",
  ...

[Bug c++/70820] New: GCC incorrectly accepts code that accesses nested names in an incomplete type

2016-04-27 Thread fdrocha at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70820

Bug ID: 70820
   Summary: GCC incorrectly accepts code that accesses nested
names in an incomplete type
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fdrocha at gmail dot com
  Target Milestone: ---

Consider the following code

template
struct Base {
static constexpr int i = Derived::j;
// static_assert(i>1, "First assert"); // First Assert
// int array[i]; // Array declation
};

struct Derived : public Base {
static  constexpr int j = 5 ;
};

static constexpr int k = Base::i; 
static_assert(Derived::i > 0, "Second Assert");
static_assert(Base::i > 0, "Third Assert");
int array[Derived::i];

GCC compiles this (I tried all versions between 4.9.0 and 5.3.0) with no errors
or warnings even with -Wall -Wextra.
If you uncomment either the line marked "First Assert" or "Array Declaration"
it correctly gives the error "error: incomplete type 'Derived' used in nested
name specifier". It should also not accept the code without those lines, for
the same reason.

[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING

2016-04-27 Thread jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200

James Greenhalgh  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jgreenhalgh at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #11 from James Greenhalgh  ---
Looks like this is fixed on all live branches. Ramana, please reopen if there
is something more to be done that I've missed.

[Bug c++/70819] New: constexpr error location wrong

2016-04-27 Thread nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70819

Bug ID: 70819
   Summary: constexpr error location wrong
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

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

Invoked as:
nathan@morden:28>./cc1plus -fpreprocessed cexpr-error.ii 

we get:

 constexpr int fn6(const int&, int) constexpr int fn7(const int*, int)
cexpr-error.ii: At global scope:
cexpr-error.ii:17:24:   in constexpr expansion of 'fn7(0u, 0)'
cexpr-error.ii:14:14:   in constexpr expansion of 'fn6((* a), b)'
cexpr-error.ii:7:7: error: 'a' is not a constant expression
   b = a;
   ^
cexpr-error.ii:18:24:   in constexpr expansion of 'fn7(0u, 8)'
cexpr-error.ii:14:14:   in constexpr expansion of 'fn6((* a), b)'
cexpr-error.ii:6:13:   in constexpr expansion of 'fn6(a, 0)'
cexpr-error.ii:18:43: error: 'a' is not a constant expression
 constexpr int n4 = fn7 ((const int *) 0, 8);

The first error is correctly located at tha 'b = a;' location.  The second
instance is  not, and shows the original call site.  inside constexpr.c the
first error is from an evaluation of the original function body.  the second is
from a cloned copy via the recursive call.  Something about cloning is throwing
off the error location.

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

2016-04-27 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 7 and 6.2.

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

2016-04-27 Thread hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Apr 27 13:35:03 2016
New Revision: 235509

URL: https://gcc.gnu.org/viewcvs?rev=235509=gcc=rev
Log:
X86: Fix a typo in call_insn_operand

r231923 has

 ;; Test for a valid operand for a call instruction.
 ;; Allow constant call address operands in Pmode only.
 (define_special_predicate "call_insn_operand"
   (ior (match_test "constant_call_address_operand
 (op, mode == VOIDmode ? mode : Pmode)")
(match_operand 0 "call_register_no_elim_operand")
-   (and (not (match_test "TARGET_X32"))
-   (match_operand 0 "memory_operand"
+   (ior (and (not (match_test "TARGET_X32"))
+(match_operand 0 "sibcall_memory_operand"))
   ^^^ A typo.
+   (and (match_test "TARGET_X32 && Pmode == DImode")
+(match_operand 0 "GOT_memory_operand")

"sibcall_memory_operand" should be "memory_operand".

gcc/

Backported from mainline
PR target/70750
* config/i386/predicates.md (call_insn_operand): Replace
sibcall_memory_operand with memory_operand.

gcc/testsuite/

Backported from mainline
PR target/70750
* gcc.target/i386/pr70750-1.c: New test.
* gcc.target/i386/pr70750-2.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr70750-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr70750-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/predicates.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/70683] [7 Regression] -fcompare-debug bug with -fsanitize=address

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/70683] [7 Regression] -fcompare-debug bug with -fsanitize=address

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 27 13:29:34 2016
New Revision: 235507

URL: https://gcc.gnu.org/viewcvs?rev=235507=gcc=rev
Log:
PR sanitizer/70683
* tree-core.h (enum operand_equal_flag): Add OEP_NO_HASH_CHECK.
* fold-const.c (operand_equal_p): If flag_checking and
OEP_NO_HASH_CHECK is not set in flag, recurse with OEP_NO_HASH_CHECK
and if it returns non-zero, assert iterative_hash_expr on both
args is the same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/tree-core.h

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

2016-04-27 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814

--- Comment #2 from Yichao Yu  ---
As an update, it seems that the llvm trunk recently switched to using
`__atomic_*` function call for int128 on all platforms (that I can test
anyway). I'm not sure how that decision is made or if there's any communication
with GCC but IMHO it would be nice to agree on using the atomic instruction on
aarch64 as long as it provides all the necessary ones.

[Bug target/70728] GCC trunk emits invalid assembly for knl target

2016-04-27 Thread kyukhin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70728

Kirill Yukhin  changed:

   What|Removed |Added

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

--- Comment #5 from Kirill Yukhin  ---
Done

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.0

--- Comment #15 from Richard Biener  ---
So the underlying issue is that

  /* If we pass the result decl by reference, honor that.  */
  if (lhsop
  && fndecl
  && DECL_RESULT (fndecl)
  && DECL_BY_REFERENCE (DECL_RESULT (fndecl)))
{

for the call

D.941390 =
std::_ZSt11make_uniqueIN3edm20ParameterDescriptionIiEEJRA16_KcRKiRbEENSt9_MakeUniqIT_E15__single_objectEDpOT0_.isra.144
("p_int_untracked", , 0); [return slot optimization]

runs into a NULL_TREE DECL_RESULT (fndecl) because that has been freed as
the decl is only an alias:

_ZSt11make_uniqueIN3edm20ParameterDescriptionIiEEJRA16_KcRKiRbEENSt9_MakeUniqIT_E15__single_objectEDpOT0_.isra.144/21428
(typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...)
[with _Tp = edm::ParameterDescription; _Args = {const char (&)[16], const
int&, bool&}]) @0x74d17450
  Type: function definition analyzed alias
  Visibility: prevailing_def_ironly artificial
  References:
_ZSt11make_uniqueIN3edm20ParameterDescriptionIiEEJRA6_KcRKiRbEENSt9_MakeUniqIT_E15__single_objectEDpOT0_.isra.149/21451
(alias)
  Referring: 
  Availability: local
  First run: 0
  Function flags: local icf_merged
  Called by:
_ZN7edmtest20ProducerWithPSetDesc16fillDescriptionsERN3edm25ConfigurationDescriptionsE/5911
(1.00 per call) 
  Calls: 

so we fail to resolve the decl to the alias target.  The following would fix
that

Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c  (revision 235404)
+++ gcc/tree-ssa-structalias.c  (working copy)
@@ -4658,9 +4658,8 @@ find_func_aliases_for_call (struct funct

   /* If we pass the result decl by reference, honor that.  */
   if (lhsop
- && fndecl
- && DECL_RESULT (fndecl)
- && DECL_BY_REFERENCE (DECL_RESULT (fndecl)))
+ && fi->is_fn_info
+ && DECL_BY_REFERENCE (DECL_RESULT (fi->decl)))
{
  struct constraint_expr lhs;
  struct constraint_expr *rhsp;

but it still won't handle indirect calls correctly which is what the 3rd
patch does.  It still might be that I'm going with sth like the above for
the GCC 6 branch.

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|6.0 |6.2

[Bug ipa/70785] LTO bootstrap with IPA PTA is broken

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70785

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.0
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #4 from Richard Biener  ---
Fixed.

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Apr 27 13:10:47 2016
New Revision: 235501

URL: https://gcc.gnu.org/viewcvs?rev=235501=gcc=rev
Log:
2016-04-27  Richard Biener  

PR ipa/70785
* tree-ssa-structalias.c (refered_from_nonlocal_fn): New
function cummulating used_from_other_partition, externally_visible
and force_output from aliases.
(refered_from_nonlocal_var): Likewise.
(ipa_pta_execute): Use call_for_symbol_and_aliases to cummulate
node flags properly.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug ipa/70785] LTO bootstrap with IPA PTA is broken

2016-04-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70785

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.0
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

2016-04-27 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-27
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
For reference, the testcase is:
#include 
#include 

std::atomic<__int128> a;

__attribute__((noinline)) void f(int64_t v)
{
a.store(v);
}

int main()
{
f(1);
return 0;
}

g++ at -O2 for aarch64 emits for the function 'f':
_Z1fl:
.LFB328:
.cfi_startproc
mov x2, x0
adrpx1, .LANCHOR0
add x0, x1, :lo12:.LANCHOR0
mov w4, 5
asr x3, x2, 63
b   __atomic_store_16

[Bug sanitizer/70342] g++ -fsanitize=undefined never finishes compiling (>24h) in qtxmlpatterns test suite

2016-04-27 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70342

--- Comment #7 from Marek Polacek  ---
There's some non-linearity.  This compiles in 25s, if I add another "<< A()"
then in 55s, if I add another "<< A()" then in 1m50s etc.

class A {};
class B {
public:
  B(A);
};
class C {
public:
  C operator<<(B);
};
class D {
  D(const int &);
  C m_blackList;
};
D::D(const int &) {
  m_blackList << A() << A() << A() << A() << A() << A() << A() << A() << A()
  << A() << A() << A() << A() << A() << A() << A() << A() << A()
  << A() << A() << A() << A() << A();
}

[Bug sanitizer/70712] False positive from AddressSanitizer with use of 'alignas'

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 27 12:23:50 2016
New Revision: 235490

URL: https://gcc.gnu.org/viewcvs?rev=235490=gcc=rev
Log:
Backported from mainline
2016-04-23  Jakub Jelinek  

PR sanitizer/70712
* cfgexpand.c (expand_stack_vars): Fix typo.

* c-c++-common/asan/pr70712.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/asan/pr70712.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cfgexpand.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/70680] [5 Regression] OpenMP SIMD linear variable privatized too eagerly

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70680

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 Regression] OpenMP |[5 Regression] OpenMP SIMD
   |SIMD linear variable|linear variable privatized
   |privatized too eagerly  |too eagerly

--- Comment #5 from Jakub Jelinek  ---
Fixed for 6.2+ as well.

[Bug middle-end/70680] [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70680

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 27 12:22:47 2016
New Revision: 235489

URL: https://gcc.gnu.org/viewcvs?rev=235489=gcc=rev
Log:
Backported from mainline
2016-04-19  Jakub Jelinek  

PR middle-end/70680
* gimplify.c (gimplify_omp_for): Call omp_notice_variable for
implicitly linear or lastprivate iterator on the outer context.

* testsuite/libgomp.c/pr70680-1.c: New test.
* testsuite/libgomp.c/pr70680-2.c: New test.

Added:
branches/gcc-6-branch/libgomp/testsuite/libgomp.c/pr70680-1.c
branches/gcc-6-branch/libgomp/testsuite/libgomp.c/pr70680-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimplify.c
branches/gcc-6-branch/libgomp/ChangeLog

[Bug target/70728] GCC trunk emits invalid assembly for knl target

2016-04-27 Thread kyukhin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70728

--- Comment #4 from Kirill Yukhin  ---
Author: kyukhin
Date: Wed Apr 27 12:09:45 2016
New Revision: 235487

URL: https://gcc.gnu.org/viewcvs?rev=235487=gcc=rev
Log:
AVX-512. PR target/70728. Use separate constraint for AVX-512BW

PR target/70728
gcc/
* gcc/config/i386/sse.md (define_insn
"3"):
Extract AVX-512BW constraint from AVX.
gcc/testsuite/
* gcc.target/i386/pr70728.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr70728.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/sse.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/70767] std::numeric_limits::digits is wrong unless --std=c++11 used

2016-04-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70767

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
For GCC 7 the specializations for cv-qualified types will always be defined.
I'm not going to backport that to current release branches though (since they
are not incorrect according to the C++98 standard).

[Bug libstdc++/70767] std::numeric_limits::digits is wrong unless --std=c++11 used

2016-04-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70767

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 27 11:57:58 2016
New Revision: 235486

URL: https://gcc.gnu.org/viewcvs?rev=235486=gcc=rev
Log:
libstdc++/70767 Define std::numeric_limits in C++98 mode

PR libstdc++/70767
* include/std/limits: Update comments about DRs.
(numeric_limits, numeric_limits,
numeric_limits): Define unconditionally.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/limits

[Bug go/49889] Calling a function whose name is obscured by a local variable does not produce an error

2016-04-27 Thread nickc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49889

--- Comment #3 from Nick Clifton  ---
Author: nickc
Date: Wed Apr 27 11:29:20 2016
New Revision: 235484

URL: https://gcc.gnu.org/viewcvs?rev=235484=gcc=rev
Log:
PR middle-end/49889
gcc * varasm.c (merge_weak): Generate an error if an attempt is made
to convert a non-weak static function into a weak, public function.

testsuite   * gcc.dg/pr49889.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr49899.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

2016-04-27 Thread amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489

--- Comment #16 from amker at gcc dot gnu.org ---
(In reply to amker from comment #15)
> Also the case is reported not vectorized on Solaris/SPARC in PR70803.  I
> will investigate and follow up it in that ticket.
> 
> Thanks.

Hmm, that one is for PR56625.c not vectorized on sparc, so this is still a
different issue.

[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #11 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug c++/70810] std::function template variadic template arguments do not unpack in function template

2016-04-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70810

--- Comment #2 from Jonathan Wakely  ---
Similar problems described at:
http://stackoverflow.com/q/11103384/981959
http://stackoverflow.com/q/34051435/981959

[Bug fortran/68887] [6/7 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68887

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #5 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug libstdc++/69332] [6/7 Regression] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69332

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #2 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug fortran/68649] [6/7 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #14 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #2 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug c++/70621] [6/7 Regression] ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70621

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #3 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug fortran/65024] [OOP] unlimited polymorphic pointer structure not built when it should be

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #15 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug sanitizer/68065] Size calculations for VLAs can overflow

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #36 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #20 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug target/67412] gfortran.dg/execute_command_line_2.f90 FAILs on Solaris 10

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #8 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug c++/70781] [6/7 Regression] ICE on invalid C++ code with lambda expressions on x86_64-linux-gnu in finish_expr_stmt, at cp/semantics.c:677

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70781

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #2 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #10 from Jakub Jelinek  ---
GCC 6.1 has been released.

[Bug rtl-optimization/66207] Switch alpha to LRA

2016-04-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |6.2

--- Comment #7 from Jakub Jelinek  ---
GCC 6.1 has been released.

  1   2   3   >