[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/59880] ix86_avoid_lea_for_addr is buggy

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

Uroš Bizjak  changed:

   What|Removed |Added

  Component|rtl-optimization|target
   Target Milestone|--- |4.7.4
   Severity|enhancement |normal

[Bug lto/55113] ICE with LTO and -fshort-double

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE in  |ICE with LTO and
   |emit_library_call_value_1,  |-fshort-double
   |at calls.c:3757 |

--- Comment #10 from Andrew Pinski  ---
 -fshort-double is what is causing the issue.  Why are you using that option in
the first place?  It changes the ABI.

With 4.7.0 (and checking enabled), I get the following ICE on all targets with
-flto -fshort-double -Os:
t7.c: In function ‘main’:
t7.c:3:5: error: non-trivial conversion at assignment
float
double
# .MEM_2 = VDEF <.MEM_1(D)>
f = 1.0e+0;

[Bug ipa/59882] [4.9 Regression] internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2014-01-20
  Component|other   |ipa
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|dev-cpp/xsd: internal   |[4.9 Regression]  internal
   |compiler error: |compiler error:
   |Segmentation fault  |Segmentation fault
   Target Milestone|--- |4.9.0

--- Comment #3 from Markus Trippelsdorf  ---
Confirmed. Another devirtualization issue.

markus@x4 tmp % cat test.ii
class A;
class B {};
struct C {
  virtual void dispatch();
  int traversal_map_;
};
template  class F : public virtual C {};

struct I : F, F {};
struct J : B, I {};
class D {};
struct L {
  L(D &, int &p2) : map_(p2) {}
  virtual void traverse(int &p1) {
int &s = p1;
names(s, names_);
  }
  int &map_;
  J names_;
  template  void names(int &, C &p2) { p2.dispatch(); }
};

struct G : D {
  G(D &, int &p2) : map_(p2) { L(*this, map_); }
  int &map_;
};

int a;
void fn1(D &p1) { G(p1, a); }

markus@x4 tmp % g++ -c -O2 test.ii
test.ii: In member function ‘virtual void L::traverse(int&)’:
test.ii:29:29: internal compiler error: Segmentation fault
 void fn1(D &p1) { G(p1, a); }
 ^
0xb541af crash_signal
../../gcc/gcc/toplev.c:337
0x98e5eb tree_check
../../gcc/gcc/tree.h:2708
0x98e5eb gimple_get_virt_method_for_binfo(long, tree_node*)
../../gcc/gcc/gimple-fold.c:3242
0x9d35a9 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**)
../../gcc/gcc/ipa-devirt.c:1312
0x9902ab possible_polymorphic_call_targets(tree_node*, bool*, void**)
../../gcc/gcc/ipa-utils.h:135
0x98d4a6 gimple_fold_call
../../gcc/gcc/gimple-fold.c:1185
0x98d4a6 fold_stmt_1
../../gcc/gcc/gimple-fold.c:1298
0xbaacb9 fold_marked_statements
../../gcc/gcc/tree-inline.c:4511
0xbb8374 optimize_inline_calls(tree_node*)
../../gcc/gcc/tree-inline.c:4592
0x1058409 early_inliner
../../gcc/gcc/ipa-inline.c:2272
0x1058409 execute
../../gcc/gcc/ipa-inline.c:2335
Please submit a full bug report,

[Bug target/59884] Unexpected warning pragma GCC target

[joey.ye at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884

--- Comment #2 from Joey Ye  ---
(In reply to Andrew Pinski from comment #1)
> Comes from:
>   if (p->target_binary != target_option_current_node)
> {
>   (void) targetm.target_option.pragma_parse (NULL_TREE,
> p->target_binary);
>   target_option_current_node = p->target_binary;
> }
> 
> 
> The front-end expects the target always to implement these target hooks it
> seems rather than the default.
> 
> Really I think the arm back-end should implement them so that thumb2 code
> can be in the same source file as arm32 code and would help out LTO when
> people mix and match them.
It is a useful feature on ARM. I don't know why it isn't support now.

But this warning still need to be fixed as there are always some targets not
supportting this pragma.

[Bug target/59884] Unexpected warning pragma GCC target

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Comes from:
  if (p->target_binary != target_option_current_node)
{
  (void) targetm.target_option.pragma_parse (NULL_TREE, p->target_binary);
  target_option_current_node = p->target_binary;
}


The front-end expects the target always to implement these target hooks it
seems rather than the default.

Really I think the arm back-end should implement them so that thumb2 code can
be in the same source file as arm32 code and would help out LTO when people mix
and match them.

[Bug c/59884] New: Unexpected warning pragma GCC target

[joey.ye at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884

Bug ID: 59884
   Summary: Unexpected warning pragma GCC target
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.ye at arm dot com

Affected target: arm. (x86/x86_64 passes)
Affected version: trunk 20140109, 4.8, 4.7

~/cases/pragma $ cat p.c
#pragma GCC push_options
#pragma GCC optimize("O2")
int foo(int a){
return a+1;
}
#pragma GCC pop_options

~/cases/pragma $ arm-none-eabi-gcc p.c -c
p.c:6:9: warning: #pragma GCC target is not supported for this machine
[-Wpragmas]
 #pragma GCC pop_options

[Bug other/36150] colorize output of gcc

[bluetooth.developer at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

bluetooth.developer at gmail dot com changed:

   What|Removed |Added

 CC||bluetooth.developer at gmail 
dot c
   ||om

--- Comment #17 from bluetooth.developer at gmail dot com ---
Alternatively you could use GilCC which is a tool to colorize GCC output in
real time. Just in case you cannot use GGC version 4.9 you still can use GilCC.

here is the download link:
http://www.onlysolutionssoftware.com/gilcc/

[Bug other/59882] dev-cpp/xsd: internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882

--- Comment #2 from David Kredba  ---
c-reduce at --sllooww>

namespace std
{
template < class, class > struct pair;
template < typename _Iterator > struct iterator_traits
{
typedef typename _Iterator::value_type value_type;
};
template < typename > class allocator
{
public:
template < typename > struct rebind
{
typedef allocator other;
};
};
template < typename > struct less
{
};
template < typename > struct _Select1st;
}

namespace __gnu_cxx
{
template < typename _Alloc > struct __alloc_traits
{
template < typename _Tp > struct rebind
{
typedef typename _Alloc::template rebind < _Tp >::other other;
};
};
}
namespace std
{
template < typename > struct _Rb_tree_node;
template < typename, typename _Val, typename, typename _Compare,
 typename _Alloc = allocator < _Val > >class _Rb_tree
{
typedef typename __gnu_cxx::__alloc_traits < _Alloc >::template rebind <
_Rb_tree_node < _Val > >::other _Node_allocator;
typedef _Alloc allocator_type;
template < typename _Key_compare > struct _Rb_tree_impl
{
_Rb_tree_impl (_Key_compare, _Node_allocator);
};
_Rb_tree_impl < _Compare > _M_impl;
public:
_Rb_tree (_Compare __comp, allocator_type __a):_M_impl (__comp,
__a)
{
}
};
template < typename _Key, typename _Tp, typename _Compare =
less < _Key >, typename _Alloc =
allocator < pair < _Key, _Tp > > >class map
{
public:
typedef _Key key_type;
typedef pair < _Key, _Tp > value_type;
typedef _Compare key_compare;
typedef _Alloc allocator_type;
typedef _Rb_tree < key_type, value_type, _Select1st < value_type >,
key_compare > _Rep_type;
_Rep_type _M_t;
map (_Compare __comp, allocator_type __a = allocator_type ()):_M_t (__comp,
__a)
{
}
};
template < typename _Tp > struct _List_iterator
{
typedef _Tp value_type;
};
template < typename _Tp > class list
{
public:
typedef _List_iterator < _Tp > iterator;
};
}

namespace Cult
{
namespace Types
{
namespace Fundamental
{
typedef void Void;
typedef int WideChar;
} using Fundamental::Void;
using Fundamental::WideChar;
} namespace
{
template < typename I > class IteratorAdapter
{
public:
typedef typename std::iterator_traits <
I >::value_type Value;
};
} namespace Types
{
template < typename > class StringTemplate;
typedef StringTemplate < WideChar > WideString;
} namespace Containers
{
template < typename K, typename T > class Map:std::map < K, T >
{
typedef std::map < K, T > Base;
typedef typename Base::key_compare Compare;
public:
Map (Compare comp = Compare ()):Base (comp)
{
}
};
template < typename T > class List
{
typedef std::list < T > Base;
public:
typedef IteratorAdapter < typename Base::iterator >
Iterator;
};
}
}

namespace
{
using namespace Cult::Types;
}

namespace XSDFrontend
{
namespace SemanticGraph
{
namespace Bits
{
template < typename > struct strip_pointer;
template < typename X > struct strip_pointer 
{
typedef X Type;
};
template < typename I > struct PointerIterator
{
typedef typename strip_pointer < typename I::Value >::Type Reference;
Reference operator* ();
};
} class Edge
{
};
class Node;
class Names:public Edge
{
};
class Scope
{
typedef Cult::Containers::List < Names * >NamesList;
public:
typedef Bits::PointerIterator < NamesList::Iterator >
NamesIterator;
};
class Type;
class Complex:public Scope
{
};
}
}
namespace FrontendElements
{
namespace Traversal
{
template < typename > class TraverserBase
{
};
template < typename X > class DispatcherBase
{
public:
virtual Void dispatch (X);
};
template < typename X > class Dispatcher:public DispatcherBase < X >
{
};
}
}

namespace XSDFrontend
{
namespace Traversal
{
namespace Bits
{
using FrontendElements::Traversal::TraverserBase;
using FrontendElements::Traversal::DispatcherBase;
using FrontendElements::Traversal::Dispatcher;
} typedef Bits::DispatcherBase < SemanticGraph::Edge > EdgeDispatcherBase;
struct EdgeBase:virtual Bits::Dispatcher < SemanticGraph::Edge >,
Bits::Dispatcher < SemanticGraph::Node >
{
};
template < typename > struct Edge:Bits::TraverserBase <
SemanticGraph::Edge >, EdgeBase
{
};
struct Names:Edge < Names >
{
};
template < typename T > struct ScopeTemplate
{
template < typename > Void names (T, EdgeDispatcherBase & d)
{
typename T::NamesIterator b;
d.dispatch (*b);
} Void names (T s, EdgeDispatcherBase & d)
{
names < ScopeTemplate > (s, d);
}
};
struct Complex:ScopeTemplate < SemanticGraph::Complex >
{
};
} typedef WideString String;
class Context
{
};
namespace Parser
{
namespace
{
typedef Cult::Containers::Map < SemanticGraph::Type,
String > TypeInstanceMap;
struct BaseType
{
BaseType (Context);
};
struct ArgList:Traversal::Complex
{
ArgList (Context, TypeInstanceMap)
{
} virtual Void traverse (SemanticGraph

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

[wjl at icecavern dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873

--- Comment #9 from Wesley J. Landaker  ---
This also happens in strings, e.g.:

static_assert(U"\u"[0] == 1, "this passes");
static_assert(U"\u"[0] == 0, "this fails");

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

[wjl at icecavern dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873

--- Comment #8 from Wesley J. Landaker  ---
Just as an additional point, L'\u' also yields a wchar_t with the value of
1. (If that is an illegal construct, it is not warned about when using -Wall
-Wextra -Werror).

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 19 23:21:10 2014
New Revision: 206786

URL: http://gcc.gnu.org/viewcvs?rev=206786&root=gcc&view=rev
Log:
2014-01-19  Steven G. Kargl  

PR libfortran/59771
PR libfortran/59774
PR libfortran/59836
* gfortran.dg/round_3.f08: New cases added.
* gfortran.dg/fmt_g_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_g_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771

--- Comment #3 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 19 23:21:10 2014
New Revision: 206786

URL: http://gcc.gnu.org/viewcvs?rev=206786&root=gcc&view=rev
Log:
2014-01-19  Steven G. Kargl  

PR libfortran/59771
PR libfortran/59774
PR libfortran/59836
* gfortran.dg/round_3.f08: New cases added.
* gfortran.dg/fmt_g_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_g_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 19 23:21:10 2014
New Revision: 206786

URL: http://gcc.gnu.org/viewcvs?rev=206786&root=gcc&view=rev
Log:
2014-01-19  Steven G. Kargl  

PR libfortran/59771
PR libfortran/59774
PR libfortran/59836
* gfortran.dg/round_3.f08: New cases added.
* gfortran.dg/fmt_g_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_g_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771

--- Comment #2 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 19 23:17:43 2014
New Revision: 206785

URL: http://gcc.gnu.org/viewcvs?rev=206785&root=gcc&view=rev
Log:
2014-01-19  Jerry DeLisle  
Dominique d'Humieres  

PR libfortran/59771
PR libfortran/59774
PR libfortran/59836
* io/write_float.def (output_float): Fix wrong handling of the
Fw.0 format.
(output_float_FMT_G_): Fixes rounding issues with -m32.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 19 23:17:43 2014
New Revision: 206785

URL: http://gcc.gnu.org/viewcvs?rev=206785&root=gcc&view=rev
Log:
2014-01-19  Jerry DeLisle  
Dominique d'Humieres  

PR libfortran/59771
PR libfortran/59774
PR libfortran/59836
* io/write_float.def (output_float): Fix wrong handling of the
Fw.0 format.
(output_float_FMT_G_): Fixes rounding issues with -m32.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774

--- Comment #14 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 19 23:17:43 2014
New Revision: 206785

URL: http://gcc.gnu.org/viewcvs?rev=206785&root=gcc&view=rev
Log:
2014-01-19  Jerry DeLisle  
Dominique d'Humieres  

PR libfortran/59771
PR libfortran/59774
PR libfortran/59836
* io/write_float.def (output_float): Fix wrong handling of the
Fw.0 format.
(output_float_FMT_G_): Fixes rounding issues with -m32.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug other/59882] dev-cpp/xsd: internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882

--- Comment #1 from David Kredba  ---
Created attachment 31896
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31896&action=edit
C-reduced test case - first run

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
Just a bit shorter (without unstable_t type):

module decays

  implicit none

  type :: decay_term_t
 type(decay_t), pointer :: unstable_product
  end type

  type :: decay_gen_t
 type(decay_term_t), allocatable :: term
 procedure(), nopass, pointer :: obs1_int
  end type

  type :: rng_t
  end type

  type, extends (decay_gen_t) :: decay_t
 class(rng_t), allocatable :: rng
  end type

  class(decay_t), pointer :: object

end

[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)

[dcb314 at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802

--- Comment #8 from David Binderman  ---
(In reply to Richard Biener from comment #7)
> Fixed.

The results I can report are for trunk dated 20130119

[dcb@zippy4 foundBugs]$ time ../results/bin/gcc -c bug129.cc 

real0m8.076s
user0m5.925s
sys0m0.131s
[dcb@zippy4 foundBugs]$ time ../results/bin/gcc -c -O2 bug129.cc 

real1m0.706s
user0m57.884s
sys0m0.402s
[dcb@zippy4 foundBugs]$ time ../results/bin/gcc -c -O3 bug129.cc 

real5m45.982s
user5m42.793s
sys0m0.457s

while the first time is trivial, the -O2 time is down by about
60% and the -O3 time is down by about 30%.

Good work !

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

--- Comment #8 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #7)
> Sure, will do.  Thought about that as well, just didn't change it before
> attaching ;)

Please use "long long" and target ! ia32 on testcase so
that it will be tested for x32.

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

--- Comment #3 from Dominique d'Humieres  ---
When the executable is run under valgrind I see a lot of

==981== Invalid write of size 8
==981==at 0x100020B99: __parser_MOD_token_assign_real (in ./seg_prod)
==981==by 0x10001ED21: __parser_MOD_parse_node_set_value (in ./seg_prod)
==981==by 0x100058249: __commands_MOD_range_real_set_value (in ./seg_prod)
==981==by 0x1000543C2: __commands_MOD_cmd_scan_execute (in ./seg_prod)
==981==by 0x100053EC9: __commands_MOD_command_list_execute (in ./seg_prod)
==981==by 0x10005E495: __whizard_MOD_whizard_process_stream (in ./seg_prod)
==981==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod)
==981==by 0x10006191E: MAIN__ (in ./seg_prod)
==981==by 0x10006204E: main (in ./seg_prod)
==981==  Address 0x100f0400d is 829 bytes inside a block of size 1,024 free'd
==981==at 0x10009252D: free (vg_replace_malloc.c:430)
==981==by 0x1A624: __iso_varying_string_MOD_op_eq_vs_vs (in ./seg_prod)
==981==by 0x10002830D: __variables_MOD_var_list_get_var_ptr (in ./seg_prod)
==981==by 0x10002839D: __variables_MOD_var_list_get_var_ptr (in ./seg_prod)
==981==by 0x100024DE2: __variables_MOD_var_list_check_user_var (in
./seg_prod)
==981==by 0x10005C9E0: __commands_MOD_cmd_var_compile (in ./seg_prod)
==981==by 0x100053F86: __commands_MOD_command_list_compile (in ./seg_prod)
==981==by 0x10005B43E: __commands_MOD_build_alt_setup (in ./seg_prod)
==981==by 0x10005450A: __commands_MOD_cmd_scan_execute (in ./seg_prod)
==981==by 0x100053EC9: __commands_MOD_command_list_execute (in ./seg_prod)
==981==by 0x10005E495: __whizard_MOD_whizard_process_stream (in ./seg_prod)
==981==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod)

when compiled with r194897 (2013-01-04). These invalid write/read disappear
with r195140 (2013-01-14). However I see a lot leak

...
=65053== 40,519 (7,344 direct, 33,175 indirect) bytes in 51 blocks are
definitely lost in loss record 126 of 128
==65053==at 0x100092679: malloc (vg_replace_malloc.c:266)
==65053==by 0x10001E6F0: __parser_MOD_parse_node_replace_last_sub (in
./seg_prod)
==65053==by 0x100057270: __commands_MOD_cmd_scan_compile (in ./seg_prod)
==65053==by 0x100053F5E: __commands_MOD_command_list_compile (in
./seg_prod)
==65053==by 0x10005E465: __whizard_MOD_whizard_process_stream (in
./seg_prod)
==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in
./seg_prod)
==65053==by 0x10006191E: MAIN__ (in ./seg_prod)
==65053==by 0x10006204E: main (in ./seg_prod)
==65053==
==65053== 54,812 (8,432 direct, 46,380 indirect) bytes in 28 blocks are
definitely lost in loss record 127 of 128
==65053==at 0x100092679: malloc (vg_replace_malloc.c:266)
==65053==by 0x100056A16: __commands_MOD_cmd_scan_compile (in ./seg_prod)
==65053==by 0x100053F5E: __commands_MOD_command_list_compile (in
./seg_prod)
==65053==by 0x10005E465: __whizard_MOD_whizard_process_stream (in
./seg_prod)
==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in
./seg_prod)
==65053==by 0x10006191E: MAIN__ (in ./seg_prod)
==65053==by 0x10006204E: main (in ./seg_prod)
==65053==
==65053== 218,271 (144 direct, 218,127 indirect) bytes in 1 blocks are
definitely lost in loss record 128 of 128
==65053==at 0x100092679: malloc (vg_replace_malloc.c:266)
==65053==by 0x10001EBC3: __parser_MOD_parse_node_create_branch (in
./seg_prod)
==65053==by 0x10001D271: parse_sequence.2386 (in ./seg_prod)
==65053==by 0x10001DD29: parse_node_match_rule.2402 (in ./seg_prod)
==65053==by 0x10001CD3B: __parser_MOD_parse_tree_init (in ./seg_prod)
==65053==by 0x10005E3FD: __whizard_MOD_whizard_process_stream (in
./seg_prod)
==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in
./seg_prod)
==65053==by 0x10006191E: MAIN__ (in ./seg_prod)
==65053==by 0x10006204E: main (in ./seg_prod)
==65053==
==65053== LEAK SUMMARY:
==65053==definitely lost: 79,291 bytes in 763 blocks
==65053==indirectly lost: 330,636 bytes in 3,687 blocks
==65053==  possibly lost: 0 bytes in 0 blocks
==65053==still reachable: 556 bytes in 12 blocks
==65053== suppressed: 88 bytes in 1 blocks
==65053==
==65053== For counts of detected and suppressed errors, rerun with: -v
==65053== ERROR SUMMARY: 19 errors from 19 contexts (suppressed: 0 from 0)

Note that on trunk I also get a lot of invalid write/read (114).

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[juergen.reuter at desy dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

--- Comment #2 from Jürgen Reuter  ---
Created attachment 31895
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31895&action=edit
bit smaller test case

This is a bit smaller test case. The main program is basically a call, and one
module has been eliminated. Also, no input file is needed any more. 
The module ifile defines internal files used for 
carrying information, lexer.f90 defines the lexer, parser.f90 the parser,
syntax_rules.f90 the corresponding syntax_rules. 
The scan command now only has one line which triggers the problems.

[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
Created attachment 31894
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31894&action=edit
Patch for the PR

This patch bootstraps and regtests on trunk.  The resulting behaviour is
identical to ifort.

I'll submit tomorrow or Tuesday.

Cheers

Paul

[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-19
 Ever confirmed|0   |1

--- Comment #10 from Marek Polacek  ---
Ah, on u.i I can see it, too.  Sorry, I thought the testcases are equivalent.

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

--- Comment #7 from Jakub Jelinek  ---
Sure, will do.  Thought about that as well, just didn't change it before
attaching ;)

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> The example works with gfortran 4.8.x and 4.9.0, but fails with all 4.7.x. 

I have built and ran the test without problem with 4.8.2 and almost latest
trunk without problem (few runs) and got random problems with 4.7.4. I'll try
to do some bisection to see it is known issue that has been fixed between 4.7
and 4.8, but don't expect a quick answer.

I would be nice if you can reduce your test further.

[Bug c++/59883] New: Missed C++ front-end devirtualizations

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59883

Bug ID: 59883
   Summary: Missed C++ front-end devirtualizations
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org

I believe the following testcase:
 struct A 
{
   virtual int foo (void) {return foo();}
}; 

struct B {
   struct A a;
};
struct A a[7]; 

int test(void)
{
  return a[3].foo();
} 

int test2(struct B *b)
{
  return b->a.foo();
}
ought to get devirtualized by C++ FE based on the fact that the object is
contained within an structure or array. (this is related to PR46507)

In the following testcase:
namespace {
  struct A 
  {
virtual int foo (void) {return 42;}
  };
}
int test(void)
{
  struct A a, *b=&a;
  return b->foo();
}

We can now probably use ipa-devirt's type inheritance graph to work out right
away that A is a final class.

And finally:
struct A 
{
   virtual int foo (void) {return foo();}
};
IMO allows devirtualization of self recursive functions

gcc-bugs@gcc.gnu.org

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172

Marc Glisse  changed:

   What|Removed |Added

 CC||leonid at volnitsky dot com

--- Comment #8 from Marc Glisse  ---
*** Bug 54425 has been marked as a duplicate of this bug. ***

[Bug c++/54425] Rvalue/Lvalue overload resolution of templated function

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54425

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||glisse at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Marc Glisse  ---
Already fixed on trunk.

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

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 31893 [details]
> gcc49-pr59880.patch
> 
> Untested fix.  The reason for the problem is that if it is just a
> (zero-extended SI->DI or normal) move from %r13, %rbp or (for k6 %esi), then
> decomposition sets parts.disp to const0_rtx and thus we count it as two
> parts, even when we wouldn't emit it as a lea insn originally.

True. However, can you put new test before costly call to
ix86_ok_to_clobber_flags and ix86_decompose_address?

[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)

[eggert at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968

eggert at gnu dot org changed:

   What|Removed |Added

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

--- Comment #9 from eggert at gnu dot org ---
(In reply to Marek Polacek from comment #8)
> Can't reproduce anymore with 4.7/4.8/4.9 (but with 4.6 I can), thus
> hopefully fixed.

Thanks, but which test case did you use, and which version of 4.8?  I can
reproduce the bug with the first test case (u.i) with the GCC 4.8.2 that is
shipped with Fedora 20 (it says it is "gcc (GCC) 4.8.2 20131212 (Red Hat
4.8.2-7)").  That is, the bug with the second test case is fixed with 4.8.2,
but the bug with the first test case remains.

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 31893
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31893&action=edit
gcc49-pr59880.patch

Untested fix.  The reason for the problem is that if it is just a
(zero-extended SI->DI or normal) move from %r13, %rbp or (for k6 %esi), then
decomposition sets parts.disp to const0_rtx and thus we count it as two parts,
even when we wouldn't emit it as a lea insn originally.

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #2)
> Ah, indeed, it is split because of the:
> (define_insn_and_split "*lea"
>   [(set (match_operand:SWI48 0 "register_operand" "=r")
> (match_operand:SWI48 1 "address_no_seg_operand" "Ts"))]
> splitter.  I'd say it is a bug in ix86_avoid_lea_for_addr, that shouldn't
> have returned true in this case, where the second operand is (zero_extend:DI
> (reg:SI)).

It shouldn't split this RTX, ix86_avoid_lea_for_addr has:

  /* There should be at least two components in the address.  */
  if ((parts.base != NULL_RTX) + (parts.index != NULL_RTX)
  + (parts.disp != NULL_RTX) + (parts.scale > 1) < 2)
return false;

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639

Bug 24639 depends on bug 58410, which changed state.

Bug 58410 Summary: [4.8/4.9 Regression] Bogus uninitialized variable warning 
for allocatable derived type array function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410

   What|Removed |Added

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

[Bug fortran/58410] [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on trunk and 4.8.

Thanks for the report

Paul

[Bug fortran/58410] [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Sun Jan 19 18:04:22 2014
New Revision: 206778

URL: http://gcc.gnu.org/viewcvs?rev=206778&root=gcc&view=rev
Log:
2014-01-19  Paul Thomas  

PR fortran/58410
* trans-array.c (gfc_alloc_allocatable_for_assignment): Do not
use the array bounds of an unallocated array but set its size
to zero instead.

Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/trans-array.c

[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Can't reproduce anymore with 4.7/4.8/4.9 (but with 4.6 I can), thus hopefully
fixed.

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

--- Comment #3 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #2)
> Ah, indeed, it is split because of the:
> (define_insn_and_split "*lea"
>   [(set (match_operand:SWI48 0 "register_operand" "=r")
> (match_operand:SWI48 1 "address_no_seg_operand" "Ts"))]
> splitter.  I'd say it is a bug in ix86_avoid_lea_for_addr, that shouldn't
> have returned true in this case, where the second operand is (zero_extend:DI
> (reg:SI)).

My patch for PR 59379:

http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01166.html

doesn't have this problem  Should we consider my patch instead?

[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-19
 CC||uros at gcc dot gnu.org
Summary|Improve REE for implicit|ix86_avoid_lea_for_addr is
   |SI->DI zero-extend  |buggy
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Ah, indeed, it is split because of the:
(define_insn_and_split "*lea"
  [(set (match_operand:SWI48 0 "register_operand" "=r")
(match_operand:SWI48 1 "address_no_seg_operand" "Ts"))]
splitter.  I'd say it is a bug in ix86_avoid_lea_for_addr, that shouldn't have
returned true in this case, where the second operand is (zero_extend:DI
(reg:SI)).

[Bug other/59882] New: dev-cpp/xsd: internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882

Bug ID: 59882
   Summary: dev-cpp/xsd: internal compiler error: Segmentation
fault
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com

Created attachment 31892
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31892&action=edit
Preprocessed source file - not reduced

Current trunk segfaults:

x86_64-pc-linux-gnu-g++
-I/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd -save-temps -fPIC
-O2 -ggdb -march=native -mtune=native -mno-avx -mno-sse4.2 -mno-3dnow -o
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.o
-c
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.cxx
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.cxx:
In member function ‘virtual Cult::Types::Fundamental::Void
CXX::Parser::{anonymous}::ArgList::traverse(XSDFrontend::SemanticGraph::Complex&)’:
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.cxx:520:9:
internal compiler error: Neoprávněný přístup do paměti (SIGSEGV)
 traverse (SemanticGraph::Complex& c)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I am c-reducing a test case with -O2 -ggdb -fPIC.

[Bug fortran/59881] New: Memory corruption with allocatable arrays in polymorphic types

[juergen.reuter at desy dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

Bug ID: 59881
   Summary: Memory corruption with allocatable arrays in
polymorphic types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de

Created attachment 31891
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31891&action=edit
Tar ball that produces code triggering the memory corruption.

The code attached (unpack, do make, make run) triggers the memory leak. Sorry
for not being able/having time to reduce the case further. The propgram
./seg_prod reads in the file structure_5.sin specifying a scan over integer and
real values that is steered in commands.f90 via the type range_t. First there
is some test output (the internal tree-like syntax structure we use),the
trivial examples pass, the final example with a multi-component range fails.
The example works with gfortran 4.8.x and 4.9.0, but fails with all 4.7.x. 
Sometimes the values are forgotten, sometimes a memory leak appears. We were
able to program around this, but nevertheless wanted to file a bug report. 
Here in our svn commit you can see how we basically removed one layer of
polymorphism for the type range_t:
https://whizard.hepforge.org/trac/changeset/5096
Furthermore, the finalizer range_final then worked again. Hope, you can boil
this down to the essential part.

[Bug rtl-optimization/59880] Improve REE for implicit SI->DI zero-extend

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
But REE does the right thing here:
In *.split2 before REE we have:
(insn 218 92 219 16 (set (reg:SI 0 ax [orig:123 D.1966 ] [123])
(reg/v:SI 6 bp [orig:85 ind ] [85])) pr59880.c:77 90 {*movsi_internal}
 (nil))
(insn 219 218 94 16 (set (reg:DI 0 ax [orig:123 D.1966 ] [123])
(zero_extend:DI (reg:SI 0 ax [orig:123 D.1966 ] [123]))) pr59880.c:77
132 {*zero_extendsidi2}
 (nil))
and REE turns that into:
(insn 218 92 94 16 (set (reg:DI 0 ax)
(zero_extend:DI (reg/v:SI 6 bp [orig:85 ind ] [85]))) pr59880.c:77 132
{*zero_extendsidi2}
 (nil))
Then split4 splits that again into:
(insn 308 92 309 21 (set (reg:SI 0 ax)
(reg/v:SI 6 bp [orig:85 ind ] [85])) pr59880.c:77 90 {*movsi_internal}
 (nil))
(insn 309 308 94 21 (set (reg:DI 0 ax)
(zero_extend:DI (reg:SI 0 ax))) pr59880.c:77 132 {*zero_extendsidi2}
 (nil))
and finally sched2 moves those 2 insns appart.  So, this is clearly a backend
issue.

[Bug c++/59867] Template string literal loses first symbol

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867

--- Comment #10 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Right now, -std=c++1y means anything after c++11.  Does anyone have an idea
about what happens when C++14 and these other TSen actually come out?

I guess I was thinking as far as this extension is concerned:
1) It is left *on* for c++1y and gnu++1y for backward compatibility. Sigh.
2) It is *on* with gnu++14 as an extension.
3) It is *off* with c++14 for strict ANSI compatibility.
4) It is maybe on for c++17 and gnu++17 when & if it ever gets in.

We seem to have dynamically sized array (VLA) in this category as well.

[Bug rtl-optimization/59880] New: Improve REE for implicit SI->DI zero-extend

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880

Bug ID: 59880
   Summary: Improve REE for implicit SI->DI zero-extend
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

After r206774, on Linux/x86-64, the following code

---foo.c---
extern __thread unsigned int __bid_IDEC_glbflags;
typedef unsigned long long UINT64;
typedef __attribute__ ((aligned(16))) struct
{
  UINT64 w[2];
} UINT128;
extern UINT64 __bid64_from_uint64 (UINT64);
extern void __bid_round64_2_18 (int q,
int x,
UINT64 C,
UINT64 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
extern void __bid_round128_19_38 (int q,
  int x,
  UINT128 C,
  UINT128 * ptr_Cstar,
  int *delta_exp,
  int *ptr_is_midpoint_lt_even,
  int *ptr_is_midpoint_gt_even,
  int *ptr_is_inexact_lt_midpoint,
  int *ptr_is_inexact_gt_midpoint);
UINT64
__bid64_from_uint64 (UINT64 x)
{
  UINT64 res;
  UINT128 x128, res128;
  unsigned int q, ind;
  int incr_exp = 0;
  int is_midpoint_lt_even = 0, is_midpoint_gt_even = 0;
  int is_inexact_lt_midpoint = 0, is_inexact_gt_midpoint = 0;
  if (x <= 0x002386F26FC0ull) {
if (x < 0x0020ull) {
  res = 0x31c0ull | x;
} else {
  res = 0x6c70ull | (x & 0x0007ull);
}
  }
  else
{
  if (x < 0x16345785d8aull) {
q = 17;
ind = 1;
  } else if (x < 0xde0b6b3a764ull) {
q = 18;
ind = 2;
  } else if (x < 0x8ac7230489e8ull) {
q = 19;
ind = 3;
  } else {
q = 20;
ind = 4;
  }
  if (q <= 19) {
__bid_round64_2_18 (
q, ind, x, &res, &incr_exp,
&is_midpoint_lt_even, &is_midpoint_gt_even,
&is_inexact_lt_midpoint, &is_inexact_gt_midpoint);
  }
  else {
x128.w[1] = 0x0;
x128.w[0] = x;
__bid_round128_19_38 (q, ind, x128, &res128, &incr_exp,
  &is_midpoint_lt_even, &is_midpoint_gt_even,
  &is_inexact_lt_midpoint, &is_inexact_gt_midpoint);
res = res128.w[0];
  }
  if (incr_exp)
ind++;
  if (is_inexact_lt_midpoint || is_inexact_gt_midpoint ||
  is_midpoint_lt_even || is_midpoint_gt_even)
*&__bid_IDEC_glbflags |= 0x0020;
  if (res < 0x0020ull) {
res = (((UINT64) ind + 398) << 53) | res;
  } else
{
  res = 0x6000ull | (((UINT64) ind + 398) << 51) |
(res & 0x0007ull);
}
}
  return(res);;
}
---

contains 2 extra SI->DI zero-extend when compiled with

-O2 -march=corei7 -mtune=slm -fPIC

movl%ebp, %edx  # 311   *movsi_internal/1   [length = 2]
^^^ Implicit SI->DI zero-extend
leaq88(%rsp), %rsp  # 267   pro_epilogue_adjust_stack_di_add/1 
[length = 5]
.cfi_remember_state
.cfi_def_cfa_offset 24
movabsq $2251799813685247, %rax # 101   *movdi_internal/5   [length
= 10]
movl%edx, %edx  # 312   *zero_extendsidi2/4 [length = 2]
^^^ Unnecessary


movl%ebp, %eax  # 308   *movsi_internal/1   [length = 2]
^^^ Implicit SI->DI zero-extend
leaq88(%rsp), %rsp  # 287   pro_epilogue_adjust_stack_di_add/1 
[length = 5]
.cfi_remember_state
.cfi_def_cfa_offset 24
movl%eax, %eax  # 309   *zero_extendsidi2/4 [length = 2]
 Unnecessary

REE pass should remove them.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 19 15:48:14 2014
New Revision: 206774

URL: http://gcc.gnu.org/viewcvs?rev=206774&root=gcc&view=rev
Log:
PR target/59379
* config/i386/i386.md (*lea): Zero-extend return register
to DImode for zero-extended addresses.


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

[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

--- Comment #25 from Jakub Jelinek  ---
Author: jakub
Date: Sun Jan 19 15:30:22 2014
New Revision: 206773

URL: http://gcc.gnu.org/viewcvs?rev=206773&root=gcc&view=rev
Log:
PR rtl-optimization/57763
* bb-reorder.c (fix_crossing_unconditional_branches): Set JUMP_LABEL
on the new indirect jump_insn and increment LABEL_NUSES (label).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c

[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860

--- Comment #4 from Richard Biener  ---
The issue is that after folding strcat_chk -> strcat -> strcpy (dst + strlen,
...)
we do gimplify_and_update_call_from_tree which as part of gimplification
folds the builtins again, which enters update_call_from_tree which tries
to preserve virtual operands (which are not yet there) and finally calls
gsi_replace which does update_stmt ().  That causes virtual operands to be
marked for renaming even if the outer folding routines happily update
virtual operands correctly.

So the issue is that we re-enter the builtin folding machinery via
gimplification and that is able to fold things further than builtins.c
folding which recurses to the tree foldings.

I'm inclined to disable that if ctx->into_ssa, or add a new flag, ->fold_calls.

[in the end we want to remove all stmt folding from the gimplifier and
maybe have one strategical place where we fold all stmts once]

Or, less intrusive, remove that strcat folding from GENERIC folding
(builtins.c) as we have tree-ssa-strlen.c now which optimizes it for
the interesting case of an already available string length - generally
folding strcat to strcpy (dst + strlen (dst), src) isn't profitable.

That also gets rid of that odd optimize_insn_for_speed_p call in builtins.c

[I've skimmed through other calls we generate in builtins.c and decided the
above is the only case where we can recurse into gimple call folding]

[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862

--- Comment #7 from rguenther at suse dot de  ---
On Sun, 19 Jan 2014, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862
> 
> --- Comment #6 from Dominique d'Humieres  ---
> > The release tarball contain generated files so you don't need tools like
> > flex or makeinfo to build GCC.  Those are not present in SVN, so this is
> > definitely not a packaging bug.
> 
> Not sure to understand: gcc/gengtype-lex.c is in the tarball, but not in SVN.
> From the above I understand that gcc/gengtype-lex.c should also not be in the
> tarball.

No, it is in the tarball so building does not require the tools to
build it.

> Is this correct? What could be the effect of gcc/gengtype-lex.c?

That local flex is not used to build gengtype-lex.c from gengtype-lex.l

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379

--- Comment #19 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #18)
> I have checked that this patch with the testcase from Comment #9, using "-O
> -march=corei7 -mtune=slm" compile options. The resulting binary worked OK.

Yes, the resulting GCC works correctly.  However, we generate
extra

(set (reg:DI) (zero_extend:DI (reg:SI)))

It is because we generate

(set (reg:SI) (reg:SI)
(set (reg:DI) (zero_extend:DI (reg:SI)))

REE pass doesn't know

(set (reg:SI) (reg:SI)

has an implicit ZERO_EXTEND.  Here is a testcase:

---foo.c---
extern __thread unsigned int __bid_IDEC_glbflags;
typedef unsigned long long UINT64;
typedef __attribute__ ((aligned(16))) struct
{
  UINT64 w[2];
} UINT128;
extern UINT64 __bid64_from_uint64 (UINT64);
extern void __bid_round64_2_18 (int q,
int x,
UINT64 C,
UINT64 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
extern void __bid_round128_19_38 (int q,
  int x,
  UINT128 C,
  UINT128 * ptr_Cstar,
  int *delta_exp,
  int *ptr_is_midpoint_lt_even,
  int *ptr_is_midpoint_gt_even,
  int *ptr_is_inexact_lt_midpoint,
  int *ptr_is_inexact_gt_midpoint);
UINT64
__bid64_from_uint64 (UINT64 x)
{
  UINT64 res;
  UINT128 x128, res128;
  unsigned int q, ind;
  int incr_exp = 0;
  int is_midpoint_lt_even = 0, is_midpoint_gt_even = 0;
  int is_inexact_lt_midpoint = 0, is_inexact_gt_midpoint = 0;
  if (x <= 0x002386F26FC0ull) {
if (x < 0x0020ull) {
  res = 0x31c0ull | x;
} else {
  res = 0x6c70ull | (x & 0x0007ull);
}
  }
  else
{
  if (x < 0x16345785d8aull) {
q = 17;
ind = 1;
  } else if (x < 0xde0b6b3a764ull) {
q = 18;
ind = 2;
  } else if (x < 0x8ac7230489e8ull) {
q = 19;
ind = 3;
  } else {
q = 20;
ind = 4;
  }
  if (q <= 19) {
__bid_round64_2_18 (
q, ind, x, &res, &incr_exp,
&is_midpoint_lt_even, &is_midpoint_gt_even,
&is_inexact_lt_midpoint, &is_inexact_gt_midpoint);
  }
  else {
x128.w[1] = 0x0;
x128.w[0] = x;
__bid_round128_19_38 (q, ind, x128, &res128, &incr_exp,
  &is_midpoint_lt_even, &is_midpoint_gt_even,
  &is_inexact_lt_midpoint, &is_inexact_gt_midpoint);
res = res128.w[0];
  }
  if (incr_exp)
ind++;
  if (is_inexact_lt_midpoint || is_inexact_gt_midpoint ||
  is_midpoint_lt_even || is_midpoint_gt_even)
*&__bid_IDEC_glbflags |= 0x0020;
  if (res < 0x0020ull) {
res = (((UINT64) ind + 398) << 53) | res;
  } else
{
  res = 0x6000ull | (((UINT64) ind + 398) << 51) |
(res & 0x0007ull);
}
}
  return(res);;
}
---

Compiling with -fPIC -O2, the differences between your patch and mine
are

--- bad.s2014-01-19 06:10:28.006570325 -0800
+++ foo.s2014-01-19 06:11:46.117754696 -0800
@@ -84,19 +84,18 @@ __bid64_from_uint64:
 movabsq$9007199254740991, %rax
 cmpq%rax, %rbx
 jbe.L23
-movl%ebp, %edx
 leaq88(%rsp), %rsp
 .cfi_remember_state
 .cfi_def_cfa_offset 24
 movabsq$2251799813685247, %rax
-movl%edx, %edx
+movl%ebp, %edx
 andq%rbx, %rax
-movabsq$6917529027641081856, %rcx
 popq%rbx
 .cfi_def_cfa_offset 16
+movabsq$6917529027641081856, %rcx
 addq$398, %rdx
-orq%rcx, %rax
 salq$51, %rdx
+orq%rcx, %rax
 popq%rbp
 .cfi_def_cfa_offset 8
 orq%rdx, %rax
@@ -154,7 +153,6 @@ __bid64_from_uint64:
 leaq88(%rsp), %rsp
 .cfi_remember_state
 .cfi_def_cfa_offset 24
-movl%eax, %eax
 addq$398, %rax
 salq$53, %rax
 orq%rbx, %rax

My patch removes 2 extra

(set (reg:DI) (zero_extend:DI (reg:SI)))

[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862

--- Comment #6 from Dominique d'Humieres  ---
> The release tarball contain generated files so you don't need tools like
> flex or makeinfo to build GCC.  Those are not present in SVN, so this is
> definitely not a packaging bug.

Not sure to understand: gcc/gengtype-lex.c is in the tarball, but not in SVN.
>From the above I understand that gcc/gengtype-lex.c should also not be in the
tarball.
Is this correct? What could be the effect of gcc/gengtype-lex.c?

[Bug fortran/57129] [4.7/4.8/4.9 Regression] Improve error message for conflicts between PROCEDURE and DERIVED.

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords|error-recovery, |diagnostic
   |ice-on-invalid-code |
   Priority|P4  |P5
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8/4.9 Regression]
   |ICE (segfault) in   |Improve error message for
   |check_extended_derived_type |conflicts between PROCEDURE
   ||and DERIVED.
   Severity|normal  |minor

--- Comment #9 from Dominique d'Humieres  ---
> However, the error message is now different from before for the test case 
> in comment 0 and this reduction:
> ...

Confirmed. AFAICT the error message with 4.6 comes from gcc/fortran/symbol.c
while the present one comes from gcc/fortran/dec.c.

I have changed the summary to reflect the present situation. Should we keep the
regression flags?

[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862

--- Comment #5 from Richard Biener  ---
(In reply to Dominique d'Humieres from comment #4)
> I have downloaded the two releases. Comparing gcc/fortran, the only
> difference is
> 
> Only in gcc-4.8.1/gcc/fortran/: gfortran.info
> 
> in wget http://ftp.gnu.org/gnu/gcc/gcc-4.8.1/gcc-4.8.1.tar.gz
> 
> Comparing gcc, the only difference is
> 
> Only in gcc-4.8.1/gcc/: gengtype-lex.c
> 
> I don't know if the presence or not of gengtype-lex.c can explain what you
> report.
> IMO this is a packaging issue not a gfortran one. I'ld like to close it as
> WONTFIX, but I am CCing release managers for advice.

The release tarball contain generated files so you don't need tools like
flex or makeinfo to build GCC.  Those are not present in SVN, so this is
definitely not a packaging bug.

[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872

Jonathan Wakely  changed:

   What|Removed |Added

 CC||drahflow at gmx dot de

--- Comment #8 from Jonathan Wakely  ---
*** Bug 59876 has been marked as a duplicate of this bug. ***

[Bug libstdc++/59876] _Rb_tree move constructor invokes _M_copy

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
dup

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

[Bug c++/59879] New: arrays in return statements or default arguments decay too early

[st at quanttec dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59879

Bug ID: 59879
   Summary: arrays in return statements or default arguments decay
too early
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: st at quanttec dot com

g++ seems to decay arrays in return statements or default arguments too early. 

The following sample fails to compile with 4.8.2 and the current GIT master
version of gcc but compiles cleanly in clang:

--
struct Test {
  template 
  Test(const char (&array)[N]) {}
};

Test test() {
  return "test";
}

void test2(Test arg = "test") {}

int main() {
  test();
  test2();
}
--

g++ test.cpp
test.cpp: In function ‘Test test()’:
test.cpp:8:10: error: could not convert ‘(const char*)"test"’ from ‘const
char*’ to ‘Test’
   return "test";
  ^
test.cpp: In function ‘int main()’:
test.cpp:15:9: error: could not convert ‘(const char*)"test"’ from ‘const
char*’ to ‘Test’
   test2();
 ^

[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type

[potswa at mac dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872

--- Comment #7 from David Krauss  ---
That's a better factoring. I was just avoiding creating a new, named function.
Thanks!

[Bug tree-optimization/59875] Missed unrolling opportunity

[josephlawrie at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875

--- Comment #4 from josephlawrie at hotmail dot com ---
> To let the compiler know that you want the standard operator delete (which
> does nothing on 0), I am not sure what should be done. It is a different
> issue, which you would need to ask about in a separate PR. 

> I think libstdc++ should provide an option to get
> inline definitions of those functions (I know the standard forbids them to
> be inline), possibly even omitting the new_handler code.

Thank you - I realise I was originally very unclear, but being able to get "an
inline version" was the intention of posting this hear. Basically link time
optimization (inconvienient) or static linking (also inconvenient) are the only
correct solitions, as others would make the functions non-replacable. 

My concern was that being unable to specify default delete could prevent
optimization in some cases (even when building statically), but according to
you this is not the case in the example, as it is the loop unrolling that
prevents the optimization here. Thank you.

[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872

--- Comment #6 from Jonathan Wakely  ---
I don't want to use SFINAE here, I'll fix it the same way it's done in the
other containers, tag dispatching using
  std::integral_constant

[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-19
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|Cannot move std::map with   |[4.9 Regression] Cannot
   |move-only mapped_type   |move std::map with
   ||move-only mapped_type
 Ever confirmed|0   |1

[Bug libstdc++/59876] _Rb_tree move constructor invokes _M_copy

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876

--- Comment #2 from Jonathan Wakely  ---
isn't this a duplicate of PR 59872?

[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414

--- Comment #12 from Paul Thomas  ---
(In reply to janus from comment #3)

snip

> 
> module ObjectLists
>   implicit none
> 
>   type :: t
>   end type
>   
>   type Object_array_pointer
> class(t), pointer :: p(:)
>   end type
> 
> contains
> 
>   subroutine AddArray (P, Pt)
> class(t) :: P(:)
> class(Object_array_pointer) :: Pt
> 
> select type (Pt)
> class is (Object_array_pointer)

ICE disappears with type is (Object_array_pointer)

>   allocate(Pt%P(1:SIZE(P)), source=P)
> end select
>   end subroutine
> 
> end module

Paul

[Bug tree-optimization/59875] Missed unrolling opportunity

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875

--- Comment #3 from Marc Glisse  ---
(In reply to josephlawrie from comment #2)
> (In reply to Marc Glisse from comment #1)
> Am I correct in understanding this would not be possible without -fno-weak
> or when linking dynamically? In those cases, the function of delete could
> not be know when optimizingm, surely?

My comments were for the version where you uncomment the definitions of new and
delete:

#include 
#include 
#include 

struct P {
P() : _value(0) {}
~P() { if(_value) free(_value); }
   char *_value;
};

int main() {
  if(std::array().size() != 4)
assert(false);
}


You can look at what happens if you change the size of the array to 1, which
removes the unrolling issue. After unrolling, you get either 4 calls to
operator delete(0), or nothing if you provided your definition of delete.

To let the compiler know that you want the standard operator delete (which does
nothing on 0), I am not sure what should be done. It is a different issue,
which you would need to ask about in a separate PR. The easiest is probably to
use -flto (it has to be used all the way, in particular when building
libsupc++). I think libstdc++ should provide an option to get inline
definitions of those functions (I know the standard forbids them to be inline),
possibly even omitting the new_handler code.

[Bug fortran/55172] [4.7 Regression] [OOP] gfc_variable_attr(): Bad array reference in SELECT TYPE

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
I think that it is best to leave this unfixed for 4.7 - see comment #5

I have therefore marked the PR as resolved.

Thanks for the report

Paul

[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878

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

[Bug libstdc++/59876] _Rb_tree move constructor invokes _M_copy

[drahflow at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876

--- Comment #1 from Jens-Wolfhard Schicke  ---
Sorry, I forgot.

~ % gcc-4.9 --version
gcc-4.9 (Debian 4.9-20140116-1) 4.9.0 20140116 (experimental) [trunk revision
206688]

~ % dpkg -l libstdc++-4.9-dev:amd64
||/ Name   Version  Architecture Description
+++-==---=
ii  libstdc++-4.9- 4.9-20140116 amd64GNU Standard C++ Library v3 (deve

[Bug bootstrap/59878] New: [4.9 Regression] ISL from cloog does not work with trunk

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878

Bug ID: 59878
   Summary: [4.9 Regression] ISL from cloog does not work with
trunk
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org

How to reproduce:

- Get isl from infrastructure directory
- configure
- install by default (installs in /usr/local)
- Get cloog from the infrastructure directory
- configure without any options
- install
- configure using

VER=../trunk/configure && test -e $VER && rm -rf * && $VER --prefix=$HOME
--with-isl=/usr/local --with-cloog=/usr/local --enable-languages=c,fortran,c++
&& make -j6 && make install

Result then is

checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for version 0.10 of ISL... no
checking for version 0.11 of ISL... no
checking for version 0.12 of ISL... no
configure: error: Unable to find a usable ISL.  See config.log for details.

The reason for this is shown in the modified test program:

ig25@linux-fd1f:/tmp> cat isl.c
#include 
#include 
int
main ()
{
  printf("%s", isl_version ());
}

ig25@linux-fd1f:/tmp> gcc isl.c -lisl
ig25@linux-fd1f:/tmp> ./a.out
UNKNOWN

It is necessary to configure cloog with --with-isl=system go get around that,
which is not documented anywhere.

[Bug target/52125] Problems with LO16 asm operands on MIPS

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52125

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #14 from Paul Thomas  ---
Finally backported to 4.8!

Thanks for the report

Paul

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585

Bug 20585 depends on bug 34547, which changed state.

Bug 34547 Summary: [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts 
invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547

   What|Removed |Added

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

[Bug fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Sun Jan 19 11:28:44 2014
New Revision: 206772

URL: http://gcc.gnu.org/viewcvs?rev=206772&root=gcc&view=rev
Log:
2014-01-19  Paul Thomas  

PR fortran/34547
* resolve.c (resolve_transfer): EXPR_NULL is always in an
invalid context in a transfer statement.

2014-01-19  Paul Thomas  

PR fortran/34547
* gfortran.dg/null_5.f90 : Include new error.
* gfortran.dg/null_6.f90 : Include new error.

Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/resolve.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/null_5.f90
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/null_6.f90

[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> So r202823 is likely to have fixed this PR.

I can confirm that r202823 has fixed the ICE: Reverting that revision
reintroduces the ICE.

I can also confirm that the ICE is gone on all recent versions of trunk, 4.8
and 4.7.

However, the error message is now different from before for the test case in
comment 0 and this reduction:

subroutine t
  type t
  end type
end

With 4.6 one correctly gets:

  type t
1
Error: PROCEDURE attribute of 't' conflicts with DERIVED attribute at (1)

while the recent versions now give:

  type t
1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 't' at (1)


This is surprising, since the FUNCTION attribute is not specified anywhere in
the test case. Apparently this is also due to Tobias' constructor patch
(r181425).

[Bug tree-optimization/59875] Missed unrolling opportunity

[josephlawrie at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875

--- Comment #2 from josephlawrie at hotmail dot com ---
(In reply to Marc Glisse from comment #1)

> I don't think it has anything to do with glibc or weak. If I patch
> tree-ssa-loop-ivcanon.c (couldn't find a sufficient option or parameter) to
> convince the compiler that it is ok to unroll the loop although it isn't an
> inner loop and it contains calls on the "hot" path, it manages to optimize
> foo to nothing.

Am I correct in understanding this would not be possible without -fno-weak or
when linking dynamically? In those cases, the function of delete could not be
know when optimizingm, surely?

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

[lucdanton at free dot fr]

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

--- Comment #1 from lucdanton at free dot fr ---
Happens too with GCC 4.9 (20140105), as well as when using decltype(auto).

[Bug c++/59877] Internal compiler error: Error reporting routines re-entered.

[hawran.diskuse at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59877

--- Comment #1 from hawran.diskuse  ---
Created attachment 31890
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31890&action=edit
A bug file and fixed file (I hope it could help)

[Bug c++/59877] New: Internal compiler error: Error reporting routines re-entered.

[hawran.diskuse at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59877

Bug ID: 59877
   Summary: Internal compiler error: Error reporting routines
re-entered.
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hawran.diskuse at gmail dot com

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

An error has occurred when compilling:
==
g++ -Wall -pedantic -g -std=c++11 main.cpp -o main
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccvp7WyF.out file, please attach this to
your bugreport.

Additional info:

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 13.04
Release:13.04
Codename:   raring
---
uname -a
Linux ... 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
---
gcc --version
gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
Copyright (C) 2012 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 fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||janus at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #11)
> Fixed by Paul's patch at
> http://gcc.gnu.org/ml/fortran/2013-11/msg00203.html

... which has been committed to trunk as r205565. Backport pending.

[Bug c++/59867] Template string literal loses first symbol

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867

--- Comment #9 from Paolo Carlini  ---
Tuesday works for me ;) Seriously, thanks for looking into this.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379

--- Comment #18 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #17)

> > I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is
> > true.
> 
> Then we should avoid the extra
> 
> (set (reg:DI) (zero_extend:DI (reg:SI)))

ree pass, located just after post-reload split, should handle this extra
zero-extend insn. Based on this fact, we can just slap a zero-extend insn at
the end of sequence with:

--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 206753)
+++ config/i386/i386.md (working copy)
@@ -5428,12 +5428,17 @@
   operands[0] = SET_DEST (pat);
   operands[1] = SET_SRC (pat);

-  /* Emit all operations in SImode for zero-extended addresses.  Recall
- that x86_64 inheretly zero-extends SImode operations to DImode.  */
+  /* Emit all operations in SImode for zero-extended addresses.  */
   if (SImode_address_operand (operands[1], VOIDmode))
 mode = SImode;

   ix86_split_lea_for_addr (curr_insn, operands, mode);
+
+  /* Zero-extend return register to DImode for zero-extended addresses.  */
+  if (mode != mode)
+emit_insn (gen_zero_extendsidi2
+  (operands[0], gen_lowpart ((mode), operands[0])));
+
   DONE;
 }
   [(set_attr "type" "lea")
--cut here--

I have checked that this patch with the testcase from Comment #9, using "-O
-march=corei7 -mtune=slm" compile options. The resulting binary worked OK.

[Bug bootstrap/59864] [4.9 regression] RTL check: expected code 'reg', have 'ne' in rhs_regno, at rtl.h:1125

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59864

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Patch has been installed.

[Bug c++/57926] Atomic functions broken with C++ but not C?

[lailavrazda1979 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926

--- Comment #11 from lailavrazda1979 at gmail dot com ---
I don't mean to be a bother, but this hasn't been updated in a while. Has it
been fixed?

[Bug tree-optimization/59875] Missed unrolling opportunity

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-19
Summary|Weak symbols in glibc   |Missed unrolling
   |prevent optimizations   |opportunity
 Ever confirmed|0   |1
   Severity|trivial |normal

--- Comment #1 from Marc Glisse  ---
(note that your new/delete prototypes are the C++03 ones, you should change
them for C++11)

I don't think it has anything to do with glibc or weak. If I patch
tree-ssa-loop-ivcanon.c (couldn't find a sufficient option or parameter) to
convince the compiler that it is ok to unroll the loop although it isn't an
inner loop and it contains calls on the "hot" path, it manages to optimize foo
to nothing.

gcc-4.4 (if we tweak the example so it compiles) did unroll the loop, but only
optimized away the test for the last element of the array.

It would also be possible for the compiler to notice that all array elements
are the same and thus any access (in range) will yield the same value, but that
seems more specialized.

[Bug libstdc++/59876] New: _Rb_tree move constructor invokes _M_copy

[drahflow at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876

Bug ID: 59876
   Summary: _Rb_tree move constructor invokes _M_copy
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drahflow at gmx dot de

#include 
#include 

using namespace std;

int main(void) {
  map> m1;
  map> m2(move(m1));
}

fails to compile under 4.9 (but works fine with 4.7 and 4.8).



A change was introduced in 4.9 after which the move constructor of _Rb_tree
invokes _M_copy on a range of elements (which might not be copy-constructible).

Cursory analysis suggests the problem is at
/usr/include/c++/4.9/bits/stl_tree.h line 1021.