[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE

2014-08-04 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Evandro Menezes from comment #3)
> Created attachment 33246 [details]
> This patch should fix this issue, though it needs a test-case

Please post to gcc-patches with a testcase.
I'd prefer if you used TARGET_FP rather than !TARGET_GENERAL_REGS_ONLY


[Bug fortran/61910] undefined computation in trans-expr.c gfc_conv_cst_int_power

2014-08-04 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910

--- Comment #3 from Vittorio Zecca  ---
A fix for the offending instruction at trans-expr.c:2107
"n = (unsigned HOST_WIDE_INT) (m < 0 ? -m : m);"
might be
"n = (unsigned HOST_WIDE_INT) (m < 0 ? - (unsigned HOST_WIDE_INT) m : m);"
So it seems this is not a sanitizer bug.


[Bug middle-end/61529] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953

2014-08-04 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529

--- Comment #2 from Zhendong Su  ---
Here is another test case that triggers the same ICE: 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-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 4.10.0 20140804 (experimental) [trunk revision 213529] (GCC) 
$ 
$ gcc-trunk -O3 small.c 
small.c: In function ‘main’:
small.c:9:1: internal compiler error: in check_probability, at
basic-block.h:956
 main ()
 ^
0xbb3e56 check_probability
../../gcc-trunk/gcc/basic-block.h:956
0xbb1631 check_probability
../../gcc-trunk/gcc/tree-vect-loop-manip.c:653
0xbb1631 combine_probabilities
../../gcc-trunk/gcc/basic-block.h:965
0xbb1631 slpeel_tree_peel_loop_to_edge
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1371
0xbb19a4 vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node*,
tree_node*, unsigned int, bool)
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1761
0xba2b07 vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:5853
0xbbfae6 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:478
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.
$ 


--


struct
{
  unsigned int f0;
} a;

int b, c;

int
main ()
{
  unsigned int d;
  int e[5];

  for (; b < 1; b++)
d = 0;
  for (; d < 1; d++)
a.f0 = 0;
  for (; a.f0 < 1; a.f0++)
;
  for (c = 0; c < 5; c++)
e[c] = 1;
  if (e[0])
c = 0;

  return 0;
}

[Bug ipa/62016] New: very slow compilation at -O3 on x86_64-linux-gnu

2014-08-04 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016

Bug ID: 62016
   Summary: very slow compilation at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following test case takes the current gcc trunk much longer to compile at
-O3 on x86_64-linux (in both 32-bit and 64-bit modes). 

It also affects gcc 4.8.x and 4.9.x, and is a regression from 4.7.x. 

This is likely due to the inliner as the code compiles fine with -fno-inline.  

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-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 4.10.0 20140804 (experimental) [trunk revision 213529] (GCC) 
$ 
$ time gcc-trunk -O2 small.c
0.02user 0.01system 0:00.28elapsed 15%CPU (0avgtext+0avgdata 50912maxresident)k
0inputs+32outputs (1major+6643minor)pagefaults 0swaps
$ time gcc-4.7 -O3 small.c
0.11user 0.02system 0:00.71elapsed 19%CPU (0avgtext+0avgdata 65344maxresident)k
0inputs+32outputs (1major+7683minor)pagefaults 0swaps
$ 
$ time gcc-trunk -O3 -fno-inline small.c
0.04user 0.01system 0:00.47elapsed 12%CPU (0avgtext+0avgdata 51776maxresident)k
0inputs+32outputs (1major+6709minor)pagefaults 0swaps
$ 
$ time gcc-trunk -O3 small.c
8.43user 0.28system 0:34.83elapsed 25%CPU (0avgtext+0avgdata
1622880maxresident)k
0inputs+32outputs (1major+106347minor)pagefaults 0swaps
$ 


--


#include 

int a, b, c, d, e, f, g, h, i, j;

void
fn1 (int *p1, int *p2)
{
  for (; a; a++)
{
  assert (p1 == 0);
  fn1 (0, p2);
  fn1 (&i, &b);
  fn1 (&f, 0);
}
}

void
fn2 ()
{
  fn1 (&c, 0);
  fn1 (&d, 0);
  fn1 (&e, 0);
  fn1 (&g, 0);
  fn1 (&h, 0);
  fn1 (&j, 0);
}

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


[Bug fortran/61910] undefined computation in trans-expr.c gfc_conv_cst_int_power

2014-08-04 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910

--- Comment #2 from Vittorio Zecca  ---
It appears not depending on i value, for i=1 or 2.

No explicit options used.
Of course I used options -fsanizitized=address -fsanitized=undefined
to generate gfortran.
I think it is either a gfortran or a sanitizer bug.


[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]

2014-08-04 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #7 from Ian Lance Taylor  ---
Fixed.


[Bug go/61866] FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments

2014-08-04 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61866

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

Thanks for reporting it.


[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]

2014-08-04 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308

--- Comment #6 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Aug  5 03:11:17 2014
New Revision: 213618

URL: https://gcc.gnu.org/viewcvs?rev=213618&root=gcc&view=rev
Log:
PR go/61308

compiler: Handle enclosing vars for function type in function lit.

This fixes a dumb bug in which the enclosing vars were
incorrectly cleared when a function literal contains a
reference to a function type.  The test for this will go into
the master repository in the change at
http://codereview.appspot.com/121200043 .

Modified:
trunk/gcc/go/gofrontend/parse.cc


[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]

2014-08-04 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Aug  5 03:10:53 2014
New Revision: 213617

URL: https://gcc.gnu.org/viewcvs?rev=213617&root=gcc&view=rev
Log:
PR go/61308

compiler: Handle enclosing vars for function type in function lit.

This fixes a dumb bug in which the enclosing vars were
incorrectly cleared when a function literal contains a
reference to a function type.  The test for this will go into
the master repository in the change at
http://codereview.appspot.com/121200043 .

Modified:
branches/gcc-4_9-branch/gcc/go/gofrontend/parse.cc


[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]

2014-08-04 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Aug  5 02:58:15 2014
New Revision: 213616

URL: https://gcc.gnu.org/viewcvs?rev=213616&root=gcc&view=rev
Log:
PR go/61308
PR go/61866

compiler: Don't cast index expr to int before bounds check.

This fixes http://gcc.gnu.org/PR61866 : on a 32-bit system,
casting an int64 index to int drops the upper 32 bits of the
value, and thus can cause an out-of-range index to appear to
be in range.

This undoes part of change 1318:fa6e0c716dba
(https://codereview.appspot.com/104610044) and therefore
breaks http://gcc.gnu.org/PR61308 again.  I have a separate
patch for that (http://codereview.appspot.com/122020043).  In
addition to undoing part of that change, this patch adds code
to avoid a compiler crash.  This changes PR61308 from a
compiler crash to an incorrect error message.

Modified:
trunk/gcc/go/gofrontend/expressions.cc


[Bug go/61866] FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments

2014-08-04 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61866

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Aug  5 02:58:15 2014
New Revision: 213616

URL: https://gcc.gnu.org/viewcvs?rev=213616&root=gcc&view=rev
Log:
PR go/61308
PR go/61866

compiler: Don't cast index expr to int before bounds check.

This fixes http://gcc.gnu.org/PR61866 : on a 32-bit system,
casting an int64 index to int drops the upper 32 bits of the
value, and thus can cause an out-of-range index to appear to
be in range.

This undoes part of change 1318:fa6e0c716dba
(https://codereview.appspot.com/104610044) and therefore
breaks http://gcc.gnu.org/PR61308 again.  I have a separate
patch for that (http://codereview.appspot.com/122020043).  In
addition to undoing part of that change, this patch adds code
to avoid a compiler crash.  This changes PR61308 from a
compiler crash to an incorrect error message.

Modified:
trunk/gcc/go/gofrontend/expressions.cc


[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]

2014-08-04 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308

--- Comment #3 from Ian Lance Taylor  ---
Test committed to master repository as fixedbugs/bug489.go.


[Bug ipa/62015] New: ipa-cp-clone uses a clone that is too specialized for the call context

2014-08-04 Thread oremanj at mit dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015

Bug ID: 62015
   Summary: ipa-cp-clone uses a clone that is too specialized for
the call context
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oremanj at mit dot edu

In the C++ program below, interprocedural constant propagation cloning creates
a clone of A::adjust() specialized for adjust(Side::Invalid, false). This clone
is then used for an adjust(side, false) call when there is no way to prove side
== Side::Invalid. This bug is present in gcc 4.8.2, is not present in 4.7.3,
and is still present in a version compiled from today's SVN. Using an
optimization level less than -O3 or passing -fno-ipa-cp-clone prevents the bug
from manifesting. The onset of the bug was bisected to commit r193410.

$ cat t.cc
extern "C" int printf(const char *fmt, ...);

struct Side {
enum _Value { Left, Right, Invalid };

constexpr Side() : _value(Invalid) {}
constexpr Side(_Value value) : _value(value) {}
operator _Value() const { return (_Value)_value; }

  private:
char _value;
};

struct A {
void init();
void adjust(Side side, bool final);
void move(Side side);
};

void A::init()
{
adjust(Side::Invalid, false);
}

__attribute__((noinline))
void A::adjust(Side side, bool final)
{
printf("adjust: side is %d, final %d\n", (int)side, final);
}

void A::move(Side side)
{
printf("move: side is %d\n", (int)side);
adjust(side, false);
adjust(side, true);
}

int main()
{
A t;
t.move(Side::Left);
}

$ g++49 -v
Using built-in specs.
COLLECT_GCC=g++49
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local --disable-nls
--libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49
--program-suffix=49 --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/
--with-libiconv-prefix=/usr/local --with-system-zlib --disable-rpath
--enable-languages=c,c++ --mandir=/usr/local/man
--infodir=/usr/local/info/gcc49 --disable-initfini-array
--disable-install-libiberty
Thread model: posix
gcc version 4.10.0 20140804 (experimental) (GCC)

$ g++49 -Wall -Wextra -o t t.cc -std=c++11 -O3
$ ./t
move: side is 0
adjust: side is 2, final 0
adjust: side is 0, final 1

The output should be 'side is 0' on all three lines.


[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.4
  Known to fail||4.3.0, 4.8.3, 4.9.1

--- Comment #6 from Jonathan Wakely  ---
fixed for 4.8.4


[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug  4 22:31:51 2014
New Revision: 213612

URL: https://gcc.gnu.org/viewcvs?rev=213612&root=gcc&view=rev
Log:
Backported from mainline
2014-07-29  Jonathan Wakely  

PR libstdc++/61946
* include/ext/rope (rope::rope(char_producer<_CharT>*, size_t, bool,
const allocator_type&)): Pass non-const allocator to
_S_new_RopeFunction.
* testsuite/ext/rope/61946.cc: New.

Added:
branches/gcc-4_9-branch/libstdc++-v3/testsuite/ext/rope/61946.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/ext/rope


[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug  4 22:16:44 2014
New Revision: 213611

URL: https://gcc.gnu.org/viewcvs?rev=213611&root=gcc&view=rev
Log:
Backported from mainline
2014-07-29  Jonathan Wakely  

PR libstdc++/61946
* include/ext/rope (rope::rope(char_producer<_CharT>*, size_t, bool,
const allocator_type&)): Pass non-const allocator to
_S_new_RopeFunction.
* testsuite/ext/rope/61946.cc: New.

Added:
branches/gcc-4_8-branch/libstdc++-v3/testsuite/ext/rope/61946.cc
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/ext/rope


[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE

2014-08-04 Thread e.menezes at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014

Evandro Menezes  changed:

   What|Removed |Added

  Attachment #33245|0   |1
is obsolete||

--- Comment #3 from Evandro Menezes  ---
Created attachment 33246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33246&action=edit
This patch should fix this issue, though it needs a test-case


[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE

2014-08-04 Thread e.menezes at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014

--- Comment #2 from Evandro Menezes  ---
(In reply to Andrew Pinski from comment #1)
> +  /* Do not spill into FP registers when "-mgeneral-regs-only" is
> specified. *
> 
> You are missing a / in your comment.

Ermahgerd!


[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE

2014-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014

--- Comment #1 from Andrew Pinski  ---
+  /* Do not spill into FP registers when "-mgeneral-regs-only" is specified. *

You are missing a / in your comment.


[Bug target/62014] New: [AArch64] Using -mgeneral-regs-only may lead to ICE

2014-08-04 Thread e.menezes at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014

Bug ID: 62014
   Summary: [AArch64] Using -mgeneral-regs-only may lead to ICE
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e.menezes at samsung dot com

Created attachment 33245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33245&action=edit
This patch should fix this issue, though it needs a test-case.

In some cases, when the LRA spills a register into an FP register, with the
option -mgeneral-regs-only specified, there is an ICE.

It seems to be caused by the LRA assuming that the FP registers are always
available and not being told when they aren't by the target.


[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable

2014-08-04 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005

--- Comment #5 from Marc Glisse  ---
(In reply to Marc Glisse from comment #4)
> Compiling without RTL checking but with -fkeep-inline-functions
> probably warns as well then.

Uh, for some reason -fkeep-inline-functions does not preserve static functions,
but it does preserve static inline functions (so it warns if I add "inline" on
the definition of get_ivts_expr). I couldn't find a -fkeep-static-functions.


[Bug c++/49718] please allow no_instrument_function attribute in class member definition/declaration

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #6 from Jonathan Wakely  ---
(In reply to bradley_small from comment #5)
> This behavior still appears in version 4.8 
> g++-4.8 (Debian 4.8.3-6) 4.8.3

To be expected, it was only fixed in January, prior to the GCC 4.9.0 release.


[Bug c++/49718] please allow no_instrument_function attribute in class member definition/declaration

2014-08-04 Thread bradley_small at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718

bradley_small at hotmail dot com changed:

   What|Removed |Added

 CC||bradley_small at hotmail dot 
com

--- Comment #5 from bradley_small at hotmail dot com ---
This behavior still appears in version 4.8 
g++-4.8 (Debian 4.8.3-6) 4.8.3


[Bug libstdc++/58962] Pretty printers use obsolete Python syntax

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|4.10.0  |4.9.2

--- Comment #8 from Jonathan Wakely  ---
backported for 4.9.2


[Bug libstdc++/61390] error in nested template parameter in ext/pb_ds header file

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61390

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.2

--- Comment #4 from Jonathan Wakely  ---
fixed for 4.9.2


[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable

2014-08-04 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005

--- Comment #4 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #3)
> That said, an interesting question is why we don't warn about this without
> rtl checking, the function still returns address of the parameter.  Is that
> because it is inlined in that case and so we don't warn then?

That seems likely, RTL checking may make the function large enough not to be
inlined. Compiling without RTL checking but with -fkeep-inline-functions
probably warns as well then.


[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

2014-08-04 Thread michael.collison at linaro dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

--- Comment #7 from Michael Collison  ---
Charlie,

I still feel that the var tracking pass should be able to protect itself 
from an infinite loop.

On 8/4/2014 11:43 AM, cbaylis at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033
>
> --- Comment #6 from cbaylis at gcc dot gnu.org ---
>
> git bisect points to r211625 as the revision which fixes/hides this bug on
> trunk.
>
> 2014-06-13  Richard Biener  
>
>  * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
>  Rewrite to propagate the VN result into all uses where
>  possible and to remove stmts becoming dead because of that.
>  (eliminate): Generalize stmt removal handling, remove in
>  reverse dominator order to support proper debug stmt
>  generation.  Update stmts before removing stmts.
>  * tree-ssa-propagate.c (propagate_tree_value): Remove
>  bogus assert.
>


[Bug libstdc++/61374] string_view::operator string() is buggy

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61374

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
fixed for 4.9.2


[Bug libstdc++/61390] error in nested template parameter in ext/pb_ds header file

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61390

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug  4 18:50:25 2014
New Revision: 213603

URL: https://gcc.gnu.org/viewcvs?rev=213603&root=gcc&view=rev
Log:
Backported from mainline
2014-06-10  Jonathan Wakely  

PR libstdc++/61390
* include/ext/pb_ds/detail/bin_search_tree_/traits.hpp
(bin_search_tree_traits): Do not redeclare template-parameters.
* testsuite/util/testsuite_iterators.h (test_container): Likewise.

Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_9-branch/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/traits.hpp
branches/gcc-4_9-branch/libstdc++-v3/testsuite/util/testsuite_iterators.h


[Bug libstdc++/58962] Pretty printers use obsolete Python syntax

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug  4 18:50:30 2014
New Revision: 213604

URL: https://gcc.gnu.org/viewcvs?rev=213604&root=gcc&view=rev
Log:
2014-08-04  Samuel Bronson  

Backport r212453 from trunk
2014-07-11  Samuel Bronson  
Matthias Klose  

PR libstdc++/58962
* python/libstdcxx/v6/printers.py: Port to Python 2+3
(imap): New compat function.
(izip): Likewise.
(Iterator): New mixin to allow writing iterators in Python 3 style
regardless of which version we're running on.
[Python3] (long) New compat alias for "int".
* testsuite/lib/gdb-test.exp: Port to Python 2+3 (print syntax)

Backport r210625 from trunk
2014-05-19  Jonathan Wakely  

* python/libstdcxx/v6/printers.py: Use Python3 raise syntax.

Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
branches/gcc-4_9-branch/libstdc++-v3/testsuite/lib/gdb-test.exp


[Bug libstdc++/61374] string_view::operator string() is buggy

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61374

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug  4 18:50:14 2014
New Revision: 213601

URL: https://gcc.gnu.org/viewcvs?rev=213601&root=gcc&view=rev
Log:
Backported from mainline
2014-06-01  Jonathan Wakely  

PR libstdc++/61374
* include/experimental/string_view (operator basic_string): Correct
order of arguments.
(to_string): Replace with member function.
Add inline specifiers. Remove unused header. Remove _S_empty_rep and
allow _M_str to be null.
* testsuite/experimental/string_view/cons/char/1.cc: Adjust to new
default constructor semantics.
* testsuite/experimental/string_view/cons/wchar_t/1.cc: Likewise.
* testsuite/experimental/string_view/operations/copy/char/1.cc: Fix
copyright dates. Remove unused header.
* testsuite/experimental/string_view/operations/copy/wchar_t/1.cc:
Likewise.
* testsuite/experimental/string_view/operations/data/char/1.cc:
Fix copyright dates. Adjust to new default constructor semantics.
* testsuite/experimental/string_view/operations/data/wchar_t/1.cc:
Likewise.
* testsuite/experimental/string_view/operations/to_string/1.cc: New.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/to_string/
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/to_string/1.cc
  - copied, changed from r213600,
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/experimental/string_view
branches/gcc-4_9-branch/libstdc++-v3/include/experimental/string_view.tcc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/cons/char/1.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/cons/wchar_t/1.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/1.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/data/char/1.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/string_view/operations/data/wchar_t/1.cc


[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable

2014-08-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I've posted a loop-unroll.c fix.

That said, an interesting question is why we don't warn about this without rtl
checking, the function still returns address of the parameter.  Is that because
it is inlined in that case and so we don't warn then?


[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

2014-08-04 Thread cbaylis at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

--- Comment #6 from cbaylis at gcc dot gnu.org ---

git bisect points to r211625 as the revision which fixes/hides this bug on
trunk.

2014-06-13  Richard Biener  

* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
Rewrite to propagate the VN result into all uses where
possible and to remove stmts becoming dead because of that.
(eliminate): Generalize stmt removal handling, remove in
reverse dominator order to support proper debug stmt
generation.  Update stmts before removing stmts.
* tree-ssa-propagate.c (propagate_tree_value): Remove
bogus assert.


[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

2014-08-04 Thread cbaylis at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cbaylis at gcc dot gnu.org

--- Comment #5 from cbaylis at gcc dot gnu.org ---
Created attachment 33244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33244&action=edit
Reduced test case


$ arm-unknown-linux-gnueabihf-gcc -S -O2 -g reduced1.cpp


[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

2014-08-04 Thread edmarwjr at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102

--- Comment #18 from edmarwjr at gcc dot gnu.org ---
Author: edmarwjr
Date: Mon Aug  4 16:55:07 2014
New Revision: 213598

URL: https://gcc.gnu.org/viewcvs?rev=213598&root=gcc&view=rev
Log:
[gcc/testsuite]
2014-08-04  Rohit  

PR target/60102
* gcc.target/powerpc/pr60102.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr60102.c
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

2014-08-04 Thread edmarwjr at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102

--- Comment #17 from edmarwjr at gcc dot gnu.org ---
Author: edmarwjr
Date: Mon Aug  4 16:48:53 2014
New Revision: 213597

URL: https://gcc.gnu.org/viewcvs?rev=213597&root=gcc&view=rev
Log:
PR target/60102

[libgcc]
2014-08-04  Rohit  
* config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update
  based on change in SPE high register numbers and 3 HTM registers.

[gcc]
2014-08-04  Rohit  
* config/rs6000/rs6000.c
  (rs6000_reg_names) : Add SPE high register names.
  (alt_reg_names) : Likewise.
  (rs6000_dwarf_register_span) : For SPE high registers, replace
  dwarf register numbers with GCC hard register numbers.
  (rs6000_init_dwarf_reg_sizes_extra) : Likewise.
  (rs6000_dbx_register_number): For SPE high registers, return dwarf
  register number for the corresponding GCC hard register number.

* config/rs6000/rs6000.h
  (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard
  register numbers for SPE high registers.
  (DWARF_FRAME_REGISTERS) :  Likewise.
  (DWARF_REG_TO_UNWIND_COLUMN) : Likewise.
  (DWARF_FRAME_REGNUM) : Likewise.
  (FIXED_REGISTERS) : Likewise.
  (CALL_USED_REGISTERS) : Likewise.
  (CALL_REALLY_USED_REGISTERS) : Likewise.
  (REG_ALLOC_ORDER) : Likewise.
  (enum reg_class) : Likewise.
  (REG_CLASS_NAMES) : Likewise.
  (REG_CLASS_CONTENTS) : Likewise.
  (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers.

[gcc/testsuite]
2014-08-04  Rohit  
* gcc.target/powerpc/pr60102.c: New testcase.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr60102.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/libgcc/ChangeLog
branches/gcc-4_9-branch/libgcc/config/rs6000/linux-unwind.h


[Bug fortran/62010] OpenMP simd produces wrong results

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010

Alexander Grund  changed:

   What|Removed |Added

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

--- Comment #4 from Alexander Grund  ---
You are right. It seems i missed that when I changed the code the last time and
forgot that it is private and not firstprivate. Without that it works.

Thanks for that!


[Bug fortran/62010] OpenMP simd produces wrong results

2014-08-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The testcases look invalid to me.  If you make j1 private, then it is
uninitialized in the loop, so if the program doesn't crash, it is by pure luck.
The other variables listed in private clause are not used in the simd loop at
all, so it doesn't make any sense to list them there.  So, just remove all
private clauses and you should be fine.


[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

2014-08-04 Thread edmarwjr at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102

--- Comment #16 from edmarwjr at gcc dot gnu.org ---
Author: edmarwjr
Date: Mon Aug  4 16:34:34 2014
New Revision: 213596

URL: https://gcc.gnu.org/viewcvs?rev=213596&root=gcc&view=rev
Log:
PR target/60102

[libgcc]
2014-07-31  Rohit  
* config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update
  based on change in SPE high register numbers and 3 HTM registers.

[gcc]
2014-07-31  Rohit  
* config/rs6000/rs6000.c
  (rs6000_reg_names) : Add SPE high register names.
  (alt_reg_names) : Likewise.
  (rs6000_dwarf_register_span) : For SPE high registers, replace
  dwarf register numbers with GCC hard register numbers.
  (rs6000_init_dwarf_reg_sizes_extra) : Likewise.
  (rs6000_dbx_register_number): For SPE high registers, return dwarf
  register number for the corresponding GCC hard register number.

* config/rs6000/rs6000.h
  (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard
  register numbers for SPE high registers.
  (DWARF_FRAME_REGISTERS) :  Likewise.
  (DWARF_REG_TO_UNWIND_COLUMN) : Likewise.
  (DWARF_FRAME_REGNUM) : Likewise.
  (FIXED_REGISTERS) : Likewise.
  (CALL_USED_REGISTERS) : Likewise.
  (CALL_REALLY_USED_REGISTERS) : Likewise.
  (REG_ALLOC_ORDER) : Likewise.
  (enum reg_class) : Likewise.
  (REG_CLASS_NAMES) : Likewise.
  (REG_CLASS_CONTENTS) : Likewise.
  (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers.

* gcc.target/powerpc/pr60102.c: New testcase.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/rs6000.md
trunk/libgcc/ChangeLog
trunk/libgcc/config/rs6000/linux-unwind.h


[Bug debug/61033] Infinite loop in variable tracking

2014-08-04 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Target|arm-linux-gnueabi   |arm-linux-gnueabi,
   ||arm-none-eabi
  Known to work||4.10.0, 4.7.4
  Known to fail||4.8.3, 4.9.1

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Filling in some fields, this still fails on the 4.8 and 4.9 branches but works
on trunk.


[Bug debug/61033] Infinite loop in variable tracking

2014-08-04 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
*** Bug 62013 has been marked as a duplicate of this bug. ***


[Bug target/62013] [4.8/4.9 Regresion] cc1plus doesn't terminate when called with -g on arm-linux-gnueabihf

2014-08-04 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62013

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'm willing to bet this is a duplicate of 61033 that also involves a
qmltextgenerator.ii preprocessed reproducer file ;)

It goes into an infinite loop for me on arm-none-eabi with 4.9 and passes with
current trunk. Didn't try 4.8, I expect it fails there like you say.

I don't remember if it was fixed in trunk and the fix not backported or just
made latent.

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


[Bug target/62013] New: [4.8/4.9 Regresion] cc1plus doesn't terminate when called with -g on arm-linux-gnueabihf

2014-08-04 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62013

Bug ID: 62013
   Summary: [4.8/4.9 Regresion] cc1plus doesn't terminate when
called with -g on arm-linux-gnueabihf
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

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

seen on the 4.8 and 4.9 branch, cc1plus doesn't terminate. omitting the -g lets
the command succeed.

$ g++ -v -std=c++0x -c -g -O2 qmltextgenerator.cpp


Program received signal SIGINT, Interrupt.
0x0054920c in canonicalize_values_star(variable_def**, dataflow_set_def*) ()
(gdb) bt
#0  0x0054920c in canonicalize_values_star(variable_def**, dataflow_set_def*)
()
#1  0x0054b0c2 in ?? ()
#2  0x0054ca08 in ?? ()
#3  0x0054d8ba in ?? ()
#4  0x0039928a in execute_one_pass(opt_pass*) ()
#5  0x00399448 in execute_pass_list(opt_pass*) ()
#6  0x00399452 in execute_pass_list(opt_pass*) ()
#7  0x00399452 in execute_pass_list(opt_pass*) ()
#8  0x00244a8c in ?? ()
#9  0x00245ca4 in compile() ()
#10 0x00246030 in finalize_compilation_unit() ()
#11 0x00158fc4 in cp_write_global_declarations() ()
#12 0x00409394 in ?? ()
#13 0x0040aad0 in toplev_main(int, char**) ()
#14 0xb6d4f630 in __libc_start_main (main=0x111e19 , argc=26, 
argv=0xbefff604, init=, fini=0x7b2af5 <__libc_csu_fini>, 
rtld_fini=0xb6fe24e5 <_dl_fini>, stack_end=0xbefff604) at libc-start.c:287
#15 0x00112058 in _start ()

defaults are -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb


[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load

2014-08-04 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 33242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33242&action=edit
patch to fix if-conversion

(In reply to Richard Biener from comment #1)
> Heh, interesting set of events ;)
> 
> Now it is interesting how much we desire to perform the tail-merging - we
> _could_
> change the alias sets of loads (and stores...) to a "common" one (either if
> they
> are "equal" or just zero otherwise).  Depends on how much we like this kind
> of pessimization.
> 
> Same for the RTL bits of course.
> 
> Btw, I still see the conditional execution after RTL expansion, just
> cfglayout mode doesn't have unconditonal gotos for the edges.

Right, when doing fdump-rtl-all, it looks like fallthrough, but it isn't, I
forgot. So it's just if-conversion that does the wrong thing.

Attached patch fixes 4.8 if-conversion in a conservative way (I suppose we want
a conservative fix for 4.8 and 4.9). OK for testing?


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

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 33241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33241&action=edit
test-case to reproduce

Options to compile are:
-Ofast -m64 -march=core-avx2 -fopenmp
and macros -DPARAM can be used to get vectorizable version of test.


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

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

Bug ID: 62012
   Summary: Loop is not vectorized after function inlining (SCEV)
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

We noticed that for one important benchmark using '-lto' options leads to
performance degradation which is caused by not-vectorizing the hottest loop
after function inlining. I can able to reproduce this deficiency using simple
test-case:
if we passed class by reference to function (it need to be compiled with
-DPARAM macros) loop is vectorized:
g++ -Ofast -m64 -march=core-avx2 -c test.cpp  -fdump-tree-vect-details -fopenmp
-DPARAM; grep 'note: vectorized' test.cpp.114t.vect 
test.cpp:45:1: note: vectorized 1 loops in function.

But if we compile it without macros we get:
g++ -Ofast -m64 -march=core-avx2 -c test.cpp  -fdump-tree-vect-details
-fopenmp; grep 'note: vectorized' test.cpp.114t.vect
test.cpp:45:1: note: vectorized 0 loops in function.

It looks like SCEV issue.


[Bug rtl-optimization/62011] New: False Data Dependency in popcnt instruction

2014-08-04 Thread debiandev at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011

Bug ID: 62011
   Summary: False Data Dependency in popcnt instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: debiandev at gmail dot com

On Sandy/Ivy Bridge and Haswell processors, the instruction:

popcnt src, dest

appears to have a false dependency on the destination register dest. Even
though the instruction only writes to it, the instruction will wait until dest
is ready before executing.

This causes a loss in performance as explained here:
http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance


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

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

--- Comment #7 from Yuri Rumyantsev  ---
It really fixes the issue. Thanks.


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread tkoeppe at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #11 from Thomas Köppe  ---
Created attachment 33240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33240&action=edit
Further fixing: Uses uintptr_ts for the difference

On Jonathan's suggestion I changed the distance computation to go through a
uintptr_t conversion.

Jonathan suggested compiling with -fno-elide-constructors, and indeed the
attached code breaks when that option is passed. As you said, the UB caused by
the distance computations of automatic objects seems to be the stumbling point.

[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #10 from rguenther at suse dot de  ---
On Mon, 4 Aug 2014, tkoeppe at google dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006
> 
> --- Comment #9 from Thomas Köppe  ---
> Argh, yes, I compiled the wrong file... indeed, the arena version works with
> GCC 4.8.2 for me, too, and in Clang as well.
> 
> So... not an issue, I suppose?

I think the issue only triggers when you end up using automatic
variables for the difference computation.

[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)

2014-08-04 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0


[Bug fortran/62010] OpenMP simd produces wrong results

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010

--- Comment #2 from Alexander Grund  ---
Related to this: In some cases OpenMP simd crashes while that crash is fixed by
removing an unrelated piece of code. See Testcase 2.

Run with:
 gfortran-4.9 gfortranBug.f -cpp && ./a.out && gfortran-4.9 gfortranBug.f -cpp
-fopenmp && ./a.out

Output:
 size  12 x  10 x   5
  -29032800293.326649 
 size  12 x  10 x   5
   3554.004000376 

Expected: Same output

And to crash run with:
gfortran-4.9 gfortranBug.f -cpp -D CRASH && ./a.out && gfortran-4.9
gfortranBug.f -cpp -D CRASH -fopenmp && ./a.out

Output:
 size  12 x  10 x   5
   3840.3482323232652 
 size  12 x  10 x   5

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.


[Bug fortran/62010] OpenMP simd produces wrong results

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010

--- Comment #1 from Alexander Grund  ---
Created attachment 33239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33239&action=edit
Testcase 2


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread tkoeppe at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #9 from Thomas Köppe  ---
Argh, yes, I compiled the wrong file... indeed, the arena version works with
GCC 4.8.2 for me, too, and in Clang as well.

So... not an issue, I suppose?

The desired real application will be for containers allocated in shared memory,
which is presumably obtained from some opaque system feature.

[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)

2014-08-04 Thread cbaylis at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from cbaylis at gcc dot gnu.org ---
Fixed in r213376

Mailing list thread: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02009.html


[Bug fortran/62010] New: OpenMP simd produces wrong results

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62010

Bug ID: 62010
   Summary: OpenMP simd produces wrong results
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.grund at mailbox dot tu-dresden.de

Created attachment 33238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33238&action=edit
Testcase 1

Using the OpenMP 4.0 SIMD construct results in wrong calculation results in
some cases. (See testcase 1)

To reproduce: simply run:
gfortran-4.9 gfortranBug.f && ./a.out && gfortran-4.9 gfortranBug.f -fopenmp &&
./a.out

Output:
 size  12
   36.016765295885790 
 size  12
   35.454228116260587 

Expected: Same for both cases.


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #8 from Richard Biener  ---
The fixed demog works for me (GCC 4.9 and 4.8 at least).


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #7 from Richard Biener  ---
Smells like a duplicate of PR49330 - still always returning 1 from
base_alias_check doesn't fix the original testcase.

Which also fails with -O -ftree-pre -ftree-partial-pre -fstrict-aliasing btw.


[Bug bootstrap/62009] Bootstrap failure in vec.h::splice

2014-08-04 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Valgrind show:

==20810== Invalid read of size 8
==20810==at 0xBA4A6F: redirect_edge_var_map_dup(edge_def*, edge_def*)
(vec.h:1184)
==20810==by 0x675552: redirect_edge_succ_nodup(edge_def*, basic_block_def*)
(cfghooks.c:437)
==20810==by 0xA18098: gimple_redirect_edge_and_branch(edge_def*,
basic_block_def*) (tree-cfg.c:5419)
==20810==by 0x6753C9: redirect_edge_and_branch(edge_def*, basic_block_def*)
(cfghooks.c:356)
==20810==by 0x675482: remove_branch(edge_def*) (cfghooks.c:398)
==20810==by 0x67F062: remove_path(edge_def*) (cfgloopmanip.c:384)
==20810==by 0xAFE5C2: canonicalize_loop_induction_variables(loop*, bool,
unroll_level, bool) (tree-ssa-loop-ivcanon.c:845)
==20810==by 0xAFEE4F: tree_unroll_loops_completely_1(bool, bool, vec&, loop*) (tree-ssa-loop-ivcanon.c:1149)
==20810==by 0xAFEDD0: tree_unroll_loops_completely_1(bool, bool, vec&, loop*) (tree-ssa-loop-ivcanon.c:1123)
==20810==by 0xAFF802: tree_unroll_loops_completely(bool, bool)
(tree-ssa-loop-ivcanon.c:1193)
==20810==by 0x92D88C: execute_one_pass(opt_pass*) (passes.c:2149)
==20810==by 0x92DE15: execute_pass_list_1(opt_pass*) (passes.c:2201)
==20810==  Address 0x55a5f08 is 152 bytes inside a block of size 208 free'd
==20810==at 0x40298D0: free (vg_replace_malloc.c:468)
==20810==by 0xBA52ED: hash_table, default_hashmap_traits>::hash_entry, xcallocator,
true>::find_slot_with_hash(edge_def* 
const&, unsigned int, insert_option) (hash-table.h:1370)
==20810==by 0xBA4A61: redirect_edge_var_map_dup(edge_def*, edge_def*)
(hash-map.h:177)
==20810==by 0x675552: redirect_edge_succ_nodup(edge_def*, basic_block_def*)
(cfghooks.c:437)
==20810==by 0xA18098: gimple_redirect_edge_and_branch(edge_def*,
basic_block_def*) (tree-cfg.c:5419)
==20810==by 0x6753C9: redirect_edge_and_branch(edge_def*, basic_block_def*)
(cfghooks.c:356)
==20810==by 0x675482: remove_branch(edge_def*) (cfghooks.c:398)
==20810==by 0x67F062: remove_path(edge_def*) (cfgloopmanip.c:384)
==20810==by 0xAFE5C2: canonicalize_loop_induction_variables(loop*, bool,
unroll_level, bool) (tree-ssa-loop-ivcanon.c:845)
==20810==by 0xAFEE4F: tree_unroll_loops_completely_1(bool, bool, vec&, loop*) (tree-ssa-loop-ivcanon.c:1149)
==20810==by 0xAFEDD0: tree_unroll_loops_completely_1(bool, bool, vec&, loop*) (tree-ssa-loop-ivcanon.c:1123)
==20810==by 0xAFF802: tree_unroll_loops_completely(bool, bool)
(tree-ssa-loop-ivcanon.c:1193)
==20810== 
==20810== Conditional jump or move depends on uninitialised value(s)
==20810==at 0xECD18A: register_active_defs(df_ref_d*) (sparseset.h:147)
==20810==by 0xECD23E: update_df_init(rtx_def*, rtx_def*) (fwprop.c:878)
==20810==by 0xECD564: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*,
rtx_def*, bool) (fwprop.c:945)
==20810==by 0xECDA5A: forward_propagate_into(df_ref_d*) (fwprop.c:1320)
==20810==by 0xECDFE7: (anonymous
namespace)::pass_rtl_fwprop::execute(function*) (fwprop.c:1457)
==20810==by 0x92D88C: execute_one_pass(opt_pass*) (passes.c:2149)
==20810==by 0x92DE15: execute_pass_list_1(opt_pass*) (passes.c:2201)
==20810==by 0x92DE27: execute_pass_list_1(opt_pass*) (passes.c:2202)
==20810==by 0x92DE68: execute_pass_list(function*, opt_pass*)
(passes.c:2212)
==20810==by 0x6997AF: expand_function(cgraph_node*) (cgraphunit.c:1776)
==20810==by 0x69ADD3: compile() (cgraphunit.c:1910)
==20810==by 0x69C874: finalize_compilation_unit() (cgraphunit.c:2331)
==20810==  Uninitialised value was created by a heap allocation
==20810==at 0x4028510: malloc (vg_replace_malloc.c:291)
==20810==by 0xFC8D27: xmalloc (xmalloc.c:147)
==20810==by 0x9CE0A4: sparseset_alloc(unsigned long) (sparseset.c:33)
==20810==by 0xECCA82: fwprop_init() (fwprop.c:1401)
==20810==by 0xECDF5A: (anonymous
namespace)::pass_rtl_fwprop::execute(function*) (fwprop.c:1441)
==20810==by 0x92D88C: execute_one_pass(opt_pass*) (passes.c:2149)
==20810==by 0x92DE15: execute_pass_list_1(opt_pass*) (passes.c:2201)
==20810==by 0x92DE27: execute_pass_list_1(opt_pass*) (passes.c:2202)
==20810==by 0x92DE68: execute_pass_list(function*, opt_pass*)
(passes.c:2212)
==20810==by 0x6997AF: expand_function(cgraph_node*) (cgraphunit.c:1776)
==20810==by 0x69ADD3: compile() (cgraphunit.c:1910)
==20810==by 0x69C874: finalize_compilation_unit() (cgraphunit.c:2331)


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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |4.9.2
Summary|Less redundant instructions |[4.9/4.10 Regression] Less
   |deleted by pre_delete after |redundant instructions
   |r208113.|deleted by pre_delete after
   ||r208113.


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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-04
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Created attachment 33237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33237&action=edit
patch

Ok, I see stuff like the following in the 179r.pre dump differences

@@ -1524,6 +1524,11 @@
 Loads : (insn_list:REG_DEP_TRUE 21 (nil))
Stores : (nil)

+  Pattern (  0): (mem/f:SI (plus:SI (reg/v/f:SI 93 [ pfile ])
+(const_int 12 [0xc])) [3 pfile_5(D)->u_buff+0 S4 A32])
+Loads : (insn_list:REG_DEP_TRUE 19 (nil))
+   Stores : (nil)
+
   Pattern (  0): (mem/f:SI (plus:SI (reg/v/f:SI 83 [ buff ])
 (const_int 12 [0xc])) [3 buff_6->limit+0 S4 A32])
 Loads : (insn_list:REG_DEP_TRUE 9 (nil))
@@ -1536,11 +1541,11 @@

   Pattern (  0): (mem/f:SI (plus:SI (reg/v/f:SI 93 [ pfile ])
 (const_int 12 [0xc])) [3 pfile_5(D)->u_buff+0 S4 A32])
-Loads : (insn_list:REG_DEP_TRUE 19 (insn_list:REG_DEP_TRUE 7 (nil)))
+Loads : (insn_list:REG_DEP_TRUE 7 (nil))
Stores : (nil)

Ah, gcse ends up calling exp_equiv_p which does

  /* Can't merge two expressions in different alias sets, since we
 can decide that the expression is transparent in a block when
 it isn't, due to it being set with the different alias set.

 Also, can't merge two expressions with different MEM_ATTRS.
 They could e.g. be two different entities allocated into the
 same space on the stack (see e.g. PR25130).  In that case, the
 MEM addresses can be the same, even though the two MEMs are
 absolutely not equivalent.

 But because really all MEM attributes should be the same for
 equivalent MEMs, we just use the invariant that MEMs that have
 the same attributes share the same mem_attrs data structure.  */
  if (MEM_ATTRS (x) != MEM_ATTRS (y))
return 0;

cfgcleanup.c has similar code.

Untested fix attached, with this we create the same code for the pr58464
testcase.


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread tkoeppe at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #6 from Thomas Köppe  ---
Created attachment 33236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33236&action=edit
Fixed demo that doesn't have UB on account of invalid pointer arithmetic

Here's a (very lazily) fixed version of the code that allocates from an arena
that is a single, large array.

The same problem persists in both GCC and Clang.

[Bug bootstrap/62009] Bootstrap failure in vec.h::splice

2014-08-04 Thread jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Target|i686|i686,
   ||arm-none-linux-gnueabihf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-04
 CC||jgreenhalgh at gcc dot gnu.org
Summary|Bootstrap failure on i686   |Bootstrap failure in
   ||vec.h::splice
 Ever confirmed|0   |1

--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
I saw something very similar on ARM, but I couldn't reproduce it across two
other bootstraps with the same configuration, nor did I see the ICE when trying
to resume the build by typing "make".

.../configure --with-cpu=cortex-a9 --with-fpu=neon-fp16 --with-mode=thumb
--with-float=hard --enable-languages=c,c++,fortran

/work/jamgre01//gcc-src/gcc/tree-ssa-pre.c: In function ‘pre_expr_d*
bitmap_find_leader(bitmap_set_t, unsigned int)’:
/work/jamgre01//gcc-src/gcc/tree-ssa-pre.c:1837:1: internal compiler error: in
splice, at vec.h:844
 bitmap_find_leader (bitmap_set_t set, unsigned int val)
 ^
0xaa2927 vec<_edge_var_map, va_heap, vl_embed>::splice(vec<_edge_var_map,
va_heap, vl_embed>&)
/work/jamgre01//gcc-src/gcc/vec.h:844
0xaa253d vec<_edge_var_map, va_heap, vl_ptr>::splice(vec<_edge_var_map,
va_heap, vl_ptr>&)
/work/jamgre01//gcc-src/gcc/vec.h:1495
0xaa1fab vec<_edge_var_map, va_heap, vl_ptr>::safe_splice(vec<_edge_var_map,
va_heap, vl_ptr>&)
/work/jamgre01//gcc-src/gcc/vec.h:1512
0xa9ddbb redirect_edge_var_map_dup(edge_def*, edge_def*)
/work/jamgre01//gcc-src/gcc/tree-ssa.c:113
0x4d8bfd redirect_edge_succ_nodup(edge_def*, basic_block_def*)
/work/jamgre01//gcc-src/gcc/cfghooks.c:437
0xa9dee5 ssa_redirect_edge(edge_def*, basic_block_def*)
/work/jamgre01//gcc-src/gcc/tree-ssa.c:173
0x8fd663 gimple_try_redirect_by_replacing_jump
/work/jamgre01//gcc-src/gcc/tree-cfg.c:5419
0x8fd6e7 gimple_redirect_edge_and_branch
/work/jamgre01//gcc-src/gcc/tree-cfg.c:5450
0x4d89d5 redirect_edge_and_branch(edge_def*, basic_block_def*)
/work/jamgre01//gcc-src/gcc/cfghooks.c:356
0x907a79 remove_forwarder_block
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:445
0x9080a7 cleanup_tree_cfg_bb
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:633
0x90818d cleanup_tree_cfg_1
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:675
0x9082cb cleanup_tree_cfg_noloop
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:731
0x9083bd cleanup_tree_cfg()
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:786
0x90897f execute_cleanup_cfg_post_optimizing
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:1081
0x908b29 execute
/work/jamgre01//gcc-src/gcc/tree-cfgcleanup.c:1143
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

--- Comment #6 from Alexander Grund  ---
gfortran 4.9.1 supports OpenMP 4.0

Removing the default(none) clause removes the error message, so it certainly IS
supported.
Besides that: Even the error message mentiones "!$OMP PARALLEL DO SIMD" so it
is recognized.


[Bug testsuite/20003] libmudflap.cth timeouts too short

2014-08-04 Thread fche at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003

Frank Ch. Eigler  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Frank Ch. Eigler  ---
mudflap has been retired


[Bug web/45782] When updating a bug, an error can be thrown if an email cannot be sent to a recipient

2014-08-04 Thread fche at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782

Frank Ch. Eigler  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Frank Ch. Eigler  ---
problem appears to have been corrected


[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #5 from Harald Anlauf  ---
(In reply to Alexander Grund from comment #4)
> I attached 2 testcases. Both are the same files but with different file
> endings. The .f works, the .F90 doesn't (it shows the reported behavior)
> 
> compile both with "gfortran -fopenmp {file}"

The reason you get no error with the .f file is that it is
a Fortran fixed format source file.

If you add -ffree-form to the gfortran options, you get the
same error.

I think the problem is that the simd directive belongs to
OpenMP 4.0 and your gfortran supports only 3.1.

You'll have to wait until OpenMP 4 is supported by gfortran.


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

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

--- Comment #5 from Yuri Rumyantsev  ---
Richard,

I put the original file into  61672 attachment and add comments  for
reproducing.

2014-08-04 15:16 GMT+04:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61672
>
> Richard Biener  changed:
>
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
>
> --- Comment #2 from Richard Biener  ---
> This only changes the way we represent mem_attrs.  It seems to me that
> eventually mem_attr comparison doesn't work as expected?  Note sure where PRE
> looks at
> the stmts - LCM looks like bitmap stuff only, I only see canon_true_dependence
> calls that may make a difference.
>
> Also please specify the target you used to reproduce this.
>
> --
> You are receiving this mail because:
> You reported the bug.


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #5 from Richard Biener  ---
Btw, points-to handles this conservatively, so -fno-tree-pta isn't a real fix
either.  We didn't yet spot the real bogus transform.

But indeed makes sure you are computing differences within one arena only.


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

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

--- Comment #4 from Yuri Rumyantsev  ---
Richard,

I put into attachment original file. For compiler built 20140208 and 20140730
I've got:

grep -c redundant test.cc.179r.pre (20140208)
3825
grep -c redundant test.182r.pre (20140730)  
314.

Note also that the following warning is emitted:
art/runtime/interpreter/interpreter_goto_table_impl.cc:2436:1: warning: the
frame size of 3408 bytes is larger than 1728 bytes [-Wframe-larger-than=]


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread tkoeppe at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #4 from Thomas Köppe  ---
Ah, you're right, this offset pointer computation as it stands is undefined
behaviour. The intended use is to use those pointers only within a preallocated
arena, so that the pointers would indeed live in a common object (a large
array).

I shall change the allocator to an arena allocator and rerun the test.

The intended use for offset pointers is to inter-process communication; a
vector with the fancy-pointer allocator can be used from two separate
processes.

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

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

--- Comment #3 from Yuri Rumyantsev  ---
Created attachment 33235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33235&action=edit
file to reproduce

Need to be compiled with
-m32 -O3 -Wframe-larger-than=1728 -std=gnu++11 -fpic
options.


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

--- Comment #3 from Richard Biener  ---
It looks ok what PRE does (it's not really a partial partial redundancy but
a full redundndancy).

The bug also reproduces with -O2 -ftree-partial-pre.  Disabling loop
optimizations and cddce2 hides the bug.

With PPRE enabled CDDCE2 removes the stores to D.46421.diff (again I see
nothing wrong with doing that).

Btw, this all happens in _M_range_initialize.  (-fno-strict-aliasing fixes
the bug as well).

Note that I see stores as OffPtrBase to automatic objects:

-  MEM[(struct OffPtrBase *)&D.46421].diff = _70;

and loads from OffPtr via this:

   _16 = &MEM[(struct OffPtr *)this_4(D)].D.43564;

or remaining stores:

   MEM[(struct OffPtrBase *)this_4(D) + 16B].diff = iftmp.15_41;

I also see:

   _74 = (sizetype) _47;
   iftmp.10_75 = &D.46429.D.43564 + _74;
   __last.3_77 = (long int) iftmp.10_75;
   __first.4_78 = (long int) &D.46430.D.43564;
   _79 = __last.3_77 - __first.4_78;

which effectively subtracts two unrelated addresses of automatic objects
(b - undefined behavior!)

I think the testcase is simply bogus.  Can you explain what the "fancy"
pointers
do?  Disabling points-to analysis also "fixes" the testcase.

Note that with points-to analysis you cannot reach any other object
with offsetting the address of an object.


[Bug bootstrap/62009] New: Bootstrap failure on i686

2014-08-04 Thread izamyatin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009

Bug ID: 62009
   Summary: Bootstrap failure on i686
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
Target: i686

After r213517 | tbsaunde | 2014-08-02 15:34:54 +0400 (Sat, 02 Aug 2014) | 27
lines

convert many uses of pointer_map to hash_map

gcc/c-family/

* cilk.c: Use hash_map instead of pointer_map.

gcc/c/

* c-typeck.c: Use hash_map instead of pointer_map.

gcc/cp/

* optimize.c, semantics.c: Use hash_map instead of pointer_map.

gcc/

* hash-map.h (default_hashmap_traits::mark_key_deleted):
Fix cast.
(hash_map::remove): New method.
(hash_map::traverse): New method.
* cgraph.h, except.c, except.h, gimple-ssa-strength-reduction.c,
ipa-utils.c, lto-cgraph.c, lto-streamer.h, omp-low.c, predict.c,
tree-cfg.c, tree-cfgcleanup.c, tree-eh.c, tree-eh.h, tree-inline.c,
tree-inline.h, tree-nested.c, tree-sra.c, tree-ssa-loop-im.c,
tree-ssa-loop-ivopts.c, tree-ssa-reassoc.c, tree-ssa-structalias.c,
tree-ssa.c, tree-ssa.h, var-tracking.c: Use hash_map instead of
 pointer_map.

bootstrap for the following configuration 

CC="gcc -m32" CXX="g++ -m32" ../src-trunk/configure --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld i686-linux
--with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc

fails like:

../../src-trunk/gcc/dwarf2cfi.c:706:1: internal compiler error: in splice, at
vec.h:844
 def_cfa_0 (dw_cfa_location *old_cfa, dw_cfa_location *new_cfa)
 ^
0x8c0c15f vec<_edge_var_map, va_heap, vl_embed>::splice(vec<_edge_var_map,
va_heap, vl_embed>&)
../../src-trunk/gcc/vec.h:844
0x8c0bd72 vec<_edge_var_map, va_heap, vl_ptr>::splice(vec<_edge_var_map,
va_heap, vl_ptr>&)
../../src-trunk/gcc/vec.h:1495
0x8c0b783 vec<_edge_var_map, va_heap, vl_ptr>::safe_splice(vec<_edge_var_map,
va_heap, vl_ptr>&)
../../src-trunk/gcc/vec.h:1512
0x8c06770 redirect_edge_var_map_dup(edge_def*, edge_def*)
../../src-trunk/gcc/tree-ssa.c:113
0x859bbac redirect_edge_succ_nodup(edge_def*, basic_block_def*)
../../src-trunk/gcc/cfghooks.c:437
0x8c068e3 ssa_redirect_edge(edge_def*, basic_block_def*)
../../src-trunk/gcc/tree-ssa.c:173
0x8a2c86b gimple_try_redirect_by_replacing_jump
../../src-trunk/gcc/tree-cfg.c:5419
0x8a2c90b gimple_redirect_edge_and_branch
../../src-trunk/gcc/tree-cfg.c:5450
0x859b940 redirect_edge_and_branch(edge_def*, basic_block_def*)
../../src-trunk/gcc/cfghooks.c:356
0x8a38335 remove_forwarder_block
../../src-trunk/gcc/tree-cfgcleanup.c:445
0x8a38b5b cleanup_tree_cfg_bb
../../src-trunk/gcc/tree-cfgcleanup.c:633
0x8a38c57 cleanup_tree_cfg_1
../../src-trunk/gcc/tree-cfgcleanup.c:675
0x8a38d88 cleanup_tree_cfg_noloop
../../src-trunk/gcc/tree-cfgcleanup.c:731
0x8a38ea2 cleanup_tree_cfg()
../../src-trunk/gcc/tree-cfgcleanup.c:786
0x8906f96 execute_function_todo
../../src-trunk/gcc/passes.c:1702
0x8906426 do_per_function
../../src-trunk/gcc/passes.c:1476
0x89072c5 execute_todo
../../src-trunk/gcc/passes.c:1806
Please submit a full bug report,


[Bug c++/61455] Internal compiler error, and other confused errors, when using array notation

2014-08-04 Thread nick.tomlinson at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455

Nick Tomlinson  changed:

   What|Removed |Added

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

--- Comment #5 from Nick Tomlinson  ---
I built GCC r213543 this morning, and have found that the code in the minimal
reproducer no longer produces an ICE - good work! :D - Thanks.


[Bug c++/62003] Possible bug in std::complex

2014-08-04 Thread wilczak at ii dot uj.edu.pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003

--- Comment #4 from Daniel Wilczak  ---
Me neither - on GNU/Linux the program runs normally.
Daniel

W dniu 2014-08-04 13:32, redi at gcc dot gnu.org pisze:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003
>
> Jonathan Wakely  changed:
>
> What|Removed |Added
> 
>   Target||mingw32
>   Status|WAITING |UNCONFIRMED
>   Ever confirmed|1   |0
>
> --- Comment #3 from Jonathan Wakely  ---
> I can't reproduce this on GNU/Linux, so it might be a target issue.
>


[Bug c++/62003] Possible bug in std::complex

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003

Jonathan Wakely  changed:

   What|Removed |Added

 Target||mingw32
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Jonathan Wakely  ---
I can't reproduce this on GNU/Linux, so it might be a target issue.


[Bug other/62008] New: CilkPlus Array Notation ICE in build_array_notation_ref when trying to build a multidimensional array from a pointer.

2014-08-04 Thread nick.tomlinson at arm dot com
UNK}/bin/g++ --version
  g++ (GCC) 4.10.0 20140804 (experimental)
  Copyright (C) 2014 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


[Bug c++/62003] Possible bug in std::complex

2014-08-04 Thread wilczak at ii dot uj.edu.pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003

--- Comment #2 from Daniel Wilczak  ---
OS version Windows 7, 64-bit.
gcc version:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32
--build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld
--enable-lto --enable-libssp --disable-multilib
--enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions
--with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runtime-libs
--with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld
--with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr=
--with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp
--enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw
--disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)


[Bug other/61963] CilkPlus Array Notation ICE in build_array_notation_ref on malformed function arguments.

2014-08-04 Thread nick.tomlinson at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61963

Nick Tomlinson  changed:

   What|Removed |Added

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

--- Comment #3 from Nick Tomlinson  ---
I built GCC r213543 this morning, and have found that the code in the minimal
reproducer no longer produces an ICE - good work! :D - Thanks.


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
There is only a single extra PRE performed by partial-PRE.  I'll have a look.


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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
This only changes the way we represent mem_attrs.  It seems to me that
eventually mem_attr comparison doesn't work as expected?  Note sure where PRE
looks at
the stmts - LCM looks like bitmap stuff only, I only see canon_true_dependence
calls that may make a difference.

Also please specify the target you used to reproduce this.


[Bug libstdc++/61909] Small function optimization not applied to small objects

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909

--- Comment #5 from Jonathan Wakely  ---
I already have a patch to do it


[Bug libstdc++/61909] Small function optimization not applied to small objects

2014-08-04 Thread lukeocamden at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909

--- Comment #4 from lukeocamden at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to lukeocamden from comment #2)
> > (In reply to Jonathan Wakely from comment #1)
> > > This is by design.
> > 
> > I don't really follow - do you mean a consequence of the design, or does the
> > standard mandate copying/moving the object into the heap, or does using the
> > heap have some other benefit?
> 
> None of the above.
> 
> I mean the author of our std::function intentionally chose to only avoid the
> heap for function pointers
> 
>   /**
>*  Trait identifying "location-invariant" types, meaning that the
>*  address of the object (or any of its members) will not escape.
>*  Also implies a trivial copy constructor and assignment operator.
>*/

If this doesn't offer a clear advantage, should I try to come up with a patch
to support small objects too?


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

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

--- Comment #1 from Yuri Rumyantsev  ---
Any comments will be appreciated.


[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

--- Comment #4 from Alexander Grund  ---
I attached 2 testcases. Both are the same files but with different file
endings. The .f works, the .F90 doesn't (it shows the reported behavior)

compile both with "gfortran -fopenmp {file}"


[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

--- Comment #3 from Alexander Grund  ---
Created attachment 33233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33233&action=edit
Broken example


[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

--- Comment #2 from Alexander Grund  ---
Created attachment 33232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33232&action=edit
Working example


[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-04
  Component|c++ |tree-optimization
Version|unknown |4.9.1
 Ever confirmed|0   |1
  Known to fail||4.10.0, 4.8.2, 4.9.1

--- Comment #1 from Jonathan Wakely  ---
N.B. compile with -std=c++11 

I can't tell whether it's a regression without rewriting some of the code to
avoid features that aren't supported prior to 4.8


[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-08-04
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #1 from Dominique d'Humieres  ---
Could you provide a complete test code?


[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

Alexander Grund  changed:

   What|Removed |Added

   Severity|normal  |major


[Bug fortran/62007] New: default(none) conflicts with iteration variable in openmp parallel loop simd

2014-08-04 Thread alexander.grund at mailbox dot tu-dresden.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007

Bug ID: 62007
   Summary: default(none) conflicts with iteration variable in
openmp parallel loop simd
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.grund at mailbox dot tu-dresden.de

If you use the "default(none)" clause in a parallel loop simd construct
gfortran will complain about having not set the iteration variable in a
private/shared clause:
" error: 'i_ct' not specified in enclosing parallel"

If you however do specify it in a private clause, gfortran will yield:
"Error: !$OMP PARALLEL DO SIMD iteration variable present on clause other than
LINEAR at (1)"

Trivial example:
!$omp parallel do simd default(none)
do i_ct = 1, 10
  ...
end do

If you use a "normal" parallel do both variants work.


[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1

2014-08-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716

--- Comment #8 from Kai Tietz  ---
(In reply to Kai Tietz from comment #7)
> As 5.1 is now already for some time no more in maintenance it would be
> interesting to learn if that problem is still there for more current version
> (4.9, 4.8) gcc.

Of course I mean 4.1


[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1

2014-08-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-08-04
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Kai Tietz  ---
As 5.1 is now already for some time no more in maintenance it would be
interesting to learn if that problem is still there for more current version
(4.9, 4.8) gcc.


[Bug c++/62006] New: Bad code generation with -O3 (possibly due to -ftree-partial-pre)

2014-08-04 Thread tkoeppe at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006

Bug ID: 62006
   Summary: Bad code generation with -O3 (possibly due to
-ftree-partial-pre)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoeppe at google dot com

Created attachment 33231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33231&action=edit
Demonstrates bad code generation with -O3

I was writing some code to demonstrate custom allocators with fancy pointers.
While testing it with GCC, I noticed memory corruption when compiling with -O3.
Jonathan Wakely had a quick look and narrowed it down to "-O2
-ftree-partial-pre"; with just "-O2" the code works.

I don't have any insights in the problem, so I'm just attaching the full code.
You can tell that it's broken by passing the program through valgrind, or
simply by noting that it prints all container elements as zero, rather than
their actual values.

(Incidentally, I believe there's a similar problem in Clang:
http://llvm.org/bugs/show_bug.cgi?id=20524)


[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable

2014-08-04 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005

--- Comment #2 from Marc Glisse  ---
Ah, I didn't test with --enable-ckecking=rtl.

We could split the "maybe" part of the warning and downgrade it to Wextra, but
I'd rather keep it at least in Wall, which means we need to change the
loop-unroll code anyway.

The code is not easy to understand. For instance, I don't see where n_loc can
be set to any value other than 1? That would make it easy to simplify this
loop...


[Bug ipa/61998] [4.10 Regression] ICE: Segmentation fault with -Wsuggest-final-types

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61998

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0


[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-04
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Heh, interesting set of events ;)

Now it is interesting how much we desire to perform the tail-merging - we
_could_
change the alias sets of loads (and stores...) to a "common" one (either if
they
are "equal" or just zero otherwise).  Depends on how much we like this kind
of pessimization.

Same for the RTL bits of course.

Btw, I still see the conditional execution after RTL expansion, just
cfglayout mode doesn't have unconditonal gotos for the edges.


[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target

2014-08-04 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Aug  4 10:03:32 2014
New Revision: 213555

URL: https://gcc.gnu.org/viewcvs?rev=213555&root=gcc&view=rev
Log:
PR 61713: ICE when expanding single-threaded version of atomic_test_and_set.

PR target/61713
* gcc/optabs.c (expand_atomic_test_and_set): Do not try to emit
move to subtarget in serial version if result is ignored.

PR target/61713
* gcc.dg/pr61756.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr61756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog


[Bug bootstrap/62005] [4.10 regression] with --enable-checking=rtl : loop-unroll.c:2095:10: error: function may return address of local variable

2014-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005

Richard Biener  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org
   Target Milestone|--- |4.10.0

--- Comment #1 from Richard Biener  ---
Hmm, the warning is true if ivts->n_loc == 0.  Marc?


  1   2   >