[Bug target/63209] [ARM] Wrong conditional move generated

2014-09-09 Thread mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce the wrong-code with gcc-4.9 on armv5tel-linux-gnueabi.


[Bug testsuite/63211] New: gcc.target/i386/avx2-*.c tests use broken type-punning

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63211

Bug ID: 63211
   Summary: gcc.target/i386/avx2-*.c tests use broken type-punning
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Target: x86_64-*-*, i?86-*-*

For example gcc.target/i386/avx2-vpblendd128-2.c does

static void
init_pblendd128 (int *src1, int *src2, int seed)
{
  int i, sign = 1;

  for (i = 0; i < 4; i++)
{
  src1[i] = (i + seed) * (i + seed) * sign;
  src2[i] = (i + seed + 20) * sign;
  sign = -sign;
}
}
...
static void
avx2_test (void)
{
  union128i_d src1, src2, dst;
  int dst_ref[4];
  int i;

  for (i = 0; i < NUM; i++)
{
  init_pblendd128 (src1.a, src2.a, i);

  dst.x = _mm_blend_epi32 (src1.x, src2.x, MASK);

which stores to src1.a/src2.a via a pointer and not a direct union access.

This makes us optimize away the init_pblendd128 function after it being
inlined.

FAIL: gcc.target/i386/avx2-vpblendd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpblendd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpblendw-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastw128-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastw256-2.c execution test
FAIL: gcc.target/i386/avx2-vpermd-2.c execution test
FAIL: gcc.target/i386/avx2-vpermps-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxsd-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxsw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxud-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxuw-2.c execution test
FAIL: gcc.target/i386/avx2-vpminsd-2.c execution test
FAIL: gcc.target/i386/avx2-vpminsw-2.c execution test
FAIL: gcc.target/i386/avx2-vpminud-2.c execution test
FAIL: gcc.target/i386/avx2-vpminuw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmuldq-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulhrsw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulhuw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulhw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulld-2.c execution test
FAIL: gcc.target/i386/avx2-vpmullw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmuludq-2.c execution test
FAIL: gcc.target/i386/avx2-vpshufd-2.c execution test
FAIL: gcc.target/i386/avx2-vpshufhw-2.c execution test
FAIL: gcc.target/i386/avx2-vpshuflw-2.c execution test
FAIL: gcc.target/i386/avx2-vpsignd-2.c execution test
FAIL: gcc.target/i386/avx2-vpsignw-2.c execution test
FAIL: gcc.target/i386/avx2-vpslld-2.c execution test
FAIL: gcc.target/i386/avx2-vpsllvd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpsllvd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpsllw-2.c execution test
FAIL: gcc.target/i386/avx2-vpsrad-2.c execution test
FAIL: gcc.target/i386/avx2-vpsravd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpsravd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpsraw-2.c execution test
FAIL: gcc.target/i386/avx2-vpsrld-2.c execution test
FAIL: gcc.target/i386/avx2-vpsrlvd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpsrlvd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpsrlw-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpckhdq-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpckhwd-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpckldq-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpcklwd-2.c execution test

the actual miscompile only happens if you apply the fix for PR40135, the
testcases are broken nevertheless according to how type-punning through
unions is supposed to work.


[Bug middle-end/40135] using alias-set zero for union accesses necessary because of RTL alias oracle

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135

--- Comment #6 from Richard Biener  ---
For reference I see for example

FAIL: gcc.target/i386/avx2-vpblendd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpblendd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpblendw-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastd128-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastd256-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastw128-2.c execution test
FAIL: gcc.target/i386/avx2-vpbroadcastw256-2.c execution test
FAIL: gcc.target/i386/avx2-vpermd-2.c execution test
FAIL: gcc.target/i386/avx2-vpermps-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxsd-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxsw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxud-2.c execution test
FAIL: gcc.target/i386/avx2-vpmaxuw-2.c execution test
FAIL: gcc.target/i386/avx2-vpminsd-2.c execution test
FAIL: gcc.target/i386/avx2-vpminsw-2.c execution test
FAIL: gcc.target/i386/avx2-vpminud-2.c execution test
FAIL: gcc.target/i386/avx2-vpminuw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmuldq-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulhrsw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulhuw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulhw-2.c execution test
FAIL: gcc.target/i386/avx2-vpmulld-2.c execution test
...
FAIL: gcc.target/i386/avx2-vpunpckhdq-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpckhwd-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpckldq-2.c execution test
FAIL: gcc.target/i386/avx2-vpunpcklwd-2.c execution test

but for example gcc.target/i386/avx2-vpblendd128-2.c contains "invalid"
type-punning through unions:

static void
init_pblendd128 (int *src1, int *src2, int seed)
{
  int i, sign = 1;

  for (i = 0; i < 4; i++)
{
  src1[i] = (i + seed) * (i + seed) * sign;
  src2[i] = (i + seed + 20) * sign;
  sign = -sign;
}
}
...
static void
avx2_test (void)
{
  union128i_d src1, src2, dst;
  int dst_ref[4];
  int i;

  for (i = 0; i < NUM; i++)
{
  init_pblendd128 (src1.a, src2.a, i);

  dst.x = _mm_blend_epi32 (src1.x, src2.x, MASK);

which stores into src1/src2 via a pointer access and only reads via a direct
access to the union.

That's not how the GCC extension specifies union type-punning. I've filed
PR63211 for that.

Here the stores do not end up in alias-set zero and with removing the
c-common.c hack the loads also end up not using alias-set zero.  Without
the fix the loads use alias-set zero and thus keep the int-stores live.

There is also no easy must-alias to identify here as the stores happen
in a loop.


[Bug bootstrap/63212] New: [5 Regression] r214957 breaks bootstrap configured with --enable-checking=release

2014-09-09 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63212

Bug ID: 63212
   Summary: [5 Regression] r214957 breaks bootstrap configured
with --enable-checking=release
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, rguenth at gcc dot gnu.org

Revision r214957 breaks bootstrap configured with --enable-checking=release:

g++ -c   -g  -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../p_work/gcc -I../../p_work/gcc/. -I../../p_work/gcc/../include
-I./../intl -I../../p_work/gcc/../libcpp/include -I/opt/mp/include 
-I../../p_work/gcc/../libdecnumber -I../../p_work/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../p_work/gcc/../libbacktrace -DCLOOG_INT_GMP 
-DCLOOG_INT_GMP -I/opt/mp/include  -o gtype-desc.o -MT gtype-desc.o -MMD -MP
-MF ./.deps/gtype-desc.TPo gtype-desc.c
In file included from ../../p_work/gcc/ggc.h:34:0,
 from ../../p_work/gcc/hash-table.h:199,
 from ../../p_work/gcc/hash-set.h:24,
 from ../../p_work/gcc/tree-core.h:24,
 from ../../p_work/gcc/tree.h:23,
 from gtype-desc.c:30:
gtype-desc.c: In function 'void gt_ggc_mx_loop(void*)':
gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header'
   gt_ggc_m_15basic_block_def ((*x).former_header);
^
./gtype-desc.h:853:7: note: in definition of macro 'gt_ggc_m_15basic_block_def'
   if (X != NULL) gt_ggc_mx_basic_block_def (X);\
   ^
gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header'
   gt_ggc_m_15basic_block_def ((*x).former_header);
^
./gtype-desc.h:853:45: note: in definition of macro
'gt_ggc_m_15basic_block_def'
   if (X != NULL) gt_ggc_mx_basic_block_def (X);\
 ^
gtype-desc.c: In function 'void gt_pch_nx_loop(void*)':
gtype-desc.c:4062:40: error: 'struct loop' has no member named 'former_header'
   gt_pch_n_15basic_block_def ((*x).former_header);
^
./gtype-desc.h:1783:7: note: in definition of macro
'gt_pch_n_15basic_block_def'
   if (X != NULL) gt_pch_nx_basic_block_def (X);\
   ^
gtype-desc.c:4062:40: error: 'struct loop' has no member named 'former_header'
   gt_pch_n_15basic_block_def ((*x).former_header);
^
./gtype-desc.h:1783:45: note: in definition of macro
'gt_pch_n_15basic_block_def'
   if (X != NULL) gt_pch_nx_basic_block_def (X);\
 ^
gtype-desc.c: In function 'void gt_pch_p_4loop(void*, void*,
gt_pointer_operator, void*)':
gtype-desc.c:7296:16: error: 'struct loop' has no member named 'former_header'
 op (&((*x).former_header), cookie);
^


[Bug bootstrap/63204] gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' breaks bootstrap

2014-09-09 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63204

Andreas Schwab  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #4 from Andreas Schwab  ---
*** Bug 63212 has been marked as a duplicate of this bug. ***


[Bug bootstrap/63212] [5 Regression] r214957 breaks bootstrap configured with --enable-checking=release

2014-09-09 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63212

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Dup.

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


[Bug c/63213] -Warray-bounds false positive with -O3

2014-09-09 Thread oliverst at online dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63213

--- Comment #1 from Oliver Stoeneberg  ---
Created attachment 33463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33463&action=edit
preprocessed source


[Bug c/63213] New: -Warray-bounds false positive with -O3

2014-09-09 Thread oliverst at online dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63213

Bug ID: 63213
   Summary: -Warray-bounds false positive with -O3
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oliverst at online dot de

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

The attached code generates the following warnings:

gcc -Wall -O3 -Wno-uninitialized -c model1.c
model1.c: In function 'fill_quad':
model1.c:94:11: warning: array subscript is above array bounds [-Warray-bounds]
while(p[ps2+1].y == cury)
   ^
model1.c:114:11: warning: array subscript is above array bounds
[-Warray-bounds]
while(p[ps2+1].y == cury)
   ^
model1.c:114:11: warning: array subscript is above array bounds
[-Warray-bounds]
model1.c:92:11: warning: array subscript is below array bounds [-Warray-bounds]
while(p[ps1-1].y == cury)
   ^
model1.c:105:11: warning: array subscript is below array bounds
[-Warray-bounds]
while(p[ps1-1].y == cury)
   ^
model1.c:105:11: warning: array subscript is below array bounds
[-Warray-bounds]

The code is quite messy and reducing it created some uninitialized warnings,
that didn't exist in the original code, but the array bounds ones stayed the
same. It was about ten times the size of this before I reduced it and I
couldn't reduce it anymore since removing any line reduces the amount of
warnings.

Apparently this false positive started with GCC 4.8.1 on some Linux
distribution (I assume it was some Fedora version), but I didn't have access to
a toolchain, that was causing it until now with the MinGW 4.9.1 release.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/mingw64-w64/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.1/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw491/x86_64-491-win32-seh-rt_v3-rev0/mingw64
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-isl-version-check --disable-cloog-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw491/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw491/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw491/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw491/prerequisites/x86_64-w64-mingw32-static
--with-cloog=/c/mingw491/prerequisites/x86_64-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='x86_64-win32-seh-rev0, Built by
MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64
CFLAGS='-O2 -pipe
-I/c/mingw491/x86_64-491-win32-seh-rt_v3-rev0/mingw64/opt/include
-I/c/mingw491/prerequisites/x86_64-zlib-static/include
-I/c/mingw491/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw491/x86_64-491-win32-seh-rt_v3-rev0/mingw64/opt/include
-I/c/mingw491/prerequisites/x86_64-zlib-static/include
-I/c/mingw491/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw491/x86_64-491-win32-seh-rt_v3-rev0/mingw64/opt/lib
-L/c/mingw491/prerequisites/x86_64-zlib-static/lib
-L/c/mingw491/prerequisites/x86_64-w64-mingw32-static/lib'
Thread model: win32
gcc version 4.9.1 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)


[Bug c++/50921] GCC cannot find dependent conversion-function-id even if there's a using declaration for it

2014-09-09 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50921

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini  ---
Any news?


[Bug middle-end/63213] -Warray-bounds false positive with -O3

2014-09-09 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63213

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |middle-end

--- Comment #2 from Marek Polacek  ---
I'm pretty sure this is a dupe, we have many -Warray-bounds bugs.


[Bug target/61749] arm_neon.h "_lane" and "_n" intrinsics can cause ICEs

2014-09-09 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Sep  9 10:15:46 2014
New Revision: 215046

URL: https://gcc.gnu.org/viewcvs?rev=215046&root=gcc&view=rev
Log:
[AArch64] PR 61749: Do not ICE in lane intrinsics when passed non-constant lane
number

PR target/61749
* config/aarch64/aarch64-builtins.c (aarch64_types_quadop_qualifiers):
Use qualifier_immediate for last operand.  Rename to...
(aarch64_types_ternop_lane_qualifiers): ... This.
(TYPES_QUADOP): Rename to...
(TYPES_TERNOP_LANE): ... This.
(aarch64_simd_expand_args): Return const0_rtx when encountering user
error.  Change return of 0 to return of NULL_RTX.
(aarch64_crc32_expand_builtin): Likewise.
(aarch64_expand_builtin): Return NULL_RTX instead of 0.
ICE when expanding unknown builtin.
* config/aarch64/aarch64-simd-builtins.def (sqdmlal_lane): Use
TERNOP_LANE qualifiers.
(sqdmlsl_lane): Likewise.
(sqdmlal_laneq): Likewise.
(sqdmlsl_laneq): Likewise.
(sqdmlal2_lane): Likewise.
(sqdmlsl2_lane): Likewise.
(sqdmlal2_laneq): Likewise.
(sqdmlsl2_laneq): Likewise.

* gcc.target/aarch64/vqdml_lane_intrinsics-bad_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/vqdml_lane_intrinsics-bad_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-builtins.c
trunk/gcc/config/aarch64/aarch64-simd-builtins.def
trunk/gcc/testsuite/ChangeLog


[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

2014-09-09 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678

--- Comment #65 from Markus Trippelsdorf  ---
Honza, does Jason's patch from comment 62 look good to you?


[Bug c++/62175] [4.9 Regression] Internal compiler error in gimplify_modify_expr gimplify.c:4616

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175

Richard Biener  changed:

   What|Removed |Added

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

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


[Bug rtl-optimization/61672] [4.9 Regression] Less redundant instructions deleted by pre_delete after r208113.

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 11:42:34 2014
New Revision: 215059

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

Backport from mainline
2014-08-05  Richard Biener  

PR rtl-optimization/61672
* emit-rtl.h (mem_attrs_eq_p): Declare.
* emit-rtl.c (mem_attrs_eq_p): Export.  Handle NULL mem-attrs.
* cse.c (exp_equiv_p): Use mem_attrs_eq_p.
* cfgcleanup.c (merge_memattrs): Likewise.
Include emit-rtl.h.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

2014-08-14  Richard Biener  

PR rtl-optimization/62079
* recog.c (peephole2_optimize): If peep2_do_cleanup_cfg
run cleanup_cfg.

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


2014-08-26  Richard Biener  

PR tree-optimization/62175
* tree-ssa-loop-niter.c (expand_simple_operations): Do not
expand possibly trapping operations.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr62079.C
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr62175.C
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cfgcleanup.c
branches/gcc-4_9-branch/gcc/cse.c
branches/gcc-4_9-branch/gcc/emit-rtl.c
branches/gcc-4_9-branch/gcc/recog.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-4_9-branch/gcc/tree-vect-slp.c


[Bug tree-optimization/62079] [4.9 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62079

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 11:42:34 2014
New Revision: 215059

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

Backport from mainline
2014-08-05  Richard Biener  

PR rtl-optimization/61672
* emit-rtl.h (mem_attrs_eq_p): Declare.
* emit-rtl.c (mem_attrs_eq_p): Export.  Handle NULL mem-attrs.
* cse.c (exp_equiv_p): Use mem_attrs_eq_p.
* cfgcleanup.c (merge_memattrs): Likewise.
Include emit-rtl.h.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

2014-08-14  Richard Biener  

PR rtl-optimization/62079
* recog.c (peephole2_optimize): If peep2_do_cleanup_cfg
run cleanup_cfg.

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


2014-08-26  Richard Biener  

PR tree-optimization/62175
* tree-ssa-loop-niter.c (expand_simple_operations): Do not
expand possibly trapping operations.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr62079.C
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr62175.C
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cfgcleanup.c
branches/gcc-4_9-branch/gcc/cse.c
branches/gcc-4_9-branch/gcc/emit-rtl.c
branches/gcc-4_9-branch/gcc/recog.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-4_9-branch/gcc/tree-vect-slp.c


[Bug tree-optimization/62075] [4.8/4.9 Regression] Vectorizer ICE on dolphin

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 11:42:34 2014
New Revision: 215059

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

Backport from mainline
2014-08-05  Richard Biener  

PR rtl-optimization/61672
* emit-rtl.h (mem_attrs_eq_p): Declare.
* emit-rtl.c (mem_attrs_eq_p): Export.  Handle NULL mem-attrs.
* cse.c (exp_equiv_p): Use mem_attrs_eq_p.
* cfgcleanup.c (merge_memattrs): Likewise.
Include emit-rtl.h.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

2014-08-14  Richard Biener  

PR rtl-optimization/62079
* recog.c (peephole2_optimize): If peep2_do_cleanup_cfg
run cleanup_cfg.

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


2014-08-26  Richard Biener  

PR tree-optimization/62175
* tree-ssa-loop-niter.c (expand_simple_operations): Do not
expand possibly trapping operations.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr62079.C
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr62175.C
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cfgcleanup.c
branches/gcc-4_9-branch/gcc/cse.c
branches/gcc-4_9-branch/gcc/emit-rtl.c
branches/gcc-4_9-branch/gcc/recog.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-4_9-branch/gcc/tree-vect-slp.c


[Bug tree-optimization/62079] [4.9 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62079

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|4.9.2   |4.9.1

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


[Bug c++/62175] [4.9 Regression] Internal compiler error in gimplify_modify_expr gimplify.c:4616

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 11:42:34 2014
New Revision: 215059

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

Backport from mainline
2014-08-05  Richard Biener  

PR rtl-optimization/61672
* emit-rtl.h (mem_attrs_eq_p): Declare.
* emit-rtl.c (mem_attrs_eq_p): Export.  Handle NULL mem-attrs.
* cse.c (exp_equiv_p): Use mem_attrs_eq_p.
* cfgcleanup.c (merge_memattrs): Likewise.
Include emit-rtl.h.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

2014-08-14  Richard Biener  

PR rtl-optimization/62079
* recog.c (peephole2_optimize): If peep2_do_cleanup_cfg
run cleanup_cfg.

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


2014-08-26  Richard Biener  

PR tree-optimization/62175
* tree-ssa-loop-niter.c (expand_simple_operations): Do not
expand possibly trapping operations.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr62079.C
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr62175.C
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cfgcleanup.c
branches/gcc-4_9-branch/gcc/cse.c
branches/gcc-4_9-branch/gcc/emit-rtl.c
branches/gcc-4_9-branch/gcc/recog.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-4_9-branch/gcc/tree-vect-slp.c


[Bug rtl-optimization/61672] [4.9 Regression] Less redundant instructions deleted by pre_delete after r208113.

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672

Richard Biener  changed:

   What|Removed |Added

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

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


[Bug c++/61214] [4.9/5 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization

2014-09-09 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Tue Sep  9 11:57:25 2014
New Revision: 215061

URL: https://gcc.gnu.org/viewcvs?rev=215061&root=gcc&view=rev
Log:
PR c++/61214
PR c++/62224
gcc/
* gimple-fold.c (can_refer_decl_in_current_unit_p): Don't allow
reference to a DECL_EXTERNAL COMDAT.
gcc/cp/
* decl2.c (decl_needed_p): Revert virtual functions change.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-40.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/decl2.c
branches/gcc-4_9-branch/gcc/gimple-fold.c
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-39.C


[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820

2014-09-09 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Tue Sep  9 11:57:25 2014
New Revision: 215061

URL: https://gcc.gnu.org/viewcvs?rev=215061&root=gcc&view=rev
Log:
PR c++/61214
PR c++/62224
gcc/
* gimple-fold.c (can_refer_decl_in_current_unit_p): Don't allow
reference to a DECL_EXTERNAL COMDAT.
gcc/cp/
* decl2.c (decl_needed_p): Revert virtual functions change.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-40.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/decl2.c
branches/gcc-4_9-branch/gcc/gimple-fold.c
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-39.C


[Bug c++/62255] [4.8/4.9 Regression] Introducing an unrelated template parameter causes compilation to fail

2014-09-09 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Tue Sep  9 11:59:45 2014
New Revision: 215062

URL: https://gcc.gnu.org/viewcvs?rev=215062&root=gcc&view=rev
Log:
PR c++/62255
* pt.c (instantiate_decl): Handle recursive instantiation of
static data member.

Added:
trunk/gcc/testsuite/g++.dg/template/recurse4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c


[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820

2014-09-09 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224

Markus Trippelsdorf  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #16 from Markus Trippelsdorf  ---
Changing resolution. Fixed.


[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540

2014-09-09 Thread aivchenk at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053

--- Comment #3 from Alexander Ivchenko  ---
Jan, by any chance, do you have any progress on that? May be we should revert
the patch until the proper fix?


[Bug c++/63194] [5 Regression] ICE in maybe_explain_implicit_delete, at cp/method.c:1552

2014-09-09 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63194

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |5.0


[Bug target/63190] Assembler errors when building md5 code from fbb on aarch64

2014-09-09 Thread yroux at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63190

--- Comment #3 from Yvan Roux  ---
Author: yroux
Date: Tue Sep  9 12:40:52 2014
New Revision: 215069

URL: https://gcc.gnu.org/viewcvs?rev=215069&root=gcc&view=rev
Log:
2014-09-09  Venkataramanan Kumar  

Backport from trunk r215004.
2014-09-07 Venkataramanan Kumar 

PR target/63190
* config/aarch64/aarch64.md (stack_protect_test_) Add register
constraint for operand0 and remove write only modifier from operand3.


Modified:
branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.md


[Bug c++/63214] New: [5.0 regression] ICE with static __thread value member in template class

2014-09-09 Thread kikairoya at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63214

Bug ID: 63214
   Summary: [5.0 regression] ICE with static __thread value member
in template class
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kikairoya at gmail dot com

following code causes ICE with gcc HEAD 5.0.0 20140908 (experimental)
(ran in http://melpon.org/wandbox/permlink/vXZsIogHe6QO5pnI )



#include 

template 
struct X {
  static __thread T value_;
};



prog.cc:5:2: internal compiler error: Segmentation fault
 };
  ^
0x9a2d3f crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:339
0x6fdee0 symbol_table::decl_assembler_name_hash(tree_node const*)
/home/heads/gcc/gcc-source/gcc/symtab.c:69
0x6fe0e8 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
/home/heads/gcc/gcc-source/gcc/symtab.c:181
0x6fe1fc symbol_table::symtab_initialize_asm_name_hash()
/home/heads/gcc/gcc-source/gcc/symtab.c:263
0x6ff3f4 symbol_table::symtab_initialize_asm_name_hash()
/home/heads/gcc/gcc-source/gcc/symtab.c:950
0x6ff3f4 symtab_node::get_for_asmname(tree_node const*)
/home/heads/gcc/gcc-source/gcc/symtab.c:939
0x709088 handle_alias_pairs
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:
0x70c94c symbol_table::finalize_compilation_unit()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2264
0x5bba2b cp_write_global_declarations()
/home/heads/gcc/gcc-source/gcc/cp/decl2.c:4666
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

-


[Bug c/38354] Spurious error: initializer element is not computable at load time

2014-09-09 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354

--- Comment #9 from Jonathan Wakely  ---
(In reply to Adam Warner from comment #6)
> Just to make sure I understand this correctly:
> 
> 1. You won't confirm this bug because it violates the C standard.

You asked why it works with C++ and I told you, I didn't say anything about
confirming it or not, because I'm not a C front-end maintainer so it's not my
place to decide what is a bug in the C front-end. (IMHO it's not a bug, but
might be a valid enhancement request.)

I stand by my statement that the C standard is more restrictive about what is
allowed in a static initializer.  C++ has a "dynamic initialization" phase
which does not exist for C.

> 2. GNU provides extensions to C when the C standard is too restrictive. In
> this case the initializer element is *clearly* computable at load time
> because all function pointers are *already* 32 bits under the non-large code
> model.
> 
> 3. To demonstrate this, a GNU extension to C++ has no problem computing the
> address of the function pointer at load time and storing it in a 32-bit
> integer array.

It's not a GNU extension, it's required by the C++ standard, and it happens at
runtime, so that fails to demonstrate your point.

> 4. Just because C is supposed to be a portable assembler and lower level
> than C++ doesn't mean you should be able to store a 32-bit address in a
> 32-bit integer at load time. Even though GNU C++ can.

Except it can't.


[Bug tree-optimization/62075] [4.8 Regression] Vectorizer ICE on dolphin

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 13:17:51 2014
New Revision: 215073

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

Backport from mainline
2014-05-05  Richard Biener  

PR middle-end/61010
* fold-const.c (fold_binary_loc): Consistently avoid
canonicalizing X & CST away from a CST that is the mask
of a mode.

* gcc.dg/torture/pr61010.c: New testcase.

2014-05-28  Richard Biener  

PR middle-end/61045
* fold-const.c (fold_comparison): When folding
X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure
the sign of the remaining constant operand stays the same.

* gcc.dg/pr61045.c: New testcase.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr61045.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr61010.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-vect-slp.c


[Bug middle-end/61045] [4.8 Regression] Wrong constant folding

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 13:17:51 2014
New Revision: 215073

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

Backport from mainline
2014-05-05  Richard Biener  

PR middle-end/61010
* fold-const.c (fold_binary_loc): Consistently avoid
canonicalizing X & CST away from a CST that is the mask
of a mode.

* gcc.dg/torture/pr61010.c: New testcase.

2014-05-28  Richard Biener  

PR middle-end/61045
* fold-const.c (fold_comparison): When folding
X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure
the sign of the remaining constant operand stays the same.

* gcc.dg/pr61045.c: New testcase.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr61045.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr61010.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-vect-slp.c


[Bug middle-end/61010] [4.8 Regression] Infinite recursion in fold

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 13:17:51 2014
New Revision: 215073

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

Backport from mainline
2014-05-05  Richard Biener  

PR middle-end/61010
* fold-const.c (fold_binary_loc): Consistently avoid
canonicalizing X & CST away from a CST that is the mask
of a mode.

* gcc.dg/torture/pr61010.c: New testcase.

2014-05-28  Richard Biener  

PR middle-end/61045
* fold-const.c (fold_comparison): When folding
X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure
the sign of the remaining constant operand stays the same.

* gcc.dg/pr61045.c: New testcase.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

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

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr61045.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr61010.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-vect-slp.c


[Bug middle-end/61045] [4.8 Regression] Wrong constant folding

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.10.0  |4.8.4, 5.0
 Resolution|--- |FIXED

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


[Bug middle-end/61010] [4.8 Regression] Infinite recursion in fold

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.10.0  |4.8.4, 5.0
 Resolution|--- |FIXED
  Known to fail|4.8.2   |4.8.3

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


[Bug tree-optimization/62075] [4.8 Regression] Vectorizer ICE on dolphin

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.4
 Resolution|--- |FIXED
  Known to fail||4.8.3

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


[Bug c++/63214] [5.0 regression] ICE with static __thread value member in template class

2014-09-09 Thread kikairoya at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63214

Tomohiro Kashiwada  changed:

   What|Removed |Added

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

--- Comment #1 from Tomohiro Kashiwada  ---
sorry. dupped.

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


[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault

2014-09-09 Thread kikairoya at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558

Tomohiro Kashiwada  changed:

   What|Removed |Added

 CC||kikairoya at gmail dot com

--- Comment #8 from Tomohiro Kashiwada  ---
*** Bug 63214 has been marked as a duplicate of this bug. ***


[Bug sanitizer/61897] sanitizer internal compiler error: in build2_stat, at tree.c:4160

2014-09-09 Thread trt at alumni dot duke.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61897

Tom Truscott  changed:

   What|Removed |Added

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

--- Comment #4 from Tom Truscott  ---
This patch works fine for me, thanks!


[Bug tree-optimization/62012] Loop is not vectorized after function inlining (SCEV)

2014-09-09 Thread ysrumyan at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012

--- Comment #4 from Yuri Rumyantsev  ---
I checked that our benchmark is successfully vectorized with function inlining.
 So this bug must be closed as fixed/resolved.


[Bug tree-optimization/62012] Loop is not vectorized after function inlining (SCEV)

2014-09-09 Thread ysrumyan at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012

--- Comment #5 from Yuri Rumyantsev  ---
You can close this bug as fixed/resolved (see my comment).

Thanks.
Yuri.

2014-09-08 15:29 GMT+04:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012
>
> Richard Biener  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2014-09-08
>  Ever confirmed|0   |1
>
> --- Comment #3 from Richard Biener  ---
> So it's independend of LTO.
>
> Confirmed.  We have
>
>   _28 = &MEM[(struct Array *)&fa + 256B].a[0] + _3;
>   *_28 = u_23;
>
> which SCEV messes up because it ends up with
>
> (instantiate_scev
>   (instantiate_below = 4)
>   (evolution_loop = 1)
>   (chrec = &MEM[(struct Array *)&fa + 256B].a[0])
>   (res = &MEM[(struct Array *)&fa + 256B].a[0]))
> (instantiate_scev
>   (instantiate_below = 4)
>   (evolution_loop = 1)
>   (chrec = {(long unsigned int) first_6(D) * 4, +, 4}_1)
>   (res = {(long unsigned int) first_6(D) * 4, +, 4}_1))
> (set_scalar_evolution
>   instantiated_below = 4
>   (scalar = _13)
>   (scalar_evolution = {&MEM[(struct Array *)&fa + 256B].a[(sizetype)
> first_6(D)], +, 4}_1))
> )
> failed: evolution of base is not affine.
>
> Not sure why it thinks that.
>
> Btw, on trunk we now vectorize this just fine probably because of the fix
> for PR63148 which avoids moving first_6 * 4 inside the array-ref and we
> get
>
>   (scalar_evolution = {&MEM[(struct Array *)&fa + 256B].a[0] + (sizetype)
> ((long unsigned int) first_6(D) * 4), +, 4}_1))
> )
> success.
>
> instead.
>
> So - can you re-check please?
>
> --
> You are receiving this mail because:
> You reported the bug.


[Bug tree-optimization/61680] [4.8 Regression] vectorization gives wrong answer for sandybridge target

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61680

Richard Biener  changed:

   What|Removed |Added

  Known to work|4.10.0  |5.0

--- Comment #12 from Richard Biener  ---
For 4.8 we can't backport the patch as group analysis and dependence analysis
are still the wrong way around.  A simple

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   (revision 215073)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -2307,6 +2307,17 @@ vect_analyze_group_access (struct data_r

   while (next)
 {
+ /* Check that there is no load-store dependencies for this loads
+to prevent a case of load-store-load to the same location.  */
+ if (GROUP_READ_WRITE_DEPENDENCE (vinfo_for_stmt (next))
+ || GROUP_READ_WRITE_DEPENDENCE (vinfo_for_stmt (prev)))
+   {
+ if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 
+"READ_WRITE dependence in interleaving.");
+ return false;
+   }
+
   /* Skip same data-refs.  In case that two or more stmts share
  data-ref (supported only for loads), we vectorize only the first
  stmt, and the rest get their vectorized loads from the first
@@ -2323,17 +2334,6 @@ vect_analyze_group_access (struct data_r
   return false;
 }

-  /* Check that there is no load-store dependencies for this loads
- to prevent a case of load-store-load to the same location. 
*/
-  if (GROUP_READ_WRITE_DEPENDENCE (vinfo_for_stmt (next))
-  || GROUP_READ_WRITE_DEPENDENCE (vinfo_for_stmt (prev)))
-{
-  if (dump_enabled_p ())
-dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 
- "READ_WRITE dependence in
interleaving.");
-  return false;
-}
-
   /* For load use the same data-ref load.  */
   GROUP_SAME_DR_STMT (vinfo_for_stmt (next)) = prev;


will regress testcases in vect.exp.

Like with two other 4.8 vectorizer miscompiles it's hard to fix them without
turning the vectorizer upside down (aka backport most of the re-org
from GCC 4.9).


[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 62012, which changed state.

Bug 62012 Summary: Loop is not vectorized after function inlining (SCEV)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012

   What|Removed |Added

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


[Bug tree-optimization/62012] Loop is not vectorized after function inlining (SCEV)

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012

Richard Biener  changed:

   What|Removed |Added

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

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


[Bug tree-optimization/61452] [4.8 Regression] hang at -O1 and -Os on x86_64-linux-gnu

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.10.0  |4.8.4, 5.0
 Resolution|--- |FIXED

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


[Bug tree-optimization/61452] [4.8 Regression] hang at -O1 and -Os on x86_64-linux-gnu

2014-09-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  9 14:45:57 2014
New Revision: 215081

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

Backport from mainline
2014-06-11  Richard Biener  

PR tree-optimization/61452
* tree-ssa-sccvn.c (visit_phi): Remove pointless setting of
expr and has_constants in case we found a leader.
(simplify_binary_expression): Always valueize operands first.
(simplify_unary_expression): Likewise.

* gcc.dg/torture/pr61452.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr61452.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-ssa-sccvn.c


[Bug ipa/61659] [4.9 Regression] Extra undefined symbol because of devirtualization

2014-09-09 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659

--- Comment #33 from John David Anglin  ---
The issue in comment 32 was introduced in revision 214177
.


[Bug c/38354] Spurious error: initializer element is not computable at load time

2014-09-09 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354

--- Comment #10 from joseph at codesourcery dot com  ---
This seems like an enhancement request to me.  Initializers using a 64-bit 
function address cast to 32-bit are outside the scope of my model of 
constant expressions for GNU C 
( - fairly 
old, may be out of date).  It so happens that the x86_64 ABI does include 
a relocation for 32-bit symbol references (in fact two of them, 
R_X86_64_32 and R_X86_64_32S), but I don't believe GCC has that 
information about what relocations the target supports at present (and 
then there would be the question of which of those two relocations to use, 
though maybe that's a question for the assembler).


[Bug target/63195] [5.0 regression] stage3 build/gengtype miscompiled

2014-09-09 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63195

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Tue Sep  9 18:49:08 2014
New Revision: 215091

URL: https://gcc.gnu.org/viewcvs?rev=215091&root=gcc&view=rev
Log:
2014-09-09  Segher Boessenkool  

PR target/63195
* config/rs6000/rs6000.md (*bool3): Allow only register
operands.  Split off the constant operand alternative to ...
(*bool3_imm): New.

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


[Bug web/62211] ./configure --with-float= and ARM

2014-09-09 Thread rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62211

--- Comment #1 from Richard Earnshaw  ---
-m{soft,hard}-float for arm should be considered deprecated (we try to support
them by mapping them onto the -mfloat-abi option), and deliberately no-longer
document them.  

Rather than clarifying what they do, the references elsewhere should be cleaned
up to use -mfloat-abi.  Specifically, in this case, the reference to
-msoft-float should be changed to -mfloat-abi=soft.


[Bug target/63195] [5.0 regression] stage3 build/gengtype miscompiled

2014-09-09 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63195

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed.  Thanks for the report!


[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

2014-09-09 Thread larryv at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

--- Comment #38 from Lawrence Velázquez  ---
Created attachment 33464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33464&action=edit
Corrected dirent patch

Couple of things:

1) The version of Sanitizer included with GCC 4.9.1 at least, and probably
earlier, has the includes in the wrong order in
sanitizer_platform_limits_posix.cc:

  #include "sanitizer_platform.h"
  #if SANITIZER_LINUX || SANITIZER_MAC

  #include "sanitizer_internal_defs.h"
  #include "sanitizer_platform_limits_posix.h"

  #include 
  #include 

Since sanitizer_platform_limits_posix.h is included before the system headers,
_DARWIN_FEATURE_64_BIT_INODE is *not* defined for the second hunk of your
patch, and the 32-bit dirent is always used. However, it *is* defined for the
first hunk, so CHECK_SIZE_AND_OFFSET does try to access d_seekoff (and
predictably fails).

The ordering is fixed in Sanitizer upstream, but it's more robust to directly
include sys/cdefs.h in sanitizer_platform_limits_posix.h to avoid relying on
include ordering.

2) You should report this bug upstream.

  http://compiler-rt.llvm.org

[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran

2014-09-09 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-09
 CC||manu at gcc dot gnu.org
 Depends on||62226
 Ever confirmed|0   |1

--- Comment #7 from Manuel López-Ibáñez  ---
The ideal fix for this would adding a function like:

+bool
+gfc_warning_cmdline (int opt, const char *gmsgid, ...)
+{
+  va_list argp;
+  diagnostic_info diagnostic;
+  bool ret;
+
+  va_start (argp, gmsgid);
+  diagnostic_set_info (&diagnostic, gmsgid, &argp, UNKNOWN_LOCATION,
+  DK_WARNING);
+  diagnostic.option_index = opt;
+  ret = report_diagnostic (&diagnostic);
+  va_end (argp);
+  return ret;
+}
+

in error.c. Then calling:

Index: gcc/fortran/scanner.c
===
--- gcc/fortran/scanner.c   (revision 214251)
+++ gcc/fortran/scanner.c   (working copy)
@@ -326,13 +326,13 @@ add_path_to_list (gfc_directorylist **li
   if (errno != ENOENT)
gfc_warning_now ("Include directory \"%s\": %s", path,
 xstrerror(errno));
   else
{
- /* FIXME:  Also support -Wmissing-include-dirs.  */
  if (warn)
-   gfc_warning_now ("Nonexistent include directory \"%s\"", path);
+   gfc_warning_cmdline (OPT_Wmissing_include_dirs,
+"Nonexistent include directory \"%s\"", path);
}
   return;
 }
   else if (!S_ISDIR (st.st_mode))
 {

Then, NOT adding gfc_option.warn_missing_include_dirs, but instead fixing
62226, and simply adding:

Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt(revision 194167)
+++ gcc/fortran/lang.opt(working copy)
@@ -254,6 +254,10 @@
 Fortran Warning
 Warn on intrinsics not part of the selected standard

+Wmissing-include-dirs
+Fortran Warning
+; Documented in C
+
 Wreal-q-constant
 Fortran Warning
 Warn about real-literal-constants with 'q' exponent-letter

This automatically will give you:

* Setting cpp_opts, even when using #pragma, -Werror= and complicated
combinations.

* Colors!

* Printing [-Wmissing-include-dirs] in the warning message.

[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820

2014-09-09 Thread chris2553 at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224

--- Comment #17 from Chris Clayton  ---
I can confirm that with Jason's code changes (referenced in comment 15) to
gcc/cp/decl2.c and gcc/gimple-fold.c, the resultant compiler successfully
builds qt-creator-3.2.0. Thanks Jason.


[Bug rtl-optimization/63156] web can't handle AUTOINC correctly

2014-09-09 Thread carrot at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156

--- Comment #9 from Carrot  ---
The original flag setting code is neither correct. Consider following
pre_modify expression:

(pre_modify (r1)// def1, use1
(plus (r1)  // use2
  (r2)))// use3

GCC will generate 4 df_ref information for this expression as noted, 1 def and
3 use. Current code only set DF_REF_READ_WRITE for def1, this causes web do
wrong renaming. The original flag setting code will set DF_REF_READ_WRITE for
all def/use in this expression, this is obviously wrong for r2. 

I don't know if this has any relations to bug 32339.


[Bug bootstrap/56750] [4.8/4.9/5 Regression] static -lstdc++ logic bleeds into all subdirs

2014-09-09 Thread vapier at gentoo dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56750

--- Comment #7 from Mike Frysinger  ---
ping ... this is causing releases of binutils' gold to be statically linked,
and causing headaches for the gold testsuites.


[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

2014-09-09 Thread larryv at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

--- Comment #39 from Lawrence Velázquez  ---
(In reply to Lawrence Velázquez from comment #38)
> 2) You should report this bug upstream.
> 
>   http://compiler-rt.llvm.org

On second thought, they probably won't accept it because the patch is invalid.

sanitizer_mac.cc explicitly defines _DARWIN_USE_64_BIT_INODE, which result in
64-bit dirents on all platforms that AddressSanitizer supports (Snow Leopard
and newer). The correct fix is to disable the AddressSanitizer build entirely
on platforms that don't support 64-bit inodes (Leopard and older).

[Bug c/38354] Spurious error: initializer element is not computable at load time

2014-09-09 Thread adam at consulting dot net.nz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354

--- Comment #11 from Adam Warner  ---
Thank you Joseph for clarifying in Comment 10 why this should be considered an
enhancement request. It would be non-trivial to change the model of what GNU C
considers a constant expression and code relying on an enhanced model of
constant expression is likely to be incompatible with other compilers.

I now have a 100% efficient fairly portable workaround in a few lines of bash
scripting. Here is an example lookup_table.c:

#include 
#include 

#include "lookup_table.h"

void fn0(void) {printf("fn0\n");}
void fn1(void) {printf("fn1\n");}
void fn2(void) {printf("fn2\n");}
void fn3(void) {printf("fn3\n");}

int main(void) {
  for (int i=0; i<4; ++i) ((void (*)(void)) (uint64_t) lookup_table[i])();
  return 0;
}


To compile/execute the C code run this bash script named lookup_table.sh:

#!/bin/bash
if [[ ! -f lookup_table.h ]]; then echo "uint32_t lookup_table[4];" >>
lookup_table.h; fi
gcc -std=gnu11 -O3 lookup_table.c -o lookup_table
mv -f lookup_table.h lookup_table.h.old
echo "uint32_t lookup_table[] = {" > lookup_table.h
objdump -d -m i386:x86-64 lookup_table | grep '> lookup_table.h
echo "};" >> lookup_table.h
diff -su lookup_table.h.old lookup_table.h && ./lookup_table ||
./lookup_table.sh


Example output:

$ ./lookup_table.sh 
--- lookup_table.h.old2014-09-10 13:35:03.162644646 +1200
+++ lookup_table.h2014-09-10 13:35:03.222648312 +1200
@@ -1 +1,6 @@
-uint32_t lookup_table[4];
+uint32_t lookup_table[] = {
+0x00400530,
+0x00400540,
+0x00400550,
+0x00400560,
+};
Files lookup_table.h.old and lookup_table.h are identical
fn0
fn1
fn2
fn3

The lookup table functions must share a unique prefix. If the new
lookup_table.h matches the old lookup_table.h then the binary is internally
consistent and ready for execution.

There is no additional overhead in the final binary:

00400410 :
  400410:   53  push   rbx
  400411:   bb e0 09 60 00  movebx,0x6009e0
  400416:   8b 03   moveax,DWORD PTR [rbx]
  400418:   48 83 c3 04 addrbx,0x4
  40041c:   ff d0   call   rax
  40041e:   48 81 fb f0 09 60 00cmprbx,0x6009f0
  400425:   75 ef   jne400416 
  400427:   31 c0   xoreax,eax
  400429:   5b  poprbx
  40042a:   c3  ret

In this example the lookup table has been mapped into memory at address
0x6009e0. There is a 32-bit load for each function call. No code is required to
populate the lookup table at run time. No internal run time checks are required
to ensure the lookup table and function addresses match. This is a perfectly
efficient workaround that is superior to the C++ approach.


[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept

2014-09-09 Thread thopre01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846

--- Comment #8 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Wed Sep 10 04:45:32 2014
New Revision: 215101

URL: https://gcc.gnu.org/viewcvs?rev=215101&root=gcc&view=rev
Log:
2014-09-10  Tony Wang  

libstdc++-v3/
PR target/56846
* libsupc++/eh_personality.cc (PERSONALITY_FUNCTION):
Return with CONTINUE_UNWINDING when the state pattern
contains: _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_personality.cc


[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

2014-09-09 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

--- Comment #19 from Alan Modra  ---
Author: amodra
Date: Wed Sep 10 05:02:02 2014
New Revision: 215102

URL: https://gcc.gnu.org/viewcvs?rev=215102&root=gcc&view=rev
Log:
PR debug/60655
* dwarf2out.c (mem_loc_descriptor ): Return NULL if addend
can't be output.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/dwarf2out.c


[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

2014-09-09 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

--- Comment #20 from Alan Modra  ---
Author: amodra
Date: Wed Sep 10 05:02:28 2014
New Revision: 215103

URL: https://gcc.gnu.org/viewcvs?rev=215103&root=gcc&view=rev
Log:
PR debug/60655
* dwarf2out.c (mem_loc_descriptor ): Return NULL if addend
can't be output.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/dwarf2out.c


[Bug lto/63215] New: LTO causes symbols for builtin functions to be omitted from object files

2014-09-09 Thread patrick at motec dot com.au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215

Bug ID: 63215
   Summary: LTO causes symbols for builtin functions to be omitted
from object files
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at motec dot com.au

-flto causes symbols for builtin functions to be omitted from object files.
Specifying -fno-builtin generates the symbols again.

This causes problems when these files are combined into an archive and used for
later linking as the linker can't resolve the symbols.

For example:

abs.c:

int abs(int j)
{
return j < 0 ? -j : j;
}

Normal compile:

$ powerpc-eabispe-gcc -c abs.c -o abs.o
$ powerpc-eabispe-gcc-nm abs.o
 T abs

Compile with lto:

$ powerpc-eabispe-gcc -flto -c abs.c -o abs_lto.o 
$ powerpc-eabispe-gcc-nm abs_lto.o
/home/patrick/toolchain/lib/gcc/powerpc-eabispe/4.9.1/../../../../powerpc-eabispe/bin/nm:
abs_lto.o: no symbols

Compile with lto and no-builtin:

$ powerpc-eabispe-gcc -fno-builtin -flto -c abs.c -o abs_lto_nobuiltin.o
$ powerpc-eabispe-gcc-nm abs_lto_nobuiltin.o
 T abs

Here is the output of gcc -v

$ powerpc-eabispe-gcc -v
Using built-in specs.
COLLECT_GCC=powerpc-eabispe-gcc
COLLECT_LTO_WRAPPER=/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.9.1/lto-wrapper
Target: powerpc-eabispe
Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.9.1/configure
--prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=powerpc-eabispe
--enable-languages=c,c++
--with-sysroot=/home/patrick/src/e7/toolchain/../prex_sysroot --disable-nls
--disable-werror --with-newlib --with-gmp=/home/patrick/src/e7/toolchain/stage2
--with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared
--disable-debug --disable-libssp --with-cpu=8540
Thread model: single
gcc version 4.9.1 (GCC)


[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files

2014-09-09 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-10
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Jan Hubicka  ---
At the moment it is not supported to LTO runtime symbols (i.e. functions and
variables whose use may be synthetized by the compiler). Doing so would be
quite tricky, since we will need to recognize them and keep for possible use
later. It would however make sense.


[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files

2014-09-09 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215

--- Comment #2 from Jan Hubicka  ---
As an ugly workaround, marking them __attribute__ ((externally_visible, used))
should work. They will however be added into every binary that is linked with
them no mater if they are used or not.


[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files

2014-09-09 Thread patrick at motec dot com.au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215

--- Comment #3 from Patrick Oppenlander  ---
Thanks for the information!

Is there a list of these functions somewhere?

Is this somehow related to bug 60395?

Thanks,

Patrick


[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611

2014-09-09 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63166

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Wed Sep 10 06:33:36 2014
New Revision: 215105

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

PR ipa/63166
* ipa-prop.c (compute_known_type_jump_func): Fix conditional.

* g++.dg/lto/pr63166_0.ii: New testcase.
* g++.dg/lto/pr63166_1.ii: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr63166_0.ii
trunk/gcc/testsuite/g++.dg/lto/pr63166_1.ii
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog