[Bug fortran/64207] New: vectorization report

[mike at mikepage dot us]

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

Bug ID: 64207
   Summary: vectorization report
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike at mikepage dot us

gfortran --version
GNU Fortran (MacPorts gcc49 4.9.2_1) 4.9.2


gfortran -O3 -ftree-vectorize -ftree-vectorizer-verbose=6 foo.f90

is not issuing vectorization report

cat foo.f90

program main
  real, dimension(1024, 1024) :: a,b,c
  call random_number(a)
  call random_number(b)
  do i=1,1024
do j=1,1024
  c(i,j) = a(j,i)*b(j,i)
end do
  end do
  print *,c
end program main

[Bug libstdc++/64203] shared_mutex compile errors on bare-metal targets

[sandra at codesourcery dot com]

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

--- Comment #2 from Sandra Loosemore  ---
(In reply to Jonathan Wakely from comment #1)
> Created attachment 34208 [details]
> fix config macros for shared_lock
> 
> Does this fix it?

No, with this patch I'm still getting the same undefined symbol errors about
defer_lock_t, try_to_lock_t, etc.

FAOD it looks like on this target _GLIBCXX_USE_C99_STDINT_TR1 is defined but
_GLIBCXX_HAS_GTHREADS is not.

[Bug jit/64206] fake.so is unlinked too early for some users

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-12-06
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
(In reply to drepper.fsp+r...@gmail.com from comment #0)
> Some users of the DSO created by the JIT (probably mostly debuggers) might
> have a hard time getting to the file before it gets unlinked.  For some gdb
> versions, for instance, this is fatal.  Try gdb 7.8.1, for instance, see
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1170861
> 
> That is certainly gdb's fault but it's an example about the type of problems
> that can appear.

For reference, this works for me with:
  gdb-7.6.50.20130731-19.fc20.x86_64

> It certainly is useful to unlink the file as quickly as possible so that in
> case of a problem crash nothing is left behind.  But there at least should
> be the possibility to prevent the early unlink.  Dave suggested to tie this
> to the enabling of debuginfo generation in libgccjit.  I'm actually not
> entirely sure that's the best possibility since even without debuginfo the
> debugger can use the ELF symbols to place breakpoints etc.  Maybe a boolean
> option?
> 
> As a solution it should be quite easy to transfer ownership of the file and
> directory from playback::context to result.

I'm working on a patch that supports delaying the cleanup of the tempdir, with
the cleanup normally occurring at the end of the compile, after the .so has
been dlopened, but deferring it to when gcc_jit_result_release occurs if the
user set GCC_JIT_BOOL_OPTION_DEBUGINFO.

FWIW I think of this flag as a
  "make debugging work please, I'm willing to take a performance hit"
request by the user, rather than specifically for the generation of debuginfo.

I want to avoid a proliferation of lots of options that need to be enabled,
since this makes the library more difficult to use.  Obviously a tradeoff
though.  (Maybe that flag should be renamed?)

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[aaron at aarongraham dot com]

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

Aaron Graham  changed:

   What|Removed |Added

  Component|c++ |libstdc++
Summary|Crash in__tls_init when |_Lock_policy used in
   |-mcpu=arm1176jzf-s is used  |thread.cc can cause
   ||incompatibilities with
   ||binaries using different
   ||-mcpu

--- Comment #3 from Aaron Graham  ---
This is a C++ standard library problem.

If the toolchain is compiled for generic arm processors, the C++ standard
library uses the "_S_mutex" _Lock_policy (see ext/concurrence.h).

// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy = 
  #ifdef __GTHREADS
  #if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
   && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
  #else
_S_mutex;
  #endif
  #else
_S_single;
  #endif


If the compiler is then used to build binaries using -mcpu=arm1176jzf-s (or
cortex-a9 or just about anything else) then those binaries use the "_S_atomic"
_Lock_policy and are *incompatible* with the standard library built with the
compiler.

Here's some simpler code that was failing because of this problem:
  void foo() {}
  int main() { std::thread(&foo).join(); }

This fails because execute_native_thread_routine accesses a shared_ptr, thereby
requiring all binaries that link to it to use its locking policy, or else.

I've solved this problem in my own setup by building the toolchain and
application binaries with the same -mcpu.

A more general solution might be to move more code out of places like thread.cc
and into the headers.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[kcc at gcc dot gnu.org]

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

--- Comment #12 from Kostya Serebryany  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Kostya Serebryany from comment #8)
> > > You haven't responded about the language thing, there is no such thing as
> > > ODR in C or Fortran, so you shouldn't report it.
> > 
> > In LLVM, I do not (and should not) know what source language is being
> > compiled.
> 
> Sounds like LLVM limitation.
> 
> > The differences between languages are represented in the linkage types 
> > of the globals. E.g. a regular global in C will not be instrumented at all 
> > unless -fno-common is given. I.e. the difference is not in the source
> > language 
> > but in the linkage type of the globals. 
> 
> I believe your
> http://llvm.org/klaus/compiler-rt/blob/
> 0926de35c9357aa1a5c47d3a618d6c72f9e8f085/test/asan/TestCases/Linux/odr-
> violation.cc
> example is valid in C

But for this example in C the globals will not get instrumented, unless 
-fno-common is given. 


> , and commonly used (sure, more commonly with functions
> than with variables, but even with variables).  Furthermore, the kind of ODR
> detection in libasan isn't really ODR detection, you are instead checking if
> the same global is registered multiple times.  GCC intentionally registers
> local aliases of the globals, so that the same global isn't registered
> multiple times if it is defined by multiple shared libraries or binary and
> some shared library - each TU registers the vars local to it, rather than
> trying to register globals in a completely different shared library.

> If LLVM uses global symbols instead of local aliases, it is more expensive.
> You can have aliases/weakrefs etc. to symbols, and those still aren't ODR
> violations.

But these again should not be instrumented by asan at all. No? 

> 
> An ODR violation is IMHO something different, it is the case where you have
> the same symbol name (but, you'd need to distinguish between globally
> visible symbols that should be ODR checked and local symbols and/or symbols
> from languages you don't want to check for it) registered multiple times for
> multiple addresses.

Never seen a case like this ("registered multiple times for multiple
addresses").
Can you give an example? 

>> So you'd need to hash based on the symbol name if
> marked for ODR checking, and check if the same (non-comdat) global isn't
> registered several times.

[Bug ipa/64049] [5 Regression] r215898 caused wrong code at -O3

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||edlinger at gcc dot gnu.org

--- Comment #12 from Bernd Edlinger  ---
not sure if I even know what I'm doing, but this seems to fix
the test case:

Index: ipa-polymorphic-call.c
===
--- ipa-polymorphic-call.c(revision 218433)
+++ ipa-polymorphic-call.c(working copy)
@@ -1047,7 +1047,8 @@

   if (TREE_CODE (base_pointer) == SSA_NAME
   && SSA_NAME_IS_DEFAULT_DEF (base_pointer)
-  && TREE_CODE (SSA_NAME_VAR (base_pointer)) != PARM_DECL)
+  && TREE_CODE (SSA_NAME_VAR (base_pointer)) != PARM_DECL
+  && TREE_CODE (SSA_NAME_VAR (base_pointer)) != RESULT_DECL)
 {
   invalid = true;
   if (instance)


This line is hit exactly once, but with a RESULT_DECL instead
of a PARM_DECL. setting invalid=true makes the whole thing look so invalid
that it gets replaced by __builtin_unreachable() later on.

[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Any progress?

[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dominique d'Humieres  ---
Works for me also for 4.9.2 and trunk (5.0 r218434). No answer for almost a
year and a half. Closing as FIXED.

[Bug jit/64206] New: fake.so is unlinked too early for some users

[drepper.fsp+rhbz at gmail dot com]

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

Bug ID: 64206
   Summary: fake.so is unlinked too early for some users
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com

Some users of the DSO created by the JIT (probably mostly debuggers) might have
a hard time getting to the file before it gets unlinked.  For some gdb
versions, for instance, this is fatal.  Try gdb 7.8.1, for instance, see

https://bugzilla.redhat.com/show_bug.cgi?id=1170861

That is certainly gdb's fault but it's an example about the type of problems
that can appear.

It certainly is useful to unlink the file as quickly as possible so that in
case of a problem crash nothing is left behind.  But there at least should be
the possibility to prevent the early unlink.  Dave suggested to tie this to the
enabling of debuginfo generation in libgccjit.  I'm actually not entirely sure
that's the best possibility since even without debuginfo the debugger can use
the ELF symbols to place breakpoints etc.  Maybe a boolean option?

As a solution it should be quite easy to transfer ownership of the file and
directory from playback::context to result.

[Bug sanitizer/64170] [5 Regression] ICE compiling Linux Kernel drivers/media/rc/imon.c in imon_incoming_packet

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/64203] shared_mutex compile errors on bare-metal targets

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Created attachment 34208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34208&action=edit
fix config macros for shared_lock

Does this fix it?

[Bug target/64205] New: powerpc64-linux --with-cpu=G5 bootstrap failure

[amodra at gmail dot com]

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

Bug ID: 64205
   Summary: powerpc64-linux --with-cpu=G5 bootstrap failure
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com

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

revision 218414

/home/alan/build/ppc/gcc-virgin/./gcc/xgcc
-B/home/alan/build/ppc/gcc-virgin/./gcc/
-B/usr/local/powerpc64-unknown-linux-gnu/bin/ -B
/usr/local/powerpc64-unknown-linux-gnu/lib/ -isystem
/usr/local/powerpc64-unknown-linux-gnu/include -isystem
/usr/local/powerpc64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2  -g -O2
-DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc
-I. -I. -I../../.././gcc -I/src/gcc-virgin/libgcc -I/src/gcc-virgin/libgcc/.
-I/src/gcc-virgin/libgcc/../gcc -I/src/gcc-virgin/libgcc/../include
-I/src/gcc-virgin/libgcc/../libdecnumber/dpd
-I/src/gcc-virgin/libgcc/../libdecnumber -DHAVE_CC_TLS  -o _addsub_sd.o -MT
_addsub_sd.o -MD -MP -MF _addsub_sd.dep -DFINE_GRAINED_LIBRARIES -DL_addsub_sd
-DWIDTH=32 -c /src/gcc-virgin/libgcc/dfp-bit.c
/src/gcc-virgin/libgcc/dfp-bit.c: In function '__dpd_addsd3':
/src/gcc-virgin/libgcc/dfp-bit.c:247:1: error: insn does not satisfy its
constraints:
 }
 ^
(insn 305 195 201 26 (set (reg/i:SD 33 1)
(mem/c:SD (plus:SI (reg/f:SI 1 1)
(const_int 84 [0x54])) [0 res32.c+0 S4 A32]))
/src/gcc-virgin/libgcc/dfp-bit.c:247 463 {movsd_hardfloat}
 (nil))

Seems to be caused by r217679.  r217678 is the last revision to bootstrap for
me.  Note that you can see the failure by compiling the attachment with -m32
-mcpu=G5 using any recent powerpc gcc.

[Bug fortran/50377] gfortran must not accept an external formal argument not declared external

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-05
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Still present at revision r218434.

[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM

[emsr at gcc dot gnu.org]

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

--- Comment #18 from emsr at gcc dot gnu.org ---
Thank you. I knew I was doing this wrong.

[Bug sanitizer/64170] [5 Regression] ICE compiling Linux Kernel drivers/media/rc/imon.c in imon_incoming_packet

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  5 23:00:09 2014
New Revision: 218440

URL: https://gcc.gnu.org/viewcvs?rev=218440&root=gcc&view=rev
Log:
PR sanitizer/64170
* sanopt.c (maybe_optimize_asan_check_ifn): If base_checks is
non-NULL, call maybe_get_dominating_check on it even if g is
non-NULL.

* gcc.dg/asan/pr64170.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr64170.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/64204] gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little endian after -mupper-regs patches went in

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-12-05
 Ever confirmed|0   |1

[Bug target/64204] gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little endian after -mupper-regs patches went in

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 34206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34206&action=edit
Proposed patch to fix the problem

[Bug target/64204] New: gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little endian after -mupper-regs patches went in

[meissner at gcc dot gnu.org]

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

Bug ID: 64204
   Summary: gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little
endian after -mupper-regs patches went in
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

The test gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little endian when it is
compiled without optimization and the target compiler was configured with
--with-cpu=power8.  If you optimize the code, it works, and if you compile it
with the -mno-upper-regs-df option.

The core problem is that an old optimization for Darwin which converts loading
up TFmode constants at RTL generation breaks when DFmode registers can go in
Altivec registers.

While looking at the code, I noticed that we weren't optimizing setting the
TFmode to 0.0L on VSX systems, and added support for that as well.

[Bug libstdc++/64203] New: shared_mutex compile errors on bare-metal targets

[sandra at codesourcery dot com]

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

Bug ID: 64203
   Summary: shared_mutex compile errors on bare-metal targets
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at codesourcery dot com
CC: 3dw4rd at verizon dot net

After merging GCC 4.9.2 onto our local branch, I saw that the new libstdc++
testcase experimental/feat-cxx14.cc is failing on bare-metal targets
(arm-none-eabi, mips-sde-elf, powerpc-eabi, possibly others).  Here's an
excerpt from the test logs:

Executing on host: mips-sde-elf-g++ -fdiagnostics-color=never -D_GLIBCXX_ASSERT
-fmessage-length=0  -g -O2 -DLOCALEDIR="."
-I/scratch/sandra/mips-elf-trunk/src/gcc-trunk-4.9/libstdc++-v3/testsuite/util
/scratch/sandra/mips-elf-trunk/src/gcc-trunk-4.9/libstdc++-v3/testsuite/experimental/feat-cxx14.cc
  -std=gnu++14 -S-mips16 -o feat-cxx14.s(timeout = 600)
/scratch/sandra/mips-elf-trunk/src/gcc-trunk-4.9/libstdc++-v3/testsuite/experimental/feat-cxx14.cc:110:4:
error: #error "__cpp_lib_shared_timed_mutex"
 #  error "__cpp_lib_shared_timed_mutex"
^
In file included from
/scratch/sandra/mips-elf-trunk/src/gcc-trunk-4.9/libstdc++-v3/testsuite/experimental/feat-cxx14.cc:13:0:
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:274:36:
error: 'defer_lock_t' has not been declared
   shared_lock(mutex_type& __m, defer_lock_t) noexcept
^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:277:36:
error: 'try_to_lock_t' has not been declared
   shared_lock(mutex_type& __m, try_to_lock_t)
^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:277:7:
error:
'std::shared_lock<_Mutex>::shared_lock(std::shared_lock<_Mutex>::mutex_type&,
int)' cannot be overloaded
   shared_lock(mutex_type& __m, try_to_lock_t)
   ^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:274:7:
error: with
'std::shared_lock<_Mutex>::shared_lock(std::shared_lock<_Mutex>::mutex_type&,
int)'
   shared_lock(mutex_type& __m, defer_lock_t) noexcept
   ^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:280:36:
error: 'adopt_lock_t' has not been declared
   shared_lock(mutex_type& __m, adopt_lock_t)
^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:280:7:
error:
'std::shared_lock<_Mutex>::shared_lock(std::shared_lock<_Mutex>::mutex_type&,
int)' cannot be overloaded
   shared_lock(mutex_type& __m, adopt_lock_t)
   ^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:274:7:
error: with
'std::shared_lock<_Mutex>::shared_lock(std::shared_lock<_Mutex>::mutex_type&,
int)'
   shared_lock(mutex_type& __m, defer_lock_t) noexcept
   ^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:
In member function 'void std::shared_lock<_Mutex>::unlock()':
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:347:29:
error: 'errc' was not declared in this scope
__throw_system_error(int(errc::resource_deadlock_would_occur));
 ^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:
In member function 'void std::shared_lock<_Mutex>::_M_lockable() const':
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:381:29:
error: 'errc' was not declared in this scope
__throw_system_error(int(errc::operation_not_permitted));
 ^
/scratch/sandra/mips-elf-trunk/install/opt/codesourcery/mips-sde-elf/include/c++/4.9.2/shared_mutex:383:29:
error: 'errc' was not declared in this scope
__throw_system_error(int(errc::resource_deadlock_would_occur));
 ^
compiler exited with status 1

I am guessing this part of  is to blame:

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
# include 
# include 
#endif

Because of the guards, I think  is not being included and nothing else
is providing declarations of the missing identifiers.  I don't know my way
around this code or the C++ library specification at all, though.

[Bug target/64200] ICE: in decide_alg, at config/i386/i386.c:24510 with -mmemcpy-strategy=libcall:-1:align -minline-stringops-dynamically

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-05
 CC||ubizjak at gmail dot com
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
GCC manual says:

'-minline-stringops-dynamically'
 For string operations of unknown size, use run-time checks with
 inline code for small blocks and a library call for large blocks.

Why are there

 gcc_assert (alg != libcall);
  if (TARGET_INLINE_STRINGOPS_DYNAMICALLY)
*dynamic_check = max;
  return alg;

libcall should be fine for TARGET_INLINE_STRINGOPS_DYNAMICALLY.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
(In reply to howarth from comment #6)
> I don't believe this can be an issue on darwin as we always default to
> producing PIC oode.
Ah, ok.

Thanks for filing this bug.

I'm wondering what other problems libgccjit has on darwin.  If you hack in the
required options into jit/Makefile.in, to what extent do "make" and "make
check-jit" work?

I notice this blog post from a couple of months ago:
  http://adek.io/2014/10/04/gcc-jit-on-osx/
which talks about an issue with:
  dyld: Library not loaded: libgccjit.so.0

Perhaps on darwin we need to be setting DYLD_LIBRARY_PATH in the various places
where we're currently setting LD_LIBRARY_PATH?  (perhaps that should be a
separate bug, perhaps under a "libgccjit on darwin" tracker bug?).

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

[mjtruog at gmail dot com]

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

Michael Truog  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Truog  ---
That does not resolve the problem.  I have tested it with -fPIC as you have
mentioned with the same result.  The compilation command lines I have provided
are minimal to represent what is being done in autoconf/automake/libtool with a
larger project, this is the minimal example based on that.

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

[mjtruog at gmail dot com]

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

Michael Truog  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #7 from Michael Truog  ---
Thanks, that was it.

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #6 from Andreas Schwab  ---
You need to compile callback_function with -fexceptions.

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
>g++ -O0 -g -c test_lib.cpp -o test_lib.o 
You need to compile this with -fPIC.

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

[mjtruog at gmail dot com]

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

--- Comment #3 from Michael Truog  ---
The commands to compile the minimal example are:
g++ -O0 -g -c test_lib.cpp -o test_lib.o 
g++ -fPIC -DPIC -shared test_lib.o -o libtest.so.0.0.0
gcc -O0 -g -c -o test_main.o test_main.c
gcc -o test test_main.o libtest.so.0.0.0 -lstdc++ -Wl,-rpath -Wl,./

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

[mjtruog at gmail dot com]

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

--- Comment #1 from Michael Truog  ---
Created attachment 34204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34204&action=edit
shared library implementation compiled as C++

[Bug c++/64202] C linkage causes shared library exception address problem on ppc64 (not x86_64)

[mjtruog at gmail dot com]

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

--- Comment #2 from Michael Truog  ---
Created attachment 34205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34205&action=edit
Main executable compiled as C

[Bug c++/64202] New: C linkage causes shared library exception address problem on ppc64 (not x86_64)

[mjtruog at gmail dot com]

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

Bug ID: 64202
   Summary: C linkage causes shared library exception address
problem on ppc64 (not x86_64)
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjtruog at gmail dot com

Created attachment 34203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34203&action=edit
Shared library interface with C linkage

This problem was found on the gcc test machine gcc112:
$ uname -a
Linux gcc2-power8.osuosl.org 3.15.10-201.fc20.ppc64p7 #1 SMP Sun Aug 31
13:31:49 MST 2014 ppc64 ppc64 ppc64 GNU/Linux
$ gcc -v -save-temps
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.3/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-ppc64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-ppc64-redhat-linux/cloog-install
--enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

The example to replicate the problem is attached.

[Bug jit/64201] New: JIT tutorial does not describe accessing symbols from other DSOs

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 64201
   Summary: JIT tutorial does not describe accessing symbols from
other DSOs
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org

The JIT tutorial doesn't yet describe how to access functions or globals found
in other DSOs.

[Bug target/64200] New: ICE: in decide_alg, at config/i386/i386.c:24510 with -mmemcpy-strategy=libcall:-1:align -minline-stringops-dynamically

[zsojka at seznam dot cz]

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

Bug ID: 64200
   Summary: ICE: in decide_alg, at config/i386/i386.c:24510 with
-mmemcpy-strategy=libcall:-1:align
-minline-stringops-dynamically
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 34202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34202&action=edit
reduced testcase

Compiler output:
$ gcc -mmemcpy-strategy=libcall:-1:align -minline-stringops-dynamically
testcase.c testcase.c: In function 'foo':
testcase.c:14:5: internal compiler error: in decide_alg, at
config/i386/i386.c:24510
   d = __builtin_va_arg(ap, typeof (d));
 ^
0xf110d2 decide_alg
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:24510
0xf59cff ix86_expand_set_or_movmem(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool)
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:24763
0x106cefe gen_movmemdi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/mnt/svn/gcc-trunk/gcc/config/i386/i386.md:15893
0xb19eb2 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
/mnt/svn/gcc-trunk/gcc/recog.h:310
0xb19eb2 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/mnt/svn/gcc-trunk/gcc/optabs.c:8395
0xb1a4c8 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/mnt/svn/gcc-trunk/gcc/optabs.c:8407
0x8d8b9e emit_block_move_via_movmem
/mnt/svn/gcc-trunk/gcc/expr.c:1330
0x8d8b9e emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long)
/mnt/svn/gcc-trunk/gcc/expr.c:1148
0x7974d1 expand_builtin_memcpy_args
/mnt/svn/gcc-trunk/gcc/builtins.c:3241
0x7a6f1c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/mnt/svn/gcc-trunk/gcc/builtins.c:6286
0x8d4716 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/mnt/svn/gcc-trunk/gcc/expr.c:10471
0x7caf89 expand_expr
/mnt/svn/gcc-trunk/gcc/expr.h:299
0x7caf89 expand_call_stmt
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:2347
0x7cb6bf expand_gimple_stmt_1
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3293
0x7cb6bf expand_gimple_stmt
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3447
0x7d0c53 expand_gimple_basic_block
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5280
0x7d3146 execute
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5889
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r218413 - ICE (after PR64108 fix)
4_9 r218177 - ICE

[Bug tree-optimization/64199] New: [4.8/4.9/5 Regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in fold_binary_loc, at fold-const.c:10404 with -ffast-math -frounding-ma

[zsojka at seznam dot cz]

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

Bug ID: 64199
   Summary: [4.8/4.9/5 Regression] ICE: tree check: expected class
'constant', have 'binary' (plus_expr) in
fold_binary_loc, at fold-const.c:10404 with
-ffast-math -frounding-math
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 34201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34201&action=edit
reduced testcase

Compiler output:
$ gcc -O -ffast-math -frounding-math testcase.c
testcase.c: In function 'foo':
testcase.c:20:1: internal compiler error: tree check: expected class
'constant', have 'binary' (plus_expr) in fold_binary_loc, at fold-const.c:10404
 }
 ^
0xe94097 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/mnt/svn/gcc-trunk/gcc/tree.c:9277
0x9152d6 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/mnt/svn/gcc-trunk/gcc/tree.h:2887
0x9152d6 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/mnt/svn/gcc-trunk/gcc/fold-const.c:10404
0x91f16a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/mnt/svn/gcc-trunk/gcc/fold-const.c:14290
0x90c652 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/mnt/svn/gcc-trunk/gcc/fold-const.c:9881
0xdd50c1 simplify_binary_expression
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:3368
0xdd50c1 try_to_simplify
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:3487
0xdd50c1 visit_use
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:3541
0xdd7911 process_scc
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:3902
0xdd7911 extract_and_process_scc_for_name
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:3988
0xdd7911 DFS
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:4040
0xdd88ce run_scc_vn(vn_lookup_kind)
/mnt/svn/gcc-trunk/gcc/tree-ssa-sccvn.c:4425
0xdae1d2 execute
/mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:4904
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gcc -v   
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-218413-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-218413-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 5.0.0 20141205 (experimental) (GCC) 


Tested revisions:
r218413 - ICE
4_9 r218177 - ICE
4_8 r218176 - ICE
4_7 r211571 - OK
4_6 r197894 - OK

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Jambor  ---
OK, hopefully this is all fixed.  Please check and reopen if not.  Sorry for
the breakage.

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Fri Dec  5 18:14:37 2014
New Revision: 218433

URL: https://gcc.gnu.org/viewcvs?rev=218433&root=gcc&view=rev
Log:
2014-12-05  Martin Jambor  

PR ipa/64192
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Convert alignment
from bits to bytes after checking they are byte-aligned.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

[Bug target/53199] __builtin_bswap64 and __builtin_bswap32 generate errors if -mcpu=power6

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Author: meissner
Date: Fri Dec  5 17:50:40 2014
New Revision: 218431

URL: https://gcc.gnu.org/viewcvs?rev=218431&root=gcc&view=rev
Log:
2014-12-05  Michael Meissner  

PR target/53199
* gcc.target/powerpc/pr53199.c: Limit tests to 64-bit.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr53199.c

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
r218369 also miscompiled SPEC CPU 2000 on Linux/i686 with LTO:

https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg00552.html

[Bug bootstrap/64197] [5 regression] SPARC bootstrap broken: SEGV in tree_estimate_loop_size

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

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

--- Comment #2 from Andreas Schwab  ---
Dup of PR64192?

[Bug c++/64195] type_traits.h: is_trivially_copyable unimplemented

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #1 from Jonathan Wakely  ---
This is already fixed on trunk.

The fix probably can't be backported because it relied on changes to the
compiler front-end.

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
I'm still in the process of testing the following fix.  I believe it will solve
all these problems.  Sorry for such a stupid mistake:

https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00507.html

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

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

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

--- Comment #3 from Andreas Schwab  ---
This is also causing unaligned accesses in the compiler on ia64, for example in
function ipa-inline-analysis.c:account_size_time:

  new_entry.predicate = *pred;

struct predicate has only 4 byte alignment, but the copy is using ld8.

[Bug c/64188] [5 Regression] empty nested function does use trampoline

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Kratochvil  ---
OK, I agree with PR 53927; although it is inconvenient for the purpose of the
C/C++ GDB plugin (gdbjit).  Maybe it could be disable by some new compilation
flag, I'll try to avoid nested functions for now.

(In reply to Tom Tromey from PR 53927 comment #4)
> but it is a little unfortunate since it makes debugging less obvious.

[Bug go/64198] New: ICE in gofrontend

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 64198
   Summary: ICE in gofrontend
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com

This test program genererates an ICE with the current gccgo HEAD:

-- snip --
package main
func main() {
var x int = 0
println(x++)
}
-- snip --

==>

$ gccgo foo.go
foo.go:4:18: error: missing ‘)’
 println(x++) 
  ^
foo.go:4:20: error: expected ‘;’ or ‘}’ or newline
 println(x++) 
^
foo.go:4:9: error: invalid left hand side of assignment
 println(x++) 
 ^
foo.go:4:9: error: expected integer, floating, complex, or string type
go1: internal compiler error: in set_type, at
go/gofrontend/expressions.cc:15374
0x801a5dc9 Numeric_constant::set_type(Type*, bool, Location)
../../gcc/go/gofrontend/expressions.cc:15374
0x801a5dc9 Integer_expression::do_check_types(Gogo*)
../../gcc/go/gofrontend/expressions.cc:1898
0x801cea8f Expression::check_types(Gogo*)
../../gcc/go/gofrontend/expressions.h:717
0x801cea8f Check_types_traverse::expression(Expression**)
../../gcc/go/gofrontend/gogo.cc:3094
0x8018d341 Expression::traverse(Expression**, Traverse*)
../../gcc/go/gofrontend/expressions.cc:43
0x8018d341 Binary_expression::do_traverse(Traverse*)
../../gcc/go/gofrontend/expressions.cc:4304
0x801d4203 Block::traverse(Traverse*)
../../gcc/go/gofrontend/gogo.cc:5552
0x801d454d Function::traverse(Traverse*)
../../gcc/go/gofrontend/gogo.cc:4707
0x801da7d3 Bindings::traverse(Traverse*, bool)
../../gcc/go/gofrontend/gogo.cc:7316
0x801db1cb Gogo::traverse(Traverse*)
../../gcc/go/gofrontend/gogo.cc:2353
0x801db1cb Gogo::check_types()
../../gcc/go/gofrontend/gogo.cc:3104
0x801ce767 go_parse_input_files(char const**, unsigned int, bool, bool)
../../gcc/go/gofrontend/go.cc:107

--

Looks like the gofrontend cannot handle the ++ for call arguments (I don't know
whether Go allows that, but the compiler shouldn't crash anyway).  If the ++ is
placed in a separate statement after the call, the crash goes away.

[Bug bootstrap/64197] [5 regression] SPARC bootstrap broken: SEGV in tree_estimate_loop_size

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug bootstrap/64197] [5 regression] SPARC bootstrap broken: SEGV in tree_estimate_loop_size

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 34200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34200&action=edit
preprocessed input

[Bug bootstrap/64197] New: [5 regression] SPARC bootstrap broken: SEGV in tree_estimate_loop_size

[ro at gcc dot gnu.org]

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

Bug ID: 64197
   Summary: [5 regression] SPARC bootstrap broken: SEGV in
tree_estimate_loop_size
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Between 20141128 (r218141) and 20141205 (r218417) SPARC bootstrap got broken
compiling the 64-bit stage2 libcc1. The following testcase is extracted from
building _ffsdi2.o, but the same happens for many other files:

cc1 -fpreprocessed libgcc2.i -mptr64 -mcpu=v9 -quiet -m64 -O2 -o libgcc2.s
/vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c: In function '__ffsti2':
/vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c:528:1: internal compiler error:
Bus Error
 __ffsDI2 (DWtype u)
 ^

Running cc1 under gdb finds

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00903928 in tree_estimate_loop_size(loop*, edge_def*, edge_def*, loop_size*,
int) ()
(gdb) where
#0  0x00903928 in tree_estimate_loop_size(loop*, edge_def*, edge_def*,
loop_size*, int) ()
#1  0x00904c60 in canonicalize_loop_induction_variables(loop*, bool,
unroll_level, bool) ()
#2  0x00906388 in tree_unroll_loops_completely_1(bool, bool, vec&, loop*) ()
#3  0x009062f4 in tree_unroll_loops_completely_1(bool, bool, vec&, loop*) ()
#4  0x0090663c in tree_unroll_loops_completely(bool, bool) ()
#5  0x00906c5c in (anonymous
namespace)::pass_complete_unrolli::execute(function*) ()
#6  0x006ddd0c in execute_one_pass(opt_pass*) ()
#7  0x006de1f4 in execute_pass_list_1(opt_pass*) [clone .constprop.71] ()
#8  0x006de218 in execute_pass_list_1(opt_pass*) [clone .constprop.71] ()
#9  0x006de25c in execute_pass_list(function*, opt_pass*) ()
#10 0x0039a6fc in cgraph_node::expand() ()
#11 0x0039c388 in symbol_table::compile() ()
#12 0x0039e1c0 in symbol_table::finalize_compilation_unit() ()
#13 0x00226a60 in c_write_global_declarations() ()
#14 0x007b045c in compile_file() ()
#15 0x00e99620 in toplev::main(int, char**) ()
#16 0x00e9a044 in main ()

  Rainer

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ienkovich at gcc dot gnu.org]

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

--- Comment #27 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Dec  5 16:00:52 2014
New Revision: 218426

URL: https://gcc.gnu.org/viewcvs?rev=218426&root=gcc&view=rev
Log:
PR target/64003
* config/i386/i386.md (*jcc_1_bnd): New.
(*jcc_2_bnd): New.
(jump_bnd): New.
(*jcc_1): Remove bnd prefix.
(*jcc_2): Likewise.
(jump): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug c++/64195] New: type_traits.h: is_trivially_copyable unimplemented

[bep684 at gmail dot com]

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

Bug ID: 64195
   Summary: type_traits.h: is_trivially_copyable unimplemented
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bep684 at gmail dot com

Attempting to use std::is_trivially_copyable results in the following error at
compile-time:
"error: 'is_trivially_copyable' is not a member of 'std'"

Found the following line in type_traits.h:
"// is_trivially_copyable (still unimplemented)"

[Bug jit/64196] New: No automated test coverage for debugging of JIT-generated code

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 64196
   Summary: No automated test coverage for debugging of
JIT-generated code
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org

gcc/jit/docs/intro/tutorial04.rst shows an example of debugging,
single-stepping through JIT-generated code in gdb [1].

This was all tested by hand.  We don't yet have any automated test coverage to
verify that this works.

[1]: built HTML version of this currently here:
https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/intro/tutorial04.html#single-stepping-through-the-generated-code

[Bug c++/64194] New: [C++14] for function template with auto return

[redi at gcc dot gnu.org]

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

Bug ID: 64194
   Summary: [C++14]  for
function template with auto return
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

template  auto id() { }

template  void g(T) { }

int main()
{
// id;
g(id);
}

G++ fails to resolve id in the call.

over.cc: In function ‘int main()’:
over.cc:8:14: error: no matching function for call to ‘g()’
 g(id);
  ^
over.cc:3:28: note: candidate: template void g(T)
 template  void g(T) { }
^
over.cc:3:28: note:   template argument deduction/substitution failed:
over.cc:8:14: note:   couldn't deduce template parameter ‘T’
 g(id);
  ^

It works if the reference to id is uncommented, or if auto id() is changed
to void id()

[Bug c++/59912] [C++1y] ICE when deducing return type for specialized functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #2 from Jonathan Wakely  ---
This also crashes clang++ and EDG!

[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-05
 Ever confirmed|0   |1

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

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

--- Comment #26 from Ilya Enkovich  ---
(In reply to rsand...@gcc.gnu.org from comment #25)
> 
> If all you want to do is add 1 byte to the length to account for a prefix
> then it might be cleaner to use ADJUST_INSN_LENGTH.  You could then keep
> the single nobnd patterns.

Currently i386 target doesn't have ADJUST_INSN_LENGTH defined.  So I prefer to
keep it so and have all length definitions explicit in md file.

[Bug rtl-optimization/63917] [5 Regression] r217646 caused many failures

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
A patch has been submitted at
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00478.html waiting for
approval!-(

[Bug libstdc++/41949] std::endl documentation contains bad link

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Prasad H. L. from comment #4)
> The link seems to be broken again. Could you please fix it?

Yes, I'll update the API docs some time this month, which will fix it.

The correct link is now
https://gcc.gnu.org/onlinedocs/libstdc++/manual/streambufs.html#io.streambuf.buffering
(and that should be stable "forever")

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #25 from rsandifo at gcc dot gnu.org  
---
(In reply to Ilya Enkovich from comment #21)
> (In reply to Jeffrey A. Law from comment #20)
> > Ilya, it's the function call in this code I think:
> > 
> >   (cond [(eq_attr "length_nobnd" "!0")
> >(plus (symbol_ref ("ix86_bnd_prefixed_insn_p (insn)"))
> >  (attr "length_nobnd"))
> > 
> > You're calling out to ix86_bnd_prefixed_insn_p, and that's problematical for
> > branch shortening if I'm understanding Joern's comments here and David's
> > comments in the PA port correctly.
> 
> Then we have three problematic patterns and the easiest way to handle it is
> to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. 
> I think the easiest way to do it is to have separate bnd and nobnd patterns
> for these instructions.  Attached patch helps me to resolve valgrind error. 
> Is such approach fine?

If all you want to do is add 1 byte to the length to account for a prefix
then it might be cleaner to use ADJUST_INSN_LENGTH.  You could then keep
the single nobnd patterns.

[Bug fortran/60414] internal compiler error: tree check

[dominiq at gcc dot gnu.org]

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

--- Comment #4 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Dec  5 14:15:27 2014
New Revision: 218422

URL: https://gcc.gnu.org/viewcvs?rev=218422&root=gcc&view=rev
Log:
2014-12-05  Andre Vehreschild  

PR fortran/60414
* interface.c (compare_parameter): Remove class argument rank
check short circuit.

2014-12-05  Andre Vehreschild  

PR fortran/60414
* gfortran.dg/unlimited_polymorphism_18.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|emsr at gcc dot gnu.org|jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek  ---
Created attachment 34199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34199&action=edit
gcc5-pr63831.patch

Untested fix.

[Bug target/64160] msp430 code generation error adding 32-bit integers

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #1 from Ulrich Weigand  ---
This is not a reload problem, it's a bug in the addsi3 splitter where it
doesn't account for overlapping source and destination.  We have initially:

(insn 11 10 12 2 (set (reg:SI 13 R13)
(plus:SI (reg:SI 12 R12)
(mem:SI (reg/v/f:HI 28 [ ap ]) [2 ap_4(D)->duration+0 S4 A16])))
bug.i:10 20 {addsi3}
 (expr_list:REG_DEAD (reg:HI 12 R12)
(nil)))

Note where the destination (reg:SI 13) partially overlaps the source (reg:SI
12).

After split 1 we have:

(insn 22 10 23 2 (parallel [
(set (reg:HI 13 R13)
(plus:HI (reg:HI 12 R12)
(mem:HI (reg/v/f:HI 28 [ ap ]) [2 ap_4(D)->duration+0 S2
A16])))
(set (reg:BI 2 R2)
(truncate:BI (lshiftrt:SI (plus:SI (zero_extend:SI (reg:HI 12
R12))
(zero_extend:SI (mem:HI (reg/v/f:HI 28 [ ap ]) [2
ap_4(D)->duration+0 S2 A16])))
(const_int 16 [0x10]
]) bug.i:10 -1
 (nil))
(insn 23 22 12 2 (set (reg:HI 14 R14 [+2 ])
(plus:HI (plus:HI (reg:HI 13 R13 [+2 ])
(mem:HI (plus:HI (reg/v/f:HI 28 [ ap ])
(const_int 2 [0x2])) [2 ap_4(D)->duration+2 S2 A16]))
(zero_extend:HI (reg:BI 2 R2 bug.i:10 -1
 (nil))

Note how the first insn of the pair now clobbers the part of the source that is
still needed for the second half.

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Hm, the only one I can reproduce is the gcc.dg/vect/pr60196-1.c
failure, but I will start with that and have a look.  Hopefully it is
the same issue.

[Bug tree-optimization/64193] Decreased performance after r173250

[cederman at gaisler dot com]

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

--- Comment #2 from Daniel Cederman  ---
Created attachment 34198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34198&action=edit
assembly output without r173250

[Bug tree-optimization/64193] Decreased performance after r173250

[cederman at gaisler dot com]

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

--- Comment #1 from Daniel Cederman  ---
Created attachment 34197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34197&action=edit
assembly output with r173250

[Bug tree-optimization/64193] New: Decreased performance after r173250

[cederman at gaisler dot com]

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

Bug ID: 64193
   Summary: Decreased performance after r173250
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cederman at gaisler dot com
Target: i686-build_pc-linux-gnu

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

When comparing version 4.4.2 with version 4.9.2 I noticed a performance
decrease for the Whetstone benchmark. It seems to have been introduced with
r173250. Compiling Whetstone with the latest master (r217599) I get the
following numbers:

Without r173250:
Loops: 500, Iterations: 1, Duration: 54 sec.
C Converted Double Precision Whetstones: 9259.3 MIPS

With r173250:
Loops: 500, Iterations: 1, Duration: 58 sec.
C Converted Double Precision Whetstones: 8620.7 MIPS

The assembly output has also increased in size.

I have attached a preprocessed copy of the Whetstone benchmark and assembly
output for i686-build_pc-linux-gnu compiled with -O3, with and without r173250.

Let me know if you need any more information.

[Bug c++/60955] [4.9/5 Regression] Erroneous warning about taking address of register with std=c++1y

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Paolo Carlini from comment #5)
> This is a regression. Manuel, are you going to pursue the issue further and
> send to the mailing list a complete patch?

I don't even remember the details of this. The above doesn't actually look like
a patch of mine, perhaps the patch that introduced the regression?

[Bug rtl-optimization/64037] [4.8/4.9 Regression] Miscompilation with -Os and enum class : char parameter

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #18 from H.J. Lu  ---
Fixed for 4.8.4 and 4.9.3.

[Bug target/64108] ICE: SIGSEGV in decide_alg() with -mmemset-strategy=libcall:-1:align -minline-all-stringops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for 4.9.3

[Bug rtl-optimization/64037] [4.8/4.9 Regression] Miscompilation with -Os and enum class : char parameter

[hjl at gcc dot gnu.org]

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

--- Comment #17 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Dec  5 12:02:33 2014
New Revision: 218420

URL: https://gcc.gnu.org/viewcvs?rev=218420&root=gcc&view=rev
Log:
Pass unpromoted argument to promote_function_mode

This patch updates setup_incoming_promotions in combine.c to match what
is actually passed in assign_parm_setup_reg in function.c.

gcc/

Backport from mainline
PR rtl-optimization/64037
* combine.c (setup_incoming_promotions): Pass the argument
before any promotions happen to promote_function_mode.

gcc/testsuite/

Backport from mainline
PR rtl-optimization/64037
* g++.dg/pr64037.C: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/pr64037.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/combine.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/60955] [4.9/5 Regression] Erroneous warning about taking address of register with std=c++1y

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|Erroneous warning about |[4.9/5 Regression]
   |taking address of register  |Erroneous warning about
   |with std=c++1y  |taking address of register
   ||with std=c++1y

--- Comment #5 from Paolo Carlini  ---
This is a regression. Manuel, are you going to pursue the issue further and
send to the mailing list a complete patch?

[Bug target/64108] ICE: SIGSEGV in decide_alg() with -mmemset-strategy=libcall:-1:align -minline-all-stringops

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Dec  5 11:52:44 2014
New Revision: 218419

URL: https://gcc.gnu.org/viewcvs?rev=218419&root=gcc&view=rev
Log:
Stop only if there aren't any usable algorithms

When searching for an usable algorithm with -minline-all-stringops,
decide_alg stops when it sees libcall even if there is a usable
algorithm.  It goes into an infinite loop.  This patch changes
decide_alg to stop searching only if there aren't any usable algorithms.
Testd on Linux/x86-64.

gcc/

Backport from mainline
PR target/64108
* config/i386/i386.c (decide_alg): Stop only if there aren't
any usable algorithms.

gcc/testsuite/

Backport from mainline
PR target/64108
* gcc.target/i386/memset-strategy-2.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/memset-strategy-2.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/64037] [4.8/4.9 Regression] Miscompilation with -Os and enum class : char parameter

[hjl at gcc dot gnu.org]

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

--- Comment #16 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Dec  5 11:47:51 2014
New Revision: 218418

URL: https://gcc.gnu.org/viewcvs?rev=218418&root=gcc&view=rev
Log:
Pass unpromoted argument to promote_function_mode

This patch updates setup_incoming_promotions in combine.c to match what
is actually passed in assign_parm_setup_reg in function.c.

gcc/

Backport from mainline
PR rtl-optimization/64037
* combine.c (setup_incoming_promotions): Pass the argument
before any promotions happen to promote_function_mode.

gcc/testsuite/

Backport from mainline
PR rtl-optimization/64037
* g++.dg/pr64037.C: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr64037.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/combine.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-05
 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Hit return too soon!-(

Revision r218369 causes some regressions with -m32

FAIL: c-c++-common/ubsan/object-size-9.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test, is
c-c++-common/ubsan/object-size-9.c:21:11: runtime error: load of address
0x7fff54fb3cdc with insufficient space for an object of type 'char'
FAIL: gcc.c-torture/execute/pr37573.c   -O3 -fomit-frame-pointer  execution
test
FAIL: gcc.c-torture/execute/pr37573.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr37573.c   -O3 -fomit-frame-pointer -funroll-loops
 execution test
FAIL: gcc.c-torture/execute/pr37573.c   -O3 -g  execution test
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-multitypes-11.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-multitypes-12.c -flto -ffat-lto-objects execution test

see for instance https://gcc.gnu.org/ml/gcc-regression/2014-12/msg00136.html.

[Bug ipa/64192] New: [5 Regression] r218369 causes some regressions with -m32.

[dominiq at lps dot ens.fr]

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

Bug ID: 64192
   Summary: [5 Regression] r218369 causes some regressions with
-m32.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr

[Bug c++/64191] New: -march=native messes up dead code elimination in loop calling dtor

[petschy at gmail dot com]

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

Bug ID: 64191
   Summary: -march=native messes up dead code elimination in loop
calling dtor
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com

Without -march=native, the loops in the 3 fns are eliminated as expected,
resulting in single retq's.

With -march=native, the loop which calls the defined, but empty dtor is
compiled into something rather weird. However, the other empty Nop() call is
optimized away as expected.

g++-5.0.0 -g -O3 -Wall -Wextra -c 20141205-dtor_loop.cpp 
g++-5.0.0 -g -O3 -Wall -Wextra -o 20141205-dtor_loop 20141205-dtor_loop.o

Dump of assembler code for function foo_dtor_loop(Foo*, unsigned int):
   0x00400570 <+0>:repz retq   
Dump of assembler code for function bar_dtor_loop(Bar*, unsigned int):
   0x00400580 <+0>:repz retq 
Dump of assembler code for function bar_nop_loop(Bar*, unsigned int):
   0x00400590 <+0>:repz retq 

So far so good.

g++-5.0.0 -g -O3 -march=native -Wall -Wextra -c 20141205-dtor_loop.cpp 
g++-5.0.0 -g -O3 -march=native -Wall -Wextra -o 20141205-dtor_loop
20141205-dtor_loop.o

Dump of assembler code for function foo_dtor_loop(Foo*, unsigned int):
   0x00400570 <+0>:retq   

Dump of assembler code for function bar_dtor_loop(Bar*, unsigned int):
   0x00400578 <+0>: test   %rdi,%rdi
   0x0040057b <+3>: je 0x4005b8 
   0x0040057d <+5>: mov%esi,%esi
   0x0040057f <+7>: lea(%rdi,%rsi,4),%rax
   0x00400583 <+11>:cmp%rax,%rdi
   0x00400586 <+14>:jae0x4005b8 
   0x00400588 <+16>:mov$0x3,%edx
   0x0040058d <+21>:lea-0x4(%rax),%rsi
   0x00400591 <+25>:sub%rdi,%rdx
   0x00400594 <+28>:add%rsi,%rdx
   0x00400597 <+31>:mov%rdx,%rcx
   0x0040059a <+34>:shr$0x2,%rcx
   0x0040059e <+38>:lea0x1(%rcx),%r8
   0x004005a2 <+42>:dec%rcx
   0x004005a5 <+45>:shr%rcx
   0x004005a8 <+48>:lea0x2(%rcx,%rcx,1),%rcx
   0x004005ad <+53>:cmp$0x2f,%rdx
   0x004005b1 <+57>:jbe0x4005b8 
   0x004005b3 <+59>:cmp%rcx,%r8
   0x004005b6 <+62>:je 0x4005b8 
   0x004005b8 <+64>:retq   

Dump of assembler code for function bar_nop_loop(Bar*, unsigned int):
   0x004005c0 <+0>: retq   

The bar_dtor_loop() fn is clearly a mess, unfortunately I can't follow the
computation.

The bar_inc_loop() does a single int increment on each object, to see what loop
code is generated if not empty fns are called. It is as expected: the loop is
unrolled 16x times, and the residual part is executed in a tight loop:
   0x00400648 <+120>:sub$0x4,%rdx
   0x0040064c <+124>:incl   (%rdx)
   0x0040064e <+126>:cmp%rdx,%rdi
   0x00400651 <+129>:jb 0x400648 

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

cat /proc/cpuinfo 
processor: 0
vendor_id: AuthenticAMD
cpu family: 21
model: 1
model name: AMD FX(tm)-8150 Eight-Core Processor
stepping: 2
microcode: 0x6000626
cpu MHz: 1400.000
cache size: 2048 KB
physical id: 0
siblings: 8
core id: 0
cpu cores: 4
apicid: 16
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni
pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb arat cpb
hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
decodeassists pausefilter pfthreshold
bugs: fxsave_leak
bogomips: 7624.63
TLB size: 1536 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb

Unfortunately, I couldn

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

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

--- Comment #24 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #23)
> (In reply to Ilya Enkovich from comment #21)
> 
> > Then we have three problematic patterns and the easiest way to handle it is
> > to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. 
> > I think the easiest way to do it is to have separate bnd and nobnd patterns
> > for these instructions.  Attached patch helps me to resolve valgrind error. 
> > Is such approach fine?
> 
> Maybe "enabled" attribute can help here to avoid unnecessary duplication.

No, please disregard the above sentence. The aproach with two patterns looks OK
AFAICS.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[y.gribov at samsung dot com]

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

--- Comment #11 from Yury Gribov  ---
(In reply to Jakub Jelinek from comment #9)
> An ODR violation is IMHO something different, it is the case where you have
> the same symbol name (but, you'd need to distinguish between globally
> visible symbols that should be ODR checked and local symbols and/or symbols
> from languages you don't want to check for it) registered multiple times for
> multiple addresses.  So you'd need to hash based on the symbol name if
> marked for ODR checking, and check if the same (non-comdat) global isn't
> registered several times.

There is already proposal to this in UBSan:
http://llvm.org/bugs/show_bug.cgi?id=21498

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

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

--- Comment #23 from Uroš Bizjak  ---
(In reply to Ilya Enkovich from comment #21)

> Then we have three problematic patterns and the easiest way to handle it is
> to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. 
> I think the easiest way to do it is to have separate bnd and nobnd patterns
> for these instructions.  Attached patch helps me to resolve valgrind error. 
> Is such approach fine?

Maybe "enabled" attribute can help here to avoid unnecessary duplication.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

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

--- Comment #22 from Ilya Enkovich  ---
Created attachment 34195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34195&action=edit
Proposed patch

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[y.gribov at samsung dot com]

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

--- Comment #10 from Yury Gribov  ---
(In reply to Kostya Serebryany from comment #8)
> (sorry for delay, I missed the last comment)
> > Generally, we do want to instrument even artificial variables, and on many
> > of them buffer overflow is possible.
> 
> Yea, agree. 

FYI this is not only about artificials - gfortran emits tons of spurious ODR
errors on user global vars in SPEC2006.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

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

--- Comment #21 from Ilya Enkovich  ---
(In reply to Jeffrey A. Law from comment #20)
> Ilya, it's the function call in this code I think:
> 
>   (cond [(eq_attr "length_nobnd" "!0")
>(plus (symbol_ref ("ix86_bnd_prefixed_insn_p (insn)"))
>  (attr "length_nobnd"))
> 
> You're calling out to ix86_bnd_prefixed_insn_p, and that's problematical for
> branch shortening if I'm understanding Joern's comments here and David's
> comments in the PA port correctly.

Then we have three problematic patterns and the easiest way to handle it is to
get rid of ix86_bnd_prefixed_insn_p call in length computation for them.  I
think the easiest way to do it is to have separate bnd and nobnd patterns for
these instructions.  Attached patch helps me to resolve valgrind error.  Is
such approach fine?

[Bug target/64056] [5 Regression] gcc.target/i386/chkp-strlen-4.c etc. FAIL

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Dec  5 10:01:33 2014
New Revision: 218415

URL: https://gcc.gnu.org/viewcvs?rev=218415&root=gcc&view=rev
Log:
gcc/

PR target/64056
* doc/sourcebuild.texi: Add mempcpy and stpcpy for Effective-Target
Keywords.

gcc/testsuite/

PR target/64056
* lib/target-supports.exp (check_effective_target_stpcpy): New.
* gcc.target/i386/chkp-strlen-2.c: Add stpcpy target check.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-2.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug c/64188] [5 Regression] empty nested function does use trampoline

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Only when not optimizing.  I think that was an intentional change, requested by
GDB folks.  See PR53927.

[Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #17 from Joost VandeVondele  
---
(In reply to Harald Anlauf from comment #16)
> (In reply to Joost VandeVondele from comment #15)
> > While if we use -fsanitize=address (at greatly increased cost), we actually
> > get a Christmas tree with losts of colourful lights:
> 
> I cannot use ASAN on any of the servers at work, as the
> administrators enforce strict limits on virtual memory.
> (See also PR 55517 on ASAN).

Sure, and one of the strong points of Fortran is that bounds checking works so
well, at a very low runtime cost... so replacing it with asan is not a general
purpose solution.

I believe your proposed patch in comment #1 is at least a reasonable partial
fix.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Kostya Serebryany from comment #8)
> > You haven't responded about the language thing, there is no such thing as
> > ODR in C or Fortran, so you shouldn't report it.
> 
> In LLVM, I do not (and should not) know what source language is being
> compiled.

Sounds like LLVM limitation.

> The differences between languages are represented in the linkage types 
> of the globals. E.g. a regular global in C will not be instrumented at all 
> unless -fno-common is given. I.e. the difference is not in the source
> language 
> but in the linkage type of the globals. 

I believe your
http://llvm.org/klaus/compiler-rt/blob/0926de35c9357aa1a5c47d3a618d6c72f9e8f085/test/asan/TestCases/Linux/odr-violation.cc
example is valid in C, and commonly used (sure, more commonly with functions
than with variables, but even with variables).  Furthermore, the kind of ODR
detection in libasan isn't really ODR detection, you are instead checking if
the same global is registered multiple times.  GCC intentionally registers
local aliases of the globals, so that the same global isn't registered multiple
times if it is defined by multiple shared libraries or binary and some shared
library - each TU registers the vars local to it, rather than trying to
register globals in a completely different shared library.
If LLVM uses global symbols instead of local aliases, it is more expensive.
You can have aliases/weakrefs etc. to symbols, and those still aren't ODR
violations.

An ODR violation is IMHO something different, it is the case where you have the
same symbol name (but, you'd need to distinguish between globally visible
symbols that should be ODR checked and local symbols and/or symbols from
languages you don't want to check for it) registered multiple times for
multiple addresses.  So you'd need to hash based on the symbol name if marked
for ODR checking, and check if the same (non-comdat) global isn't registered
several times.