[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Fixing on SPARC.

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

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #8)
> Confirmed, however compiling the second test in comment #0, namely
> 
>  integer, allocatable :: i(:)
>  print *, NULL(i)
> end
> gives an ICE with 4.8.1 and trunk (4.9)


"If an input item is a pointer, it shall be associated with a definable target
and data are transferred from the file to the associated target. If an output
item is a pointer, it shall be associated with a target and data are
transferred
from the target to the file." (F2008, "9.6.3 Data transfer input/output list")

And NULL(...) isn't. Fixed by Paul's patch at
http://gcc.gnu.org/ml/fortran/2013-11/msg00203.html

[Bug tree-optimization/59359] New: Segmentation fault in thread_through_all_blocks

[antoine.balestrat at gmail dot com]

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

Bug ID: 59359
   Summary: Segmentation fault in thread_through_all_blocks
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoine.balestrat at gmail dot com

Hello !
The following testcase makes GCC 4.9.0 as of 20131201 crash.

$ cat seg.c
int a, b;

void f()
{
int c = 0;

for(; b; b++)
{
for(a = 0; a; a++);

unsigned d = 1;

for(; c < 2; c++)
if(d = (c = d) < 1)
return;
}
}

$ xgcc -O2 -w seg.c
seg.c: In function ‘f’:
seg.c:3:6: internal compiler error: Segmentation fault
 void f()
  ^
0x9901cf crash_signal
../../srcdir/gcc/toplev.c:336
0xb33a67 thread_through_all_blocks(bool)
../../srcdir/gcc/tree-ssa-threadupdate.c:1652
0xa7a7ab tree_ssa_dominator_optimize
../../srcdir/gcc/tree-ssa-dom.c:886
0xa7a7ab execute
../../srcdir/gcc/tree-ssa-dom.c:984
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.

[Bug fortran/57354] Wrong run-time assignment of allocatable array of derived type with allocatable component

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
(In reply to Paul Thomas from comment #3)
> This patch is preliminary since a temporary is produced, for each
> assignment, copied to the newly reallocated lhs and then deallocated.
> Clearly it would be more efficient to deallocate the lhs and then point the
> lhs to the temporary.

Well, if one has code such as
  a = [a, e]
(and not: "a = [e, a]" or "a = [a, e]*5") one could even do a simple realloc(),
which preserves the data when being extended.

However, one needs to be careful with finalization when using realloc() as both
the LHS and the array constructor would be finalized. (Order: evaluation of the
RHS, finalization of the LHS, assignment, finalization of the RHS [= of the
array constructor/temporaries]. – But that would often involve defined
assignment.)
Note: Finalization of the LHS and of function results + array/structure
constructors after their use is not yet implemented.

[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 #5 from Paul Thomas  ---
Author: pault
Date: Sun Dec  1 11:42:25 2013
New Revision: 205566

URL: http://gcc.gnu.org/viewcvs?rev=205566&root=gcc&view=rev
Log:
2013-12-01  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:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug fortran/57354] Wrong run-time assignment of allocatable array of derived type with allocatable component

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sun Dec  1 11:50:20 2013
New Revision: 205567

URL: http://gcc.gnu.org/viewcvs?rev=205567&root=gcc&view=rev
Log:
2013-12-01  Paul Thomas  

PR fortran/57354
* trans-array.c (gfc_conv_resolve_dependencies): For other than
SS_SECTION, do a dependency check if the lhs is liable to be
reallocated.

2013-12-01  Paul Thomas  

PR fortran/57354
* gfortran.dg/realloc_on_assign_23.f90 : New test

Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_23.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn

[stigge at antcom dot de]

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

--- Comment #5 from Roland Stigge  ---
More info: I just checked that the issue is still present in 4.8.2.

Without --with-long-double-128, the problem doesn't occur.

Any hint where I should look for?

Thanks in advance!

[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with >=O2

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-01
  Component|c   |tree-optimization
   Target Milestone|--- |4.8.3
Summary|Infinite loop generated |[4.8/4.9 Regression]
   |with >=O2   |Infinite loop generated
   ||with >=O2
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #1 from Marc Glisse  ---
void smartlist_ensure_capacity(int *capacity, int size) {
  int higher = *capacity;
  if (size > higher) {
if (size <= 16) {
  while (size > higher) {
higher *= 2;
  }
}
  }
}

compiled with -O2, VRP1 seems guilty.

[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type

[d.frey at gmx dot de]

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

Daniel Frey  changed:

   What|Removed |Added

 CC||d.frey at gmx dot de

--- Comment #2 from Daniel Frey  ---
Here's another short example which seems to expose the same bug:

template< typename > struct X
{
  void foo() {}

  auto bar() -> decltype( X::foo() ) //1
  {
return foo();
  }
};

int main()
{
  X().bar();
}

Note that the decltype in //1 causes the problem, not the body of the function.
Changing //1 to decltype(foo()) fails with the same error message, changing it
to either decltype(this->foo()) or decltype(std::declval().foo()) solves the
problem and GCC accepts the code. Also note that Clang compiles all versions
just fine.

The bug seems to occur in unevaluated contexts and only for templates. If you
change the above class X to be a non-template GCC accepts the code as well.

[Bug c++/59360] New: Complicated bind expression causing infinite recursive template instantiations

[eric.niebler at gmail dot com]

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

Bug ID: 59360
   Summary: Complicated bind expression causing infinite recursive
template instantiations
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com

This code compiles with clang 3.3 but doesn't compile with gcc 4.8.2 with
-std=gnu++11:

#include 
#include 
#include 
#include 
#include 

constexpr struct adjacent_finder
{
template
typename Rng::const_iterator
operator()(Rng const & rng) const
{
return std::adjacent_find(rng.begin(), rng.end());
}
} adjacent_find {};

constexpr struct ranger
{
template
std::pair
operator()(It begin, It end) const
{
return std::make_pair(begin, end);
}
} range {};

constexpr struct prever
{
template
It operator()(It begin) const
{
return std::prev(begin);
}
} prev {};

constexpr struct ender
{
template
typename Rng::const_iterator
operator()(Rng const & rng) const
{
return rng.end();
}
} end {};

int main()
{
using std::placeholders::_1;

auto fun = std::bind(
range,
std::bind(adjacent_find, _1),
std::bind(prev, std::bind(end, _1))
);

std::vector vi;
fun(vi);
}

From the error backtrace:

In file included from test2.cpp:2:0:
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1138:35: error: template
instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase
the maximum) substituting ‘template typename
std::add_rvalue_reference<  >::type std::declval()
[with _Tp = std::vector&]’
  -> decltype(__arg(declval<_Args>()...))
   ^
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1391:40:   recursively
required by substitution of ‘template decltype
(__arg((declval<_Args>)()...)) std::_Mu<_Arg, true, false>::operator()(_CVArg&,
std::tuple<_Args2 ...>&) const volatile [with _CVArg = _CVArg; _Args = {_Args
...}; _Arg = std::_Bind)>] [with _CVArg = const
volatile std::_Bind)>; _Args = {std::vector >&}]’
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1391:40:   required by
substitution of ‘template decltype (__arg((declval<_Args>)()...)) std::_Mu<_Arg, true,
false>::__call(_CVArg&, std::tuple<_Args2 ...>&, const
std::_Index_tuple<_Indexes ...>&) const volatile [with _CVArg = _CVArg; _Args =
{_Args ...}; unsigned int ..._Indexes = {_Indexes ...}; _Arg =
std::_Bind)>)>] [with _CVArg =
std::_Bind)>)>; _Args =
{std::vector >&}; unsigned int ..._Indexes = {0u}]’
/usr/local/gcc-4.8.2/include/c++/4.8.2/functional:1143:50:   template
instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase
the maximum) substituting ‘template typename
std::add_rvalue_reference<  >::type std::declval()
[with _Tp = std::vector&]’

[rest snipped...]

[Bug c++/59361] New: cannot expand parenthesized pack expression

[eric.niebler at gmail dot com]

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

Bug ID: 59361
   Summary: cannot expand parenthesized pack expression
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com

The following compiles with clang but doesn't with g++ 4.8.2 with -std=gnu++11:

template
struct and_ 
{
constexpr static bool value{true};
};

template
struct true_
{
constexpr operator bool() const { return true; }
};

template
constexpr bool foo(Ts...)
{
return and_<(true_())...>::value;
}

int main()
{
}

The error I get is:

test.cpp: In function ‘constexpr bool foo(Ts ...)’:
test.cpp:16:34: error: expected parameter pack before ‘...’
 return and_<(true_())...>::value;
  ^
test.cpp:16:37: error: template argument 1 is invalid
 return and_<(true_())...>::value;
 ^

[Bug c++/59360] Complicated bind expression causing infinite recursive template instantiations

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
another dup of PR 57899 ?

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
Created attachment 31343
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31343&action=edit
WIP

Let me attach this here. save_expr+build_vector_from_val is unnecessary, the
BIT_*_EXPR case would handle it. scalar&&vector is short-circuit (not
vector&&any), that's easy to change but it makes sense to me to have it
short-circuit since it is possible.

This is all untested and more stage1 material anyway.

And we will still need quite a few simple optimizations on vectors to get
sensible code out of it (things like (a

[Bug c/59362] New: Abort in fini_object_sizes

[dcb314 at hotmail dot com]

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

Bug ID: 59362
   Summary: Abort in fini_object_sizes
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 31344
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31344&action=edit
C source code

I just tried to compile the attached source code
with trunk of 20131130 and it said

lens.c:1063:7: internal compiler error: Aborted
0xa8ed5f crash_signal
../../src/trunk/gcc/toplev.c:336
0xb18fe4 fini_object_sizes
../../src/trunk/gcc/tree-object-size.c:1200
0xb18fe4 compute_object_sizes
../../src/trunk/gcc/tree-object-size.c:1279
0xb18fe4 execute
../../src/trunk/gcc/tree-object-size.c:1309
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Preprocessed source code attached. Flags -O2 -std=gnu99 required.
~

[Bug libfortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-12/msg00018.htm
   ||l
  Component|fortran |libfortran
   Target Milestone|--- |4.9.0

--- Comment #4 from Uroš Bizjak  ---
Patch at [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00018.html

[Bug c/59362] Abort in fini_object_sizes

[octoploid at yandex dot com]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||octoploid at yandex dot com

--- Comment #1 from Markus Trippelsdorf  ---
Valgrind shows:

==3073== Invalid write of size 8
==3073==at 0x8C60BF: collect_object_sizes_for(object_size_info*,
tree_node*) (tree-object-size.c:913)
==3073==by 0x8C6CA4: merge_object_sizes(object_size_info*, tree_node*,
tree_node*, unsigned long) [clone .isra.26] (tree-object-size.c:745)
==3073==by 0x8C68BA: collect_object_sizes_for(object_size_info*,
tree_node*) (tree-object-size.c:956)
==3073==by 0x8C5188: compute_builtin_object_size(tree_node*, int)
(tree-object-size.c:539)
==3073==by 0x5BACA7: fold_builtin_2(unsigned int, tree_node*, tree_node*,
tree_node*, bool) (builtins.c:12721)
==3073==by 0x5BBBAB: fold_builtin_n(unsigned int, tree_node*, tree_node**,
int, bool) (builtins.c:8)
==3073==by 0x5C3F54: fold_call_stmt(gimple_statement_base*, bool)
(builtins.c:14252)
==3073==by 0x8C43A6: (anonymous namespace)::pass_object_sizes::execute()
(tree-object-size.c:1224)
==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215)
==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268)
==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269)
==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763)
==3073==  Address 0x53a8bc8 is 0 bytes after a block of size 856 alloc'd
==3073==at 0x40274F0: malloc (vg_replace_malloc.c:291)
==3073==by 0xD38CC7: xmalloc (xmalloc.c:147)
==3073==by 0x8C4182: init_object_sizes() [clone .part.28]
(tree-object-size.c:1183)
==3073==by 0x8C4B83: (anonymous namespace)::pass_object_sizes::execute()
(ssa-iterators.h:498)
==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215)
==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268)
==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269)
==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763)
==3073==by 0x5FE477: compile() (cgraphunit.c:1868)
==3073==by 0x5FE7D4: finalize_compilation_unit() (cgraphunit.c:2280)
==3073==by 0x51E92B: c_write_global_declarations() (c-decl.c:10388)
==3073==by 0x866B7C: compile_file() (toplev.c:561)
==3073== 
==3073== Invalid read of size 8
==3073==at 0x8C6535: collect_object_sizes_for(object_size_info*,
tree_node*) (tree-object-size.c:799)
==3073==by 0x8C6CA4: merge_object_sizes(object_size_info*, tree_node*,
tree_node*, unsigned long) [clone .isra.26] (tree-object-size.c:745)
==3073==by 0x8C68BA: collect_object_sizes_for(object_size_info*,
tree_node*) (tree-object-size.c:956)
==3073==by 0x8C5188: compute_builtin_object_size(tree_node*, int)
(tree-object-size.c:539)
==3073==by 0x5BACA7: fold_builtin_2(unsigned int, tree_node*, tree_node*,
tree_node*, bool) (builtins.c:12721)
==3073==by 0x5BBBAB: fold_builtin_n(unsigned int, tree_node*, tree_node**,
int, bool) (builtins.c:8)
==3073==by 0x5C3F54: fold_call_stmt(gimple_statement_base*, bool)
(builtins.c:14252)
==3073==by 0x8C43A6: (anonymous namespace)::pass_object_sizes::execute()
(tree-object-size.c:1224)
==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215)
==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268)
==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269)
==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763)
==3073==  Address 0x53a8bc8 is 0 bytes after a block of size 856 alloc'd
==3073==at 0x40274F0: malloc (vg_replace_malloc.c:291)
==3073==by 0xD38CC7: xmalloc (xmalloc.c:147)
==3073==by 0x8C4182: init_object_sizes() [clone .part.28]
(tree-object-size.c:1183)
==3073==by 0x8C4B83: (anonymous namespace)::pass_object_sizes::execute()
(ssa-iterators.h:498)
==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215)
==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268)
==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269)
==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763)
==3073==by 0x5FE477: compile() (cgraphunit.c:1868)
==3073==by 0x5FE7D4: finalize_compilation_unit() (cgraphunit.c:2280)
==3073==by 0x51E92B: c_write_global_declarations() (c-decl.c:10388)
==3073==by 0x866B7C: compile_file() (toplev.c:561)
==3073== 

AddressSanitizer:

markus@x4 tmp % /var/tmp/gcc_sani/usr/local/bin/gcc -c -O2 -std=gnu99 bug124.c
=
==2994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6180001343d8
at pc 0x133f0e8 bp 0x7fffe70fc990 sp 0x7fffe70fc988
WRITE of size 8 at 0x6180001343d8 thread T0
#0 0x133f0e7 in collect_object_sizes_for(object_size_info*, tree_node*)
/var/tmp/gcc_build_dir/gcc/

[Bug c/59362] Abort in fini_object_sizes

[octoploid at yandex dot com]

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

--- Comment #2 from Markus Trippelsdorf  ---
Reduced:

markus@x4 tmp % cat test.i
char *a;
long int b;
void enc_format() {
  b = __builtin_object_size(0, 0);
  a = __builtin___stpcpy_chk(0, "", b);
  b = __builtin_object_size(a, 0);
}

markus@x4 tmp % gcc -c -O2 test.i
*** Error in `/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1': free(): invalid
next size (fast): 0x029aaab0 ***
=== Backtrace: =
...

[Bug libfortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Dec  1 20:56:21 2013
New Revision: 205574

URL: http://gcc.gnu.org/viewcvs?rev=205574&root=gcc&view=rev
Log:
PR libfortran/59313
* intrinsics/erfc_scaled.c (erfc_scaled_r16): Also provide for
quadruple precision long double variant.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/erfc_scaled.c
trunk/libgfortran/intrinsics/erfc_scaled_inc.c

[Bug libfortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
> print *, a
produces (internal representation, -fdump-tree-original):
a.dtype = 265;
a.dim[0].lbound = 1;
a.dim[0].ubound = 4;
a.dim[0].stride = 1;
a.data = (void * restrict) &t[0].a;
  _gfortran_transfer_array_write (&dt_parm.6, &a, 4, 0);
obviously, stride = 1 is wrong.

In trans_associate_var, one has:
  if (sym->assoc->variable)
{
  se.direct_byref = 1;
  se.expr = desc;
}
  gfc_conv_expr_descriptor (&se, e);
where desc == backend decl of "a" (name in the associate statement) and e ==
gfc_expr of the selector (i.e. t%a).

I have not yet completely understood why, but the call gfc_conv_expr_descriptor
yields a unit stride.

[Bug target/59363] New: [4.9 Regression] r203886 miscompiles git

[octoploid at yandex dot com]

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

Bug ID: 59363
   Summary: [4.9 Regression] r203886 miscompiles git
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: octoploid at yandex dot com

Starting with r203886 git gets miscompiled on my machine.
For example:

 % git blame gcc/tree-object-size.c

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x0051240d in xdl_emit_hunk_hdr (s1=s1@entry=1291, c1=, s2=s2@entry=1291, c2=c2@entry=1, func=func@entry=0x7fffd2d8 "",
funclen=0, 
ecb=ecb@entry=0x7fffd580) at xdiff/xutils.c:460
#2  0x00512af7 in xdl_emit_diff (xe=0x7fffd390, xscr=, ecb=0x7fffd580, xecfg=0x7fffd590) at xdiff/xemit.c:237
#3  0x00510a5d in xdl_diff (mf1=mf1@entry=0x7fffd510,
mf2=mf2@entry=0x7fffd520, xpp=xpp@entry=0x7fffd570,
xecfg=xecfg@entry=0x7fffd590, 
ecb=ecb@entry=0x7fffd580) at xdiff/xdiffi.c:601
#4  0x0050b005 in xdi_diff (mf1=, mf2=,
xpp=xpp@entry=0x7fffd570, xecfg=xecfg@entry=0x7fffd590,
xecb=xecb@entry=0x7fffd580)
at xdiff-interface.c:136
#5  0x004104df in diff_hunks (file_a=, file_b=, ctxlen=ctxlen@entry=0, hunk_func=hunk_func@entry=0x411320
, 
cb_data=cb_data@entry=0x7fffd830) at builtin/blame.c:105
#6  0x00412b54 in pass_blame_to_parent (parent=0x144a7b0,
target=0x125dcb0, sb=0x7fffd6e0) at builtin/blame.c:815
#7  pass_blame (opt=0, origin=0x125dcb0, sb=0x7fffd6e0) at
builtin/blame.c:1281
#8  assign_blame (opt=, sb=0x7fffd6e0) at
builtin/blame.c:1559
#9  cmd_blame (argc=, argv=, prefix=) at builtin/blame.c:2523
#10 0x004060b5 in run_builtin (argv=0x7fffe528, argc=2, p=0x578bd8
) at git.c:314
#11 handle_internal_command (argc=2, argv=0x7fffe528) at git.c:478
#12 0x00405772 in main (argc=2, av=) at git.c:575

This only happens when I compile git with -march=native (=amdfam10 on this
machine).

I will try to come up with a testcase tomorrow.

[Bug tree-optimization/59362] [4.9 Regression] Abort in fini_object_sizes

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-01
 CC||rguenther at suse dot de
   Target Milestone|--- |4.9.0
Summary|Abort in fini_object_sizes  |[4.9 Regression] Abort in
   ||fini_object_sizes
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
It is caused by r204966.

[Bug c++/59364] New: C++11 extern thread_local breaks linking: undefined reference to TLS init function

[conradsand.arma at gmail dot com]

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

Bug ID: 59364
   Summary: C++11 extern thread_local breaks linking: undefined
reference to TLS init function
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: conradsand.arma at gmail dot com

Short description:

Declaring a variable as extern thread_local in a C++11 program leads to
"undefined reference to `TLS init function for ..." during linking.

Long description:

Consider three files: rng.hpp, a.cpp and b.cpp, listed below.
Compile using:
g++ a.cpp -c -o a.o -std=c++11
g++ b.cpp -c -o b.o -std=c++11
g++ a.o b.o -o prog -std=c++11

b.o: In function `TLS wrapper function for rng_instance':
b.cpp:(.text._ZTW12rng_instance[_ZTW12rng_instance]+0x5): undefined reference
to `TLS init function for rng_instance'

Things only work if thread_local is removed.

gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) on Fedora 19 (x86-64).

---
rng.hpp:

#include 

class rng {
  public:
  std::mt19937_64 engine;
  std::uniform_real_distribution distr;
  double get_val() { return distr(engine); }
  };

---
a.cpp:

#include "rng.hpp"
thread_local rng rng_instance;

---
b.cpp:

#include 
#include "rng.hpp"

extern thread_local rng rng_instance;

int main(int argc, char** argv)
  {
  std::cout << "val: " << rng_instance.get_val() << std::endl;
  return 0;
  }
---

[Bug c++/57163] Link failure with thread_local

[conradsand.arma at gmail dot com]

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

Conrad  changed:

   What|Removed |Added

 CC||conradsand.arma at gmail dot 
com

--- Comment #4 from Conrad  ---
Confirmed for gcc 4.8.2

[Bug other/59365] New: Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1

[djfd at mail dot ru]

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

Bug ID: 59365
   Summary: Configure script does not pass CFLAGS/CXXFLAGS down to
subtargets @ stage1
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: djfd at mail dot ru

Hi,

If I confgure gcc build with CFLAGS/CXXFLAGS set to custom values, these are
not propagate down to subtargets (to gcc @ stage1, particularly).

how to reproduce

mkdir -p ~/tmp-gcc/bld
cd ~/tmp-gcc

#companion libraries
wget ftp://ftp.gnu.org/gnu/gmp/gmp-5.1.3.tar.bz2
tar -xf gmp-5.1.3.tar.bz2

wget ftp://ftp.gnu.org/gnu/mpfr/mpfr-3.1.2.tar.bz2
tar -xf mpfr-3.1.2.tar.bz2

wget ftp://ftp.gnu.org/gnu/mpc/mpc-1.0.1.tar.gz
tar -xf mpc-1.0.1.tar.gz

# gcc itself
wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.8.2/gcc-4.8.2.tar.bz2
tar -xf gcc-4.8.2.tar.bz2

PFX=$HOME/fresh-gcc

mkdir bld/gmp ; cd bld/gmp
../../gmp-5.1.3/configure --prefix=$PFX && make && make install
cd ../..

mkdir bld/mpfr ; cd bld/mpfr
../../mpfr-3.1.2/configure --prefix=$PFX --with-gmp=$PFX && make && make
install
cd ../..

mkdir bld/mpc ; cd bld/mpc
../../mpc-1.0.1/configure --prefix=$PFX --with-gmp=$PFX --with-mpfr=$PFX &&
make && make install
cd ../..

mkdir bld/gcc ; cd bld/gcc
CFLAGS="--sysroot=/"   \
CXXFLAGS="--sysroot=/" \
../../gcc-4.8.2/configure \
--prefix=$PFX  \
--with-gmp=$PFX\
--with-mpfr=$PFX   \
--with-mpc=$PFX\
 && make

then sit back, relax until ~/tmp-gcc/bld/gcc/gcc/config.cache is created. After
that stop the process by ^C and check the flags passed:

find ~/tmp-gc/bld/gcc -name config.status -print0 | xargs -0 egrep
'"C(XX)?FLAGS"'

which gives:
bld/gcc/config.status:S["CXXFLAGS"]="--sysroot=/"
bld/gcc/config.status:S["CFLAGS"]="--sysroot=/"
bld/gcc/libiberty/config.status:S["CFLAGS"]="-g"
bld/gcc/lto-plugin/config.status:S["CFLAGS"]="-g"
bld/gcc/gcc/config.status:S["CXXFLAGS"]="-g "
bld/gcc/gcc/config.status:S["CFLAGS"]="-g "
bld/gcc/intl/config.status:S["CFLAGS"]="-g"

ie. main config.cache (two first lines) has correct values set and lower ones
are wrong (or at least unexpected).

a possible way to fix
-
there is a line in main configure script:

# Stage specific cflags for build.
stage1_cflags="-g"

this causes such behaviour, as it will be later expanded (in
~/tmp-gcc/bld/gcc/Makefile) as
STAGE1_CFLAGS = -g
...
# Override the above if we're bootstrapping C++.
STAGE1_CXXFLAGS = $(STAGE1_CFLAGS)
...
BASE_FLAGS_TO_PASS = ... "STAGE1_CFLAGS=$(STAGE1_CFLAGS)"
"STAGE1_CXXFLAGS=$(STAGE1_CXXFLAGS)"...
...
RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS)

which in turn will be passed to other subtargets via $(MAKE)
$(RECURSE_FLAGS_TO_PASS)... calls

So maybe make it more sophisticated instead of just assigning "-g" flag? Say,
`stage1_cflags="-g" $CFLAGS` (or, if we want to have that -g flag, reverse the
order, ie. stage1_cflags=$CFLAGS "-g"

Or maybe am I wrong and it is intentionally, by design?

Regards

[Bug sanitizer/59275] Document environment variables used by the sanitizers

[kcc at gcc dot gnu.org]

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

--- Comment #7 from Kostya Serebryany  ---
(In reply to Tobias Burnus from comment #6)
> Close as sufficiently FIXED.
> 
> However, on the Wiki side, one should add the missing items, cf. comment 2,
> to ASAN/TSAN - and LSAN completely misses a flag description.
> 
> Kostya: What's the best way to get them added to the Wiki pages?
lsan flags are now documented at
https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
All ASAN/TSAN flags that we wanted to document are already documented 
on their wikis.

[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
By design. Use STAGE1_CFLAGS/STAGE1_CXXFLAGS instead.

[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1

[djfd at mail dot ru]

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

djfd at mail dot ru changed:

   What|Removed |Added

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

--- Comment #2 from djfd at mail dot ru ---
Hi Andrew,

it will not work too. and, to confirm, just tried this
STAGE1_CFLAGS="--sysroot=/" \
STAGE1_CXXFLAGS="--sysroot=/"   \
../../gcc-4.8.2/configure \
--prefix=$PFX   \
--with-gmp=$PFX \
--with-mpfr=$PFX\
--with-mpc=$PFX \
 && make

^C
find -name config.status -print0 | xargs -0 egrep '"C(XX)?FLAGS"'
./config.status:S["CXXFLAGS"]="-g -O2"
./config.status:S["CFLAGS"]="-g -O2"
./libiberty/config.status:S["CFLAGS"]="-g"
./lto-plugin/config.status:S["CFLAGS"]="-g"
./gcc/config.status:S["CXXFLAGS"]="-g "
./gcc/config.status:S["CFLAGS"]="-g "
./intl/config.status:S["CFLAGS"]="-g"

Please spent a five minutes of your time to review the sequence:

# Stage specific cflags for build.
stage1_cflags="-g" (it is set unconditionally in main configure script)

this causes such behaviour, as it will be later expanded (in
~/tmp-gcc/bld/gcc/Makefile) as
STAGE1_CFLAGS = -g
...
# Override the above if we're bootstrapping C++.
STAGE1_CXXFLAGS = $(STAGE1_CFLAGS)
...
BASE_FLAGS_TO_PASS = ... "STAGE1_CFLAGS=$(STAGE1_CFLAGS)"
"STAGE1_CXXFLAGS=$(STAGE1_CXXFLAGS)"...
...
RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS)
...
$(MAKE) $(RECURSE_FLAGS_TO_PASS) ... 
...
-

How would these your recommended STAGE1_CFLAGS/STAGE1_CXXFLAGS do work if they
are overrided unconditionally, as folows form the makefile sequence?

Regards