[Bug fortran/81048] New: incorrect derived type initialization

[dm577216smith at gmail dot com]

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

Bug ID: 81048
   Summary: incorrect derived type initialization
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dm577216smith at gmail dot com
  Target Milestone: ---

A large program that ran correctly on several previous versions of gfortran
(and other compilers) failed when I installed from gfortran-6.3-Sierra.dmg
and CommandLineToolsforXcode8.3.2.dmg on a new Mac.

Please let me know if this is a gfortran6 bug, or if I have messed up the
installation.

Thanks,

David Smith
dsm...@lmu.edu


---

I will include a small program that seems to show the problem.

I think this is the correct output, from gfortran 5:

~ $ gfortran gfortran6test.f95 -o gfortran6test
~ $ gfortran6test
  a%f =   -1
  b(1:3)%f =-1  -1  -1
  g2(1:3)%f =   -1  -1  -1
  b = g(a) gives b(1:3)%f =   -2  -2   
  -2
  h2(1:3)%f =   -1  -1  -1
  b = h(a) gives b(1:3)%f =   -2  -2   
  -2
~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local/gfortran
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin14
Thread model: posix
gcc version 5.2.0 (GCC) 


---


Here is my output from 6.3:

~ $ gfortran gfortran6test.f95 -o gfortran6test
~ $ gfortran6test
  a%f =   -1
  b(1:3)%f =-1  -1  -1
  g2(1:3)%f =   -1  -1  -1
  b = g(a) gives b(1:3)%f =   -2  -2   
  -2
  h2(1:3)%f =   -2  -2  -2
  b = h(a) gives b(1:3)%f =   -12346  -12346 
-12346
~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin16/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16
Configured with: ../gcc-6.3.0/configure --prefix=/usr/local/gfortran
--enable-languages=c,c++,
fortran,objc,obj-c++ --build=x86_64-apple-darwin16
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64
 --with-mpfr=/Users/fx/devel/gcc/deps-static/x86_64
--with-mpc=/Users/fx/devel/gcc/deps-static/x86_64
 --with-isl=/Users/fx/devel/gcc/deps-static/x86_64
Thread model: posix
gcc version 6.3.0 (GCC) 
~ $ 

---


module m
   type f
   integer :: f = -1
   end type
   interface g
   module procedure g2
   end interface
   contains
   function g2(a)
  type(f) :: a, g2(3)
  write (*,*) ' g2(1:3)%f = ', g2(1:3)%f
  do j = 1, 3
 if (g2(j)%f == -1) then
 g2(j)%f = a%f - 1
 else
 g2(j)%f = a%f - 12345
 endif
  enddo
   end function g2
end module m

module m2
   use m
   interface h
   module procedure h2
   end interface
   contains
   function h2(a)
  type(f) :: a, h2(3)
  write (*,*) ' h2(1:3)%f = ', h2(1:3)%f
  do j = 1, 3
 if (h2(j)%f == -1) then
 h2(j)%f = a%f - 1
 else
 h2(j)%f = a%f - 12345
 endif
  enddo
   end function h2
end module m2

program test
   use m2
   type(f) :: a, b(3)
   write (*,*) ' a%f = ', a%f
   write (*,*) ' b(1:3)%f =  ', b(1:3)%f
   b = g(a)
   write (*,*) ' b = g(a) gives b(1:3)%f = ', b(1:3)%f
   b = h(a)
   write (*,*) ' b = h(a) gives b(1:3)%f = ', b(1:3)%f
end program test

[Bug tree-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

[doug.gilmore at imgtec dot com]

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

Doug Gilmore  changed:

   What|Removed |Added

Summary|[MIPS] soft-float glibc |[8 Regression] gcc ICE
   |build fails at r248863  |while building glibc for
   ||MIPS soft-float multi-lib
   ||variant

--- Comment #6 from Doug Gilmore  ---
We are back to having our MIPS nightly ToT toolchain builds all
working with r247049 reverted.

Given that r247049 exposes another PRE issue, see bug 80620,
does it make sense to back out until we resolve the problems
at hand?

[Bug c++/81047] New: thread local storage static class members of class type cannot be initialized

[jason.vas.dias at gmail dot com]

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

Bug ID: 81047
   Summary: thread local storage static class members of class
type cannot be initialized
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

I am not seeing how it is possible to initialize a static TLS structure
member that is of a class type :

#include 
#include 
struct in_tls
{ int a;
  std::string b;
};
bool tls_init=false;
struct A
{ static __thread in_tls _in_tls ;
  void f()
  { _in_tls.a = 1;
  }
  A()
  { if( !tls_init )
{ _in_tls = { 0, std::string() };
  tls_init = true;
}
  }
};
__thread in_tls A::_in_tls = { 0 };
// = { 0, "" } | 
// = { 0, std::string() } : tried both, same result
void init(void)
{ A::_in_tls.b=std::string();
  tls_init=true;
}
void init(void)  __attribute__((constructor));
int main(int argc, char *const* argv)
{ A a; a.f();
  return 0;
}


G++ 5.4.0 refuses to accept that 'in_tls.b' is initialized:

$ g++ -std=gnu++11 -I. -D_REENTRANT -pthread -fPIC -pipe -Wall -Wextra \
 -Wno-unused -o /tmp/t /tmp/tTLS.C
/tmp/tTLS.C:20:34: warning: missing initializer for member 'in_tls::b'
[-Wmissing-field-initializers]
 __thread in_tls A::_in_tls = { 0 };
  ^
/tmp/tTLS.C:20:34: error: non-local variable 'A::_in_tls' declared '__thread'
needs dynamic initialization
/tmp/tTLS.C:20:17: note: C++11 'thread_local' allows dynamic initialization and
destruction
 __thread in_tls A::_in_tls = { 0 };
 ^

But I cannot seem to find ANY way to initialize a member like 'b' of a 
static TLS member .

The test code compiles fine (with a warning about uninitialized '_in_tls.b',
(unless its initializer is specified like '{0, std::string()}', then no
warning) - but does succeed, if either of :
1. '__thread' is undefined and redefined as nothing ;
 #undef __thread
 #define __thread
 (not a  workaround!)
OR
2. '_in_tls.b' is made to be not a C++ class object, like 'const char *' -
 (again, not a workaround)
changes are made.

There is no way to put C++ object structure members in TLS and get them
initialized ?

I have tried compiling with '-std=gnu++1'{4,7} with same result.

Is there any special magic I need to do to get the example
std::string '_in_tls.b' initialized so that compiler sees it and 
does not fail with the error?

Incidentally, the error is very confusing - it first claims that it
is an error to attempt to initialize the TLS variable dynamically, and
then issues a 'note:' that C++11 supports dynamic initialization of 
TLS objects - but it doesn't ?

thanks in advance for any advice,
Jason

[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||msp430

--- Comment #5 from Andrew Pinski  ---
(In reply to Alexey Neyman from comment #4)
> Author: amonakov 
> Date:   Mon May 30 14:37:02 2016 +

This just exposed the bug.

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #12 from Michael Meissner  ---
*** Bug 81044 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/81044] fold-const change in svn 248447 breaks PowerPC spec 2006 hmmr

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
It appears to be fixed in subversion id 248919 (i.e. PR 80974).  Thanks Andrew.

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

[Bug middle-end/81046] New: [8 Regression] FAIL: gcc.dg/pr28796-2.c execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 81046
   Summary: [8 Regression] FAIL: gcc.dg/pr28796-2.c execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr28796-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-funsafe-math-optimizations -fno-finite-math-only -DUNSAFE -lm -o
./pr28796-2.exe
PASS: gcc.dg/pr28796-2.c (test for excess errors)Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/g
nu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-li
nux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/
gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/
libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev
-gccExecution timeout is: 300spawn [open ...]FAIL: gcc.dg/pr28796-2.c execution
test

Similar fail:
FAIL: gcc.dg/pr77925.c execution test

Probably introduced by fix for PR 77926.

[Bug c++/81045] [7 Regression] return type deduction causes template function call failure

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Somehow GCC is deciding that easyObjects->begin() and end() are dependent types
so you need to use the template keyword for the call to cast.

That is:
auto casted = obj.template cast();

I don't know if GCC is correct here or not.

[Bug c++/81045] New: [7 Regression] return type deduction causes template function call failure

[sintendo at gmail dot com]

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

Bug ID: 81045
   Summary: [7 Regression] return type deduction causes template
function call failure
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sintendo at gmail dot com
  Target Milestone: ---

Created attachment 41530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41530&action=edit
source

https://godbolt.org/g/3pXcbe

g++ -std=c++14 bug.cpp

The attached testcase will fail to compile in GCC 7.1.0:

: In member function 'void Group::objects() const':
:46:31: error: expected primary-expression before '>' token
   auto casted = obj.cast();
   ^
:46:33: error: expected primary-expression before ')' token
   auto casted = obj.cast();
 ^

Explicitly stating the return types for vector::begin() and vector::end() will
make the error go away, although I do not think it is necessary in this case.
clang and older GCC versions do not have this problem.

[Bug rtl-optimization/81044] fold-const change in svn 248447 breaks PowerPC spec 2006 hmmr

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
I had recorded my observations in PR 80894.

[Bug rtl-optimization/81044] fold-const change in svn 248447 breaks PowerPC spec 2006 hmmr

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This was broken for me on aarch64-linux-gnu too by the same revision but had
been fixed by revision 248919 aka PR80974.  Can you try again to see if it is
still broken also.

[Bug rtl-optimization/81044] fold-const change in svn 248447 breaks PowerPC spec 2006 hmmr

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 41529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41529&action=edit
Assembly code from svn 248446 that fails

[Bug rtl-optimization/81044] fold-const change in svn 248447 breaks PowerPC spec 2006 hmmr

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 41528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41528&action=edit
Assembly code from svn 248446 that works

[Bug rtl-optimization/81044] New: fold-const change in svn 248447 breaks PowerPC spec 2006 hmmr

[meissner at gcc dot gnu.org]

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

Bug ID: 81044
   Summary: fold-const change in svn 248447 breaks PowerPC spec
2006 hmmr
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41527&action=edit
hmmio.i file that was used.

I was running spec 2006 benchmarks on a little endian power8 system, and I
noticed that the 456.hmmer benchmark doesn't run starting with subversion id
248447.

Note, in order to get it to fail, you need to use the -mveclibabi=mass option
to vectorize math functions and use the MASS 8.1.3 libraries.  I traced this
down the hmmio.c module getting miscompiled when -O2 or higher is used.  Note,
the hmmio.c function does not call any of the vectorized math functions, but it
needs other modules to use them.

I haven't looked at all of the differences, but the changes for the code
generated for line 664 seem to be wrong.  It is collapsing two different 32-bit
compares into one 64-bit compare and then doing a MCRF (move condition
register) instruction to duplicate the test.

This is the ChangeLog for the 248446 change:
2017-05-25  Marc Glisse  

* fold-const.c (fold_binary_loc) [(A & C) == D]: Remove transformation.
* match.pd (X == C): Rewrite it here.
(with_possible_nonzero_bits, with_possible_nonzero_bits2,
with_certain_nonzero_bits2): New predicates.
* tree-ssanames.c (get_nonzero_bits): Handle INTEGER_CST.

[Bug c++/67969] [concepts] bug with overloaded function when using constraints

[hstong at ca dot ibm.com]

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

Hubert Tong  changed:

   What|Removed |Added

 CC||hstong at ca dot ibm.com

--- Comment #2 from Hubert Tong  ---
Reproduced on GCC 6.1.
Works for me on GCC 6.2: https://wandbox.org/permlink/oLKUMUjPG7Gm2hLK

[Bug c++/81043] New: [concepts] partially specializing on differing constraints gives cryptic error

[hstong at ca dot ibm.com]

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

Bug ID: 81043
   Summary: [concepts] partially specializing on differing
constraints gives cryptic error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Having more than one partial specialization with, ignoring constraints, the
same arguments results in a cryptic error.

### SOURCE ():
template  concept bool C0 = sizeof(T) <= 4;
template  concept bool C1 = sizeof(T) > 4;
template  struct A;
template  struct A;
template  struct A;


### COMPILER INVOCATION:
g++ -fsyntax-only -x c++ -std=gnu++1z -fconcepts -


### EXPECTED OUTPUT:
(rc=0)


### ACTUAL OUTPUT:
:5:24: error: 'A' does not match any declaration


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170608 (experimental) (GCC)

[Bug c++/81042] Too many constexpr interations on unreachable loop.

[kevincox at kevincox dot ca]

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

--- Comment #1 from Kevin Cox  ---
Also it appears the loop condition isn't properly evaluated. For example the
following three examples (and any other number I tested also cause the error.

while (++i == 0) {} // Unreachable
while (++i == 1) {} // Unreachable
while (++i == 2) {} // Unreachable

However some simpler expressions don't cause the error.

while (false) {} // Unreachable
while (i != i) {} // Unreachable

[Bug debug/81042] New: Too many constexpr interations on unreachable loop.

[kevincox at kevincox dot ca]

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

Bug ID: 81042
   Summary: Too many constexpr interations on unreachable loop.
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevincox at kevincox dot ca
  Target Milestone: ---

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

The following code causes an error for too many iterations in the unreachable
loop. Clang correctly creates a binary which returns 1 when run. It's worth
noting that the previous version of gcc I tried this on hung forever, however
7.1.1 gives the too many iterations error.

Example online: https://godbolt.org/g/QFRmwk

$ g++ -std=c++17 test.cc 
/home/kevincox/test.cc: In function ‘int main()’:
/home/kevincox/test.cc:14:24:   in constexpr expansion of ‘foo()’
/home/kevincox/test.cc:7:3: error: constexpr loop iteration count exceeds limit
of 262144 (use -fconstexpr-loop-limit= to increase the limit)
   while (true) {} // Unreachable
   ^

// test.cc
constexpr static bool foo() {
int i = 0;
while (i < 1) {
i++;
continue;

while (true) {} // Unreachable
}

return true;
}

int main() {
constexpr bool f = foo();
return f;
}

[Bug libstdc++/80675] Incorrect implementation of LWG 2534

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-09
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

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

[Bug libstdc++/80940] Private inheritance from std::ostream - compilation error for custom operator <

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-09
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

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

[Bug c++/80384] ICE when deducing noexcept in class template partial specialization

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jun  9 20:13:38 2017
New Revision: 249078

URL: https://gcc.gnu.org/viewcvs?rev=249078&root=gcc&view=rev
Log:
PR c++/80384 - ICE with dependent noexcept-specifier

* pt.c (dependent_type_p_r) [FUNCTION_TYPE]: Check for dependent
noexcept-specifier.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/noexcept-type15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from janus at gcc dot gnu.org ---
Fix backported to the 5,6,7 branches. Closing.

[Bug target/80968] stack frame reference allowed in delay slot of return instruction

[davem at gcc dot gnu.org]

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

--- Comment #8 from davem at gcc dot gnu.org ---
Author: davem
Date: Fri Jun  9 19:24:51 2017
New Revision: 249074

URL: https://gcc.gnu.org/viewcvs?rev=249074&root=gcc&view=rev
Log:
sparc: Further adjustments for alloca epilogue blockage.

gcc/

PR target/80968
* config/sparc/sparc.c (sparc_flat_expand_epilogue): Don't
emit frame blockage here.
(sparc_expand_epilogue): Do it here.
* config/sparc/sparc.md (return expander): Emit frame blockage
for alloca here too.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/sparc/sparc.c
branches/gcc-6-branch/gcc/config/sparc/sparc.md

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Jun  9 19:23:48 2017
New Revision: 249073

URL: https://gcc.gnu.org/viewcvs?rev=249073&root=gcc&view=rev
Log:
2017-06-09  Janus Weil  

Backport from trunk
PR fortran/70601
* trans-expr.c (gfc_conv_procedure_call): Fix detection of allocatable
function results.


2017-06-09  Janus Weil  

Backport from trunk
PR fortran/70601
* gfortran.dg/proc_ptr_comp_50.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_50.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/80968] stack frame reference allowed in delay slot of return instruction

[davem at gcc dot gnu.org]

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

--- Comment #7 from davem at gcc dot gnu.org ---
Author: davem
Date: Fri Jun  9 19:21:15 2017
New Revision: 249072

URL: https://gcc.gnu.org/viewcvs?rev=249072&root=gcc&view=rev
Log:
sparc: Further adjustments for alloca epilogue blockage.

gcc/

PR target/80968
* config/sparc/sparc.c (sparc_flat_expand_epilogue): Don't
emit frame blockage here.
(sparc_expand_epilogue): Do it here.
* config/sparc/sparc.md (return expander): Emit frame blockage
for alloca here too.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sparc/sparc.c
branches/gcc-5-branch/gcc/config/sparc/sparc.md

[Bug other/81041] New: [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058

[seurer at gcc dot gnu.org]

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

Bug ID: 81041
   Summary: [8 regression] test case gcc.dg/pr78582.c fails with
ICE starting with r249058
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing this on powerpc64 both BE and LE.

make -k check-gcc RUNTESTFLAGS=dg.exp=gcc.dg/pr78582.c

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr78582.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fprofile-generate -S -o
pr78582.s
during IPA pass: profile
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr78582.c: In function 'main':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr78582.c:18:1: internal
compiler error: Segmentation fault
0x109469ab crash_signal
/home/seurer/gcc/gcc-test/gcc/toplev.c:338
0x105f76d8 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/home/seurer/gcc/gcc-test/gcc/gimple-walk.c:915
0x1040fda7 cgraph_node::record_stmt_references(gimple*)
/home/seurer/gcc/gcc-test/gcc/cgraphbuild.c:277
0x1040fda7 cgraph_edge::rebuild_edges()
/home/seurer/gcc/gcc-test/gcc/cgraphbuild.c:445
0x10a63a3f tree_profiling
/home/seurer/gcc/gcc-test/gcc/tree-profile.c:735
0x10a63a3f execute
/home/seurer/gcc/gcc-test/gcc/tree-profile.c:770
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
output is:
during IPA pass: profile
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr78582.c: In function 'main':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr78582.c:18:1: internal
compiler error: Segmentation fault
0x109469ab crash_signal
/home/seurer/gcc/gcc-test/gcc/toplev.c:338
0x105f76d8 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/home/seurer/gcc/gcc-test/gcc/gimple-walk.c:915
0x1040fda7 cgraph_node::record_stmt_references(gimple*)
/home/seurer/gcc/gcc-test/gcc/cgraphbuild.c:277
0x1040fda7 cgraph_edge::rebuild_edges()
/home/seurer/gcc/gcc-test/gcc/cgraphbuild.c:445
0x10a63a3f tree_profiling
/home/seurer/gcc/gcc-test/gcc/tree-profile.c:735
0x10a63a3f execute
/home/seurer/gcc/gcc-test/gcc/tree-profile.c:770
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

FAIL: gcc.dg/pr78582.c (internal compiler error)
FAIL: gcc.dg/pr78582.c (test for excess errors)
Excess errors:
during IPA pass: profile
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr78582.c:18:1: internal
compiler error: Segmentation fault
0x109469ab crash_signal
/home/seurer/gcc/gcc-test/gcc/toplev.c:338
0x105f76d8 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/home/seurer/gcc/gcc-test/gcc/gimple-walk.c:915
0x1040fda7 cgraph_node::record_stmt_references(gimple*)
/home/seurer/gcc/gcc-test/gcc/cgraphbuild.c:277
0x1040fda7 cgraph_edge::rebuild_edges()
/home/seurer/gcc/gcc-test/gcc/cgraphbuild.c:445
0x10a63a3f tree_profiling
/home/seurer/gcc/gcc-test/gcc/tree-profile.c:735
0x10a63a3f execute
/home/seurer/gcc/gcc-test/gcc/tree-profile.c:770

testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|7.2 |5.5

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Jun  9 18:10:48 2017
New Revision: 249067

URL: https://gcc.gnu.org/viewcvs?rev=249067&root=gcc&view=rev
Log:
2017-06-09  Janus Weil  

Backport from trunk
PR fortran/70601
* trans-expr.c (gfc_conv_procedure_call): Fix detection of allocatable
function results.


2017-06-09  Janus Weil  

Backport from trunk
PR fortran/70601
* gfortran.dg/proc_ptr_comp_50.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_50.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[walt.brainerd at gmail dot com]

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

--- Comment #11 from Walt Brainerd  ---
I am not sure what you changed your mind from or to :-).

Yes, the assignment is invalid because r is real the the rhs is type B_type.

And, yes, the type of the io list item is B_type.

However, the uncommented WRITE statement is valid, and,
in the absence or a DT edit descriptor, the components (one real) are
written in order, so 20.0 is written with f4.1 format.

ifort 2017 and gfortran 7.01. both agree with this (maybe the latter
because of you).

If you disagree with this, I would be happy to solicit opinions from more
experts.

On Thu, Jun 8, 2017 at 10:05 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> --- Comment #10 from Jerry DeLisle  ---
> After a lot of head scratching I think I am changing my mind on this one.
>
> If one tries to assign to a real variable as in:
>
> program test_b_write_dt_mod
>
>use :: B_write_dt_mod
>implicit none
>
>type(B_type) :: x != B_type(20.0)
>real :: r
>
>r = B_type(20.0)
>
>write (unit=*, fmt="(f4.1)") B_type(20.0)
>!write (unit=*, fmt="(f4.1)") x
>
> end program test_b_write_dt_mod
>
> The effective item is of type B_type not real and the assignment to r is
> rejected.
>
> So I believe the effective type in the write statement is likewise derived
> type
> ad not real.
>
> My thinking is this PR is invalid.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Jun  9 17:45:53 2017
New Revision: 249066

URL: https://gcc.gnu.org/viewcvs?rev=249066&root=gcc&view=rev
Log:
2017-06-09  Janus Weil  

Backport from trunk
PR fortran/70601
* trans-expr.c (gfc_conv_procedure_call): Fix detection of allocatable
function results.


2017-06-09  Janus Weil  

Backport from trunk
PR fortran/70601
* gfortran.dg/proc_ptr_comp_50.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_50.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/81039] INTERNAL-PROC procedure rejected as EXTERNAL-PROC

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
All OK after clean build.

[Bug sanitizer/81040] New: asan false negative if parameter of a global function passed by reference

[ryabinin.a.a at gmail dot com]

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

Bug ID: 81040
   Summary: asan false negative if parameter of a global function
passed by reference
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryabinin.a.a at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

The following test case doesn't produce asan warning while it should.
For some reason gcc doesn't surround 'a' with redzones.

$ cat asan_test.c 

static __attribute__((noinline)) void goo(int *a)
{
*(volatile int*)a;
}

 __attribute__((noinline)) void foo(char a)
{
goo((int*)&a);
}

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

$ gcc -fsanitize=address -O2 asan_test.c 
$ ./a.out
$


Now, if we make foo() static, asan suddenly works:

$ cat asan_static_test.c 

static __attribute__((noinline)) void goo(int *a)
{
*(volatile int*)a;
}

static __attribute__((noinline)) void foo(char a)
{
goo((int*)&a);
}

int main()
{
foo(1);
return 0;
}
$ gcc -fsanitize=address -O2 asan_static_test.c 
$ ./a.out 
=
==3278==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffc2e298480 at pc 0x0040083b bp 0x7ffc2e298440 sp 0x7ffc2e298438
READ of size 4 at 0x7ffc2e298480 thread T0
#0 0x40083a in goo (/home/andrew/linux/a.out+0x40083a)
#1 0x4008a0 in foo.constprop.0 (/home/andrew/linux/a.out+0x4008a0)
#2 0x4006e8 in main (/home/andrew/linux/a.out+0x4006e8)
#3 0x7ff179db971f in __libc_start_main (/lib64/libc.so.6+0x2071f)
#4 0x400738 in _start (/home/andrew/linux/a.out+0x400738)

Address 0x7ffc2e298480 is located in stack of thread T0 at offset 32 in frame
#0 0x40084f in foo.constprop.0 (/home/andrew/linux/a.out+0x40084f)

  This frame has 1 object(s):
[32, 33) 'a' <== Memory access at offset 32 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
(/home/andrew/linux/a.out+0x40083a) in goo
Shadow bytes around the buggy address:
  0x15c4b040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b080: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x15c4b090:[01]f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x15c4b0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15c4b0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==3278==ABORTING

[Bug fortran/81039] INTERNAL-PROC procedure rejected as EXTERNAL-PROC

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #1)
> WORKSFORME: r248853 and x86_64-apple-darwin16.

Updating my trunk and doing a clean build.

[Bug fortran/81039] INTERNAL-PROC procedure rejected as EXTERNAL-PROC

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME: r248853 and x86_64-apple-darwin16.

[Bug fortran/81039] New: INTERNAL-PROC procedure rejected as EXTERNAL-PROC

[jvdelisle at gcc dot gnu.org]

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

Bug ID: 81039
   Summary: INTERNAL-PROC procedure rejected as EXTERNAL-PROC
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41525&action=edit
Valid code rejected

$ gfortran -fcoarray=single -c co_reduce_res_im.f90 
co_reduce_res_im.f90:52:2:

   function factorial ( n ) result ( rslt )
  1
Error: INTERNAL-PROC procedure at (1) is already declared as EXTERNAL-PROC
procedure

Attached valid code is rejected. Works with gfortran 6.2.1 and 7.1.1, fails on
trunk 8.0

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-09
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41524&action=edit
gcc8-pr80998.patch

Untested initial implementation.  So far it only instruments POINTER_PLUS_EXPR
GIMPLE_ASSIGN statements, LLVM seems to instrument also some &a->ptr, a[i],
etc., guess we should do the same and more (basically do the rest in spots
where ubsan_null is called, just don't call get_base_address on it, but call
get_inner_reference instead, and build from that a byte offset to the start. 
If the base is an automatic var or something like that, ignore it if we can
prove it is in-bounds or if -fsanitize=bounds checks the bounds already?, if it
is a global var defined in the current TU, similarly.

Then what we need and this patch doesn't implement is a sanopt optimization
similer to the UBSAN_NULL opts, if we have checked already ptr + i doesn't
overflow in a dominating stmt, don't check it again, if we have ptr + 10 and a
dominating stmt checked ptr + 15 (i.e. bigger constant), also don't check it.

And, there are some inefficiencies in the tests where the offset is variable,
while I've tried to use gimple_build in that case, it isn't able to optimize
say
char *foo (char *p, unsigned int i) { return p + i; }
on 64-bit targets by knowing (ssizetype) off >= 0 (where off is i zero extended
to sizetype) is always true.  Or using value ranges.

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc*-*-*
 CC||krebbel at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc*-*-*
  Build||powerpc*-*-*

--- Comment #1 from seurer at gcc dot gnu.org ---
Note:  fails on powerpc64 both BE and LE.

[Bug tree-optimization/81038] New: [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[seurer at gcc dot gnu.org]

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

Bug ID: 81038
   Summary: [8 regression] test case g++.dg/vect/slp-pr56812.cc
fails starting with r248678
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test case was failing recently
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925) but starting working
again.  Now it is failing once more.

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++98 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mpower8-vector
-fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic -S -o
slp-pr56812.s
PASS: g++.dg/vect/slp-pr56812.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++98  scan-tree-dump-times slp1 "basic
block vectorized" 1
Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/vect/slp-pr56812.cc 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=c++11 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mpower8-vector
-fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic  -S   -o
slp-pr56812.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++11 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mpower8-vector
-fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic -S -o
slp-pr56812.s
PASS: g++.dg/vect/slp-pr56812.cc  -std=c++11 (test for excess errors)
FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++11  scan-tree-dump-times slp1 "basic
block vectorized" 1
Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/vect/slp-pr56812.cc 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=c++14 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mpower8-vector
-fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic  -S   -o
slp-pr56812.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++2/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

--- Comment #3 from Jack Howarth  ---
(In reply to Jack Howarth from comment #1)
> Created attachment 41522 [details]
> reproducer for gcc 6.3.0 bootstrap failure with Xcode 9 beta
> 
> bzip2 compressed archive with auto-profile.ii preprocessed source to
> reproduce bootstrap failure under Xcode 9 beta on OS X 10.12 using the
> supplied compile shell script.

The offending preprocessed source in this case is actually darwin-driver.ii.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

--- Comment #2 from Jack Howarth  ---
Created attachment 41523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41523&action=edit
reproducer for gcc 5.4.0 bootstrap failure with Xcode 9 beta

bzip2 compressed archive with auto-profile.ii preprocessed source to reproduce
bootstrap failure under Xcode 9 beta on OS X 10.12 using the supplied compile
shell script.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
Created attachment 41522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41522&action=edit
reproducer for gcc 6.3.0 bootstrap failure with Xcode 9 beta

bzip2 compressed archive with auto-profile.ii preprocessed source to reproduce
bootstrap failure under Xcode 9 beta on OS X 10.12 using the supplied compile
shell script.

[Bug bootstrap/81037] New: Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

Bug ID: 81037
   Summary: Xcode 9 requires back ports on gcc-5-branch and
gcc-6-branch for bootstrapping under Xcode 9
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
  Target Milestone: ---

Current gcc-5-branch and gcc-6-branch fails to bootstrap against Xcode 9 beta
on 10.12 due to the absence of back ports from gcc-7-branch (which does
bootstrap). The first issue is the bootstrap failure of...

g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common -DHAVE_CONFIG_H -o darwin-driver.o darwin-driver.ii

../../gcc-6.3.0/gcc/config/darwin-driver.c:302:13: error: cannot initialize a
variable of type 'char *' with an rvalue of type
  'const char *'
  char *first_period = strchr(vers_string, '.');
^  
Back porting the fix from 

https://github.com/gcc-mirror/gcc/commit/5972cd58bde3bc8bacfe994e5b127c411241f255.patch

The second failure specific to gcc-5-branch is...

g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o
auto-profile.o auto-profile.ii

In file included from ../../gcc-5.4.0/gcc/auto-profile.c:26:
In file included from
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/map:446:
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:1398:2:
error: no member
  named 'fancy_abort' in namespace 'std::__1'; did you mean simply
'fancy_abort'?
 std::__1::fancy_abort
("/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/func...
 ^~

I suspect this can be fixed by back porting both...

https://github.com/gcc-mirror/gcc/commit/49622efa89937fa310add53b1efb50273ec0d857

and

https://github.com/gcc-mirror/gcc/commit/ec8c949f8f296d1270fc41404175cd7249df4cd4

Unfortunately the second patch doesn't apply cleaning on gcc-5-branch and may
require additional back ports to do so.

[Bug other/81029] Compiling sketch with arduinodroid

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-09
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source which is causing the crash?  Also can
you check that the stack size between the two machines?

[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2017-06-09 10:35 AM, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540
>
> --- Comment #6 from Jerry DeLisle  ---
> Some other bugs were fixed and I am wondering if this is still failing?
It's still failing as of r248904.

[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Some other bugs were fixed and I am wondering if this is still failing?

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[matt at godbolt dot org]

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

--- Comment #14 from Matt Godbolt  ---
I've just hit this same issue too (in only one of several projects I build with
7.1 and LTO). If anyone has any thoughts at a workaround I'd be very
appreciative. Thanks!

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #29 from Ian Lance Taylor  ---
My apologies for not explaining how to find the compilation commands, and I'm
sorry you had to waste time on it.  Using "make GOTESTFLAGS=--trace net/check"
will put the commands in net/check-testlog.

[Bug target/81036] New: -fcall-saved-X does not work for floating-point registers

[thopre01 at gcc dot gnu.org]

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

Bug ID: 81036
   Summary: -fcall-saved-X does not work for floating-point
registers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm*-*-*

Hi,

When compiling the below testcase with "-S -march=armv7-a -fcall-saved-s14
-mfpu=vfpv4 -mfloat-abi=hard" the compiler fails to generate the save/restore
sequence for S14.

void
saved_regs (void)
{
  __asm volatile ("" ::: "s14");
}

Similarly, compiling the below testcase with "-S -march=armv7-a -fcall-used-s16
-mfpu=vfpv4 -mfloat-abi=hard" does not get rid of the save/restore sequence for
S16.

void
saved_regs (void)
{
  __asm volatile ("" ::: "s16");
}

[Bug middle-end/81035] noreturn leads to worse code due to lack of sibcall optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Richard Biener  ---
That's why it is done though.  Maybe you can suggest how to enhance
documentation?

[Bug middle-end/81035] New: noreturn leads to worse code due to lack of sibcall optimization

[fw at gcc dot gnu.org]

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

Bug ID: 81035
   Summary: noreturn leads to worse code due to lack of sibcall
optimization
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

Created attachment 41521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41521&action=edit
C test case

The attached test case compiles to this code with -O2 -DNORETURN:

 :
   0:   69 d6 46 54 bc 00   imul   $0xbc5446,%esi,%edx
   6:   89 f0   mov%esi,%eax
   8:   89 f9   mov%edi,%ecx
   a:   0f af c7imul   %edi,%eax
   d:   29 f1   sub%esi,%ecx
   f:   48 83 ec 08 sub$0x8,%rsp
  13:   01 fa   add%edi,%edx
  15:   01 c2   add%eax,%edx
  17:   89 f0   mov%esi,%eax
  19:   31 f8   xor%edi,%eax
  1b:   69 ff a0 a2 14 00   imul   $0x14a2a0,%edi,%edi
  21:   0f af c1imul   %ecx,%eax
  24:   01 f7   add%esi,%edi
  26:   89 d6   mov%edx,%esi
  28:   01 c7   add%eax,%edi
  2a:   e8 00 00 00 00  callq  2f 
2b: R_X86_64_PC32   f-0x4

And with -O2:

 :
   0:   69 d6 46 54 bc 00   imul   $0xbc5446,%esi,%edx
   6:   89 f0   mov%esi,%eax
   8:   89 f9   mov%edi,%ecx
   a:   0f af c7imul   %edi,%eax
   d:   29 f1   sub%esi,%ecx
   f:   01 fa   add%edi,%edx
  11:   01 c2   add%eax,%edx
  13:   89 f0   mov%esi,%eax
  15:   31 f8   xor%edi,%eax
  17:   69 ff a0 a2 14 00   imul   $0x14a2a0,%edi,%edi
  1d:   0f af c1imul   %ecx,%eax
  20:   01 f7   add%esi,%edi
  22:   89 d6   mov%edx,%esi
  24:   01 c7   add%eax,%edi
  26:   e9 00 00 00 00  jmpq   2b 
27: R_X86_64_PC32   f-0x4

The -O2 code is shorter because it doesn't need CFI annotations.

It's probably a good idea to inhibit the sibcall optimization for noreturn
functions, to get more accurate stack trace, but that's not what the manual
suggests.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #39 from simon at pushface dot org ---
[...]
> Updated patch posted here; working on gcc-patches@ submission.

Thanks for the analysis and the patch.  I'll give it a whirl once PR
bootstrap/81033 is resolved.

One nit for actual submission: your current patch contains lots of
unrelated changes, removing trailing whitespace.  While that is fine in
itself, please move it to a separate patch.

Thanks.
Rainer

[Bug target/80855] [nvptx] missing sorry("target cannot support label values"

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
Patch with testcase committed, marking resolved-fixed.

[Bug target/80855] [nvptx] missing sorry("target cannot support label values"

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Fri Jun  9 13:11:52 2017
New Revision: 249060

URL: https://gcc.gnu.org/viewcvs?rev=249060&root=gcc&view=rev
Log:
Add "sorry, target cannot support label values" for nvptx

2017-06-09  Tom de Vries  

PR target/80855
* config/nvptx/nvptx.md (define_expand "mov"): Error out
with
"target cannot support label values" when encountering LABEL_REF.

* gcc.target/nvptx/label-values.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/nvptx/label-values.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.md
trunk/gcc/testsuite/ChangeLog

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #41474|0   |1
is obsolete||

--- Comment #39 from simon at pushface dot org ---
Created attachment 41520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41520&action=edit
Patch (2) to top-level configure.ac, configure

The notes on -shared-libgcc at
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html say

   However, if a library or main executable is supposed to throw or
   catch exceptions, you must link it using the G++ driver, as
   appropriate for the languages used in the program, or using the
   option -shared-libgcc, such that it is linked with the shared
   libgcc.

This seems not to be true for Linux (Debian Jessie) but is definitely
true for Darwin. If, using GCC 7.1.0, we build

   with Ada.Text_IO; use Ada.Text_IO;
   procedure Raiser is
   begin
  begin
 raise Program_Error;
  exception
 when others =>
Put_Line ("caught it");
  end;
   end Raiser;

with

   $ gnatmake raiser -largs -static-libgcc -static-libstdc++

then

   $ ./raiser
   Illegal instruction: 4

The actual ld invocation was

   /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0
   -weak_reference_mismatches non-weak -o raiser -L./
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o
   ./raiser.o -v
   /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a
   -no_compact_unwind -lgcc_eh -lgcc -lSystem

This PR was raised because of a mishandled exception raised by
Rtsfind.Load_Fail while processing g-exptty.adb. g-exptty.adb had been
updated on 2017-04-25 (but so had a lot of other parts of GNAT). Since
a lot of other compilations had been performed successfully by this
point, one may assume that this was the first that actually caused an
exception.

Comment 14 works because --with-boot-ldflags=-static-libstdc++ means
that the default boot-ldflags (-static-libgcc -static-libstdc++) is
overridden, so that libgcc defaults to being shared (and
-static-libstdc++ is ignored, as per comment 25, resulting in the
stage 2 problems in comment 5, comment 24).

Following the suggestion on comment 22 (put -lSystem before -lgcc),
I've tried gcc-8-20170528 with

   --with-stage1-ldflags='-lSystem -static-libgcc -static-libstdc++'
   --with-boot-ldflags='-lSystem -static-libgcc -static-libstdc++'

AND IT WORKS (on macOS Sierra, Debian jessie).

Changing the command line above to the equivalent

   $ gnatmake raiser -largs -lSystem -static-libgcc -static-libstdc++

results in the ld invocation

   /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0
   -weak_reference_mismatches non-weak -o raiser -L./
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0
   -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o
   ./raiser.o -lSystem -v
   /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a
   -no_compact_unwind -lgcc_eh -lgcc -lSystem

and

   $ ./raiser
   caught it

Updated patch posted here; working on gcc-patches@ submission.



I'd like to point out that even if gnat1 hadn't failed, building GNAT
tools without shared libgcc results in failures as in PR61027; but
they only affect users of the tools, not the bootstrap.

[Bug target/81022] invalid address with pointer type casting

[vvsed at hotmail dot com]

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

--- Comment #3 from Vladimir Sedach  ---
(In reply to Richard Biener from comment #1)
> 
> So I'd say INVALID but x86 people may want to double-check the official
> intrinsic documentation.

I was using _mm_store_sd(_mm_load_sd()) to copy an arbitrary 8-byte struct, and
came across this situation incidentally. If I'm modifying the code a little
(with remaining _mm_store_sd()), it starts working correctly. I think 99% of
programmers (me too) are sure this code is "correct" and have never heard of
__may_alias__ :)

[Bug target/81022] invalid address with pointer type casting

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
Intrinsics guide states [1] that this intrinsic:
Store the lower double-precision (64-bit) floating-point element from a into
memory. mem_addr does not need to be aligned on any particular boundary.

[1] -
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_store_sd&expand=5157

[Bug tree-optimization/81028] GCC miscompiles placement new

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 9 Jun 2017, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81028
> 
> Markus Trippelsdorf  changed:
> 
>What|Removed |Added
> 
>  CC||trippels at gcc dot gnu.org
> 
> --- Comment #4 from Markus Trippelsdorf  ---
> clang and icc also call abort.

not that I didn't expect this ;)  C testcase follows, writing to a union
member activates it:

extern void abort();

typedef int A;
typedef float B;

void __attribute__((noinline,noclone))
foo(A *p, B *q, long unk)
{
  for (long i = 0; i < unk; ++i) {
  *p = 1;
  q[i] = 42;
  }
}

int main(void)
{
  union { A x; B f; } u;
  foo(&u.x, &u.f, 1);
  if (u.f != 42) abort();
  return 0;
}

[Bug tree-optimization/81028] GCC miscompiles placement new

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
clang and icc also call abort.

[Bug tree-optimization/81028] GCC miscompiles placement new

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Simpler testcase.  The sinking is valid if the aliasing does not occur in the
last iteration of the loop.  In case *p would be done conditionally only
that would not necessarily be the case.

inline void* operator new(__SIZE_TYPE__, void* __p) { return __p; }

extern "C" void abort();

typedef int A;
typedef float B;

void __attribute__((noinline,noclone))
foo(A *p, A *q, long unk)
{
for (long i = 0; i < unk; ++i) {
*p = 1;
new (static_cast(&q[i])) B(42);
}
}

int main(void)
{
  union { A x; B f; } u = { 0 };
  foo(&u.x, &u.x, 1);
  if (u.f != 42) abort();
}

[Bug fortran/80965] [7/8 Regression] ICE with class argument and -O2 optimization

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Created attachment 41519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41519&action=edit
Patch for the bug

This appears to be a consequence of r241450, which fixed PR69834 (select type
clashes).

The fix depended on selection of the address of the selector vtable, which I
obtained using the intrinsic LOC function. In building the function call, I
used the name 'loc' for the symtree, which meant that all references to the
class object 'loc' picked up the intrinsic function. Changing the selecting
intrinsic name to '_loc' seems to fix the problem and all the select type
testcases regtest OK.

I am in the middle of working on a massive patch for PR34640 and so will come
back to this PR as soon as a I can.

Cheers

Paul

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #28 from Martin Jambor  ---
Created attachment 41518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41518&action=edit
Possible fix

I'm testing the attached two patches which should fix the issue.  If
everything goes well, I will see whether I can up quickly come up with
a C testcase and re-read the patch on Monday to make sure I covered
all corner cases and then post it to the mailing list.

[Bug target/81034] [x86] Broken IRA pass when printing results of intrinsic execution

[sebastian.peryt at intel dot com]

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

--- Comment #2 from Sebastian Peryt  ---
I agree, that vec_merge takes 3 operands. And 3 are in my md (naming according
to GCC internals):

vec1:
(vec_merge:V2DF
(match_operand:V2DF 1 "nonimmediate_operand" "m")
(match_operand:V2DF 2 "vector_move_operand" "0C")
(match_operand:QI 3 "register_operand" "Yk"))

vec2:
(const_vector:V2DF [(const_int 0) (const_int 0)])

items:
(const_int 1)

I am not sure if const_vec should have been here match operand actually. Maybe
not with vec_merge, but still similar use can be seen already in sse.md e.g. -
floatv2div2sf2_mask.

Also, if md would be wrong I'd expect some other issue show up also, and both
intrinsic not work. 

My best guess is that the problem might be due to the fact that with mask 0 or
2 all of the elements in the vector are actually 0 and this might be getting
optimized.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #27 from Martin Jambor  ---
Created attachment 41517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41517&action=edit
Hack for revealing compiler command lines

Thanks Ian, the above was definitely helpful but did not allow me to
get at the compiler invocation lines, which was what I needed to get
at tree dumps, run the compilation in gdb and so forth.  In the end, i
had to resort to the attached hack to get them.  I do not know how the
trace feature of libgo/gotest script is supposed to work but I had to
redirect them to find them.

It would be great if the testsuite left some libgo.log file with all
necessary command lines to replay the test by hand like all other
testsuites do.  I spent half of the time on this bug so far just
looking for the command lines which does not look reasonable.

[Bug target/81034] [x86] Broken IRA pass when printing results of intrinsic execution

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Comment on attachment 41516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41516
Reproducible

Hmm, bugzilla might not be the right place for this kind of issue. I suspect
your avx512f_loadv2df_mask pattern is incorrect. Vec_merge takes 3 operands,
two vectors and a const_int. Maybe the other thing is the const_vector here
should have been a match_operand.

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Fri, 9 Jun 2017, tetra2005 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731
> 
> --- Comment #6 from Yuri Gribov  ---
> (In reply to rguent...@suse.de from comment #5)
> > On Fri, 9 Jun 2017, tetra2005 at gmail dot com wrote:
> > 
> > > This should probly go to reassoc? Or better keep it in folder?
> > 
> > As loads are involved it doesn't really fit reassoc.  Likewise it doesn't
> > really fit the folder.
> 
> The || case is optimized by the folder.

Yes, but that's quite premature and doesn't work for

 if (..)
 else if (..)

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to rguent...@suse.de from comment #5)
> On Fri, 9 Jun 2017, tetra2005 at gmail dot com wrote:
> 
> > This should probly go to reassoc? Or better keep it in folder?
> 
> As loads are involved it doesn't really fit reassoc.  Likewise it doesn't
> really fit the folder.

The || case is optimized by the folder.

[Bug target/81034] New: [x86] Broken IRA pass when printing results of intrinsic execution

[sebastian.peryt at intel dot com]

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

Bug ID: 81034
   Summary: [x86] Broken IRA pass when printing results of
intrinsic execution
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.peryt at intel dot com
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Created attachment 41516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41516&action=edit
Reproducible

During missing intrinsic implementation I found strange bug connected to
printf. The reproducer is attached.

The intrinsics I've been implementing are _mm_mask_load_sd and
_mm_maskz_load_sd. Both of them use the same md. Unfortunately, with
_mm_maskz_load_sd, when I want to printf values that were generated for some
particular cases it breaks compilation and results in following error:

during RTL pass: ira
In file included from
/gcc/gcc/testsuite/gcc.target/i386/avx512f-vmovsd-2.c:5:0:
/gcc/gcc/testsuite/gcc.target/i386/avx512f-check.h: In function ‘do_test’:
/gcc/gcc/testsuite/gcc.target/i386/avx512f-check.h:11:1: internal compiler
error: in wide_int_to_tree, at tree.c:1487
0xe9e9f3 wide_int_to_tree(tree_node*,
generic_wide_int > const&)
../../gcc/gcc/tree.c:1487
0x895df6 make_tree(tree_node*, rtx_def*)
../../gcc/gcc/expmed.c:5113
0x895e8b make_tree(tree_node*, rtx_def*)
../../gcc/gcc/expmed.c:5139
0xee83a2 force_const_mem(machine_mode, rtx_def*)
../../gcc/gcc/varasm.c:3733
0xa1652b setup_reg_equiv
../../gcc/gcc/ira.c:3992
0xa1652b ira
../../gcc/gcc/ira.c:5244
0xa1652b execute
../../gcc/gcc/ira.c:5580

To reproduce this error two conditions has to be met:
- mask value has to be either 0 or 2
- optimization has to be O2, O3 or Ofast

It is also interesting that for Os optimization it works.

When printf of res4 in attached code is commented out it also compiles. On the
other hand, for res3 printf doesn't make a difference - it always works.

I have compared passes' dumps for version with res4 printf and without and I
found some interesting discrepancies there:
1. On 029t.einline pass, in compiling (non-printf) version function do_test ()
has been partially expanded by what looks like to be the content of
avx512f_test () function.
2. On 051i.ipa_oacc pass the order of functions in dump files has been changed
and optimized - for non-compiling one setting the order:
  a.avx512f_test ()
  b.main ()
  c.do_test ()
and for compiling one:
  a.main ()
  b.do_test ()
3. On 087t.fixup_cfg4 pass main () is totally deleted from not compiling
version leaving only do_test ().

I would appreciate any input on that issue.

[Bug bootstrap/81033] [8 Regression] Bootstrap broken on darwin

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin16   |x86_64-apple-darwin*
   Host|x86_64-apple-darwin16   |x86_64-apple-darwin*
  Build|x86_64-apple-darwin16   |x86_64-apple-darwin*

--- Comment #3 from Rainer Orth  ---
I'm also seeing it on x86_64-apple-darwin11.4.2, so I suspect all Darwin
targets
are affected.

[Bug bootstrap/81033] [8 Regression] Bootstrap broken on darwin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, wrong-code
   Priority|P3  |P1

[Bug c++/81032] [5/6/7/8 Regression] ICE with lambda and broken constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |7.1.1
   Target Milestone|--- |5.5

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-09
 CC||hubicka at gcc dot gnu.org
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE on valid code at -O1|[8 Regression] ICE on valid
   |(only) on x86_64-linux-gnu: |code at -O1 (only) on
   |verify_flow_info failed |x86_64-linux-gnu:
   ||verify_flow_info failed
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Sounds like fallout of honzas reorg.

[Bug tree-optimization/81028] GCC miscompiles placement new

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-09
  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.2, 4.3.6, 4.5.4, 4.8.5,
   ||7.1.0

--- Comment #2 from Richard Biener  ---
Confirmed.  LIM applies store motion to ++*p.

non-C++11 testcase:

inline void* operator new(__SIZE_TYPE__, void* __p) { return __p; }

extern "C" void abort();

typedef int A;
typedef float B;

B *qq;

void __attribute__((noinline,noclone))
foo(A *p, A *q, long unk)
{
for (long i = 0; i < unk; ++i) {
++*p;
qq = new (static_cast(&q[i])) B(42);
}
}

int main(void)
{
  union { A x; B f; } u = { 0 };
  foo(&u.x, &u.x, 1);
  if (*qq != 42) abort();
}

[Bug fortran/80965] [7/8 Regression] ICE with class argument and -O2 optimization

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #2)
> The change occurred between revisions r241395 (2016-10-21, compiles) and
> r241433 (2016-10-21, ICE), likely r241403 (pr69566).

Dear All,

A workaround is not to call the class object 'loc'. This is fine:
module mode3_mod
contains
  subroutine xyz(loc1)
implicit none
class(*) :: loc1
real x(6)
integer ix_use
select type (loc1)
type is (integer)
  x = 0
  print *, "is an integer"
type is (real)
  ix_use = 0
  print *, "is real"
end select
  end subroutine xyz
end module mode3_mod

I will look into the cause of this. If you attempt to use associate the
subroutine by calling it, the following message appears:
   use mode3_mod
  1
Error: DUMMY attribute conflicts with INTRINSIC attribute in ‘loc’ at (1)

The class object is being compiled as a function type pointer, void (*),
ie. as the 'loc' intrinsic.

Cheers

Paul

[Bug target/81022] invalid address with pointer type casting

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 CC||kyukhin at gcc dot gnu.org
  Component|c++ |target

--- Comment #1 from Richard Biener  ---
You are violating strict aliasing rules when writing with an lvalue of type
double to storage of type 'long long int'.

If the intrinsics documentation suggest that those are fine then our
implementation is buggy:

/* Stores the lower DPFP value.  */
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_store_sd (double *__P, __m128d __A)
{
  *__P = ((__v2df)__A)[0];
}

the other intrinsic is fine:

extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_storel_epi64 (__m128i_u *__P, __m128i __B)
{
  *(__m64_u *)__P = (__m64) ((__v2di)__B)[0];
}

as __m64_u is declared with may_alias:

typedef int __m64_u __attribute__ ((__vector_size__ (8), __may_alias__,
__aligned__ (1)));


So I'd say INVALID but x86 people may want to double-check the official
intrinsic documentation.

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug rtl-optimization/81019] [6/7/8 Regression] wrong code with -O -fno-tree-ccp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug tree-optimization/79483] [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] [graphite] |[7 Regression] [graphite]
   |ICE: verify_ssa failed  |ICE: verify_ssa failed
   |(error: definition in block |(error: definition in block
   |31 does not dominate use in |31 does not dominate use in
   |block 28)   |block 28)
  Known to fail||7.1.0

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

[Bug c++/81007] [7 Regression] ICE with virtual function in broken class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |virtual function in broken  |virtual function in broken
   |class   |class
  Known to fail||7.1.0

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

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk, fix may be backportable so leaving open for now.

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  9 09:40:45 2017
New Revision: 249053

URL: https://gcc.gnu.org/viewcvs?rev=249053&root=gcc&view=rev
Log:
2017-06-09  Richard Biener  

PR tree-optimization/66623
* tree-vect-loop.c (vect_is_simple_reduction): Cleanup,
refactor check_reduction into two parts, properly computing
whether we have to check reduction validity for outer loop
vectorization.

* gcc.dg/vect/pr66623.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr66623.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/79483] [7/8 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  9 09:36:06 2017
New Revision: 249052

URL: https://gcc.gnu.org/viewcvs?rev=249052&root=gcc&view=rev
Log:
2017-06-09  Richard Biener  

PR tree-optimization/79483
* graphite-scop-detection.c (order): New global.
(get_order): Compute bb to order mapping that satisfies code
generation constraints.
(cmp_pbbs): New helper.
(build_scops): Start domwalk at entry block, sort generated
pbbs.

* gcc.dg/graphite/pr79483.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr79483.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81007] [7/8 Regression] ICE with virtual function in broken class

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  9 09:35:05 2017
New Revision: 249051

URL: https://gcc.gnu.org/viewcvs?rev=249051&root=gcc&view=rev
Log:
2017-06-09  Richard Biener  

PR middle-end/81007
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::restrict_to_inner_class):
Skip FIELD_DECLs with error_mark_node type.
* passes.def (all_lowering_passes): Run pass_build_cgraph_edges
last again.

* g++.dg/pr81007.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/pr81007.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-polymorphic-call.c
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 9 Jun 2017, tetra2005 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731
> 
> Yuri Gribov  changed:
> 
>What|Removed |Added
> 
>  CC||tetra2005 at gmail dot com
> 
> --- Comment #4 from Yuri Gribov  ---
> (In reply to rguent...@suse.de from comment #3)
> > The various patches to
> > lower bitfield accesses made this work automagically.  Thus this
> > PR is probably a dup of some other(s).
> 
> Interestingly, a slightly different code works fine:
>   return s->b || s->c;  // || instead of |
> This happens because it compiles to
>   (s->b != 0) || (s->c != 0)
> Each component is converted to BIT_FIELD_REF by optimize_bit_field_compare and
> results are folded to a single BIT_AND.
> 
> With original use-case this does not work because we don't know that result
> will be NE-ed when trying to fold IOR in fold_binary_loc.
> 
> Ideally we want to detect generic patterns like
>   (s->f1 | s->f2 | ... | s->fN | other unrelated conds) != 0  // Or &, or ==
> sort fi's to groups according to their memory location and optimize from 
> there.
> This should probly go to reassoc? Or better keep it in folder?

As loads are involved it doesn't really fit reassoc.  Likewise it doesn't
really fit the folder.

It kind-of matches if-combine but given that loads are involved it's
difficult as well.

Maybe the bswap pass (which is combining loads) can be enhanced here.

Richard.

[Bug bootstrap/81033] [8 Regression] Bootstrap broken on darwin

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-09
 CC||ro at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
Same for me.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #29 from Daniel Santos  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #28)
>> As I've said before, the parallelization of ms-sysv.exp runs may be a
>> bonus, but is certainly separate from this PR and thus should be split
>> out:
>
> Yes, you are right of course.  I was trying to kill too many birds with one
> stone and I somehow omitted a bit of your patch for the function size thing,
> sorry about that.  Some of this gets complicated though, if you want me to use
> dg-runtest then a few other changes must be made as well, but obviously not as
> many as I had included.  I'll get this sorted out.

Fine.  Imagine your formatting/coding style changes: when they are
intermixed with functional changes, every reviewer has to check
thoroughly which part is which.  If you separate them (which is easy for
you to do) and submit them separately, the formatting stuff will be
obvious or nearly so, and you save everyone time by having to review
only the beef of the functional changes, in the end also giving you
faster review.

> Please also note that I did seek guidance when putting this exp file together
> (back in December)  I was following Mike Stump's direction, but you were
> probably on vacation or something. :) 
> https://gcc.gnu.org/ml/gcc/2016-12/msg00145.html

Might be.  However, I've been appointed testsuite maintainer at a time
when nobody else was around.  Later, Mike stepped up again who's way
more experienced here than I am.  In the case at hand, I happen to be
both victim of your patches' fallout and testsuite maintainer ;-)

> I've also been motivated to expand the tests by a change somebody else made to
> my original patch that I wasn't confident the original tests would fully check
> (been worried about it, but it all looks good).  I'll get a cleaned up patch
> for you soon.

Excellent, thanks for your patience.  I know the first times through the
system can be hard and tedious...

> (In reply to r...@cebitec.uni-bielefeld.de from comment #27)
>
>> * Also as I'd reported before, with the fix above, I still get a couple
>>   of FAILures:
>> 
>>
>> FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p0\ -t64"
>> (test for excess errors)
>> Excess errors:
>> /var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv/ms-sysv-
>> generated.h:30:1: error: bp cannot be used in asm here
>> 
>>   Full compiler output is
>> 
>> In file included from
>> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-
>> sysv.c:158:0:
>> /var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv/ms-sysv-
>> generated.h: In function 'msabi_02_0':
>> /var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv/ms-sysv-
>> generated.h:30:1: error: bp cannot be used in asm here
>> 
>>   At least some of the tests PASS now :-)
>
> Well this is a problem and is unexpected.  Can you please post the relevant
> portion of the log file?  What I really need to see is the command line to
> build ms-sysv.c.  I'm going to *guess* that the problem is that
> TEST_ALWAYS_FLAGS contains something that enables hard frame pointers and that
> I need this little change:
>
>  # Detect when hard frame pointers are enabled (or required) so we know 
> not
>  # to generate bp clobbers.
> -if [regexp "^(.+ +| *)-(O0|fno-omit-frame-pointer|p|pg)( +.*)?$" \
> -  $cflags match] then {
> +if [regexp "^( *|.* )-(O0|fno-omit-frame-pointer|p|pg)( *| +.*)$" \
> +  "$TEST_ALWAYS_FLAGS $cflags" match] then {
> set generator_args "$generator_args --omit-rbp-clobbers"
>  }

Here's the complete output from and amd64-pc-solaris2.12 build with your
patch included:

spawn /var/gcc/regression/trunk/12-gcc-64/build/gcc/xgcc
-B/var/gcc/regression/trunk/12-gcc-64/build/gcc/
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -DGEN_ARGS=-p1 -t64
-I/var/gcc/regression/trunk/12-gcc-64/build/gcc/testsuite/gcc6/ms-sysv
-I/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv -Wall
-Wall
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
-lm -o ./ms-sysv.exe^M
In file included from
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:158:0:^M
/var/gcc/regression/trunk/12-gcc-64/build/gcc/testsuite/gcc6/ms-sysv/ms-sysv-generated.h:
In function 'msabi_02_1':^M
/var/gcc/regression/trunk/12-gcc-64/build/gcc/testsuite/gcc6/ms-sysv/ms-sysv-generated.h:42:1:
error: bp cannot be used in asm here^M
compiler exited with status 1

I suspect the problem is not explicitly passing -fno-omit-frame-pointer,
though.  gcc/config/i386/sol2.h has

#define USE_IX86_FRAME_POINTER 1
#define USE_X86_64_FRAME_POINTER 1

which does this implicitly...

Rainer

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[aivchenk at gcc dot gnu.org]

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

Bug 79988 Summary: [7/8 Regression][CHKP] ICE in tree check: accessed operand 5 
of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79988

   What|Removed |Added

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

[Bug middle-end/79988] [7/8 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851

[aivchenk at gcc dot gnu.org]

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

Alexander Ivchenko  changed:

   What|Removed |Added

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

--- Comment #5 from Alexander Ivchenko  ---
Fixed on trunk

[Bug bootstrap/81033] [8 Regression] Bootstrap broken on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Created attachment 41515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41515&action=edit
Broken assembly

[Bug bootstrap/81033] New: [8 Regression] Bootstrap broken on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 81033
   Summary: [8 Regression] Bootstrap broken on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

Created attachment 41514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41514&action=edit
working assembly

Bootstrap is broke on darwin at revision r249022 (r249007 bootstraps):

bitmap_allocator.s:7266:1: error: invalid symbol redefinition
___cold_sect_of_allocate:
^
bitmap_allocator.s:8727:1: error: invalid symbol redefinition
___cold_sect_of__S_refill_pool:
^
bitmap_allocator.s:9719:1: error: invalid symbol redefinition
___cold_sect_of__M_allocate_single_object:
^
bitmap_allocator.s:10746:1: error: invalid symbol redefinition
___cold_sect_of__M_deallocate_single_object:
^
bitmap_allocator.s:11928:1: error: invalid symbol redefinition
___cold_sect_of_allocate:
^
bitmap_allocator.s:13067:1: error: invalid symbol redefinition
___cold_sect_of_allocate:
^
bitmap_allocator.s:14156:1: error: invalid symbol redefinition
___cold_sect_of_deallocate:
^

I &m attaching two assembly files. The first one (working) is compiled with

gcc8 -shared-libgcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/libsupc++/.libs
-I/opt/gcc/work/libgcc
-I/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/include/x86_64-apple-darwin16.6.0
-I/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=bitmap_allocator.lo -g -O2 -c
../../../../../work/libstdc++-v3/src/c++98/bitmap_allocator.cc -fno-common
-DPIC -D_GLIBCXX_SHARED -save-temps

The second one, giving the above errors, is compiled with

/opt/gcc/build_w/gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/libsupc++/.libs
-I/opt/gcc/work/libgcc
-I/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/include/x86_64-apple-darwin16.6.0
-I/opt/gcc/build_w/x86_64-apple-darwin16.6.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=bitmap_allocator.lo -g -O2 -c
../../../../../work/libstdc++-v3/src/c++98/bitmap_allocator.cc -fno-common
-DPIC -D_GLIBCXX_SHARED -save-temps

[Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863

[graham.stott at btinternet dot com]

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

--- Comment #5 from graham.stott at btinternet dot com ---
Hi Doug
I build both GCC and GLIBC daily but for mips-img-linux-gnu and hard-float the
only prob. I see is ADA fails building one multilib config. I do all langs I'll
give try hard-float mips-mti-linux-gnu.
Graham
ps My son now has British passport

 Original message 
From: "doug.gilmore at imgtec dot com"  
Date: 09/06/2017  09:12  (GMT+00:00) 
To: gcc-bugs@gcc.gnu.org 
Subject: [Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at
r248863 

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

Doug Gilmore  changed:

   What    |Removed |Added

 CC|    |rguenth at gcc dot gnu.org

--- Comment #4 from Doug Gilmore  ---
Created attachment 41513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41513&action=edit
cut down example via delta

Sorry attachment for the last comment was dropped.

I bisected the failure to r247049 using the cut down
example, compiled via:

$dir/xgcc -B$dir -O2 -msoft-float -mabi=32 delta_1.i -c -std=gnu11
-fgnu89-inline  -O2 -fmerge-all-constants -fno-stack-protector -frounding-math
-g

For this bisect I configured with --disable-multilib.

I'll look into this more tomorrow.

[Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863

[doug.gilmore at imgtec dot com]

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

Doug Gilmore  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Doug Gilmore  ---
Created attachment 41513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41513&action=edit
cut down example via delta

Sorry attachment for the last comment was dropped.

I bisected the failure to r247049 using the cut down
example, compiled via:

$dir/xgcc -B$dir -O2 -msoft-float -mabi=32 delta_1.i -c -std=gnu11
-fgnu89-inline  -O2 -fmerge-all-constants -fno-stack-protector -frounding-math
-g

For this bisect I configured with --disable-multilib.

I'll look into this more tomorrow.

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

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|VERIFIED|REOPENED
   Last reconfirmed||2017-06-09
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #8 from tnfchris at gcc dot gnu.org ---
wrong state

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

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from tnfchris at gcc dot gnu.org ---
That's true. The ticket was for aarch64 but even there it doesn't work for
binary128 so I'll re-open.

[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029

[stilor at att dot net]

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

Alexey Neyman  changed:

   What|Removed |Added

 CC||stilor at att dot net

--- Comment #4 from Alexey Neyman  ---
Seeing this issue with a test case as simple as:

int
reallocarray(unsigned __int20 a, unsigned __int20 b)
{
 return 0xfUL / a < b;
}

This is a regression in GCC7/GCC8, GCC6 compiles it successfully. Started with
the following commit:

Author: amonakov 
Date:   Mon May 30 14:37:02 2016 +

match.pd: optimize unsigned mul overflow check

gcc/
2016-05-28  Alexander Monakov  
Marc Glisse  

PR tree-optimization/71289
* match.pd (-1 / B < A, A > -1 / B): New transformations.

gcc/testsuite/
2016-05-28  Alexander Monakov  

PR tree-optimization/71289
* gcc.dg/pr71289.c: New test.



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