[Bug c++/77858] New: std::polar throws an exception if rho is negative

[holger.seelig at yahoo dot de]

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

Bug ID: 77858
   Summary: std::polar throws an exception if rho is negative
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.seelig at yahoo dot de
  Target Milestone: ---

I think it is not right to throw an exception if rho is negative. The result is
well defined for polar representation if rho is negative if polar is something
like this:

real = rho * cos (theta);
imag = rho * sin (theta);

then:

-polar (abs (r), t) == polar (-abs (r), t)

It is in the responsibility of the programmer to check the input of those
function.

If std::polar throws an exception why does the calculation 1.0 / 0.0 not throw
an exception the result is not well defined in that case. Numbers like complex
are there to do calculations, and I can very nice do nice calculations with an
negative rho. If I cannot pass a negative rho then I cannot use complex numbers
in my caluclations. Should I now switch back to handle this with cos and sin
where std::polar was so elegant? Numbers are there to calculate something for
me but not now anymore std::complex. What a pity!

[Bug go/77857] New: gccgo: vendoring doesn't work in gcc 6/7

[doko at gcc dot gnu.org]

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

Bug ID: 77857
   Summary: gccgo: vendoring doesn't work in gcc 6/7
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

reported in https://github.com/golang/go/issues/15628
reported in https://bugs.debian.org/839598

didn't check with GCC 5; according to the bug report an earlier version of
gitlab-workhorse successfully built.

[Bug libstdc++/77854] New: std::deque doesn't use allocator's size_type and difference_type

[redi at gcc dot gnu.org]

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

Bug ID: 77854
   Summary: std::deque doesn't use allocator's size_type and
difference_type
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template >
class deque : protected _Deque_base<_Tp, _Alloc>
{
  ...
  typedef size_t size_type;
  typedef ptrdiff_t  difference_type;

These should come from allocator_traits

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[andysem at mail dot ru]

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

--- Comment #13 from andysem at mail dot ru ---
Ok. For the record, opened bug 77845.

[Bug c++/77804] Internal compiler error on incorrect initialization of new-d array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed for 7.0 in r240754 and for 6.3 in r240755.

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug target/77850] New: FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute

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

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

Bug ID: 77850
   Summary: FAIL: gcc.dg/compat/scalar-by-value-4
c_compat_x_tst.o-c_compat_y_tst.o execute
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: powerpc-*-*

All the new _Complex char va tests fail on powerpc -m32.

[Bug c++/77849] New: [regression/4.9] Warning about deprecated enum even when "-Wdeprecated-declarations" is off

[thiago at kde dot org]

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

Bug ID: 77849
   Summary: [regression/4.9] Warning about deprecated enum even
when "-Wdeprecated-declarations" is off
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

$ cat test.cpp
class C {
public:
enum __attribute__((__deprecated__("Do not use"))) MyEnum
{
Foo,
Bar
};

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"

__attribute__((__deprecated__("Really, do not use"))) static const MyEnum
mySpecialEnum = Foo;

#pragma GCC diagnostic pop

};

int main() {
  return C::Foo;
}

$ gcc-6 -fsyntax-only test.cpp
test.cpp:1:7: warning: ‘C::mySpecialEnum’ is deprecated: Really, do not use
[-Wdeprecated-declarations]
test.cpp:12:79: note: declared here

Notes:
* no warnings on GCC 4
* warnings on mySpecialEnum in GCC 5 and 6 (not about the actual enum usage,
about the actual definition of mySpecialEnum)
* no warnings with ICC
* warnings in main on clang 3.7-3.9

Sorry, I don't have a GCC trunk (7) build available.

[Bug tree-optimization/77848] New: Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

Bug ID: 77848
   Summary: Gimple if-conversion results in redundant comparisons
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu

Gimple if-conversion is aggressive about converting PHIs to conditional
expressions.  When these expressions are not vectorized, they remain in
conditional form throughout the middle end phases.  Sometimes such conditionals
do not correspond to any target instructions, so they must be re-expanded to
branching logic.  When this happens, and several conditionals have the same
condition, GCC doesn't manage to combine the redundant conditions (at least,
not always).

I suspect that if such unusable conditionals were converted back to branching
logic after failed vectorization, jump threading would be able to pick up the
pieces and generate good code again, but I'm not certain.

As an example, on powerpc64le-linux, consider this Fortran code:

$ gfortran -S -O3 -mcpu=power8 -mtune=power8 -funroll-loops -ffast-math
-mrecip=all d138.f

  subroutine sub(x,a,n,m)
  implicit none
  real*8 x(*),a(*),atemp
  integer i,j,k,m,n
  real*8 s,t,u,v
  do j=1,m
 atemp=0.d0
 do i=1,n
if (abs(a(i)).gt.atemp) then
   atemp=a(i)
   k = i
end if
 enddo
 call dummy(atemp,k)
  enddo
  return
  end

Prior to if-conversion, we have:

  :
  # i_29 = PHI 
  # atemp_lsm.3_7 = PHI 
  # atemp_lsm.4_6 = PHI 
  # k_lsm.5_27 = PHI 
  _1 = (integer(kind=8)) i_29;
  _2 = _1 + -1;
  _3 = *a_17(D)[_2];
  _4 = ABS_EXPR <_3>;
  if (_4 > atemp_lsm.3_7)
goto ;
  else
goto ;

  :

  :
  # atemp_lsm.3_9 = PHI 
  # atemp_lsm.4_28 = PHI 
  # k_lsm.5_26 = PHI 
  i_20 = i_29 + 1;
  if (_16 < i_20)
goto ;
  else
goto ;

Following if-conversion, the PHIs in  have been converted into
conditional expressions in :

  :
  # i_29 = PHI 
  # atemp_lsm.3_7 = PHI 
  # atemp_lsm.4_6 = PHI 
  # k_lsm.5_27 = PHI 
  _1 = (integer(kind=8)) i_29;
  _2 = _1 + -1;
  _3 = *a_17(D)[_2];
  _4 = ABS_EXPR <_3>;
  atemp_lsm.3_9 = _4 > atemp_lsm.3_7 ? _3 : atemp_lsm.3_7;
  atemp_lsm.4_28 = _4 > atemp_lsm.3_7 ? 1 : atemp_lsm.4_6;
  k_lsm.5_26 = _4 > atemp_lsm.3_7 ? i_29 : k_lsm.5_27;
  i_20 = i_29 + 1;
  if (_16 < i_20)
goto ;
  else
goto ;

Types of the vars in the converted expressions are:

  integer(kind=4) k_lsm.5;
  logical(kind=4) atemp_lsm.4;
  real(kind=8) atemp_lsm.3;

The vectorizer is unable to vectorize the loop (unsupported pattern), so these
conditionals stay in place until expand time.  The first of these corresponds
to a floating-point select statement, so it is fine.  But the other two perform
floating-point comparisons to select between either integer or logical values,
and there is no such instruction for POWER.

The resulting code is (one iteration of an unrolled loop):

.L20:   
addi 8,3,1  
extsw 10,10 
extsw 3,8   
addi 4,4,8  
.L42:   
lfd 2,0(4)  
fabs 3,2
fcmpu 7,3,6 
fsub 4,6,3  
fsel 5,4,6,2
ble 7,.L23  
li 9,1  
.L23:   
fcmpu 0,3,6 
rldicl 9,9,0,32 
ble 0,.L24  
mr 10,3 
.L24:

[Bug tree-optimization/71661] [7 Regression] wrong code at -O3

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
As noted in my last comment, removal of a forwarder block may turn an
irreducible loop into a natural loop.  The loop header for any such exposed
natural loop will not be recognized as a loop header by tree_forwarder_block_p
(which avoids forwarding through loop headers).

So the easiest way to fix this problem is check if a block is a loop header in
remove_forwarder_block* rather than just in tree_forwarder_block_p.  This is
comparable to how we avoid infinite loops where we have this tidbit of code:

  /* We check for infinite loops already in tree_forwarder_block_p.
 However it may happen that the infinite loop is created
 afterwards due to removal of forwarders.  */
  if (dest == bb)
return false;

[Bug tree-optimization/71661] [7 Regression] wrong code at -O3

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
So digging a bit deeper.  When we leave threading we've exposed a new natural
loop.  However, there is still an irreducible loop in the CFG.  The CFG and the
cached loop information are conservatively correct at this point.

Later the mergephi pass finds a forwarder block with a PHI node.  It squashes
out that forwarder block.  Obviously when we remove a forwarder block, we
redirect all the incoming edges to the destination of the forwarder block.

In this particular case, redirecting those edges results in the remaining
irreducible loop becoming a natural loop.  We're actually likely still OK at
this point.  But.

It turns out the target of that forwarder block is itself also a forwarder
block that forwards into one of the natural loops.  So mergephi gladly squashes
out that forwarder block, redirecting all the incoming edges into the loop.

Now we've taken the loop nest exposed by the first mergephi transformation and
turned it into a single loop with multiple latches -- which means the iteration
information we had stored for the loop is no longer valid.

Later loop unrolling uses that invalid iteration information and we get
incorrect code.

We can likely invalidate the cached information, but ISTM that there's a
reasonable chance we're going to be playing whack-a-mole with this stuff.

[Bug c++/77804] Internal compiler error on incorrect initialization of new-d array

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Oct  4 17:34:00 2016
New Revision: 240754

URL: https://gcc.gnu.org/viewcvs?rev=240754=gcc=rev
Log:
PR c++/77804 - Internal compiler error on incorrect initialization of new-d
array

gcc/cp/ChangeLog:

PR c++/77804
* init.c (warn_placement_new_too_small): Avoid assuming an array type
has a constant size.

gcc/testsuite/ChangeLog:

PR c++/77804
* g++.dg/warn/Wplacement-new-size-4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wplacement-new-size-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77846] Wrong error recovery with switch, goto and initialization skipped

[denis.campredon at gmail dot com]

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

--- Comment #1 from denis.campredon at gmail dot com ---
I'm pretty sure it is linked the following code, compiled with '-fpermissive'
only prints A instead of AB

--
enum E{ A, B };
class C {public:C(){};};

static inline
void f(E e) {
if (0)
goto out;
switch (e) {
case A:
__builtin_printf("A");
C c;
break;
  case B:
   __builtin_printf("B");
}
out:{}
}

int main() {
  f(E::B);
  f(E::A);
  return 0;
}
-

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
(In reply to andysem from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > 
> > I think this testcase is violating C++ ODR.  In that
> > INSTRUCTION_SET::my_simd_func_impl is the same between the TUs.  If you had
> > used an anonymous namespace, it should have worked correctly.  If anonymous
> > namespace does not work, please file a separate bug.
> 
> INSTRUCTION_SET is defined differently for the two translation units, so we
> essentially have sse2::my_simd_func_impl and avx::my_simd_func_impl. This
> does not violate ODR.

Oh I did not notice INSTRUCTION_SET was defined on the command line.  as I said
please file a different bug.

[Bug lto/77845] New: LTO accumulates CPU requirements from all input objects (reopen)

[andysem at mail dot ru]

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

Bug ID: 77845
   Summary: LTO accumulates CPU requirements from all input
objects (reopen)
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Created attachment 39752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39752=edit
The testcase that miscompiles with gcc 5.4

This is a continuation of bug 61043.

In the attached testcase, the compiler produces my_simd.so library with two
functions (my_simd_func_sse2 and my_simd_func_avx), which are implemented in
separate TUs, which are compiled with -msse2 and -mavx, respectively. However,
the disassembler shows that both my_simd_func_sse2 and my_simd_func_avx contain
VEX-encoded instructions (i.e. the compiler used AVX in both cases). This only
happens when LTO is used. See build.sh for compiler command lines.

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

[Bug c++/77804] Internal compiler error on incorrect initialization of new-d array

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Oct  4 17:55:43 2016
New Revision: 240755

URL: https://gcc.gnu.org/viewcvs?rev=240755=gcc=rev
Log:
PR c++/77804 - Internal compiler error on incorrect initialization of new-d
array

gcc/cp/ChangeLog:

PR c++/77804
* init.c (warn_placement_new_too_small): Avoid assuming an array type
has a constant size.

gcc/testsuite/ChangeLog:

PR c++/77804
* g++.dg/warn/Wplacement-new-size-4.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/warn/Wplacement-new-size-4.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/init.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[andysem at mail dot ru]

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

andysem at mail dot ru changed:

   What|Removed |Added

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

--- Comment #10 from andysem at mail dot ru ---
(In reply to Andrew Pinski from comment #9)
> 
> I think this testcase is violating C++ ODR.  In that
> INSTRUCTION_SET::my_simd_func_impl is the same between the TUs.  If you had
> used an anonymous namespace, it should have worked correctly.  If anonymous
> namespace does not work, please file a separate bug.

INSTRUCTION_SET is defined differently for the two translation units, so we
essentially have sse2::my_simd_func_impl and avx::my_simd_func_impl. This does
not violate ODR.

[Bug target/77835] -O2 -pg -m32 overwrites saved lr with bogus value

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
A broken glibc patch broke _mcount.

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
(In reply to andysem from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > 
> > I think this testcase is violating C++ ODR.  In that
> > INSTRUCTION_SET::my_simd_func_impl is the same between the TUs.  If you had
> > used an anonymous namespace, it should have worked correctly.  If anonymous
> > namespace does not work, please file a separate bug.
> 
> INSTRUCTION_SET is defined differently for the two translation units, so we
> essentially have sse2::my_simd_func_impl and avx::my_simd_func_impl. This
> does not violate ODR.

Open a new bug.

[Bug target/77847] New: PowerPC big endian power7/power8 do not bootstrap due to fall through error

[meissner at gcc dot gnu.org]

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

Bug ID: 77847
   Summary: PowerPC big endian power7/power8 do not bootstrap due
to fall through error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

If you build a big endian GCC compiler using the --with-cpu=power7 or
--with-cpu=power8 option, it will fail to bootstrap:

make[3]: Entering directory
`/home/meissner/fsf-build-ppc64/trunk-240752/libcpp'
/home/meissner/fsf-build-ppc64/trunk-240752/./prev-gcc/xg++
-B/home/meissner/fsf-build-ppc64/trunk-240752/./prev-gcc/
-B/home/meissner/fsf-install-ppc64/trunk-240752/powerpc64-unknown-linux-gnu/bin/
-nostdinc++
-B/home/meissner/fsf-build-ppc64/trunk-240752/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/meissner/fsf-build-ppc64/trunk-240752/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/meissner/fsf-build-ppc64/trunk-240752/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu

-I/home/meissner/fsf-build-ppc64/trunk-240752/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include
 -I/home/meissner/fsf-src/trunk-240752/libstdc++-v3/libsupc++
-L/home/meissner/fsf-build-ppc64/trunk-240752/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/meissner/fsf-build-ppc64/trunk-240752/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -I/home/meissner/fsf-src/trunk-240752/libcpp -I.
-I/home/meissner/fsf-src/trunk-240752/libcpp/../include
-I/home/meissner/fsf-src/trunk-240752/libcpp/include  -g -O2 -gtoggle -W -Wall
-Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic
-Wno-long-long -Werror -fno-exceptions -fno-rtti
-I/home/meissner/fsf-src/trunk-240752/libcpp -I.
-I/home/meissner/fsf-src/trunk-240752/libcpp/../include
-I/home/meissner/fsf-src/trunk-240752/libcpp/include   -c -o lex.o -MT lex.o
-MMD -MP -MF .deps/lex.Tpo /home/meissner/fsf-src/trunk-240752/libcpp/lex.c
/home/meissner/fsf-src/trunk-240752/libcpp/lex.c: In function ‘const uchar*
search_line_fast(const uchar*, const uchar*)’:
/home/meissner/fsf-src/trunk-240752/libcpp/lex.c:735:4: error: this statement
may fall through [-Werror=implicit-fallthrough]
  s += sizeof(unsigned long);
  ~~^~
/home/meissner/fsf-src/trunk-240752/libcpp/lex.c:736:7: note: here
   case 2:
   ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [lex.o] Error 1
make[3]: Leaving directory `/home/meissner/fsf-build-ppc64/trunk-240752/libcpp'
make[2]: *** [all-stage2-libcpp] Error 2
make[2]: Leaving directory `/home/meissner/fsf-build-ppc64/trunk-240752'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/meissner/fsf-build-ppc64/trunk-240752'
make: *** [all] Error 2

The reason is code in lex.c that is optimized to use the Altivec instructions
does not have the proper fall through markers.  Note, this particular code is
only enabled if it is on a PowerPC, the Altivec instructions are available
(i.e. --with-cpu=power7 or --with-cpu=power8), and the target is big endian.

[Bug c++/77846] New: Wrong error recovery with switch, goto and initialization skipped

[denis.campredon at gmail dot com]

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

Bug ID: 77846
   Summary: Wrong error recovery with switch, goto and
initialization skipped
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Compiling the following code with -Wswitch
---
enum E {A, B};
class C {public: C();};

void f(E e) {
goto out;
switch (e) {
case A:
C c;
case B:;
}
out:{}
}
---

main.cpp: In function 'void f(E)':
main.cpp:9:14: error: jump to case label [-fpermissive]
 case B:;
  ^
main.cpp:8:11: note:   crosses initialization of 'C c'
 C c;
   ^
main.cpp:6:12: warning: enumeration value 'B' not handled in switch [-Wswitch]
 switch (e) {
^

The warning 
main.cpp:6:12: warning: enumeration value 'B' not handled in switch [-Wswitch]
Is wrong since B is handled in the switch.

Also it would be nice if the line of the goto and the line of the label were
shown in the output, something like:
Jumping from `goto' to `label' crosses the initialization of 'c, d, ...

[Bug c++/77775] [7 Regression] since r238559 Kdevelop gets miscompiled

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Oct  4 21:14:18 2016
New Revision: 240757

URL: https://gcc.gnu.org/viewcvs?rev=240757=gcc=rev
Log:
PR c++/5 - misoptimization of PMF comparison

* constexpr.c (cxx_eval_component_reference): Use name matching
for PMFs.

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

[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Ah, the passes have moved around some since I last looked at this.  This used
to follow a dom pass, so the code for copies didn't kick in any more at that
point.  So it's understandable that the copy propagation part is now important
again.

[Bug libgcj/25398] .jar files held open twice at runtime

[gnu_andrew at member dot fsf.org]

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

Andrew John Hughes  changed:

   What|Removed |Added

 CC||gnu_andrew at member dot 
fsf.org

--- Comment #4 from Andrew John Hughes  ---
Created attachment 39753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39753=edit
Test case which opens a JAR file using JarURLConnection

[Bug c++/77775] [7 Regression] since r238559 Kdevelop gets miscompiled

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Eric, can you please provide a test case where you are seeing the unpropagated
copies?  Thanks!

[Bug c++/77852] New: ICE when deducing class template arguments for pair or tuple

[ville.voutilainen at gmail dot com]

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

Bug ID: 77852
   Summary: ICE when deducing class template arguments for pair or
tuple
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

First test:

#include 

int main()
{
std::pair x{42, 666};
}

Second test:

#include 

int main()
{
std::tuple y{1,2,3};
}

ICE for the first:

c-a-d.cpp: In function ‘int main()’:
c-a-d.cpp:5:21: error: direct-list-initialization of ‘auto’ requires exactly
one element [-fpermissive]
  std::pair x{42, 666};
 ^
c-a-d.cpp:5:21: note: for deduction to ‘std::initializer_list’, use
copy-list-initialization (i.e. add ‘=’ before the ‘{’)
c-a-d.cpp:5:21: internal compiler error: same canonical type node for different
types _Tp and pair
0x781f7b comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1436
0x67fb58 template_args_equal(tree_node*, tree_node*)
../../gcc/cp/pt.c:7918
0x67f83f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**)
../../gcc/cp/pt.c:7965
0x68f2f6 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/cp/pt.c:1652
0x6e2be5 hash_table::find_with_hash(spec_entry*
const&, unsigned int)
../../gcc/hash-table.h:840
0x6ba9c2 lookup_template_class_1
../../gcc/cp/pt.c:8355
0x6ba9c2 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:8670
0x6d5f6e listify_autos
../../gcc/cp/pt.c:24023
0x6d88eb do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../gcc/cp/pt.c:24488
0x66f92f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6706
0x76aeec cp_parser_init_declarator
../../gcc/cp/parser.c:18987
0x76b594 cp_parser_simple_declaration
../../gcc/cp/parser.c:12566
0x76b935 cp_parser_block_declaration
../../gcc/cp/parser.c:12442
0x76c3e9 cp_parser_declaration_statement
../../gcc/cp/parser.c:12051
0x74ae43 cp_parser_statement
../../gcc/cp/parser.c:10603
0x74bdbd cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10935
0x74be9f cp_parser_compound_statement
../../gcc/cp/parser.c:10889
0x7698a3 cp_parser_function_body
../../gcc/cp/parser.c:20997
0x7698a3 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21033
0x76a2e1 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:25785
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

ICE for the second:

c-a-d_2.cpp: In function ‘int main()’:
c-a-d_2.cpp:5:20: error: direct-list-initialization of ‘auto’ requires exactly
one element [-fpermissive]
  std::tuple y{1,2,3};
^
c-a-d_2.cpp:5:20: note: for deduction to ‘std::initializer_list’, use
copy-list-initialization (i.e. add ‘=’ before the ‘{’)
c-a-d_2.cpp:5:20: internal compiler error: same canonical type node for
different types _Tp and tuple
0x781f7b comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1436
0x67fb58 template_args_equal(tree_node*, tree_node*)
../../gcc/cp/pt.c:7918
0x67f83f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**)
../../gcc/cp/pt.c:7965
0x68f2f6 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/cp/pt.c:1652
0x6e2b52 hash_table::find_with_hash(spec_entry*
const&, unsigned int)
../../gcc/hash-table.h:827
0x6ba9c2 lookup_template_class_1
../../gcc/cp/pt.c:8355
0x6ba9c2 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:8670
0x6d5f6e listify_autos
../../gcc/cp/pt.c:24023
0x6d88eb do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../gcc/cp/pt.c:24488
0x66f92f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6706
0x76aeec cp_parser_init_declarator
../../gcc/cp/parser.c:18987
0x76b594 cp_parser_simple_declaration
../../gcc/cp/parser.c:12566
0x76b935 cp_parser_block_declaration
../../gcc/cp/parser.c:12442
0x76c3e9 cp_parser_declaration_statement
../../gcc/cp/parser.c:12051
0x74ae43 cp_parser_statement
../../gcc/cp/parser.c:10603
0x74bdbd cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10935
0x74be9f cp_parser_compound_statement
../../gcc/cp/parser.c:10889
0x7698a3 cp_parser_function_body
../../gcc/cp/parser.c:20997
0x7698a3 cp_parser_ctor_initializer_opt_and_function_body

[Bug target/77851] New: Odd code for _Complex float return value

[hjl.tools at gmail dot com]

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

Bug ID: 77851
   Summary: Odd code for _Complex float return value
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-6 gcc]$ cat /tmp/c.c 
_Complex float
foo (_Complex float y)
{
  return y;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/c.c -O3
[hjl@gnu-6 gcc]$ cat c.s 
.file   "c.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movq%xmm0, -8(%rsp)
movss   -8(%rsp), %xmm0
movss   %xmm0, -16(%rsp)
movss   -4(%rsp), %xmm0
movss   %xmm0, -12(%rsp)
movq-16(%rsp), %xmm0
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 7.0.0 20161004 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$ 

It should be simply "ret".

[Bug c/72858] incorrect fixit hints in -Wformat diagnostics

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I came across one subtle case that I think might be better handled differently
than the others.

The type of the expected argument to a %lc directive is wint_t, which is
commonly int, but on some targets long int.  When the promoted type of the
argument is int, the hint suggests to replace the %lc directive with %c (even
when int and long are the same size).  The trouble with the suggestion is that
%lc behaves differently than %c in two ways: 1) it first converts the wint_t
argument to wchar_t and then to a multibyte character sequence as if by
wctomb(), and 2) it produces between zero and MB_CUR_MAX bytes while %c exactly
one.  This is rather subtle and might be missed by people maintaining
internationalization code they're not familiar with, leading them to introduce
bugs.  To minimize the risk, I think it might be better to change the hint to
suggest to cast the %lc argument to wint_t instead on the assumption that the
%lc is likely to be correct.  Another option might be to suppress the %lc
-Wformat warning altogether when the argument's type is an integer with the
same precision as wint_t.

$ cat /build/tmp/t.c &&
/build/sysroot/sparc-sun-solaris2.12/bin/sparc-sun-solaris2.12-gcc -S -Wall
-m32 /build/tmp/t.c
void f (int x)
{
  __builtin_printf ("%lc", x);
}
/build/tmp/t.c: In function 'f':
/build/tmp/t.c:3:24: warning: format '%lc' expects argument of type 'wint_t',
but argument 2 has type 'int' [-Wformat=]
   __builtin_printf ("%lc", x);
  ~~^
  %c

[Bug c/72858] incorrect fixit hints in -Wformat diagnostics

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Here's a slightly different but arguably even more compelling test case from
x86_64-linux with ILP32 where wchar_t is a typedef for long for some strange
reason yet wint_t is a typedef for int.  Passing a wchar_t argument to a %lc
directive (as I suspect is not uncommon) produces a -Wformat warning and the
hint suggests replacing %lc with %ld, which is almost certainly not correct.

$ cat t.c && gcc -S -Wall -m32 t.c
typedef __WCHAR_TYPE__ wchar_t;

void f (const wchar_t *ws)
{
  __builtin_printf ("%lc", *ws);
}
t.c: In function ‘f’:
t.c:5:24: warning: format ‘%lc’ expects argument of type ‘wint_t’, but argument
2 has type ‘wchar_t {aka const long int}’ [-Wformat=]
   __builtin_printf ("%lc", *ws);
  ~~^   ~~~
  %ld

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.3

--- Comment #3 from Richard Biener  ---
I'll have a look.

[Bug target/77822] [6/7 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||assemble-failure
 Status|WAITING |NEW
   Last reconfirmed|2016-10-03 00:00:00 |2016-10-4
  Known to work||5.4.1
   Target Milestone|--- |6.3
Summary|[6 REGRESSION] arm64 Error: |[6/7 Regression] arm64
   |immediate value out of  |Error: immediate value out
   |range 0 to 63 at operand 3  |of range 0 to 63 at operand
   ||3
  Known to fail||6.2.1, 7.0

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Thanks for that. Reproduced and confirmed

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
SCC consists of: .MEM_16 .MEM_15 .MEM_35 .MEM_26 ez_12 .MEM_14 wo_37 _5 _6
hy.3_7 _8 .MEM_32 hy.0_1 ez_28 _3 wo_40

Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to ez_12 (changed)
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:580, gimple-match.c:33849
Match-and-simplified ez_28 ^ wo_37 to 0
RHS ez_28 ^ wo_37 simplified to 0
Setting value number of _3 to 0 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to 0 (changed)

Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to 0 (changed)
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:83, gimple-match.c:33640
Match-and-simplified ez_28 ^ wo_37 to ez_12
RHS ez_28 ^ wo_37 simplified to ez_12
Setting value number of _3 to ez_12 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to ez_12 (changed)
...


  :
  # tc_11 = PHI <0(4), tc_31(5)>
  # ez_12 = PHI <0(4), ez_28(5)>
  # b8_13 = PHI <0(4), b8_30(5)>
  # wo_37 = PHI <0(4), wo_40(5)>

so we're iterating between "same PHI" and same value.  This is because
only when wo_40 == ez_12 we detect that it is actually zero ... we
fail to apply the wo_40 == 0 -> wo_37 == 0 -> ez_12 == 0 step when we
in the first iteration numbered wo_37 to ez_12.  As the comment says:

  /* First see if it is equivalent to a phi node in this block.  We prefer
 this as it allows IV elimination - see PRs 66502 and 67167.  */

we have the issue that the algorithm doesn't handle all cases, this now
shows we even can oscillate between them :/

[Bug target/77833] [7 Regression] ICE: in plus_constant, at explow.c:87 with -O -mavx512f

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
#1  0x00a5937e in plus_constant (mode=SImode, x=0x76a35fa0, c=-1, 
inplace=false) at /space/rguenther/src/svn/trunk/gcc/explow.c:87
87gcc_assert (GET_MODE (x) == VOIDmode || GET_MODE (x) == mode);
(gdb) p debug_rtx (x)
(const_vector:V2DI [
(const_int 0 [0])
(const_int 1 [0x1])
])

#3  0x008d737f in init_alias_analysis ()
at /space/rguenther/src/svn/trunk/gcc/alias.c:3359
3359 INTVAL (XEXP (src, 1)));
(gdb) p debug_rtx (insn)
(insn 26 25 27 2 (parallel [
(set (reg:SI 115 [ i ])
(plus:SI (reg:SI 92 [ _6 ])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))
]) t.c:9 211 {*addsi_1}
 (expr_list:REG_DEAD (reg:SI 92 [ _6 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(gdb) p debug_rtx (t)
(mem/u/c:SI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [1  S4 A128])

so we're running into

case MEM:
  /* If this is a reference to the constant pool, try replacing it with
 a reference to a new constant.  If the resulting address isn't
 valid, don't return it because we have no way to validize it.  */
  if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
  && CONSTANT_POOL_ADDRESS_P (XEXP (x, 0)))
{
  rtx cst = get_pool_constant (XEXP (x, 0));

  if (GET_CODE (cst) == CONST_VECTOR
  && GET_MODE_INNER (GET_MODE (cst)) == mode)
{
  cst = gen_lowpart (mode, cst);
  gcc_assert (cst);
}

with mode == SImode and cst == V2DI.  I think the above needs to give up
for CONST_VECTOR != VNmode.

[Bug target/77833] [7 Regression] ICE: in plus_constant, at explow.c:87 with -O -mavx512f

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I'll have a look.

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||gmc at synopsys dot com

--- Comment #2 from Richard Biener  ---
*** Bug 77832 has been marked as a duplicate of this bug. ***

[Bug target/77832] isnan() check causes signal 8 with signaling nans

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
dup then

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

[Bug target/77822] [6/7 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from ktkachov at gcc dot gnu.org ---
I'll have a look

[Bug libfortran/77828] [7 Regression] Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes when containing write to string

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from Richard Biener  ---
I believe we did run into this issue before.  I'll have a closer look into the
failure mode but as both conversions need to be there I can't see how it
matches.
As said, I'll have a look (but yes, the lazy type matching of operand_equal_p
is a problem...)

[Bug libfortran/77828] [7 Regression] Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes when containing write to string

[vehre at gcc dot gnu.org]

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

--- Comment #3 from vehre at gcc dot gnu.org ---
That's what library version numbering was made, wasn't it? I.e., this is the
way to go IMO.

[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t

[jaak at ristioja dot ee]

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

Jaak Ristioja  changed:

   What|Removed |Added

 CC||jaak at ristioja dot ee

--- Comment #1 from Jaak Ristioja  ---
A minimum example I've found for this is:

void f() { decltype(nullptr)(); }

With -std=c++11 the warning is emitted in versions 4.8.5, 4.9.3, 5.3.0, 5.4.0
and 6.2.0, but not in 4.7.4.

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
There's a cycle in CSSVN:

Value numbering store hy to _6
Setting value number of .MEM_32 to .MEM_32
Value numbering hy.0_1 stmt = hy.0_1 = hy;
Setting value number of hy.0_1 to 0
Value numbering ez_28 stmt = ez_28 = hy.0_1 ^ ez_12;
Applying pattern match.pd:83, gimple-match.c:33234
Match-and-simplified hy.0_1 ^ ez_12 to ez_12
RHS hy.0_1 ^ ez_12 simplified to ez_12
Setting value number of ez_28 to ez_12
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:567, gimple-match.c:33443
Match-and-simplified ez_28 ^ wo_37 to 0
RHS ez_28 ^ wo_37 simplified to 0
Setting value number of _3 to 0 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to 0 (changed)
Starting iteration 46252
Value numbering .MEM_16 stmt = .MEM_16 = PHI <.MEM_18(D)(2), .MEM_35(9)>
Setting value number of .MEM_16 to .MEM_16
Value numbering .MEM_15 stmt = .MEM_15 = PHI <.MEM_16(3), .MEM_32(7)>
Setting value number of .MEM_15 to .MEM_15
Value numbering .MEM_35 stmt = hy ={v} {CLOBBER};
Setting value number of .MEM_35 to .MEM_35
Value numbering .MEM_26 stmt = hy = 0;
RHS 0 simplified to 0
No store match
Value numbering store hy to 0
Setting value number of .MEM_26 to .MEM_26
Value numbering ez_12 stmt = ez_12 = PHI <0(4), ez_28(5)>
Setting value number of ez_12 to ez_12
Value numbering .MEM_14 stmt = .MEM_14 = PHI <.MEM_26(4), .MEM_14(5)>
Setting value number of .MEM_14 to .MEM_26
Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to 0 (changed)
Value numbering _5 stmt = _5 = b8_13 < wo_37;
Setting value number of _5 to _5
Value numbering _6 stmt = _6 = (int) _5;
Setting value number of _6 to _6
Value numbering hy.3_7 stmt = hy.3_7 = hy;
Setting value number of hy.3_7 to 0
Value numbering _8 stmt = _8 = _6 + hy.3_7;
Applying pattern match.pd:83, gimple-match.c:25537
Match-and-simplified _6 + hy.3_7 to _6
RHS _6 + hy.3_7 simplified to _6
Setting value number of _8 to _6
Value numbering .MEM_32 stmt = hy = _8;
No store match
Value numbering store hy to _6
Setting value number of .MEM_32 to .MEM_32
Value numbering hy.0_1 stmt = hy.0_1 = hy;
Setting value number of hy.0_1 to 0
Value numbering ez_28 stmt = ez_28 = hy.0_1 ^ ez_12;
Applying pattern match.pd:83, gimple-match.c:33234
Match-and-simplified hy.0_1 ^ ez_12 to ez_12
RHS hy.0_1 ^ ez_12 simplified to ez_12
Setting value number of ez_28 to ez_12
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:83, gimple-match.c:33234
Match-and-simplified ez_28 ^ wo_37 to ez_12
RHS ez_28 ^ wo_37 simplified to ez_12
Setting value number of _3 to ez_12 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to ez_12 (changed)
Starting iteration 46253

[Bug middle-end/77798] [7 Regression] 465.tonto ICE with trunk with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/77821] C++ binary size increase or LTO not working?

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
If you force (not sure what's the default on your target) -fno-fat-lto-objects
then you'll notice if LTO is used at link time.

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[tamar.christina at arm dot com]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tamar.christina at arm dot com

--- Comment #14 from Tamar Christina  ---
The ICE also happens on AArch64 in other expand functions and also seems to
cause some weird values on vector operations. 

FAIL: gcc.dg/tree-ssa/forwprop-35.c (internal compiler error)
FAIL: gcc.dg/tree-ssa/forwprop-35.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/forwprop-35.c scan-tree-dump-times cddce1 "VEC_PERM_EXPR"
1
FAIL: gcc.dg/tree-ssa/forwprop-35.c scan-tree-dump-times cddce1 "\\(v4sf\\) " 2
FAIL: gcc.target/aarch64/simd/vcvt_s64_f64_1.c (internal compiler error)
FAIL: gcc.target/aarch64/simd/vcvt_s64_f64_1.c (test for excess errors)
FAIL: gcc.target/aarch64/simd/vcvt_s64_f64_1.c scan-assembler fcvtzs[
\t]+[xX][0-9]+, ?[dD][0-9]+\n
FAIL: gcc.target/aarch64/simd/vcvt_u64_f64_1.c (internal compiler error)
FAIL: gcc.target/aarch64/simd/vcvt_u64_f64_1.c (test for excess errors)
UNRESOLVED: gcc.target/aarch64/simd/vcvt_s64_f64_1.c compilation failed to
produce executable
UNRESOLVED: gcc.target/aarch64/simd/vcvt_u64_f64_1.c compilation failed to
produce executable

[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Fallout in GENERIC folding from doing that:

FAIL: c-c++-common/fold-divmul-1.c  -std=gnu++11  scan-tree-dump-not original
"/
[ex]"
FAIL: g++.dg/cpp1y/constexpr-array4.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/ipa/devirt-28a.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/gomp/declare-simd-3.C  -std=gnu++98  scan-assembler-times
_ZGVeN16v
ulLUR4__Z2f4iiiRKiS0_S0_: 1
FAIL: g++.dg/torture/pr71448.C   -O0  (test for excess errors)

FAIL: c-c++-common/fold-divmul-1.c  -Wc++-compat   scan-tree-dump-not original
"
/[ex]"
FAIL: gcc.dg/pr58742-1.c scan-tree-dump cddce1 "return e"

so for GENERIC the used types_match () is too strict it seems.

[Bug target/77833] [7 Regression] ICE: in plus_constant, at explow.c:87 with -O -mavx512f

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/77842] New: genmatch segfault on a missing brace

[marxin at gcc dot gnu.org]

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

Bug ID: 77842
   Summary: genmatch segfault on a missing brace
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Adding following (wrong pattern) to match.pd:

(simplify
  (lt @0 @1)
   (if (integer_zerop (@0))
{
/* causing segfault:   } */
))

Causes segfault in:
Program received signal SIGSEGV, Segmentation fault.
_cpp_lex_direct (pfile=pfile@entry=0x689970) at ../../../libcpp/lex.c:2407
2407  if (buffer->need_line)
(gdb) bt
#0  _cpp_lex_direct (pfile=pfile@entry=0x689970) at ../../../libcpp/lex.c:2407
#1  0x0042af9a in _cpp_lex_token (pfile=pfile@entry=0x689970) at
../../../libcpp/lex.c:2291
#2  0x00431778 in cpp_get_token_1 (pfile=0x689970,
location=location@entry=0x0) at ../../../libcpp/macro.c:2462
#3  0x00431a47 in cpp_get_token (pfile=) at
../../../libcpp/macro.c:2604
#4  0x00414de8 in parser::next (this=) at
../../gcc/genmatch.c:3769
#5  parser::parse_c_expr (this=this@entry=0x7fffdb30,
start=start@entry=CPP_OPEN_BRACE) at ../../gcc/genmatch.c:4119
#6  0x00415561 in parser::parse_op (this=this@entry=0x7fffdb30) at
../../gcc/genmatch.c:4166
#7  0x00415f25 in parser::parse_result (this=this@entry=0x7fffdb30,
result=result@entry=0x0, matcher=matcher@entry=0x0) at
../../gcc/genmatch.c:4265
#8  0x00416db4 in parser::parse_simplify
(this=this@entry=0x7fffdb30, kind=kind@entry=simplify::SIMPLIFY,
simplifiers=..., matcher=matcher@entry=0x0, result=result@entry=0x0) at
../../gcc/genmatch.c:4415
#9  0x00417003 in parser::parse_pattern
(this=this@entry=0x7fffdb30) at ../../gcc/genmatch.c:4649
#10 0x0041835d in parser::parser (this=0x7fffdb30, r_=) at ../../gcc/genmatch.c:4735
#11 0x00408a2f in main (argc=, argv=) at
../../gcc/genmatch.c:4833

I don't know whether it worth for fixing, but I'm adding the issue..

[Bug lto/77821] C++ binary size increase or LTO not working?

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
Aha! 4.9.4 and additional LDFLAGS=$CFLAGS reproduces the larger size.
(-fno-fat-lto-objects on its own still works as expected)

Probably thee clue to solving this mystery :)

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Tue Oct  4 13:40:54 2016
New Revision: 240744

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

PR tree-optimization/77399
* tree-ssa-forwprop.c (simplify_vector_constructor): Properly
verify the target can convert.

* gcc.dg/tree-ssa/forwprop-35.c: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c
trunk/gcc/tree-ssa-forwprop.c

[Bug rtl-optimization/77843] New: ICE for gcc.dg/tree-ssa/forwprop-35.c

[segher at gcc dot gnu.org]

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

Bug ID: 77843
   Summary: ICE for gcc.dg/tree-ssa/forwprop-35.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/segher/build/tot-master/gcc/xgcc
-B/home/segher/build/tot-master/gcc/
/home/segher/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c  
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O -fdump-tree-cddce1
-S  -m64  -o forwprop-35.s(timeout = 300)
spawn -ignore SIGHUP /home/segher/build/tot-master/gcc/xgcc
-B/home/segher/build/tot-master/gcc/
/home/segher/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -fdump-tree-cddce1 -S
-m64 -o forwprop-35.s
/home/segher/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c: In function
'vec_cast':
/home/segher/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c:9:10: internal
compiler error: in expand_float, at optabs.c:4774
0x10781e93 expand_float(rtx_def*, rtx_def*, int)
/home/segher/src/gcc/gcc/optabs.c:4774
0x104d4307 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/segher/src/gcc/gcc/expr.c:8868
0x104be3b3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/segher/src/gcc/gcc/expr.c:9721
0x104ca3d7 expand_normal
/home/segher/src/gcc/gcc/expr.h:285
0x104ca3d7 copy_blkmode_to_reg(machine_mode, tree_node*)
/home/segher/src/gcc/gcc/expr.c:2717
0x10364e57 expand_return
/home/segher/src/gcc/gcc/cfgexpand.c:3516
0x10364e57 expand_gimple_stmt_1
/home/segher/src/gcc/gcc/cfgexpand.c:3618
0x10364e57 expand_gimple_stmt
/home/segher/src/gcc/gcc/cfgexpand.c:3745
0x1036a1c7 expand_gimple_basic_block
/home/segher/src/gcc/gcc/cfgexpand.c:5752
0x1036d407 execute
/home/segher/src/gcc/gcc/cfgexpand.c:6363

(powerpc64-linux, -m32, -m64, both BE and LE)

[Bug middle-end/77407] Optimize integer i / abs (i) into the sign of i

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Oct  4 13:18:18 2016
New Revision: 240742

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

PR middle-end/77407
* match.pd (X / abs (X) -> X < 0 ? -1 : 1): Drop vector
type support, mark with :C.
(X / -X -> -1): Mark with :C.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug target/77833] [7 Regression] ICE: in plus_constant, at explow.c:87 with -O -mavx512f

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Oct  4 13:39:22 2016
New Revision: 240743

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

PR middle-end/77833
* explow.c (plus_constant): Verify the mode of the constant
pool offset before calling plus_constant.

* gcc.target/i386/pr77833.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr77833.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/explow.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 4 Oct 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
> 
> --- Comment #4 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #3)
> > --- gcc/genmatch.c  (revision 240739)
> > +++ gcc/genmatch.c  (working copy)
> > @@ -2593,8 +2601,10 @@ dt_operand::gen_match_op (FILE *f, int i
> >  {
> >char match_opname[20];
> >match_dop->get_name (match_opname);
> > -  fprintf_indent (f, indent, "if (%s == %s || operand_equal_p (%s, %s,
> > 0))\n",
> > - opname, match_opname, opname, match_opname);
> > +  fprintf_indent (f, indent, "if (%s == %s || (operand_equal_p (%s, %s, 0) 
> > "
> > + "&& types_match (%s, %s)))\n",
> > + opname, match_opname, opname, match_opname,
> > + opname, match_opname);
> >fprintf_indent (f, indent + 2, "{\n");
> >return 1;
> >  }
> 
> But that will mean the pattern will no longer match.

Yes.  I'm not sure if in all patterns a mismatched type wouldn't not
cause wrong-code eventually.

>  While it is generally
> safer, for the cases like this simplify, shall it then use (convert? @2)
> instead and add operand_equal_p for @0 and @2?  I guess all it cares is that 
> @0
> actually has the same type as @1 there, not a different one?

Well, they have the same type by construction (being operands to bit_ior).

The issue with constants is that if we had (int) x_2 and valueize x_2 to
1 then the matcher still sees (int) 1 thus valueized matching occurs on
an otherwise "unfolded" tree ...

The pattern fails to handle (long)(2 | Y) ^ 2L as well, so it really
would need to do

/* (X | Y) ^ X -> Y & ~ X*/
(simplify
 (bit_xor:c (convert1? (bit_ior:c @0 @1)) (convert2? @0))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (convert (bit_and @1 (bit_not @0)

which then exposes the fact that if @0 == constant we might have
different types in the two places.  So it would need to be done as

/* (X | Y) ^ X -> Y & ~ X*/  
(simplify
 (bit_xor:c (convert1? (bit_ior:c @0 @1)) (convert2? @2))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
  && (@0 == @2 || operand_equal_p (@0, @2, 0)))
  (convert (bit_and @1 (bit_not @0)


Anyway - I think the safer operand_equal_p () && types_match () is
the way to go.  OTOH I don't like the explicit matching with
operand_equal_p ...

[Bug lto/77821] C++ binary size increase or LTO not working?

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
Just tried your suggestion and during the final link, /tmp is full of ltrans
objects so LTO seems to be working fine (GCC5 + -fno-fat-lto-objects) but the
stripped size ended up even larger (2.5M).

Anyway, here's what works for gcc 4.9.4 (sdl, sdl-ttf, sdl-mixer required):

$ export CFLAGS='-mcpu=cortex-a5 -Ofast -marm -fomit-frame-pointer -mfpu=neon
-ftree-vectorize -flto' CXXFLAGS='-mcpu=cortex-a5 -Ofast -marm
-fomit-frame-pointer -mfpu=neon -ftree-vectorize -flto'
git clone -b master git://git.code.sf.net/p/ufoai/code ufoai
cd ufoai && make -j4 && strip -s ufo

Starting with GCC5, even running:

LDFLAGS="$CFLAGS" ./configure ..., etc.

makes no difference, which makes me wonder if the LTO part of the GCC5
changelog could be relevant here?

[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> --- gcc/genmatch.c  (revision 240739)
> +++ gcc/genmatch.c  (working copy)
> @@ -2593,8 +2601,10 @@ dt_operand::gen_match_op (FILE *f, int i
>  {
>char match_opname[20];
>match_dop->get_name (match_opname);
> -  fprintf_indent (f, indent, "if (%s == %s || operand_equal_p (%s, %s,
> 0))\n",
> - opname, match_opname, opname, match_opname);
> +  fprintf_indent (f, indent, "if (%s == %s || (operand_equal_p (%s, %s, 0) "
> + "&& types_match (%s, %s)))\n",
> + opname, match_opname, opname, match_opname,
> + opname, match_opname);
>fprintf_indent (f, indent + 2, "{\n");
>return 1;
>  }

But that will mean the pattern will no longer match.  While it is generally
safer, for the cases like this simplify, shall it then use (convert? @2)
instead and add operand_equal_p for @0 and @2?  I guess all it cares is that @0
actually has the same type as @1 there, not a different one?

[Bug lto/77821] C++ binary size increase or LTO not working?

[tulipawn at gmail dot com]

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

--- Comment #5 from PeteVine  ---
Missed the configure step, just before make:

$ ./configure --enable-release --disable-sdl2 --enable-only-ufo

[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ideally we'd do operand_equal_p's job in the pattern but there is no reliable
way to get at the type of the (convert? @0) operand.  So I'm thinking of
amending operand_equal_p () with a types_match () check instead...

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 240739)
+++ gcc/genmatch.c  (working copy)
@@ -2593,8 +2601,10 @@ dt_operand::gen_match_op (FILE *f, int i
 {
   char match_opname[20];
   match_dop->get_name (match_opname);
-  fprintf_indent (f, indent, "if (%s == %s || operand_equal_p (%s, %s, 0))\n",
- opname, match_opname, opname, match_opname);
+  fprintf_indent (f, indent, "if (%s == %s || (operand_equal_p (%s, %s, 0) "
+ "&& types_match (%s, %s)))\n",
+ opname, match_opname, opname, match_opname,
+ opname, match_opname);
   fprintf_indent (f, indent + 2, "{\n");
   return 1;
 }

[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
We might have a duplicate about this alread.

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct  4 14:44:16 2016
New Revision: 240747

URL: https://gcc.gnu.org/viewcvs?rev=240747=gcc=rev
Log:
Backport from mainline
2016-09-29  Uros Bizjak  

* config/i386/driver-i386.c (host_detect_local_cpu): Check maximum
ext_level before calling CPUID with 0x8008.

2016-09-29  Uros Bizjak  

PR target/77756
* config/i386/cpuid.h (__get_cpuid_count): New.
(__get_cpuid): Rename __level to __leaf.

testsuite/ChangeLog:

Backport from mainline
2016-09-29  Uros Bizjak  

PR target/77756
* gcc.target/i386/pr77756.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77756.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/cpuid.h
branches/gcc-6-branch/gcc/config/i386/driver-i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/77843] ICE for gcc.dg/tree-ssa/forwprop-35.c

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
It is trying to do a signed conversion from TImode to float here, to be
stored in BLKmode.

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

[tulipawn at gmail dot com]

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

--- Comment #7 from PeteVine  ---
Even though it's probably a dfifferent issue (affecting GCC6/7), profiling
makes the solver about 2-3% slower on aarch64:

profiled/non-profiled
gcc5.4 799/875
gcc6.2 790/773
gcc7.0 752/730

But guess what, if you grep for `sdiv`, there's 9 of them in the profiled asm
file versus just 6 in the non-profiled version. FWIW, so I'm attaching the
files.

[Bug c++/77840] List-initialization and copy-constructor

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Wolfgang Roehrl from comment #0)
> Hi,
> I would like to post a bug report for the GNU C/C++ compiler 6.1.1.
> We use the compiler to generate code for a PowerPC processor.
> Invokation line for the GNU C compiler:
> 
> ccppc -c -x c -std=gnu11 -Wall -Werror -g -mcpu=e6500 -m32
>   -maltivec -mvrsave -ftls-model=local-exec -msdata=sysv
>   -fno-common -fno-openmp -mbig -mmultiple -mno-string -misel
>   -mstrict-align -fverbose-asm -G 8 -O3
>   -I
>   -D
>   X.C -oX.O
> 
> 
> // file X.C
> 
> struct X
> {
> X (int);
> X (const X&) = delete;
> };
> 
> X arrX = { 1, 2, 3 };

I assume you meant arrX[] here?


> The compiler rejects this program because the copy constructor is
> deleted. But according to the C++11 standard this initialization
> should not involve a copy/move constructor (cf. 12.6.1/2).

I don't think that's correct. The code is roughly equivalent to:

  X arrX[] = { X(1), X(2), X(3) };

and that requires a copy constructor to initialize the array elements from the
X(1), X(2), X(3) temporaries.

> By the way, the compiler accepts a slighty different programm:
> 
> // file X.C
> 
> struct X
> {
> X (int);
> X (const X&) = delete;
> };
> 
> 
> X arrX[] = { {1}, {2}, {3} };

This is valid. In this code each X in the array is direct-list-initialized from
the {1} initializer, with no temporaries to be copied.

In other words, in the first example initialization of each element is
equivalent to

  X x = 1;

and in the second is equivalent to:

  X x{1};

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

[tulipawn at gmail dot com]

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

--- Comment #8 from PeteVine  ---
Created attachment 39749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39749=edit
aarch64 assembly

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #15 from Uroš Bizjak  ---
Fixed.

[Bug libfortran/77663] libgfortran/caf/single.c: three minor problems and a lost token

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to vehre from comment #1)
> what SW did you use to find this?

cppcheck, a static analyser for C/C++, available from sourceforge.

I run it sometimes over the compiler source code.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-04
 CC||amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #3 from Alan Modra  ---
Confirmed.  See also pr77853

[Bug c/77853] New: -Wimplicit-fallthrough: Fall through comment made ineffective by following comment

[amodra at gmail dot com]

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

Bug ID: 77853
   Summary: -Wimplicit-fallthrough: Fall through comment made
ineffective by following comment
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

int
f (int x)
{
  int ret = 0;
  switch (x)
{
case 1:
  ret++;
  /* Fall through.  */

  /* Important comment about case 0.  */
case 0:
  ret++;
}
  return ret;
}

Noticed when building binutils with current master gcc.

[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> Eric, can you please provide a test case where you are seeing the
> unpropagated copies?  Thanks!

I only have an Ada testcase but I think that it would be fairly easy to see
unpropagated copies: replace

case MODIFY_EXPR:
  slsr_process_copy (gs, rhs1, speed);
  break;

with

case SSA_NAME:
  gcc_unreachable ();

and run the C testsuite.  Of course that doesn't mean any transformation would
necessarily be done in the end.

[Bug c++/77844] New: Compilation of simple C++ example exhaust memory

[graeser at mi dot fu-berlin.de]

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

Bug ID: 77844
   Summary: Compilation of simple C++ example exhaust memory
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: graeser at mi dot fu-berlin.de
  Target Milestone: ---

Created attachment 39750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39750=edit
Compiling with 'g++-4.9 -O -g' triggers the problem.

When trying to compile the attached example with 'g++-4.9 -O -g' compilation
does not terminate and memory usage grows slowly. I terminated compilation when
gcc used more than 14gb of memory.

Notice that the issue is not triggered if one level of indirection is removed,
e.g., if the body of test() is copied into main().

[Bug middle-end/77844] Compilation of simple C++ example exhaust memory

[graeser at mi dot fu-berlin.de]

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

--- Comment #2 from graeser at mi dot fu-berlin.de ---
With gcc 5.4.0 on Ubuntu this issue seems to be essentially fixed. However,
compilation still takes about 14s and eats up about 1gb which looks huge
compared to 0.1s and 31mb if the indirection via test() is removed.

[Bug c++/77791] ICE on invalid C++11 code with redefined function parameter: tree check: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in cp_parser_lambda_declarator_opt, at

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Oct  4 15:34:16 2016
New Revision: 240751

URL: https://gcc.gnu.org/viewcvs?rev=240751=gcc=rev
Log:
PR c++/77791
* parser.c (cp_parser_lambda_declarator_opt): Only pedwarn
for C++11 on decls in the param_list.  Test cxx_dialect < cxx14 before
the loop just once.

* g++.dg/cpp0x/lambda/lambda-77791.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-77791.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/77844] Compilation of simple C++ example exhaust memory

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This might have been fixed already. Can you try out gcc 5.4.0?

[Bug tree-optimization/77808] [7 Regression] ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[mpf at gcc dot gnu.org]

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

--- Comment #1 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Tue Oct  4 15:28:23 2016
New Revision: 240749

URL: https://gcc.gnu.org/viewcvs?rev=240749=gcc=rev
Log:
Fix PR tree-optimization/77808

gcc/
PR tree-optimization/77808
* tree-ssa-loop-prefetch.c (issue_prefetch_ref): Check base_addr
and addr are different before copying points-to information.

gcc/testsuite/
PR tree-optimization/77808
* gcc.dg/tree-ssa/pr77808.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-prefetch.c

[Bug lto/65239] typeinfo / VTT for some classes not visibile in shared library when LTO is used

[andysem at mail dot ru]

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

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #3 from andysem at mail dot ru ---
I'm having this problem too with gcc 5.4 from Kubuntu 16.04 x86_64 with our
private project.

[Bug c++/77852] ICE when deducing class template arguments for pair or tuple

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed Oct  5 01:24:38 2016
New Revision: 240765

URL: https://gcc.gnu.org/viewcvs?rev=240765=gcc=rev
Log:
PR c++/77852 - class deduction from list-init

* pt.c (do_class_deduction): Handle list-initialization.
(do_auto_deduction): Call it sooner.
(build_deduction_guide): Use tsubst_arg_types.
(rewrite_template_parm): Don't copy_type.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction14.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction15.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction16.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/77852] ICE when deducing class template arguments for pair or tuple

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug tree-optimization/77856] New: wrong code at -O2 on x86_64-linux-gnu in 32-bit mode

[su at cs dot ucdavis.edu]

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

Bug ID: 77856
   Summary: wrong code at -O2 on x86_64-linux-gnu in 32-bit mode
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It is a regression from 6.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161004 (experimental) [trunk revision 240755] (GCC) 
$ 
$ gcc-6.2 -m32 -O2 small.c; ./a.out
1
$ gcc-trunk -m32 -Os small.c; ./a.out
1
$ 
$ gcc-trunk -m32 -O2 small.c; ./a.out
64
$ 
$ 


--


int printf (const char *, ...);

unsigned a, e;

struct S0
{
  int f1;
  int f8;
} c = {4, 6};

int b, f, g, h, i, j, l, p;
short d, o = -7;
char k, n = 5;

unsigned fn1 (int p1, int p2)
{
  return p2 >= 2 || p1 >> p2 ? p1 : p1 << p2;
}

static short fn2 (struct S0 p1)
{
  int *q = 0;
  int r = 7;
  if (!a)
{
  c.f1 = 1;
  for (; c.f1; c.f1--)
if (fn1 (10 != 0, p1.f8))
  {
short s = 9 << ~o % (d ^ n);
int t = s >> h % ~d;
p = r;
r = s | p * (d && 9) | t;
int u = i & c.f1;
unsigned v = ~(~(u & h) | (~(8 >> c.f1) & i));
int w = v;
if (u < 9)
  w = c.f1;
if (i > h && u)
  {
printf ("%d\n", c.f1);
continue;
  }
c.f1 = w;
if (!p)
  continue;
return 0;
  }
  for (;;)
*q = 0;
}
  return 0; 
}

static void fn3 ()
{
  fn2 (c);
  l = c.f1 < b;
  if (l)
{
L1:
  e = l | j / e % ~f;
  j = f - 4 % k < c.f1 / e / b - j - 1;
  if (l)
{
  printf ("%d\n", b);
  goto L1;
}
  int m[245];
  g = m[2];
}
}

int main ()
{
  fn3 ();
  printf ("%d\n", c.f1);
  return 0; 
}

[Bug rtl-optimization/77855] New: wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

Bug ID: 77855
   Summary: wrong code at -O3 on x86_64-linux-gnu (in both 32-bit
and 64-bit modes)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It is a regression from 6.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161004 (experimental) [trunk revision 240755] (GCC) 
$ 
$ gcc-6.2 -O3 small.c; ./a.out
2
$ gcc-trunk -O2 small.c; ./a.out
2
$ 
$ gcc-trunk -O3 small.c; ./a.out
0
$ 


--


int a, b = 1, c, e, f, g, k, m, n, o;
char d, h, i, j, l; 

void fn1 ()
{
  if (e)
j = 1;
  if (f)
  L1:
k = j | (a & l);
  for (;;)
{
  __builtin_printf ("%d\n", d);
  if (d)
break;
  for (; o; o--)
for (; n;)
  for (; m; m++)
;
  goto L1;
}
}

void fn2 ()
{
  d = 2;
}

void fn3 ()
{
  for (;;)
{
  for (; b; b--)
{
  fn2 (8);  
  fn1 ();
}
  g = h;
  c = i;
  break;
}
}

int main ()
{
  fn3 ();
  return 0; 
}

[Bug tree-optimization/71661] [7 Regression] wrong code at -O3

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
I'm really just getting started looking at this one.   I had hoped that this
was the same issue as 71550, but instead is just looks related (as in there's
another case where a pass collapses two loops into one and thus needs to
invalidate the cached iteration information).

What I've concluded so far is that we start with 3 loops, two of which are
irreducible.  Jump threading cleans things up ever-so-slightly turning one
irreducible loop into a natural loop which is discovered by the loop
infrastructure.

That newly exposed natural loop is contained within the remaining irreducible
loop.  The header of the newly exposed natural loop is also the target of the
"backedge" of the irreducible loop.  My current theory is that CFG structure is
confusing a later pass (possibly loop-ch as Jakub mentions in his comments).

[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Eric, thanks for the report!  I'll have a look.  Much obliged.  This used to
work several years ago...

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[andysem at mail dot ru]

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

andysem at mail dot ru changed:

   What|Removed |Added

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

--- Comment #7 from andysem at mail dot ru ---
I believe, this bug is not yet fixed in gcc 5.4 on Kubuntu 16.04 x86_64.

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

I attached a new testcase. The compiler still produces AVX instructions in both
_Z17my_simd_func_sse2PKhPh and _Z16my_simd_func_avxPKhPh functions.

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[andysem at mail dot ru]

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

--- Comment #8 from andysem at mail dot ru ---
Created attachment 39751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39751=edit
A new testcase which produces invalid code with gcc 5.4

[Bug lto/61043] LTO accumulates CPU requirements from all input objects

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
(In reply to andysem from comment #8)
> Created attachment 39751 [details]
> A new testcase which produces invalid code with gcc 5.4

I think this testcase is violating C++ ODR.  In that
INSTRUCTION_SET::my_simd_func_impl is the same between the TUs.  If you had
used an anonymous namespace, it should have worked correctly.  If anonymous
namespace does not work, please file a separate bug.

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

[n8tm at aol dot com]

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

--- Comment #12 from n8tm at aol dot com ---
On 9/25/2016 3:03 PM, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593
>
> --- Comment #9 from Jerry DeLisle  ---
> (In reply to tprince from comment #8)
>> I show my configure parameters in my test results posts.  At some time in
>> the past, each of them has been important.  I don't know if the parameters
>> quoted by cygwin release pertain to cross compiling.  As the parameters I
>> use have been successful again last week on win8.1 I don't see how they
>> might pertain to the f951 bootstrap failure on win10.  When I get back to
>> the win10 box I will compare with disable bootstrap.
> Tim, using your parameters I was able to build.  I proceeded to do a 
> regression
> hunt and confirmed that it was at the DTIO patch on 8/31/2016.
>
> In this patch we added two new functions to libgfortran and set the symbol
> versioning. I modified the library by inserting a printf("ping\n") in the code
> path for a simple program.
>
> print *, "hello"
> end
>
> The ping does not show which means the wrong library is being used at run 
> time.
>
> I am trying various config and bath settings to see if I can sort it out. No
> luck so far.
>
Jerry,
They fixed the blocking update in trunk libstdc++ yesterday.  In order
to build libgfortran, I #if'd out the __MINGW64_VERSION_MAJOR section in
intrinsics/random.c (not having received any advice about this). 
gfortran testsuite for cygwin/win8.1 is hanging on some of the arrayio
tests which I am having to kill by Task Manager.
If I try to use any parallel method for testsuite, there are pipe
failures, so I guess the cygwin implementation of pipes remains non
thread-safe.
I had no trouble completing gfortran testsuite in Windows 10 Ubuntu
subsystem (it skipped many tests), but it remains relatively easy to
hang the entire linux subsystem, requiring a full Windows reboot.

[Bug target/77822] [6 REGRESSION] arm64 Error: immediate value out of range 0 to 63 at operand 3

[jordi at gnu dot org]

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

--- Comment #12 from Jordi Mallach  ---
Created attachment 39748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39748=edit
s file

[Bug target/77822] [6 REGRESSION] arm64 Error: immediate value out of range 0 to 63 at operand 3

[jordi at gnu dot org]

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

--- Comment #11 from Jordi Mallach  ---
Created attachment 39747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39747=edit
ii file

[Bug c++/77840] New: List-initialization and copy-constructor

[wolfgang.roe...@gi-de.com]

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

Bug ID: 77840
   Summary: List-initialization and copy-constructor
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wolfgang.roe...@gi-de.com
  Target Milestone: ---

Hi,
I would like to post a bug report for the GNU C/C++ compiler 6.1.1.
We use the compiler to generate code for a PowerPC processor.
Invokation line for the GNU C compiler:

ccppc -c -x c -std=gnu11 -Wall -Werror -g -mcpu=e6500 -m32
  -maltivec -mvrsave -ftls-model=local-exec -msdata=sysv
  -fno-common -fno-openmp -mbig -mmultiple -mno-string -misel
  -mstrict-align -fverbose-asm -G 8 -O3
  -I
  -D
  X.C -oX.O


// file X.C

struct X
{
X (int);
X (const X&) = delete;
};

X arrX = { 1, 2, 3 };


The compiler rejects this program because the copy constructor is
deleted. But according to the C++11 standard this initialization
should not involve a copy/move constructor (cf. 12.6.1/2).

By the way, the compiler accepts a slighty different programm:

// file X.C

struct X
{
X (int);
X (const X&) = delete;
};


X arrX[] = { {1}, {2}, {3} };



With kind regards
W. Roehrl

[Bug tree-optimization/77836] Simplify (x>>4)*16 in gimple

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #1)
> The easy way to do this is to canonicalize the shift to a multiply or the
> multiply to a shift which is what it is done on the RTL level.

For unsigned types that seems fine, but for signed types, lshift looses
information on (im)possible overflow compared to multiplication, so I am
reluctant to turn mult into lshift, and turning lshift into mult requires VRP.

[Bug target/77822] [6 REGRESSION] arm64 Error: immediate value out of range 0 to 63 at operand 3

[jordi at gnu dot org]

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

--- Comment #10 from Jordi Mallach  ---
OK, to avoid the .gch includes, build with PRECOMPILE=0 REGENIE=1. I'm
attaching the result.

[Bug c++/77841] New: a new expression of a char array cannot be initialized by a string literal

[kariya_mitsuru at hotmail dot com]

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

Bug ID: 77841
   Summary: a new expression of a char array cannot be initialized
by a string literal
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com
  Target Milestone: ---

Please see the sample code below.

== sample code ==
int main()
{
char* s = new char[4]{"abc"};
}
== sample code ==

= compiler output (GCC HEAD 7.0.0 20161003) =
prog.cc: In function 'int main()':
prog.cc:3:32: error: invalid conversion from 'const char*' to 'char'
[-fpermissive]
 char* s = new char[4]{"abc"};
^
= compiler output (GCC HEAD 7.0.0 20161003) =

cf. http://melpon.org/wandbox/permlink/utGUZYo8NKRqGDM5


The latest draft standard says,

5.3.4 New [expr.new] p.17.2
Otherwise, the new-initializer is interpreted according to the initialization
rules of 8.5 for direct-initialization.

8.5 Initializers [dcl.init] p.17.1
If the initializer is a (non-parenthesized) braced-init-list, the object or
reference is list-initialized (8.5.4).

8.5.4 List-initialization [dcl.init.list] p.3.2
Otherwise, if T is a character array and the initializer list has a single
element that is an appropriately-typed string literal (8.5.2), initialization
is performed as described in that section.

So, I think that the sample code above should be compiled successfully.

Note that 8.5.4 p.3.2 was added for resolution of
DR1490.(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1490) and
DR1467.(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1467).

Note also that GCC (at least 4.4.7 or later) accepts a string-literal within a
brace-init-list for (usual) direct-initialization.

== sample code ==
int main()
{
char s[4]{"abc"};
}
== sample code ==

cf. http://melpon.org/wandbox/permlink/fZkVTLQXBxatUjBX

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-04
 CC||marxin at gcc dot gnu.org
  Known to work||5.4.0
Summary|[7 Regression] Memory- and  |[6/7 Regression] Memory-
   |compile time hog at -O1 and |and compile time hog at -O1
   |above   |and above
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, GCC 5.4.0 works fine, starts with GCC 6.1.0.