[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

2015-12-16 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707

--- Comment #19 from rguenther at suse dot de  ---
On December 16, 2015 8:24:49 PM GMT+01:00, "alalaw01 at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
>
>--- Comment #18 from alalaw01 at gcc dot gnu.org ---
>Well, we've seen this patch fix some of the vectorizer performance
>regressions
>we've had on some benchmarks.
>
>On SPEC...the "SLP cancelled" case triggers all over the place, but in
>most of
>those cases, doesn't lead to any codegen difference. (Presumably SLP
>would have
>failed anyway for some other reason, e.g. costs, and either we generate
>load/store-lanes either way, or we still *can't* generate
>load/store-lanes...).
>The only sub-benchmark where codegen changes is facerec, where we seem
>to
>*lose* st2 rather than gainthis needs more analysis.

Would be nice to have a reduced testcase for this one.

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

2015-12-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68937

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37052|0   |1
is obsolete||

--- Comment #7 from H.J. Lu  ---
Created attachment 37053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37053=edit
A new patch

This one is better.

[Bug rtl-optimization/25972] pack and unpack of long doubles via union generates poor code

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25972

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #6 from Bill Schmidt  ---
It appears this relic could be closed, correct?

[Bug rtl-optimization/10588] [PPC] i==0||j==0 should use cntlzw and srawi

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10588

Bill Schmidt  changed:

   What|Removed |Added

 CC||dje.gcc at gmail dot com,
   ||wschmidt at gcc dot gnu.org

--- Comment #9 from Bill Schmidt  ---
David, looks like you fixed this long ago -- can this be closed?

[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug jit/64296] link failure of libgccjit.so for "in tree" gmp/mpc/mpfr/isl

2015-12-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64296

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-04-13 00:00:00 |2015-12-16
 CC||msebor at gcc dot gnu.org
  Known to fail||6.0

--- Comment #3 from Martin Sebor  ---
Assuming this is the same error, it's still failing on today's trunk.  After
configuring with the following options:

--enable-languages=ada,c,c++,fortran,go,java,jit,lto,objc,obj-c++
--enable-host-shared

I got the error below.  I added the --enable-host-shared after a configure
error that said it was needed for jit.

/home/msebor/build/gcc-trunk-svn/./prev-gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/msebor/build/gcc-trunk-svn/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/msebor/build/gcc-trunk-svn/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/msebor/build/gcc-trunk-svn/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/msebor/build/gcc-trunk-svn/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/msebor/scm/fsf/gcc-svn/libstdc++-v3/libsupc++
-L/home/msebor/build/gcc-trunk-svn/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/msebor/build/gcc-trunk-svn/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie   -g -O2 -gtoggle -DIN_GCC -fPIC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o
lto/lto-symtab.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
-L/home/msebor/build/gcc-trunk-svn/./isl/.libs  -lisl
-L/home/msebor/build/gcc-trunk-svn/./gmp/.libs
-L/home/msebor/build/gcc-trunk-svn/./mpfr/.libs
-L/home/msebor/build/gcc-trunk-svn/./mpc/src/.libs -lmpc -lmpfr -lgmp -rdynamic
-ldl  -L./../zlib -lz libcommon.a ../libcpp/libcpp.a  
../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a
../libdecnumber/libdecnumber.a 
/usr/bin/ld:
/home/msebor/build/gcc-trunk-svn/./isl/.libs/libisl.a(isl_val_gmp.o):
relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC
/home/msebor/build/gcc-trunk-svn/./isl/.libs/libisl.a: error adding symbols:
Bad value
collect2: error: ld returned 1 exit status
/home/msebor/scm/fsf/gcc-svn/gcc/jit/Make-lang.in:84: recipe for target
'libgccjit.so.0.0.1' failed
make[3]: *** [libgccjit.so.0.0.1] Error 1
make[3]: *** Waiting for unfinished jobs
rm -f stamp-gnatlib2-rts stamp-tools
rm fsf-funding.pod grmic.pod gcov.pod gc-analyze.pod gpl.pod cpp.pod gfdl.pod
gccgo.pod gfortran.pod gcc.pod gcj-dbtool.pod jcf-dump.pod gcj.pod
jv-convert.pod gcov-tool.pod gij.pod
make[3]: Leaving directory '/home/msebor/build/gcc-trunk-svn/gcc'
Makefile:4435: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory '/home/msebor/build/gcc-trunk-svn'
Makefile:27942: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/home/msebor/build/gcc-trunk-svn'
Makefile:28185: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

[Bug middle-end/68832] FAIL: gcc.c-torture/execute/alias-2.c -O1 execution test

2015-12-16 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68832

--- Comment #6 from Jan Hubicka  ---
The bug is caused by achors.  We call

Breakpoint 6, write_dependence_p (mem=0x769006f0, x=0x769006c0,
x_mode=SImode, x_addr=0x76900690, mem_canonicalized=true,
x_canonicalized=true, writep=false)
at ../../gcc/alias.c:2897
2897  gcc_checking_assert (x_canonicalized
(gdb) p debug_rtx (x)
(mem:SI (plus:SI (mult:SI (reg:SI 110 [ off.0_2 ])
(const_int 4 [0x4]))
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182])) [1 a S4 A32])
$38 = void
(gdb) p debug_rtx (mem)
(mem:SI (plus:SI (mult:SI (reg:SI 110 [ off.0_2 ])
(const_int 4 [0x4]))
(symbol_ref:SI ("b") [flags 0x2]  )) [1 b S4
A32])
$39 = void

which is OK but we also have:
(gdb) p debug_rtx (x_addr)
(plus:SI (mult:SI (reg:SI 110 [ off.0_2 ])
(const_int 4 [0x4]))
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))
$50 = void

and we dispatch to:
Breakpoint 9, base_alias_check (x=0x76900690, x_base=0x768fb5f0,
y=0x769006d8, y_base=0x768fef48, x_mode=SImode, y_mode=SImode) at
../../gcc/alias.c:2065
(gdb) p debug_rtx (x_base)
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
$57 = void
(gdb) p debug_rtx (y_base)
(symbol_ref:SI ("b") [flags 0x2]  )
$58 = void

and eventually we return 0 in:
  if (GET_CODE (x_base) == SYMBOL_REF && GET_CODE (y_base) == SYMBOL_REF)
{
  tree x_decl = SYMBOL_REF_DECL (x_base);
  tree y_decl = SYMBOL_REF_DECL (y_base);

  /* We can assume that no stores are made to labels.  */
  if (!x_decl || !y_decl)
return 0;
  return compare_base_decls (x_decl, y_decl) != 0;
}

because x_base is NULL.  I suppose easy fix is to always return true for
anchor/decl compare, but perhaps there is a better way to check if the anchor
possibly corresponds to the declaration?

[Bug target/68753] PowerPC: double precision reciprocal estimate missed optimisations

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68753

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/68945] enable libcilkrts on SPARC

2015-12-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-16
 CC||ebotcazou at gcc dot gnu.org
Summary|RFE: enable libcilkrts on   |enable libcilkrts on SPARC
   |SPARC [ patch included ]|
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Eric Botcazou  ---
Patches need to be posted on the gcc-patches@ mailing-list.

A few remarks:

  - SPARC is not a platform/target, only an architecture, so I presume that you
mean SPARC/Solaris here?

  - you don't need 2 entries in configure.tgt

  - you don't need 2 entries in the target field of testcases.

  - you cannot patch Makefile.in directly, go through configure.ac instead.

  - I don't think that patching runtime/config/generic/os-unix-sysdep.c is the
way to go, you probably need to create runtime/config/sparc instead.

  - Why do you test all the possible flavours of macros?

#if defined(sun) || defined(__sun) || defined(__sun__)

#ifdef __sun__ is the correct version.

[Bug c/68162] [5 Regression] Incompatible pointer type using a typedef

2015-12-16 Thread jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

--- Comment #19 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Dec 16 21:11:01 2015
New Revision: 231722

URL: https://gcc.gnu.org/viewcvs?rev=231722=gcc=rev
Log:
Fix TYPE_MAIN_VARIANT construction for arrays of qualified typedefs (PR
c/68162).

PR c/68162 reports a spurious warning about incompatible types
involving arrays of const double, constructed in one place using a
typedef for const double and in another place literally using const
double.

The problem is that the array of the typedef was incorrectly
constructed without a TYPE_MAIN_VARIANT being an array of unqualified
elements as it should be (though it seems some more recent change
resulted in this producing incorrect diagnostics, likely the support
for C++-style handling of arrays of qualified type).  This patch fixes
the logic in grokdeclarator to determine first_non_attr_kind, which is
used to determine whether it is necessary to use the TYPE_MAIN_VARIANT
of the type in the declaration specifiers.

However, fixing that logic introduces a failure of
gcc.dg/debug/dwarf2/pr47939-4.c, a test introduced along with
first_non_attr_kind.  Thus, it is necessary to track the original
qualified typedef when qualifying an array type, to use it rather than
a newly-constructed type, to avoid regressing regarding typedef names
in debug info.  This is done along lines I suggested in
: track the
original type and the number of levels of array indirection at which
it appears, and, in possibly affected cases, pass extra arguments to
c_build_qualified_type (with default arguments to avoid needing to
pass those extra arguments explicitly everywhere).  Given Richard's
recent fix to dwarf2out.c, this allows the C bug to be fixed without
causing debug information regressions.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.

gcc/c:
PR c/68162
* c-decl.c (grokdeclarator): Set first_non_attr_kind before
following link from declarator to next declarator.  Track original
qualified type and pass it to c_build_qualified_type.
* c-typeck.c (c_build_qualified_type): Add arguments
orig_qual_type and orig_qual_indirect.

gcc/c-family:
PR c/68162
* c-common.h (c_build_qualified_type): Add extra default
arguments.

gcc/cp:
PR c/68162
* tree.c (c_build_qualified_type): Add extra arguments.

gcc/testsuite:
PR c/68162
* gcc.dg/pr68162-1.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68162-1.c
Modified:
branches/gcc-5-branch/gcc/c-family/ChangeLog
branches/gcc-5-branch/gcc/c-family/c-common.h
branches/gcc-5-branch/gcc/c/ChangeLog
branches/gcc-5-branch/gcc/c/c-decl.c
branches/gcc-5-branch/gcc/c/c-typeck.c
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/tree.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes

2015-12-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to fail||4.9.3, 5.3.0

--- Comment #7 from Jonathan Wakely  ---
Fixed for 4.9.4 and 5.4

[Bug c++/68941] ice in vect_analyze_stmt, at tree-vect-stmts.c:8013

2015-12-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68941

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup.

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

[Bug c++/68948] New: G++ voluntarily removes a function call with terrible side effects

2015-12-16 Thread basil at list dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948

Bug ID: 68948
   Summary: G++ voluntarily removes a function call with terrible
side effects
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: basil at list dot ru
  Target Milestone: ---

This was reproduced in Chromium on Android in
https://codereview.chromium.org/1480153002/#ps980001. A test calls
RemoveLoginsByOriginAndTime(). The call with all the arguments
construction/destruction is absent from the assembly code. Clang builds it
correctly.

Grep for the line in the code 'base_store->RemoveLoginsByOriginAndTime'. The
call is removed by GCC.

$
/media/SSD/clank/src/third_party/android_tools/ndk//toolchains/x86-4.9/prebuilt/linux-x86_64/bin/i686-linux-android-g++
-v -save-temps -MMD -MF
obj/components/password_manager/core/browser/components_unittests.password_store_default_unittest.o.d
-DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -D_FILE_OFFSET_BITS=64 -DNO_TCMALLOC
-DDISABLE_NACL -DCHROMIUM_BUILD -DCR_CLANG_REVISION=255169-1 -DCOMPONENT_BUILD
-DUSE_LIBJPEG_TURBO=1 -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1
-DUSE_PROPRIETARY_CODECS -DENABLE_BROWSER_CDMS -DENABLE_CONFIGURATION_POLICY
-DENABLE_NOTIFICATIONS -DDONT_EMBED_BUILD_METADATA -DFIELDTRIAL_TESTING_ENABLED
-DENABLE_AUTOFILL_DIALOG=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1
-DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DENABLE_SUPERVISED_USERS=1
-DVIDEO_HOLE=1 -DV8_USE_EXTERNAL_STARTUP_DATA -DENABLE_WEBVR
-DSAFE_BROWSING_DB_REMOTE -DGTEST_HAS_POSIX_RE=0 -DGTEST_LANG_CXX11=0
-DMOJO_USE_SYSTEM_IMPL -DUNIT_TEST -DGTEST_HAS_RTTI=0 -DGTEST_HAS_CLONE=0
-DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_HAS_TR1_TUPLE=1 -DU_USING_ICU_NAMESPACE=0
-DU_ENABLE_DYLOAD=0 -DI18N_ADDRESSINPUT_USE_BASICTYPES_OVERRIDE=1
-DFEATURE_ENABLE_SSL -DFEATURE_ENABLE_VOICEMAIL -DEXPAT_RELATIVE_PATH
-DGTEST_RELATIVE_PATH -DNO_MAIN_THREAD_WRAPPING -DNO_SOUND_SYSTEM -DANDROID
-DWEBRTC_POSIX -DXML_STATIC -DI18N_PHONENUMBERS_USE_ICU_REGEXP=1
-DLIBXML_STATIC -DPROTOBUF_USE_DLLS -DGOOGLE_PROTOBUF_NO_RTTI
-DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER
'-DPRECACHE_CONFIG_SETTINGS_URL="https://www.gstatic.com/chrome/wifiprefetch/precache_config;'
'-DPRECACHE_MANIFEST_URL_PREFIX="https://www.gstatic.com/chrome/wifiprefetch/hosts/;'
-DAPPCACHE_USE_SIMPLE_CACHE -DV8_SHARED -DUSING_V8_SHARED
-DCHROME_PNG_WRITE_SUPPORT -DPNG_USER_CONFIG -DCHROME_PNG_READ_PACK_SUPPORT
-DSKIA_DLL -DGR_GL_IGNORE_ES3_MSAA=0 -DSK_SUPPORT_GPU=1
-DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_BUILD_FOR_ANDROID -DOPENSSL_SMALL
-DBORINGSSL_SHARED_LIBRARY -DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -DUSE_OPENSSL_CERTS=1
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__GNU_SOURCE=1
'-DCHROME_BUILD_ID=""' -DHAVE_SYS_UIO_H -DDYNAMIC_ANNOTATIONS_ENABLED=1
-DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_DEBUG -Igen -I../.. -I../../skia/config
-I../../third_party/khronos -I../../gpu -Igen/angle
-I../../third_party/WebKit/Source -Igen/protoc_out
-I../../testing/gmock/include -I../../testing/gtest/include
-I../../third_party/icu/source/i18n
-I../../third_party/leveldatabase/src/include
-I../../third_party/leveldatabase/src -I../../third_party/leveldatabase
-I../../third_party/libaddressinput/chromium/override
-I../../third_party/libaddressinput/src/cpp/include
-Igen/third_party/libaddressinput/ -I../../third_party/webrtc_overrides
-I../../third_party/libjingle/overrides -I../../third_party/libjingle/source
-I../../third_party -I../../third_party/expat/files/lib
-Igen/protoc_out/third_party/libphonenumber
-I../../third_party/libphonenumber/src -I../../third_party/libxml/linux/include
-I../../third_party/libxml/src/include -I../../third_party/icu/source/common
-I../../third_party/protobuf -I../../third_party/protobuf/src
-I../../third_party/re2 -Igen/ui/resources
-I../../third_party/dom_distiller_js/dist/proto_gen
-I../../third_party/cacheinvalidation/overrides
-I../../third_party/cacheinvalidation/src
-I../../third_party/cacheinvalidation/google/cacheinvalidation -Igen/components
-Igen/components/strings -I../../third_party/WebKit -I../../third_party/WebKit
-I../../third_party/npapi -I../../third_party/npapi/bindings -I../../v8/include
-I../../third_party/libpng -I../../third_party/zlib -I../../third_party/libwebp
-I../../third_party/ots/include -I../../third_party/qcms/src
-I../../third_party/iccjpeg -I../../third_party/libjpeg_turbo -I../../skia/ext
-I../../third_party/skia/include/core -I../../third_party/skia/include/effects
-I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu
-I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops
-I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports
-I../../third_party/skia/include/utils -I../../breakpad/src
-I../../third_party/android_tools/ndk/sources/android/cpufeatures

[Bug tree-optimization/68946] [6 Regression] ICE at -O3 on x86_64-linux-gnu in both 32- and 64-bit modes (in vect_analyze_stmt, at tree-vect-stmts.c:8013)

2015-12-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68946

Marek Polacek  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from Marek Polacek  ---
*** Bug 68941 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/25972] pack and unpack of long doubles via union generates poor code

2015-12-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25972

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Bergner  ---
(In reply to Bill Schmidt from comment #6)
> It appears this relic could be closed, correct?

Yes, this is fixed.  We generate the following for Alan's test cases and
options now:

pack:
blr

unpack:
stfd 1,0(5)
stfd 2,0(6)
blr

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

2015-12-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68937

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37049|0   |1
is obsolete||

--- Comment #6 from H.J. Lu  ---
Created attachment 37052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37052=edit
A patch

Please try this.

[Bug rtl-optimization/25972] pack and unpack of long doubles via union generates poor code

2015-12-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25972

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from Peter Bergner  ---
Fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)

2015-12-16 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 10588, which changed state.

Bug 10588 Summary: [PPC] i==0||j==0 should use cntlzw and srawi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10588

   What|Removed |Added

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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

2015-12-16 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
Bug 15524 depends on bug 10588, which changed state.

Bug 10588 Summary: [PPC] i==0||j==0 should use cntlzw and srawi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10588

   What|Removed |Added

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

[Bug rtl-optimization/10588] [PPC] i==0||j==0 should use cntlzw and srawi

2015-12-16 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10588

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #10 from David Edelsohn  ---
Fixed.

[Bug middle-end/68832] FAIL: gcc.c-torture/execute/alias-2.c -O1 execution test

2015-12-16 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68832

--- Comment #7 from Jan Hubicka  ---
Created attachment 37055
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37055=edit
proposed fix

This patch adds compare of anchored variables

[Bug target/68805] ICE while var-tracking in simplify_binary_operation_1 with -g and -mvsx-timode

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68805

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/24332] asm label declaration may be missing aliasing info

2015-12-16 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24332
Bug 24332 depends on bug 25140, which changed state.

Bug 25140 Summary: aliases, including weakref, break alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

   What|Removed |Added

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

[Bug middle-end/25140] aliases, including weakref, break alias analysis

2015-12-16 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Depends on|68832   |
 Resolution|--- |FIXED

--- Comment #17 from Jan Hubicka  ---
The issue described in this PR is fixed now.  I made 68832 separate. To fix
that one we still need to use assembler name hash to introduce the aliases. 
Have path for that but need to do more testing to see if any problems surfaces.

Honza


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68832
[Bug 68832] FAIL: gcc.c-torture/execute/alias-2.c   -O1  execution test

[Bug lto/61886] [4.9/5/6 Regression] LTO breaks fread with _FORTIFY_SOURCE=2

2015-12-16 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Bug 61886 depends on bug 25140, which changed state.

Bug 25140 Summary: aliases, including weakref, break alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

   What|Removed |Added

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

[Bug middle-end/68832] FAIL: gcc.c-torture/execute/alias-2.c -O1 execution test

2015-12-16 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68832

--- Comment #5 from Jan Hubicka  ---
I will take a look. Seems something still needs update for alias.

[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects

2015-12-16 Thread basil at list dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948

--- Comment #1 from Vasily Sukhanov  ---
Created attachment 37051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37051=edit
compressed preprocessed file

I had to compress the file to fit into 1M.

[Bug ipa/68930] Aggregate replacements not applied to inline function bodies.

2015-12-16 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930

--- Comment #7 from rguenther at suse dot de  ---
On December 16, 2015 7:28:35 PM GMT+01:00, hubicka at ucw dot cz
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
>
>--- Comment #6 from Jan Hubicka  ---
>For the Martin's answer.  I poked about this a bit.
>One can add call to node->get_body to the end of
>cgraph_materialize_clone which
>after removing the associated assert will call to the ipa-prop
>transform
>method.  It will also call inliner's transform which will in turn
>remove the
>cgraph and break.
>
>I suppose I can fix this by making IPA transforms function speicfic
>(they
>should
>be) and making inliner to only drop its transform method on functions
>non-inline
>functions and make ipa-cp add transforms only to the clones.  It should
>improve
>compile time, too.
>
>Still we will get missed optimizations, so keeping this info for GVN
>seems like
>resonable thing to do.

If the information is there in some way then I can try using it from GVN. just
tell me where it is.

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

2015-12-16 Thread alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707

--- Comment #18 from alalaw01 at gcc dot gnu.org ---
Well, we've seen this patch fix some of the vectorizer performance regressions
we've had on some benchmarks.

On SPEC...the "SLP cancelled" case triggers all over the place, but in most of
those cases, doesn't lead to any codegen difference. (Presumably SLP would have
failed anyway for some other reason, e.g. costs, and either we generate
load/store-lanes either way, or we still *can't* generate load/store-lanes...).
The only sub-benchmark where codegen changes is facerec, where we seem to
*lose* st2 rather than gainthis needs more analysis.

[Bug tree-optimization/68946] [6 Regression] ICE at -O3 on x86_64-linux-gnu in both 32- and 64-bit modes (in vect_analyze_stmt, at tree-vect-stmts.c:8013)

2015-12-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68946

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -O3 on   |[6 Regression] ICE at -O3
   |x86_64-linux-gnu in both|on x86_64-linux-gnu in both
   |32- and 64-bit modes (in|32- and 64-bit modes (in
   |vect_analyze_stmt, at   |vect_analyze_stmt, at
   |tree-vect-stmts.c:8013) |tree-vect-stmts.c:8013)
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with

commit 6d37c1112ee274824159e7697fc5e216b9222e0f
Author: rguenth 
Date:   Mon Dec 14 15:26:24 2015 +

2015-12-14  Richard Biener  

PR tree-optimization/68852
* tree-vectorizer.h (struct _slp_tree): Add def_type member.
(SLP_TREE_DEF_TYPE): New accessor.
* tree-vect-stmts.c (vect_is_simple_use): Remove BB vectorization
hack.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_DEF_TYPE.
(vect_build_slp_tree): When a node is to be built up from scalars
do not push a NULL as child but instead set its def_type to
vect_external_def.
(vect_analyze_slp_cost_1): Check for child def-type instead
of NULL.
(vect_detect_hybrid_slp_stmts): Likewise.
(vect_bb_slp_scalar_cost): Likewise.
(vect_get_slp_defs): Likewise.
(vect_slp_analyze_node_operations): Likewise.  Before
processing node push the children def-types to the underlying
stmts vinfo and restore it afterwards.
(vect_schedule_slp_instance): Likewise.
(vect_slp_analyze_bb_1): Do not mark stmts not in SLP instances
as not vectorizable.

* g++.dg/torture/pr68852.C: New testcase.


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

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

2015-12-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68937

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37053|0   |1
is obsolete||

--- Comment #8 from H.J. Lu  ---
Created attachment 37054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37054=edit
A patch

I am testing this.

[Bug c/68162] [5 Regression] Incompatible pointer type using a typedef

2015-12-16 Thread jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #20 from Joseph S. Myers  ---
Fixed for 5.4 and 6.

[Bug target/68872] -mcpu=powerpc64le does not pass -mpower8 to gas

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68872

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug libfortran/68867] numeric formatting problem in the fortran library

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867

--- Comment #16 from Bill Schmidt  ---
Hm, but comment #8 from PR24685 indicates that this is clearly a regression. 
At that time Andrew Pinski asserted that this failure was restricted to Darwin,
and powerpc*-linux didn't fail the test.

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/68532] [ARM] Incorrect code result on arm big endian

2015-12-16 Thread cbaylis at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01644.html

[Bug target/68945] New: RFE: enable libcilkrts on SPARC [ patch included ]

2015-12-16 Thread stefan.teleman at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945

Bug ID: 68945
   Summary: RFE: enable libcilkrts on SPARC [ patch included ]
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan.teleman at oracle dot com
  Target Milestone: ---

Hi.

I would like to submit a patch for enabling libcilkrts on SPARC.

The patch is based on GCC 4.9.3.

With this patch, the libcilkrts test harness passes 100% on SPARC.

[Bug rtl-optimization/68947] New: CFG expansion computes incorrect frequencies with -ftree-parallelize-loops=4

2015-12-16 Thread kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68947

Bug ID: 68947
   Summary: CFG expansion computes incorrect frequencies with
-ftree-parallelize-loops=4
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

Consider the existing test program: testsuite/gcc.d/torture/pr52429.c

Compile with options -S -O3 -ftree-parallelize-loops=4 -S -m64 -da -o pr52429.s

Examine the control-flow-graph represented at the end of the generated dump
file pr52429.c.205r.expand, starting with the label:

;; Full RTL generated for this function

The control-flow graph consists of the following blocks

bb2: 0 -> bb4 (75%), bb9(25%)
bb4: 80 -> bb5 (0%), bb6(100%)
bb9: 80 -> bb4(100%)
bb5: 80 -> bb10(100%)
bb6: 80 -> bb7(100%)
bb7: 7920 -> bb7(100%), bb8(0%)
bb8: 0 -> bb10(100%)
bb10: 0

In order of "decreasing significance", the problems with the frequency values
associated with each basic block are that:

1. The loop comprised of bb7 has an incoming frequency of 80, but an outgoing
frequency of 0.  For every loop, the sum of incoming edge frequencies should
equal the sum of outgoing edge frequencies.

2. bb9, which is reached with 25% probability from bb2, has frequency 80.  But
bb2 has frequency 0.  25% of 0 is 0.

3. bb5, which is reached with 0% probability from bb4, has frequency 80.  It
should have frequency 0, since 0% of 80 is 0.

4. bb10, which is reached with 100% probability from bb8 and with 100%
probability from bb5, should have frequency 80 instead of 0.  That's because
100% of 80 is 80.

[Bug c/66208] macro location not detected

2015-12-16 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66208

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bernd Schmidt  ---
Working on it.

[Bug ipa/68930] Aggregate replacements not applied to inline function bodies.

2015-12-16 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930

--- Comment #5 from Jan Hubicka  ---
> But how would you represent this info?  I don't see how it's going to
> do better than the inliner inserting an extra initialization (of course
> that might stay around if there are no cleanup opportunities and actually
> make the code bigger & slower)

Just keep the existing transformation data used by ipcp_modif_dom_walker
and feed it into GVN at entry block.

Consider code:

foo (struct a)
{
  struct b=a;
  return b.a;
}

this is a common case of post inlining code.  Now the way ipa-prop works if we
figure out that b.a=1 it won't update the copy b=a because it is not access to
the field it knows value of so no transformation happens.
GVN will figure out that the return is equivalent to a.a and if it knew that
a.a==1
it would optimize the code.

It is quite important bug that we work hard to figure out all those constants
and
then we drop them to the floor :)

Honza

[Bug c++/68309] [5/6 Regression] ICE: Segmentation fault

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68309

--- Comment #7 from Jason Merrill  ---
(In reply to Jason Merrill from comment #6)
>   * pt.c (instantiate_decl): Revert earlier change.

The bug is now fixed by the patch for 63628.

[Bug target/32429] [PPC, missing optimization] stack space not optimized when stack not used

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32429

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #2 from Bill Schmidt  ---
Judging from Pat's comment, I believe this can be closed.  Correct?

[Bug c/64637] Incorrect location for -Wunused-value warnings in for-loop

2015-12-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64637

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

2015-12-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

--- Comment #3 from Jonathan Wakely  ---
(In reply to Philipp Ochsendorf from comment #0)
> I think the following decision is too restrictive:
> 
> return std::__uninitialized_copy<__is_trivial(_ValueType1)
> && __is_trivial(_ValueType2)
> && __assignable>::
>   __uninit_copy(__first, __last, __result);
> 
> (cf. stl_uninitialized.h:123ff). The following should be sufficient:
> 
> return std::__uninitialized_copy && is_trivially_copyable(_ValueType2)
> && __assignable>::
>   __uninit_copy(__first, __last, __result);
> 
> Found this in 5.2.0 and 6.0. Probably it's in versions prior to 5.2.0 as
> well.

This is not OK. It would do the wrong thing for:

struct X { X() { } };

That type is not trivial, and so in uninitialized_copy we loop and invoke copy
constructors to initialize each element. Everything is good.

With the suggestion above we would start using std::copy, which would just use
assignment to copy objects, but no constructor would ever have run so the
object's lifetime would not have started, and we'd be doing an assignment
(admittedly a trivial one, but that doesn't matter) to raw memory, not an
object.

Ville is working on a correct fix, but it is much more involved than just
changing the condition shown above.

[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes

2015-12-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Wed Dec 16 17:09:47 2015
New Revision: 231701

URL: https://gcc.gnu.org/viewcvs?rev=231701=gcc=rev
Log:
Fix ambiguity with multiple enable_shared_from_this bases

PR libstdc++/56383
* testsuite/20_util/enable_shared_from_this/56383.cc: New.
* include/bits/shared_ptr_base.h (__enable_shared_from_this): Make
friend declaration match previous declaration of
__enable_shared_from_this_helper.
* include/bits/shared_ptr.h (enable_shared_from_this): Likewise.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/enable_shared_from_this/56383.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/shared_ptr.h
branches/gcc-4_9-branch/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug objc/68943] New: GCC should support nullable and nonnull

2015-12-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68943

Bug ID: 68943
   Summary: GCC should support nullable and nonnull
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin15.2.0
Target: x86_64-apple-darwin15.2.0
 Build: x86_64-apple-darwin15.2.0

A couple of Objectiv-C and Objective-C++ tests are FAILing on Mac OS X 10.11.2
like this:

FAIL: objc.dg/encode-7-next-64bit.m -fnext-runtime (test for excess errors)
Excess errors:
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:19:21:
error: unknown type name 'nullable'

https://developer.apple.com/swift/blog/?id=25

  Rainer

[Bug target/67808] LRA ICEs on simple double to long double conversion test case

2015-12-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67808

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  ---
(In reply to Bernd Schmidt from comment #5)
> Can this be closed?

Confirmed fixed.

[Bug ipa/68930] Aggregate replacements not applied to inline function bodies.

2015-12-16 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930

--- Comment #6 from Jan Hubicka  ---
For the Martin's answer.  I poked about this a bit.
One can add call to node->get_body to the end of cgraph_materialize_clone which
after removing the associated assert will call to the ipa-prop transform
method.  It will also call inliner's transform which will in turn remove the
cgraph and break.

I suppose I can fix this by making IPA transforms function speicfic (they
should
be) and making inliner to only drop its transform method on functions
non-inline
functions and make ipa-cp add transforms only to the clones.  It should improve
compile time, too.

Still we will get missed optimizations, so keeping this info for GVN seems like
resonable thing to do.

[Bug c++/68309] [5/6 Regression] ICE: Segmentation fault

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68309

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc

2015-12-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053

--- Comment #15 from Peter Bergner  ---
(In reply to Bill Schmidt from comment #14)
> (In reply to Alan Modra from comment #13)
> > Created attachment 29382 [details]
> > Fix
> 
> Alan, did this make it upstream?  Can this be closed?

Looking at trunk, no, this change is not upstream yet.

[Bug rtl-optimization/67201] PowerPC -mlra hits ICE: Max. number of generated reload insns per insn is achieved

2015-12-16 Thread meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67201

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||meissner at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Michael Meissner  ---
Fixed in October 2 on the trunk, and November 11th on the GCC 5 branch.

[Bug c++/68942] New: overly strict use of deleted function before argument-dependent lookup (ADL)

2015-12-16 Thread lucdanton at free dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942

Bug ID: 68942
   Summary: overly strict use of deleted function before
argument-dependent lookup (ADL)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

Tested on 5.2.0, 5.2.1 and 6.

I believe the testcase is incorrectly rejected. Clang accepts the program. Note
that leaving void foo(int); undefined, rather than defined as deleted, lets GCC
accept the program.

$ g++-trunk -std=c++14 main.cpp
main.cpp: In function 'void lookup(X)':
main.cpp:5:3: error: use of deleted function 'void foo(int)'
 { foo(x); }
   ^~~

main.cpp:1:6: note: declared here
 void foo(int) = delete;
  ^~~

$ cat main.cpp
void foo(int) = delete;

template
void lookup(X x)
{ foo(x); }

namespace ns {

struct dummy {};
int foo(dummy) { return 3; }

} // ns

int main()
{
lookup(ns::dummy {});
}

[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)

2015-12-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-16
 Ever confirmed|0   |1

[Bug libfortran/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

2015-12-16 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743

--- Comment #25 from dave.anglin at bell dot net ---
On 2015-12-16 12:12 PM, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
>
> --- Comment #24 from joseph at codesourcery dot com  dot com> ---
> The transformation that generates floorf calls should not happen if the
> TARGET_LIBC_HAS_FUNCTION says that the target does not have that function.
> You should fix either the definition of TARGET_LIBC_HAS_FUNCTION or the
> logic that should be checking it, rather than working around it in
> libgfortran.
I agree and have been looking at it this morning.  We have
#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
in pa-hpux.h.  Thus, IMPLICIT should be false for BUILT_IN_FLOORF.

So, I think a check is missing.

[Bug c/68946] New: ICE at -O3 on x86_64-linux-gnu in both 32- and 64-bit modes (in vect_analyze_stmt, at tree-vect-stmts.c:8013)

2015-12-16 Thread chengniansun at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68946

Bug ID: 68946
   Summary: ICE at -O3 on x86_64-linux-gnu in both 32- and 64-bit
modes (in vect_analyze_stmt, at
tree-vect-stmts.c:8013)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk on x86_64-linux-gnu at -O3 in both 32-bit
and 64-bit modes. 

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151216 (experimental) [trunk revision 231674] (GCC) 
$: 
$: gcc-trunk -w -m64 small.c -O3
small.c: In function ‘fn1’:
small.c:4:6: internal compiler error: in vect_analyze_stmt, at
tree-vect-stmts.c:8013
 void fn1() {
  ^~~

0xd21f9d vect_analyze_stmt(gimple*, bool*, _slp_tree*)
../../gcc-trunk/gcc/tree-vect-stmts.c:8013
0xd3bd6a vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2219
0xd3bc53 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2203
0xd3bc53 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2203
0xd3bc53 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2203
0xd3cd74 vect_slp_analyze_operations(vec<_slp_instance*, va_heap, vl_ptr>,
void*)
../../gcc-trunk/gcc/tree-vect-slp.c:2251
0xd41f10 vect_slp_analyze_bb_1
../../gcc-trunk/gcc/tree-vect-slp.c:2525
0xd41f10 vect_slp_bb(basic_block_def*)
../../gcc-trunk/gcc/tree-vect-slp.c:2612
0xd44335 execute
../../gcc-trunk/gcc/tree-vectorizer.c:759
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-trunk -w -m32 small.c -O3
small.c: In function ‘fn1’:
small.c:4:6: internal compiler error: in vect_analyze_stmt, at
tree-vect-stmts.c:8013
 void fn1() {
  ^~~

0xd21f9d vect_analyze_stmt(gimple*, bool*, _slp_tree*)
../../gcc-trunk/gcc/tree-vect-stmts.c:8013
0xd3bd6a vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2219
0xd3bc53 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2203
0xd3bc53 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2203
0xd3bc53 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.c:2203
0xd3cd74 vect_slp_analyze_operations(vec<_slp_instance*, va_heap, vl_ptr>,
void*)
../../gcc-trunk/gcc/tree-vect-slp.c:2251
0xd41f10 vect_slp_analyze_bb_1
../../gcc-trunk/gcc/tree-vect-slp.c:2525
0xd41f10 vect_slp_bb(basic_block_def*)
../../gcc-trunk/gcc/tree-vect-slp.c:2612
0xd44335 execute
../../gcc-trunk/gcc/tree-vectorizer.c:759
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.
$: 
$: cat small.c
int a, b, g;
short c, e, h, i;
int f[8];
void fn1() {
  short j;
  for (; a;) {
printf("%d", g);
b = 7;
for (; b >= 0; b--) {
  i = 1;
  short k = f[b];
  e = k ? k : 3;
  j = (i && (c |= e)) << 3;
  int l = j, m = 0;
  h = l < 0 || l >> m;
  f[b] = h;
}
  }
}

[Bug libstdc++/68912] Wrong value category used in _Bind functor

2015-12-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68912

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.4
  Known to fail||4.9.3, 5.3.0

--- Comment #4 from Jonathan Wakely  ---
Fixed for 4.9.4 and 5.4

[Bug libfortran/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

2015-12-16 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743

--- Comment #24 from joseph at codesourcery dot com  ---
The transformation that generates floorf calls should not happen if the 
TARGET_LIBC_HAS_FUNCTION says that the target does not have that function.  
You should fix either the definition of TARGET_LIBC_HAS_FUNCTION or the 
logic that should be checking it, rather than working around it in 
libgfortran.

[Bug objc/68944] New: Testsuite failures due to objc_object::isa deprecation

2015-12-16 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68944

Bug ID: 68944
   Summary: Testsuite failures due to objc_object::isa deprecation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin15.2.0
Target: x86_64-apple-darwin15.2.0
 Build: x86_64-apple-darwin15.2.0

Several Objective-C and Objective-C++ testcases FAIL like this:

FAIL: obj-c++.dg/isa-field-1.mm -fnext-runtime (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/obj-c++.dg/isa-field-1.mm:19:25:
warning: 'objc_object::isa' is deprecated [-Wdeprecated-declarations]

   has

/// Represents an instance of a class.
struct objc_object {
Class isa  OBJC_ISA_AVAILABILITY;
};

   has

/* OBJC_ISA_AVAILABILITY: `isa` will be deprecated or unavailable 
 * in the future */
#if !defined(OBJC_ISA_AVAILABILITY)
#   if __OBJC2__
#   define OBJC_ISA_AVAILABILITY  __attribute__((deprecated))
#   else
#   define OBJC_ISA_AVAILABILITY  /* still available */
#   endif
#endif

  Rainer

[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

2015-12-16 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68256

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|6.0 |7.0
Summary|[6 regression] switching|Defining
   |constant pools to rodata|TARGET_USE_CONSTANT_BLOCKS_
   |sections causes go  |P causes go bootstrap
   |bootstrap failure.  |failure on aarch64.

--- Comment #4 from Ramana Radhakrishnan  ---
The issue of the bootstrap failure with the change in
aarch64_use_constant_blocks_p remains but this is no longer a 6 regression.
That can now get pushed out to 7.0 as I would neither have the time nor do I
feel comfortable about getting that fixed for 6.0.

[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #14 from Bill Schmidt  ---
(In reply to Alan Modra from comment #13)
> Created attachment 29382 [details]
> Fix

Alan, did this make it upstream?  Can this be closed?

[Bug c/64637] Incorrect location for -Wunused-value warnings in for-loop

2015-12-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64637

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Dec 16 16:50:07 2015
New Revision: 231700

URL: https://gcc.gnu.org/viewcvs?rev=231700=gcc=rev
Log:
PR c/64637
* c-typeck.c (c_process_expr_stmt): Use location of the expression if
available.

* gcc.dg/pr64637.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr64637.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/68912] Wrong value category used in _Bind functor

2015-12-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68912

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Dec 16 17:09:52 2015
New Revision: 231702

URL: https://gcc.gnu.org/viewcvs?rev=231702=gcc=rev
Log:
Fix cv-qualifiers in std::bind invocation

PR libstdc++/68912
* include/std/functional (_Bind::operator()): Use lvalue functor to
deduce return type.
* testsuite/20_util/bind/68912.cc: New.

Added:
branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/bind/68912.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/std/functional

[Bug fortran/68940] -Wno-error=compare-reals not working

2015-12-16 Thread jahns at dkrz dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68940

--- Comment #1 from Thomas Jahns  ---
Just noticed the same applies to -Wunused-parameter.

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

2015-12-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68937

--- Comment #4 from H.J. Lu  ---
sibcall_memory_operand shouldn't allow any callee-saved registers
as GOT base register since they must be restored before return.

[Bug c++/63628] [c++1y] cannot use decltype on captured arg-pack

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628

--- Comment #7 from Jason Merrill  ---
*** Bug 61814 has been marked as a duplicate of this bug. ***

[Bug c++/54367] [meta-bug] lambda expressions

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 61814, which changed state.

Bug 61814 Summary: [c++1y] cannot use decltype on captured variable in generic 
lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814

   What|Removed |Added

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

[Bug c++/63628] [c++1y] cannot use decltype on captured arg-pack

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/61814] [c++1y] cannot use decltype on captured variable in generic lambda

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814

Jason Merrill  changed:

   What|Removed |Added

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

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

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

[Bug c++/63628] [c++1y] cannot use decltype on captured arg-pack

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Wed Dec 16 18:36:55 2015
New Revision: 231715

URL: https://gcc.gnu.org/viewcvs?rev=231715=gcc=rev
Log:
PR c++/63628
* pt.c (tsubst_pack_expansion): Also make dummy decls if
retrieve_local_specialization fails.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug target/64783] -march=armv8.1-a should be supported

2015-12-16 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed for GCC 6.0

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

2015-12-16 Thread ville.voutilainen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

Ville Voutilainen  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
   Severity|normal  |enhancement

--- Comment #4 from Ville Voutilainen  ---
To elaborate on what Jonathan said: std::uninitialized_copy currently calls
std::copy for the trivial cases. std::copy should require assignability;
std::unitialized_copy wouldn't need to. We need to introduce a new low-level
function that does not perform the check, so that std::uninitialized_copy can
call it directly and std::copy can call it with a check. Furthermore, there
is a similar-ish optimization opportunity for std::uninitialized_fill and
std::uninitialized_fill_n (which currently call std::fill and std::fill_n, 
which should perform extra checks), those functions
would also benefit from yet another new low-level function.

After discussing this with Jonathan, we deemed it unsuitable for Stage 3.
I'll get back on this after we get to Stage 1 for gcc 7, chances are of course
that we can backport when the time comes.

Setting target milestone to 7 and changing importance to enhancement.

[Bug target/67808] LRA ICEs on simple double to long double conversion test case

2015-12-16 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67808

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Peter Bergner  ---
Closing as fixed.

[Bug c++/63628] [c++1y] cannot use decltype on captured arg-pack

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Dec 16 18:22:17 2015
New Revision: 231713

URL: https://gcc.gnu.org/viewcvs?rev=231713=gcc=rev
Log:
PR c++/63628
* pt.c (tsubst_pack_expansion): Also make dummy decls if
retrieve_local_specialization fails.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/68309] [5/6 Regression] ICE: Segmentation fault

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68309

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Dec 16 18:22:23 2015
New Revision: 231714

URL: https://gcc.gnu.org/viewcvs?rev=231714=gcc=rev
Log:
PR c++/68309
* pt.c (instantiate_decl): Revert earlier change.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/54367] [meta-bug] lambda expressions

2015-12-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 63628, which changed state.

Bug 63628 Summary: [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628

   What|Removed |Added

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

[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)

2015-12-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68937

--- Comment #5 from H.J. Lu  ---
Created attachment 37049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37049=edit
A patch for sibcall_memory_operand

[Bug target/68945] RFE: enable libcilkrts on SPARC [ patch included ]

2015-12-16 Thread stefan.teleman at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945

Stefan Teleman  changed:

   What|Removed |Added

 CC||stefan.teleman at oracle dot 
com

--- Comment #1 from Stefan Teleman  ---
Created attachment 37050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37050=edit
enable libcilkrts on SPARC

[Bug target/68928] AVX loops on unaligned arrays could generate more efficient startup/cleanup code when peeling

2015-12-16 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68928

--- Comment #2 from Peter Cordes  ---
Richard wrote: 
> [...] avoid peeling for alignment on x86_64 and just use unaligned ops

Yeah, that's what clang does, and may be optimal.  Certainly it's easy, and
gives optimal performance when buffers *are* in fact aligned, even when the
programmer has neglected to inform the compiler of any guarantee.

However, with vector sizes getting closer to the cache-line size, unaligned
accesses will cross cache lines more of the time.  (e.g. an AVX loop over an
unaligned buffer will have a cacheline split on every other iteration).  Iff we
can *cheaply* avoid this, it may be worth it.

IIRC, all modern x86 / x86-64 CPUs have no penalty for unaligned loads, as long
as they don't actually cross a cache-line boundary.  (True for Intel since
Nehalem).  Store-forwarding doesn't work well if the stores don't line up with
the loads, though.

[Bug other/68813] [openacc] lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c

2015-12-16 Thread cesar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68813

cesar at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-16
 CC||cesar at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |cesar at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from cesar at gcc dot gnu.org ---
(In reply to vries from comment #1)
> Related discussion: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02076.html

I think that's more of a band-aid rather than a proper fix. But I suspect that
patch will still come in handy for routines. 

For some reason, reductions don't like firstprivate variables in fortran. I
tried a similar test in gcc and g++, and neither of those compilers ICE'd. You
can also reduce this test case a little bit by removing the array 'a' and
replacing the reduction with 'sum = sum + 1'. 

I'll work on this.

[Bug libfortran/68867] numeric formatting problem in the fortran library

2015-12-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867

--- Comment #20 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #19)
> (In reply to Bill Seurer from comment #12)
> 
> > I checked with the revision previous to this patch and the revision for this
> > patch and the only differences were fmt_g0_7 succeeding and
> > default_format_denormal_2 failing.
> 
> Sorry about that Bill, I missed that in my testing, there are other tests
> already failing and I thought it was one of those.  All the patch did was
> decrease the width of the default format, in other words, the width chosen
> when none is specified by the user.  The patch changed nothing
> computationaly speaking.
> 
> I will take a look at this default_format_denormal_2 and see.  It should
> just be a minor adjustment of the test itself.  Let me know if you see any
> thing else.

OK, the failing of default_format_denormal_2 has nothing to do with this PR or
formatting for printing of floating point numbers.  It has to do with internal
representations.  I believe that Steve is correct and the test should be
XFailed for all PowerPC.  It is already { xfail powerpc*-apple-darwin* }

[Bug c++/68949] New: [5.? Regression] Implicit initialization of array member silently miscompiling.

2015-12-16 Thread woutershep at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68949

Bug ID: 68949
   Summary: [5.? Regression] Implicit initialization of array
member silently miscompiling.
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: woutershep at gmail dot com
  Target Milestone: ---

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

Hello, i believe that i have found a bug in gcc. This is my first time
submitting a bug to this project so if i'm missing something important please
let me know so i can provide it. I've tried to follow the guidelines best i
could.

More specifically, i think there is a bug in the way it handles the implicit
default initialization of an array member when that member has a constexpr
constructor and a non-inline move constructor that delegates.

I can imagine that doesn't really paint a clear picture so ill just let the
code do the talking instead:

"""
// % $CXX -std=c++11 -Wall -Wextra -o zero zero.cc && ./zero; echo $?
//
// expected return
// return of g++ 4.9.2
// return of clang++ 3.7.0
// 0
//
// return of g++ 5.2.0
// return of g++ 5.3.0
// 1

struct Sub {
int i;

constexpr Sub() : i(-1) {} // remove constexpr and it works as expected
Sub(Sub&& rhs); // remove this constructor and it works as epxected.
};

// v-- move this inline and it works as expected
// v-- remove ': Sub()' and it works as expected
Sub::Sub(Sub&& rhs) : Sub() { int tmp = i; i = rhs.i; rhs.i = tmp; }

struct Class {
// v-- remove '[1]' and it works as expected
// v-- add '= {}' and it works as expected
Sub s[1];

// v-- add ': s{}' and it works as expected
// v-- removing this constructor makes it work as expected
Class() {}
};

int main() {
Class c;
return c.s[0].i != -1;
}
"""

Instead of the expected '-1', 'i' is actually '0' on 5.2 and 5.3 causing it to
return 1 on those.

Ive attached the .ii that this file produced. And for completion here is the -v
output of the gcc's i had at my disposal (the gcc-5.2 behavior was given by
someone else):

% x86_64-pc-linux-gnu-gcc-5.1 -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-gcc-5.1
COLLECT_LTO_WRAPPER=/usr/x86_64-pc-linux-gnu/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/paludis/build/sys-devel-gcc-5.3.0/work/gcc-5.3.0/configure
--cache-file=config.cache --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/usr/x86_64-pc-linux-gnu --datarootdir=/usr/share --localstatedir=/var
--sysconfdir=/etc --disable-dependency-tracking --enable-fast-install
--enable-serial-configure --disable-bootstrap --disable-decimal-float
--disable-install-libiberty --disable-libada --disable-libatomic
--disable-libcilkrts --disable-libffi --disable-libgfortran --disable-libgo
--disable-libgomp --disable-libitm --disable-libjava --disable-libmpx
--disable-libobjc --disable-liboffloadmic --disable-libquadmath
--disable-libsanitizer --disable-libssp --disable-libstdcxx
--disable-libstdc++-v3 --disable-libvtv --disable-vtable-verify
--disable-multilib --disable-nls --disable-shared --enable-lto --disable-plugin
--enable-threads --enable-languages=c,c++,fortran,objc,obj-c++ --with-sysroot=
--with-gxx-include-dir=/usr/x86_64-pc-linux-gnu/include/c++/5.3.0 --with-isl
--program-transform='s,$,-5.1,' --with-lib-path=/usr/x86_64-pc-linux-gnu/lib
--with-as=/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-as
--with-ld=/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld
--with-system-zlib --with-glibc-version=2.11 --enable-linker-build-id
--with-multilib-list=
Thread model: posix
gcc version 5.3.0 (GCC)

% x86_64-pc-linux-gnu-gcc-4.9 -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-gcc-4.9
COLLECT_LTO_WRAPPER=/usr/x86_64-pc-linux-gnu/libexec/gcc/x86_64-pc-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/paludis/build/sys-devel-gcc-4.9.2-r11/work/gcc-4.9.2/configure
--cache-file=config.cache --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/usr/x86_64-pc-linux-gnu --datarootdir=/usr/share --localstatedir=/var
--sysconfdir=/etc --disable-dependency-tracking --enable-fast-install
--enable-serial-configure --disable-bootstrap --disable-decimal-float
--disable-install-libiberty --disable-libada --disable-libatomic
--disable-libcilkrts --disable-libffi --disable-libgfortran --disable-libgo
--disable-libgomp --disable-libitm --disable-libjava --disable-libobjc
--disable-libquadmath --disable-libsanitizer --disable-libssp
--disable-libstdcxx --disable-libstdc++-v3 --disable-libvtv
--disable-vtable-verify --disable-multilib --disable-nls --disable-shared
--enable-lto --disable-plugin --enable-threads

[Bug libfortran/68867] numeric formatting problem in the fortran library

2015-12-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867

--- Comment #19 from Jerry DeLisle  ---
(In reply to Bill Seurer from comment #12)

> I checked with the revision previous to this patch and the revision for this
> patch and the only differences were fmt_g0_7 succeeding and
> default_format_denormal_2 failing.

Sorry about that Bill, I missed that in my testing, there are other tests
already failing and I thought it was one of those.  All the patch did was
decrease the width of the default format, in other words, the width chosen when
none is specified by the user.  The patch changed nothing computationaly
speaking.

I will take a look at this default_format_denormal_2 and see.  It should just
be a minor adjustment of the test itself.  Let me know if you see any thing
else.

[Bug target/32429] [PPC, missing optimization] stack space not optimized when stack not used

2015-12-16 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32429

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #3 from Pat Haugen  ---
Fixed quite a while ago.

[Bug middle-end/32401] [PPC/Altivec] Non optimal code structure with -mabi=altivec

2015-12-16 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32401
Bug 32401 depends on bug 32429, which changed state.

Bug 32429 Summary: [PPC, missing optimization] stack space not optimized when 
stack not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32429

   What|Removed |Added

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

[Bug c++/68949] [5.? Regression] Implicit initialization of array member silently miscompiling.

2015-12-16 Thread woutershep at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68949

--- Comment #1 from Wouter van Kesteren  ---
Created attachment 37057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37057=edit
cc

[Bug libfortran/68867] numeric formatting problem in the fortran library

2015-12-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867

--- Comment #21 from Jerry DeLisle  ---
Just to be double sure, I reverted my patch on the PowerPC I use for testing
and see that default_format_denormal_2.f90 fails regardless, so this is a
separate issue from this PR.  I think xfailing the test is valid since it
really is not a gfortran issue.

[Bug libfortran/68867] numeric formatting problem in the fortran library

2015-12-16 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867

--- Comment #17 from Steve Kargl  ---
On Wed, Dec 16, 2015 at 08:52:19PM +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
> 
> --- Comment #16 from Bill Schmidt  ---
> Hm, but comment #8 from PR24685 indicates that this is clearly a regression. 
> At that time Andrew Pinski asserted that this failure was restricted to 
> Darwin,
> and powerpc*-linux didn't fail the test.
> 

I prefer the sentiments of comment #2 from PR61399.

Perhaps, the test passed on powerpc*-linux because
it was a poorly defined test for that target and
ppc*linux got lucky.

But, I'll restate the obvious from my comment #15.

   Given the lack of details regarding the nature
   of the failure, xfailing the testcase is the
   only option.

Or in other words, we can't fix something that is
poorly defined.  So, the only solution is to sweep it
under the rug.

[Bug tree-optimization/68892] [6 Regression] Excessive dead loads produced by BB vectorization

2015-12-16 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68892

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #4 from Bill Seurer  ---
That fix broke the test case pr60203.c.

PASS: gcc.target/powerpc/pr60203.c (test for excess errors)
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not stfd
FAIL: gcc.target/powerpc/pr60203.c scan-assembler-not lfd
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not lxsdx
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not stxsdx
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not mfvsrd
PASS: gcc.target/powerpc/pr60203.c scan-assembler-not mtvsrd

There are two lfds and lots of other ops in the generated code with the fix

pack:
xxpermdi 0,2,1,0
addi 9,1,-16
xxpermdi 0,0,0,2
stxvd2x 0,0,9
lfd 1,-16(1)
lfd 2,-8(1)
blr

and none without

pack:
blr

Compiled with  -mcpu=power8 -O3.

[Bug lto/68685] LTO build hits ICE in copy_to_mode_reg, at explow.c:595

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/68690] PowerPC64: TOC save in PHP core loop results in load hit store

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68690

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug lto/67548] [5 Regression] LTO drops weak binding with "ld -r"

2015-12-16 Thread belagod at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548

--- Comment #14 from Tejas Belagod  ---
Author: belagod
Date: Wed Dec 16 22:33:51 2015
New Revision: 231724

URL: https://gcc.gnu.org/viewcvs?rev=231724=gcc=rev
Log:
Backport from Mainline
PR lto/67548
* lto-plugin.c (linker_output, linker_output_set): New statics.
(all_symbols_read_handler): Add -flinker-output option.
(onload): Record linker_output info.

* ipa-visibility.c (cgraph_externally_visible_p,
varpool_node::externally_visible_p): When doing incremental linking,
hidden symbols may be still used later.
(update_visibility_by_resolution_info): Do not drop weak during
incremental link.
(function_and_variable_visibility): Fix formating.
* flag-types.h (lto_linker_output): Declare.
* common.opt 9flag_incremental_link): New flag.

* lto-lang.c (lto_post_options): Process flag_lto_linker_output.
* lang.opt (lto_linker_output): New enum.
(flinker_output): New flag.


Added:
branches/ARM/embedded-5-branch/gcc/lto/ChangeLog.arm
branches/ARM/embedded-5-branch/lto-plugin/ChangeLog.arm
Modified:
branches/ARM/embedded-5-branch/gcc/ChangeLog.arm
branches/ARM/embedded-5-branch/gcc/common.opt
branches/ARM/embedded-5-branch/gcc/flag-types.h
branches/ARM/embedded-5-branch/gcc/ipa-visibility.c
branches/ARM/embedded-5-branch/gcc/lto/lang.opt
branches/ARM/embedded-5-branch/gcc/lto/lto-lang.c
branches/ARM/embedded-5-branch/lto-plugin/lto-plugin.c

[Bug objc++/68932] FAIL: obj-c++.dg/property/at-property-23.mm -fgnu-runtime (internal compiler error)

2015-12-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68932

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-16
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug objc++/68932] FAIL: obj-c++.dg/property/at-property-23.mm -fgnu-runtime (internal compiler error)

2015-12-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68932

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed in r231726.

[Bug objc++/68932] FAIL: obj-c++.dg/property/at-property-23.mm -fgnu-runtime (internal compiler error)

2015-12-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68932

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Wed Dec 16 23:56:27 2015
New Revision: 231726

URL: https://gcc.gnu.org/viewcvs?rev=231726=gcc=rev
Log:
PR objc++/68932  - FAIL: obj-c++.dg/property/at-property-23.mm -fgnu-runtime
   (internal compiler error)

cp/
* decl.c (grokdeclarator): Avoid assuming ctype is non-null when
checking the validity of a flexible array member.

testsuite/
* obj-c++.dg/property/at-property-23.mm: Remove check for
an error message.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/property/at-property-23.mm

[Bug libfortran/68867] numeric formatting problem in the fortran library

2015-12-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867

--- Comment #18 from Andrew Pinski  ---
(In reply to Bill Schmidt from comment #16)
> Hm, but comment #8 from PR24685 indicates that this is clearly a regression.
> At that time Andrew Pinski asserted that this failure was restricted to
> Darwin, and powerpc*-linux didn't fail the test.

That is because at the time (2006) powerpc*-linux* did not use 128bit long
double (double double); things changed around 2008 time frame.  So my comment
applies at the time I wrote it but the powerpc*-linux* targets changed after
that point.

[Bug target/68928] AVX loops on unaligned arrays could generate more efficient startup/cleanup code when peeling

2015-12-16 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68928

--- Comment #3 from Peter Cordes  ---
I posted this as a question on stackoverflow, and got some useful comments (and
had some ideas while writing up a mask-gen answer).

http://stackoverflow.com/questions/34306933/vectorizing-with-unaligned-buffers-using-vmaskmovps-generating-a-mask-from-a-m

Stephen Canon points out that VMASKMOVPS isn't actually useful: you can instead
use unaligned loads/stores for the peeled first/last iteration, and do
overlapping work.  You just have to make sure you load any data you need before
clobbering it.  I posted an answer using that idea, but I'm not sure if it's
the sort of thing a compiler could decide to use.


For reduction loops where we need to accumulate each element exactly once, a
mask is still useful, but we can use it for ANDPS / ANDNPS instead of VMASKMOV.

I improved the mask-generation to a single AVX2 VPMOVSXBD load (with 5 or 7
single-uop integer instructions to generate the index from the start/end
address).  VPCMPGT isn't needed: instead just use an index to take the right
window of bytes from memory.  This emulates a variable-count VPSLLDQ on a
buffer of all-ones.

This is something gcc could maybe use, but probably some experimental testing
to compare with just using unaligned is warranted before spending any time
implementing automatic generation of something complicated like this.

[Bug fortran/68950] New: [fortran] gfc_format_decoder cannot handle %qE

2015-12-16 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68950

Bug ID: 68950
   Summary: [fortran] gfc_format_decoder cannot handle %qE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I.

Consider test.f90:
...
subroutine bar ()
  implicit none
  !$acc routine nohost gang
end subroutine
...

When compiling with current gomp-4_0-branch, we run into an assert during
error:
...
$ ./lean-fortran/install/bin/gfortran test.f90 -O2 -fopenacc -S
‘
test.f90:1:0:

 subroutine bar ()


in pp_format, at pretty-print.c:635
0x1e3426e pp_format(pretty_printer*, text_info*)
src/gcc/pretty-print.c:635
0x1e2de0a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
src/gcc/diagnostic.c:797
0x1e2f0d7 error(char const*, ...)
src/gcc/diagnostic.c:1157
0x1eae569 decl_attributes(tree_node**, tree_node*, int)
src/gcc/attribs.c:450
0x842726 build_function_decl
src/gcc/fortran/trans-decl.c:2114
0x84506e gfc_create_function_decl(gfc_namespace*, bool)
src/gcc/fortran/trans-decl.c:2755
0x850b9b gfc_generate_function_code(gfc_namespace*)
src/gcc/fortran/trans-decl.c:5967
0x81885b gfc_generate_code(gfc_namespace*)
src/gcc/fortran/trans.c:1977
0x7ae412 translate_all_program_units
src/gcc/fortran/parse.c:5549
0x7aea6d gfc_parse_file()
src/gcc/fortran/parse.c:5755
0x802356 gfc_be_parse_file
src/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...


II.

The assert that triggers is:
...
(gdb) 
#5  0x01e3426f in pp_format (pp=0x2b85a80, text=0x7fffd310)
at
/home/vries/gcc_versions/devel/gomp-4_0-branch/src/gcc/pretty-print.c:635
635 gcc_assert (ok);
(gdb) l
630 bool ok;
631 
632 gcc_assert (pp_format_decoder (pp));
633 ok = pp_format_decoder (pp) (pp, text, p,
634  precision, wide, plus, hash);
635 gcc_assert (ok);
636   }
637 }
638 
639   if (quote)
...

The assert occurs when we trying to print this text:
...
(gdb) p *text
$1 = {format_spec = 0x25a0c20 "wrong number of arguments specified for %qE
attribute", args_ptr = 0x7fffd2f8, err_no = 0, 
  x_data = 0x7fffd340, m_richloc = 0x7fffd350}
...

Using this pretty-printer:
...
(gdb) p *pp
$2 = {_vptr.pretty_printer = 0x2570490 , buffer =
0x2b85ad0, prefix = 0x0, padding = pp_none, 
  maximum_length = 0, indent_skip = 0, wrapping = {rule =
DIAGNOSTICS_SHOW_PREFIX_NEVER, line_cutoff = 0}, 
  format_decoder = 0x73c23a , 
  emitted_prefix = false, need_newline = false, translate_identifiers = true,
show_color = true}
...


III.

The error message originates here:
...
  else if (list_length (args) < spec->min_length
   || (spec->max_length >= 0
   && list_length (args) > spec->max_length))
{
  error ("wrong number of arguments specified for %qE attribute",
 name);
  continue;
}
...

Because args is not null:
...
(gdb) call debug_generic_expr (args)
nohost
...

And the spec doesn't allow any args since min_length and max_length are 0:
...
(gdb) p *spec
$3 = {name = 0x1f013ac "omp declare target", min_length = 0, max_length = 0,
decl_required = true, type_required = false, 
  function_type_required = false, handler = 0x8022e7
, 
  affects_type_identity = false}
...

The error occurs because nohost support is not finished yet for fortran in
gomp-4_0-branch, but this PR is not about that.


IV.

The compiler shouldn't assert during printing the error message.

AFAIU, the assert happens because gfc_format_decoder can't handle %qE, it only
handles %C and %L.

So, it sound like gfc_format_decoder misses handling of %qE, which is also
missing in trunk, but not so easy to trigger there.

[Bug target/68664] PowerPC: speculative sqrt in c-ray main loop causes large slow down

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/67530] Failure to eliminate dead code produced by vector lowering

2015-12-16 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67530

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68892] [6 Regression] Excessive dead loads produced by BB vectorization

2015-12-16 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68892

--- Comment #5 from Bill Seurer  ---
It also causes an ice when I compile 20100610.c

seurer@genoa:~/tests/gcc$ ~/gcc/install/gcc-test3/bin/gcc -c -fgnu-tm -O3
20100610.c
In function 'TMelement_alloc':
cc1: internal compiler error: tree check: expected tree that contains 'decl
common' structure, have 'ssa_name' in prepare_gimple_addressable, at
gimplify.c:3308
0x10b42f0b tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/seurer/gcc/gcc-test3/gcc/tree.c:9778
0x10567f3f contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/seurer/gcc/gcc-test3/gcc/tree.h:3111
0x10567f3f prepare_gimple_addressable
/home/seurer/gcc/gcc-test3/gcc/gimplify.c:3308
0x1055ba37 gimplify_addr_expr
/home/seurer/gcc/gcc-test3/gcc/gimplify.c:5081
0x1055ba37 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/seurer/gcc/gcc-test3/gcc/gimplify.c:10162
0x1057b81b force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
/home/seurer/gcc/gcc-test3/gcc/gimplify-me.c:78
0x1057ba1f force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
/home/seurer/gcc/gcc-test3/gcc/gimplify-me.c:115
0x10838cf3 gimplify_addr
/home/seurer/gcc/gcc-test3/gcc/trans-mem.c:1183
0x10844153 expand_assign_tm
/home/seurer/gcc/gcc-test3/gcc/trans-mem.c:2330
0x1084560b expand_block_tm
/home/seurer/gcc/gcc-test3/gcc/trans-mem.c:2516
0x1084560b execute_tm_mark
/home/seurer/gcc/gcc-test3/gcc/trans-mem.c:3014
0x1084560b execute
/home/seurer/gcc/gcc-test3/gcc/trans-mem.c:3059

  1   2   3   >