[Bug c/61942] New: loop-iv.c:2272 signed integer overflow

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61942

Bug ID: 61942
   Summary: loop-iv.c:2272 signed integer overflow
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com

/* from pr32349.c */
// gcc -funroll-loops -O3
// ../../gcc-4.9.1/gcc/loop-iv.c:2272:24: runtime error: 
// signed integer overflow: 9223372036854775807 - -9223372036854775808 cannot
be represented in type 'long int'
// offending instruction "nmax = INTVAL (mmax) - INTVAL (mmin);"
extern long *x1, *x2, *x3;

int
foo ()
{
  long *p1, *p2;
  long m, n, i;

  p1 = x1;
  p2 = x2;
  n = 0;
  for (i = *x3; 0 < i; i--)
{
  m = (*p1++) ^ (*p2++);
  m = (m & 0x) + ((m >> 1) & 0x);
  n += m;
}
  return n;
}

[Bug c/61943] New: tree-ssa-loop-ivopts.c:4148 signed integer overflow

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943

Bug ID: 61943
   Summary: tree-ssa-loop-ivopts.c:4148 signed integer overflow
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com

// from pr55569.c
// gcc -O
// ../../gcc-4.9.1/gcc/tree-ssa-loop-ivopts.c:4148:24: runtime error: signed
integer overflow: 4 * 4611686018427387903 cannot be represented in type 'long
int'
// "offset = - ratio * int_cst_value (cbase);"
int *bar (void);

void
foo (void)
{
  long x;
  int *y = bar ();
for (x = -1 / sizeof (int); x; --x, ++y)
   *y = 0;
}

[Bug c/61944] New: loop-iv.c:2610 signed integer overflow

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61944

Bug ID: 61944
   Summary: loop-iv.c:2610 signed integer overflow
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com

// from pr42049.c
// gcc -funroll-loops -O
// ../../gcc-4.9.1/gcc/loop-iv.c:2610:14: runtime error: 
// signed integer overflow: 7 - -9223372036854775808 cannot be represented in
type 'long int'
// "max = (up - down) / inc + 1;"
extern char *strcpy (char *s1, const char *s2);
struct S { char s[4]; };

int
foo (int x, char **y)
{
  struct S s[9];
  long i;
  for (i = 2; i  && i < 8; i++)
strcpy (s[i].s, y[i + 1]);
}

[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.

[xguo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123

--- Comment #8 from xuepeng guo  ---
Author: xguo
Date: Tue Jul 29 07:11:02 2014
New Revision: 213147

URL: https://gcc.gnu.org/viewcvs?rev=213147&root=gcc&view=rev
Log:
gcc/c-family/
2014-07-29  Terry Guo  

Backport mainline r211832
2014-06-20  Hale Wang  

PR lto/61123
* c.opt (fshort-enums): Add to LTO.
* c.opt (fshort-wchar): Likewise.

gcc/testsuite/
2014-07-29  Terry Guo  

Backport mainline r211832
2014-06-20  Hale Wang  

* gcc.target/arm/lto/: New folder to verify the LTO option.
* gcc.target/arm/lto/pr61123-enum-size_0.c: New test case.
* gcc.target/arm/lto/pr61123-enum-size_1.c: Likewise.
* gcc.target/arm/lto/lto.exp: New exp file used to test LTO option.
* lib/lto.exp (object-readelf): New procedure.

Added:
branches/ARM/embedded-4_8-branch/gcc/c-family/ChangeLog.arm
branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/
branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/lto.exp
   
branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_0.c
   
branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_1.c
Modified:
branches/ARM/embedded-4_8-branch/gcc/c-family/c.opt
branches/ARM/embedded-4_8-branch/gcc/testsuite/ChangeLog.arm
branches/ARM/embedded-4_8-branch/gcc/testsuite/lib/lto.exp

[Bug c++/61945] New: tree check fail with -Woverloaded-virtual

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945

Bug ID: 61945
   Summary: tree check fail with -Woverloaded-virtual
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 33201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33201&action=edit
gzipped C++ source code

For the attached code, compiled with trunk dated 20140727,
built with --enable-checking=yes, the compiler says

/home/dcb/rpmbuild/BUILD/permlib-0.2.8/include/permlib/abstract_bsgs.h:53:7:
int
ernal compiler error: tree check: expected function_decl, have template_decl in 
warn_hidden, at cp/class.c:2825
 class AbstractBSGS : public AbstractPermutationGroup {
   ^
0xed411b tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src/trunk/gcc/tree.c:9169
0x63f4a3 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../src/trunk/gcc/tree.h:2728
0x63f4a3 warn_hidden
../../src/trunk/gcc/cp/class.c:2825

Compiler flag -Woverloaded-virtual required.

[Bug libstdc++/60037] SIGFPE in std::generate_canonical

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037

--- Comment #11 from emsr at gcc dot gnu.org ---
Patch posted.

I must have been nuts.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
[...]
> With the patch, SPARC bootstrap concluded on mainline.  I'm seeing two
> different regressions with this patch in tree:
>
> * on i386-pc-solaris2.10, gcc.dg/pch/import-[12].c FAILs (SEGV in cc1
>   due to unaligned movaps destination)
>
> * on sparc-sun-solaris2.*, many 64-bit gfortran.dg tests (starting with
>   gfortran.dg/allocate_class_3.f90) FAIL at -O1 and above
>
> I'd like to make sure those are not related to your patch first.

It turned out that both failures are unrelated.  I'll start reghunting now.

>From my POV, the patch is good to go.  I'll next try it on the 4.9
branch as Eric asked.

Rainer

[Bug libstdc++/61946] New: rope construction, passing allocator referenct without const

[stuff at trez dot name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

Bug ID: 61946
   Summary: rope construction, passing allocator referenct without
const
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stuff at trez dot name

Include file ext/rope of libstdc++ in revision 124427, there was a change with
passing allocator through in-template functions, in my interest is constructor:

rope(char_producer<_CharT> *, size_t, bool, const allocator_type& )

which calls _S_new_RopeFunction, the change was with adding reference to 4
parameter:

from:
 _S_new_RopeFunction(char_producer<_CharT>* __f, size_t __size, bool __d,
allocator_type __a

to:
 _S_new_RopeFunction(char_producer<_CharT>* __f, size_t __size, bool __d,
allocator_type& __a


and it makes problem with compilation of example code:

#include 

class empty_char_prod : public __gnu_cxx::char_producer
{
  public:
virtual void operator()(size_t start_pos, size_t len, char* buffer)
{}
};

int main ()
{
empty_char_prod* ecp = new empty_char_prod;
__gnu_cxx::crope excrope ( ecp, 10L, true );

return 0;
}

compilation on gcc version 4.9.1 (Debian 4.9.1-1):
/usr/include/c++/4.9/ext/rope: In instantiation of ‘__gnu_cxx::rope<_CharT,
_Alloc>::rope(__gnu_cxx::char_producer<_CharT>*, std::size_t, bool, const
allocator_type&) [with _CharT = char; _Alloc = std::allocator;
std::size_t = long unsigned int; __gnu_cxx::rope<_CharT,
_Alloc>::allocator_type = std::allocator]’:
./cropy.cc:17:47:   required from here
/usr/include/c++/4.9/ext/rope:1880:57: error: no matching function for call to
‘__gnu_cxx::rope::_S_new_RopeFunction(__gnu_cxx::char_producer*&,
std::size_t&, bool&, const allocator_type&)’
0 : _S_new_RopeFunction(__fn, __len, __delete_fn, __a);
 ^
/usr/include/c++/4.9/ext/rope:1880:57: note: candidate is:
/usr/include/c++/4.9/ext/rope:1673:7: note: static __gnu_cxx::rope<_CharT,
_Alloc>::_RopeFunction* __gnu_cxx::rope<_CharT,
_Alloc>::_S_new_RopeFunction(__gnu_cxx::char_producer<_CharT>*, std::size_t,
bool, __gnu_cxx::rope<_CharT, _Alloc>::allocator_type&) [with _CharT = char;
_Alloc = std::allocator; __gnu_cxx::rope<_CharT, _Alloc>::_RopeFunction =
__gnu_cxx::_Rope_RopeFunction >; std::size_t = long
unsigned int; __gnu_cxx::rope<_CharT, _Alloc>::allocator_type =
std::allocator]
   _S_new_RopeFunction(char_producer<_CharT>* __f,
   ^
/usr/include/c++/4.9/ext/rope:1673:7: note:   no known conversion for argument
4 from ‘const allocator_type {aka const std::allocator}’ to
‘__gnu_cxx::rope::allocator_type& {aka std::allocator&}’


I thing the change should by from copy to const reference, like this:
 _S_new_RopeFunction(char_producer<_CharT>* __f, size_t __size, bool __d, const
allocator_type& __a

[Bug tree-optimization/61938] Vectorization not happening .

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-07-29
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
The issue is the store to result[k] where k is not an affine induction
variable.
This is a "distribute" store (similar to a "gather" load).  I see no sensible
way of vectorizing this, do you?

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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-07-29
  Known to work||4.2.4
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|rope construction, passing  |[4.8/4.9/4.10 Regression]
   |allocator referenct without |rope construction, passing
   |const   |allocator referenct without
   ||const
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The correct fix is to use _M_get_allocator() to pass a non-const reference:

--- a/libstdc++-v3/include/ext/rope
+++ b/libstdc++-v3/include/ext/rope
@@ -1876,8 +1876,9 @@ protected:
   const allocator_type& __a = allocator_type())
   : _Base(__a)
   {
-   this->_M_tree_ptr = (0 == __len) ?
- 0 : _S_new_RopeFunction(__fn, __len, __delete_fn, __a);
+   this->_M_tree_ptr = (0 == __len)
+ ? 0
+ : _S_new_RopeFunction(__fn, __len, __delete_fn, _M_get_allocator());
   }

   rope(const rope& __x, const allocator_type& __a = allocator_type())

[Bug rtl-optimization/61712] thumb1_reorg crashes

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #18 from Richard Earnshaw  ---
Duplicate.

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

[Bug target/61544] ICE due to thumb1_reorg function mishandles label type insn

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544

Richard Earnshaw  changed:

   What|Removed |Added

 CC||manjian2006 at gmail dot com

--- Comment #4 from Richard Earnshaw  ---
*** Bug 61712 has been marked as a duplicate of this bug. ***

[Bug middle-end/55035] reload1.c:3766:41: error: ‘orig_dup[0]’ may be used uninitialized in this function (for fr30, microblaze, moxie, rl78)

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035

Hans-Peter Nilsson  changed:

   What|Removed |Added

  Known to fail||4.10.0

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #2)
> I.e. host gcc-4.9.1 on gcc110 compiling trunk r212879.

Also seen with trunk r212879 compiling trunk r212879, so these poor targets
would have broken native builds.  Thankfully apparently none have self-hosted
systems at this time.

[Bug libstdc++/61947] New: Ambiguous calls when constructing std::tuple

[roman.perepelitsa at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947

Bug ID: 61947
   Summary: Ambiguous calls when constructing std::tuple
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.perepelitsa at gmail dot com

#include 

struct ConvertibleToAny {
  template  operator T() const { return T(); }
};

int main() {
  std::tuple t(ConvertibleToAny{});
}

Produces:

third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:262:4:
error: call to constructor of '_Head_base<0UL, (anonymous
namespace)::ConvertibleToAny &&, __empty_not_final::value>' is ambiguous
  _Base(std::forward<_UHead>(__head)) { }
  ^ 
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:405:4:
note: in instantiation of function template specialization 'std::_Tuple_impl<0,
(anonymous namespace)::ConvertibleToAny &&>::_Tuple_impl<(anonymous
namespace)::ConvertibleToAny, void>' requested here
: _Inherited(std::forward<_UElements>(__elements)...) { }
  ^
experimental/users/romanp/tuple_bug/tuple-bug.cc:13:34: note: in instantiation
of function template specialization 'std::tuple<(anonymous
namespace)::ConvertibleToAny &&>::tuple<(anonymous
namespace)::ConvertibleToAny, void>' requested here
  std::tuple t(ConvertibleToAny{});
 ^
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:128:12:
note: candidate is the implicit move constructor
struct _Head_base<_Idx, _Head, false>
   ^
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:128:12:
note: candidate constructor (the implicit copy constructor) has been implicitly
deleted
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:142:7:
note: candidate constructor
  _Head_base(__uses_alloc0)

The call shouldn't be ambiguous. It should pick the following constructor:

[tuple.cnstr]

  template 
  explicit tuple(UTypes&&... u);

  Requires: sizeof...(Types) == sizeof...(UTypes). is_constructible::value is true for all i.
  Effects: Initializes the elements in the tuple with the corresponding value
in std::forward(u).

is_constructible::value is true, so the
precondition is satisfied.

This bug affects std::bind as it's built on top of std::tuple.

#include 

struct ConvertibleToAny {
  template  operator T() const { return T(); }
};

void Sink(int) {}

int main() {
  std::bind(Sink, std::placeholders::_1)(ConvertibleToAny{});
}

Error:

third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:262:4:
error: call to constructor of '_Head_base<0UL, (anonymous
namespace)::ConvertibleToAny &&, __empty_not_final::value>' is ambiguous
  _Base(std::forward<_UHead>(__head)) { }
  ^ 
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:405:4:
note: in instantiation of function template specialization 'std::_Tuple_impl<0,
(anonymous namespace)::ConvertibleToAny &&>::_Tuple_impl<(anonymous
namespace)::ConvertibleToAny, void>' requested here
: _Inherited(std::forward<_UElements>(__elements)...) { }
  ^
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:868:14:
note: in instantiation of function template specialization
'std::tuple<(anonymous namespace)::ConvertibleToAny &&>::tuple<(anonymous
namespace)::ConvertibleToAny, void>' requested here
{ return tuple<_Elements&&...>(std::forward<_Elements>(__args)...); }
 ^
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/functional:1354:13:
note: in instantiation of function template specialization
'std::forward_as_tuple<(anonymous namespace)::ConvertibleToAny>' requested here
  std::forward_as_tuple(std::forward<_Args>(__args)...),
   ^
experimental/users/romanp/tuple_bug/tuple-bug.cc:15:41: note: in instantiation
of function template specialization 'std::_Bind))(int)>::operator()<(anonymous
namespace)::ConvertibleToAny, void>' requested here
  std::bind(Sink, std::placeholders::_1)(ConvertibleToAny{});
^
third_party/crosstool/v17/stable/gcc-x86_64-grtev3-linux-gnu/x86_64-grtev3-linux-gnu/include/c++/4.8.x-google/tuple:128:12:
note: candidate is the implicit move constructor
struct _Head_base<_Idx, _Head, false>
   ^
third_party/crosstool/v17/stable/gcc-x86_64-grt

[Bug middle-end/54664] expand_gimple_cond warning for predictably small BRANCH_COST

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org
  Known to fail||4.10.0, 4.9.1

--- Comment #1 from Hans-Peter Nilsson  ---
Also seen for 4.9.1 and 4.10.0 i.e. trunk r212879.

[Bug middle-end/52478] -ftrapv calls the wrong functions in libgcc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52478

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 29 11:10:49 2014
New Revision: 213153

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

PR middle-end/52478
* expr.c (expand_expr_real_2): Revert last change.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c

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

[cbaylis at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

Bug ID: 61948
   Summary: [ARM] [4.9 regression] ICE with DImode shift by 1 bit
(in copyprop_hardreg_forward_1)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: cbaylis at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
Target: arm-unknown-linux-gnueabihf

Created attachment 33202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33202&action=edit
Original test case, needs -std=c++11

Originally reported at:
https://bugs.linaro.org/show_bug.cgi?id=176

The lshrdi3_neon,ashrdi3_neon,ashldi3_neon patterns can call
gen_arm_di3_1bit without checking that the register allocation
constraints of the resulting insn are satisfied. This results in an ICE:

Simplified test case:
--<
long long f (long long *c)
{
  long long t = c[0];
  /* force t into [r1,r2] */
  asm ("nop" : : : "r0", "r3", "r4", "r5",
   "r6", "r7", "r8", "r9",
   "r10", "r11", "r12", "memory");
  return t >> 1;
}
===>---

$ arm-unknown-linux-gnueabihf-gcc -O2 -mfpu=neon -mthumb -c t.c
t.c: In function ‘f’:
t.c:8:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 18 7 14 2 (parallel [
(set (reg/i:DI 0 r0)
(ashiftrt:DI (reg/v:DI 1 r1 [orig:110 t ] [110])
(const_int 1 [0x1])))
(clobber (reg:CC 100 cc))
]) t.c:8 131 {arm_ashrdi3_1bit}
 (expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
t.c:8:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:775

[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error

[charles.barcza at blackpanther dot hu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875

--- Comment #4 from charles.barcza at blackpanther dot hu ---
Hi,
Confirmed this problem but the follow post solved libsanitizer problem:

"Comment #3 from Tatiana Udalova  ---

You can fix problem in Tizen via deletting -fexceptions flag from the default
flags for gcc, cross-gcc and cross-gcc-accel packages:
OPT_FLAGS=`echo "$OPT_FLAGS" | sed -e 's/-fexceptions / /'`"


Thx to t.udalova

RGDS

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

[cbaylis at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-07-29
 Ever confirmed|0   |1

[Bug lto/61868] -frandom-seed always results in random_seed of 0

[bmei at broadcom dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61868

Bingfeng Mei  changed:

   What|Removed |Added

  Component|driver  |lto

--- Comment #1 from Bingfeng Mei  ---
Change the component to lto as gcc should generate lto section name with
specified random seed.

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725

--- Comment #8 from Marat Zakirov  ---
UPDATE

Using little fix you may got a much better code...

transpose_16x16:
.fnstart
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r2, r0, #128
vld4.16 {d24, d26, d28, d30}, [r0]
add r1, r0, #160
vld4.16 {d16, d18, d20, d22}, [r2]
add r0, r0, #32
movwr3, #:lower16:m1
vldrd6, .L2
vldrd7, .L2+8(in CSE)
movwr2, #:lower16:m0
movtr3, #:upper16:m1
movtr2, #:upper16:m0
vld4.16 {d25, d27, d29, d31}, [r0]
vld4.16 {d17, d19, d21, d23}, [r1]
vmul.i16q12, q3, q12
vmul.i16q8, q3, q8
vmul.i16q13, q3, q13
vmul.i16q9, q3, q9
vmul.i16q14, q3, q14
vmul.i16q10, q3, q10
vmul.i16q15, q3, q15
vmul.i16q11, q3, q11
vstmia  r2, {d24-d31}
vstmia  r3, {d16-d23}
bx  lr
.L3:

About fix:

I discovered that GCC register allocator has 'weak' support for stream (in my
case NEON) registers. RA works with stream resgisters as with unsplitible
ranges. So if some register of range becomes free GCC do not reuse them untill
whole range becomes free.

Is actually OK, but...

I found that GCC CSE phase makes partly substitution for register-ranges and
this leads to terrible register pressure increse.

Example

Before CSE

a = b
a0 = a0 * 3
a1 = a1 * 3
a2 = a2 * 3
a3 = a3 * 3

After

a = b
a0 = b0 * 3 
a1 = a1 * 3 <<< *
a2 = a2 * 3
a3 = a3 * 3

CSE do not substitute b1 to a1 because at the moment (*) a0 was define so
actually a != b. Yes but a1 = b1, unfortuanatly CSE also do not how to handle
register-ranges parts as RA does. And I am not sure that 'unfortuanatly'.

Because.

a0 = b0 * 3 
a1 = b1 * 3
a2 = b2 * 3
a3 = b3 * 3

Also requres x2 more stream registers than its really need to.

My solution here is to forbid CSE for XImode registers.

[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-07-29
  Known to work||4.6.4
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|Ambiguous calls when|[4.8/4.9/4.10 Regression]
   |constructing std::tuple |Ambiguous calls when
   ||constructing std::tuple
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
stupid allocators

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725

--- Comment #9 from Marat Zakirov  ---
I used following patch

diff --git a/gcc/cse.c b/gcc/cse.c
index 34f9364..a9e0442 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -2862,6 +2862,9 @@ canon_reg (rtx x, rtx insn)
|| ! REGNO_QTY_VALID_P (REGNO (x)))
  return x;

+if (GET_MODE (x) == XImode)
+  return x;
+
q = REG_QTY (REGNO (x));
ent = &qty_table[q];
first = ent->first_reg;
diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 547fcd6..eadc729 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -1317,6 +1317,9 @@ forward_propagate_and_simplify (df_ref use, rtx def_insn,
rtx def_set)
   if (!new_rtx)
 return false;

+  if (GET_MODE (reg) == XImode)
+return false;
+
   return try_fwprop_subst (use, loc, new_rtx, def_insn, set_reg_equal);
 }

[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734

--- Comment #10 from Ilya Enkovich  ---
Thanks for the fix!

Is there any reason for ABS_EXPR detection for not working on 64bit target for
the same test? The only difference should be the long long type size. How does
it affect optimizations?

[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947

--- Comment #2 from Jonathan Wakely  ---
Created attachment 33203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33203&action=edit
proposed patch

Add std::allocator_arg_t parameter to unary _Head_base constructors taking a
__uses_allocN tag type, so that they are not candidates for calls with one
parameter. This allows the !is_convertible constraint to be removed from the
_Head_base::_Head_base(__UHead&&) constructor.

[Bug middle-end/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug tree-optimization/61929] Graphite: Banerjee and Omega differ on distance vectors (internal compiler error in compute_affine_dependence)

[gcc at crg4 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61929

--- Comment #4 from Charles Greathouse  ---
I now have a testcase for failure with -floop-parallelize-all (without
-fcheck-data-deps). I believe this is the same bug, or at least related,
because this testcase also fails with the previous compile command.

int main() {}
void generateICE2(char *s, int i)
{
for (; i >= 2; i--) s[i] = s[i-1];
}

This fails with

gcc testcase.c -lm -O2 -floop-parallelize-all -floop-nest-optimize

or even

gcc testcase.c -lm -O2 -floop-parallelize-all -floop-nest-optimize
-fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps
-fno-align-labels -fno-align-loops -fno-asynchronous-unwind-tables
-fno-branch-count-reg -fno-caller-saves -fno-combine-stack-adjustments
-fno-common -fno-compare-elim -fno-cprop-registers -fno-crossjumping
-fno-cse-follow-jumps -fno-dce -fno-defer-pop -fno-delete-null-pointer-checks
-fno-devirtualize -fno-dse -fno-early-inlining -fno-expensive-optimizations
-fno-forward-propagate -fno-gcse -fno-gcse-lm -fno-guess-branch-probability
-fno-hoist-adjacent-loads -fno-if-conversion -fno-if-conversion2 -fno-inline
-fno-inline-atomics -fno-inline-functions-called-once
-fno-inline-small-functions -fno-ipa-cp -fno-ipa-profile -fno-ipa-pure-const
-fno-ipa-reference -fno-ipa-sra -fno-ira-hoist-pressure -fno-ivopts
-fno-jump-tables -fno-math-errno -fno-merge-constants -fno-move-loop-invariants
-fno-optimize-register-move -fno-optimize-sibling-calls -fno-optimize-strlen
-fno-peephole -fno-peephole2 -fno-prefetch-loop-arrays -fno-regmove
-fno-rename-registers -fno-reorder-blocks -fno-reorder-functions
-fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic
-fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock
-fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec
-fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep
-fno-schedule-insns2 -fno-set-stack-executable -fno-short-enums
-fno-shrink-wrap -fno-signed-zeros -fno-split-ivs-in-unroller
-fno-split-wide-types -fno-strict-aliasing -fno-thread-jumps -fno-trapping-math
-fno-tree-bit-ccp -fno-toplevel-reorder -fno-tree-builtin-call-dce
-fno-tree-ccp -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-copyrename
-fno-tree-cselim -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse
-fno-tree-forwprop -fno-tree-fre -fno-tree-loop-if-convert -fno-tree-loop-im
-fno-tree-loop-ivcanon -fno-tree-phiprop -fno-tree-pre -fno-tree-pta
-fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize
-fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge
-fno-tree-ter -fno-tree-vect-loop-version -fno-tree-vrp -fno-unit-at-a-time
-fno-var-tracking -fno-var-tracking-assignments -fno-web

which is -O2 with everything but floop-parallelize-all -floop-nest-optimize
-ftree-loop-optimize -ftree-ch -fthreadsafe-statics turned off. However the bug
does not appear at -O1 and below even with these options.

[Bug middle-end/61949] New: [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949

Bug ID: 61949
   Summary: [4.10 regression] SEGV compiling
gcc.dg/pch/import-[12].c
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10

Between 20140711 (r212451) and 20140718 (r15669), the gcc.dg/pch/import-[12].c
tests started to FAIL on Solaris 10/x86 (only, Solaris 11 is unaffected):

FAIL: gcc.dg/pch/import-1.c  -O0 -g -I. -Dwith_PCH (internal compiler error)
FAIL: gcc.dg/pch/import-1.c  -O0 -g -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/import-1.c -O0 -g assembly comparison

and all others, both 32 and 64-bit.

cc1 SEGVs here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x08c34226 in md5_read_ctx (resbuf=0x8047278, ctx=0x8047140)
at /vol/gcc/src/hg/trunk/local/libiberty/md5.c:91
91memcpy (resbuf, buffer, 16);
1: x/i $pc
=> 0x8c34226 :  movaps -0x28(%ebp),%xmm0

-0x28(%ebp) isn't 16-byte aligned as required.

This only happens with the stage3 cc1, stages 1 and 2 are unaffected.

A reghunt revealed that this is caused by this patch:

2014-07-11  Richard Biener  

   PR middle-end/61473
   * builtins.c (fold_builtin_memory_op): Inline memory moves
   that can be implemented with a single load followed by a
   single store.
   (c_strlen): Only warn when only_value is not 2.

  Rainer

[Bug middle-end/61950] New: [4.10 regression] Many 64-bit fortran allocate tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950

Bug ID: 61950
   Summary: [4.10 regression] Many 64-bit fortran allocate tests
FAIL
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Host: sparc-sun-solaris2.1[01]
Target: sparc-sun-solaris2.1[01]
 Build: sparc-sun-solaris2.1[01]

Between 20140718 (r212815) and 20140725 (r213049) many 64-bit gfortran tests
started to FAIL on Solaris/SPARC, at -O1 and beyond only:

FAIL: gfortran.dg/allocate_class_3.f90   -O1  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O2  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/allocate_class_3.f90   -Os  execution test
FAIL: gfortran.dg/class_19.f03   -O1  execution test
FAIL: gfortran.dg/class_19.f03   -O2  execution test
FAIL: gfortran.dg/class_19.f03   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/class_19.f03   -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/class_19.f03   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/class_19.f03   -O3 -g  execution test
FAIL: gfortran.dg/class_19.f03   -Os  execution test

and many more.

A reghunt revealed the following patch as the culprit:

2014-07-25  Richard Biener  

PR middle-end/61762
PR middle-end/61894
* fold-const.c (native_encode_int): Add and handle offset
parameter to do partial encodings of expr.

The first test e.g aborts here:

#4  0x0001213c in MAIN__ ()
at /var/gcc/reghunt/trunk/gcc/testsuite/gfortran.dg/allocate_class_3.f90:76
76if (any (x%i .ne. [1,2])) call abort

  Rainer

[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug c++/61951] New: -wExtra switch produce warning: parameter 'ptr' set but not used [-Wunused-but-set-parameter]

[moblaza at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61951

Bug ID: 61951
   Summary: -wExtra switch produce warning: parameter 'ptr' set
but not used [-Wunused-but-set-parameter]
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moblaza at gmail dot com

Created attachment 33204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33204&action=edit
program with this code example

Hello! Il write code example with lambda expression, with operator new class
allocation, and g++ produce warning:

D:\workspace\gcc_test1\main.cpp:33:67: warning: parameter 'ptr' set but not
used [-Wunused-but-set-parameter]
 std::for_each(ref.begin(), ref.end(), [](Base* ptr){

but after allocation, lambda parameter is used also in lambda expression with
for_each algorithm. See attached code.

PS.
My: gcc version 4.8.1 (rev5, Built by MinGW-W64 project)

[Bug ada/60652] System.OS_Constants CRTSCTS

[charlet at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60652

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.10.0

--- Comment #1 from Arnaud Charlet  ---
Should be fixed now (commit rev 213201).

[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734

--- Comment #11 from Eric Botcazou  ---
> Is there any reason for ABS_EXPR detection for not working on 64bit target
> for the same test?

It is probably visible in the .original dump.

[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple

[ppluzhnikov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

--- Comment #3 from Paul Pluzhnikov  ---
Google ref: b/16644819

[Bug fortran/61952] New: ICE allocattion of array of type of type

[valeryweber at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61952

Bug ID: 61952
   Summary: ICE allocattion of array of type of type
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com

Dear All

the following code is ICEing with gfortran 4.9.1

v

>gfortran-4.9.1 -c  bug.F90 
bug.F90: In function ‘sm_multiply_a’:
bug.F90:29:0: internal compiler error: in gfc_conv_descriptor_data_set, at
fortran/trans-array.c:171
 ALLOCATE( matrices_a( n_push_tot + 1 ), matrices_b( n_push_tot + 1 ),
STAT=istat )
 ^
0x5ebe16 gfc_conv_descriptor_data_set
../../gcc-4.9.1/gcc/fortran/trans-array.c:171
0x5ebe16 gfc_conv_descriptor_data_set(stmtblock_t*, tree_node*, tree_node*)
../../gcc-4.9.1/gcc/fortran/trans-array.c:166
0x5f37cd structure_alloc_comps
../../gcc-4.9.1/gcc/fortran/trans-array.c:7785
0x5f2e8b structure_alloc_comps
../../gcc-4.9.1/gcc/fortran/trans-array.c:7978
0x5f311f structure_alloc_comps
../../gcc-4.9.1/gcc/fortran/trans-array.c:7646
0x5f4606 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, gfc_typespec*)
../../gcc-4.9.1/gcc/fortran/trans-array.c:5322
0x63c0b9 gfc_trans_allocate(gfc_code*)
../../gcc-4.9.1/gcc/fortran/trans-stmt.c:4952
0x5e89c7 trans_code
../../gcc-4.9.1/gcc/fortran/trans.c:1794
0x6082e2 gfc_generate_function_code(gfc_namespace*)
../../gcc-4.9.1/gcc/fortran/trans-decl.c:5653
0x5e9f01 gfc_generate_module_code(gfc_namespace*)
../../gcc-4.9.1/gcc/fortran/trans.c:1995
0x5a7b48 translate_all_program_units
../../gcc-4.9.1/gcc/fortran/parse.c:4940
0x5a7b48 gfc_parse_file()
../../gcc-4.9.1/gcc/fortran/parse.c:5150
0x5e4ca5 gfc_be_parse_file
../../gcc-4.9.1/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

>cat bug.F90
MODULE distribution_types
  ABSTRACT INTERFACE
 FUNCTION dist_map_blk_to_proc_func ( row, col, nrow_tot, ncol_tot,
proc_grid ) RESULT( reslt )
   INTEGER, INTENT( IN ) :: row, col, nrow_tot, ncol_tot
   INTEGER, DIMENSION( : ), INTENT( IN ) :: proc_grid
   INTEGER, DIMENSION( : ), ALLOCATABLE :: reslt
 END FUNCTION dist_map_blk_to_proc_func
  END INTERFACE
  TYPE, PUBLIC :: dist_type
 INTEGER, DIMENSION( : ), ALLOCATABLE :: task_coords
 PROCEDURE( dist_map_blk_to_proc_func ), NOPASS, POINTER :: map_blk_to_proc
=> NULL( )
  END TYPE dist_type
END MODULE distribution_types

MODULE sparse_matrix_types
  USE distribution_types,  ONLY : dist_type
  TYPE, PUBLIC :: sm_type
 TYPE( dist_type ) :: dist
  END TYPE sm_type
END MODULE sparse_matrix_types

MODULE sparse_matrix_multiply_a
  USE sparse_matrix_types,  ONLY : sm_type
CONTAINS
  SUBROUTINE sm_multiply_a (  )
INTEGER :: n_push_tot, istat
TYPE( sm_type ), DIMENSION( : ), ALLOCATABLE :: matrices_a, matrices_b
n_push_tot =2
ALLOCATE( matrices_a( n_push_tot + 1 ), matrices_b( n_push_tot + 1 ),
STAT=istat )
  END SUBROUTINE sm_multiply_a
END MODULE sparse_matrix_multiply_a

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

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||ramana at gcc dot gnu.org
  Known to work||4.8.3, 4.9.0, 4.9.1
Version|4.9.0   |4.10.0
Summary|[ARM] [4.9 regression] ICE  |[ARM] [4.10 regression] ICE
   |with DImode shift by 1 bit  |with DImode shift by 1 bit
   |(in |(in
   |copyprop_hardreg_forward_1) |copyprop_hardreg_forward_1)

--- Comment #1 from Ramana Radhakrishnan  ---
I can't reproduce this on the FSF 4.9 branch but do see it failing on trunk
with Thumb2 and I suspect this to be due to my change to allow any old register
for DImode values in Thumb2. 

Please remember to fill in Keywords, Known to Work, Known to Fail and all
command line options needed to reproduce this issue.


Reproduced on trunk with 
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb

[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734

--- Comment #12 from Ilya Enkovich  ---
Before your last fix both 32bit and 64bit versions of .original look similar
except a condition. We have (a - b > 0) for 64 bit and (a > b) for 32bit.

64bit version (before and after the patch)

{
  sum = ((int) a - (int) b > 0 ? (long unsigned int) ((int) a - (int) b) :
(long unsigned int) ((int) b - (int) a)) + sum;
  return sum;
}

32bit version (before the patch):

{
  sum = ((int) a > (int) b ? (long unsigned int) ((int) a - (int) b) : (long
unsigned int) ((int) b - (int) a)) + sum;
  return sum;
}

It is not clear why such difference exists though.

[Bug ada/60652] System.OS_Constants CRTSCTS

[charlet at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60652

--- Comment #2 from Arnaud Charlet  ---
Author: charlet
Date: Tue Jul 29 14:46:27 2014
New Revision: 213201

URL: https://gcc.gnu.org/viewcvs?rev=213201&root=gcc&view=rev
Log:
2014-07-29  Robert Dewar  

* gnat_rm.texi, sem_prag.adb: Minor reformatting.

2014-07-29  Sergey Rybin  

* gnat_ugn.texi: gnatmetric: clarify documentation for cyclomatic
complexity metrics.

2014-07-29  Thomas Quinot  

PR ada/60652
* s-oscons-tmplt.c: For Linux, define _BSD_SOURCE in order for
CRTSCTS to be visible.

2014-07-29  Bob Duff  

* g-trasym.adb, g-trasym.ads: Code cleanup.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/g-trasym.adb
trunk/gcc/ada/g-trasym.ads
trunk/gcc/ada/gnat_rm.texi
trunk/gcc/ada/gnat_ugn.texi
trunk/gcc/ada/s-oscons-tmplt.c
trunk/gcc/ada/sem_prag.adb

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[alan.lawrence at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114

Alan Lawrence  changed:

   What|Removed |Added

 CC||alan.lawrence at arm dot com

--- Comment #8 from Alan Lawrence  ---
Here's a simpler testcase that shows the "if (BYTES_BIG_ENDIAN)" in
tree-vect-loop.c is wrong:

static unsigned char in[16];

int
main ( unsigned char argc, char **argv)
{
  unsigned char i = 0;
  unsigned char sum = 0;
  for (i = 0; i < 16; i++)
in[i] = i;

  for (i = 0; i < 16; i++)
sum += in[i];

  if (sum != (unsigned char) 120)
__builtin_printf ("Failed\n");  
}

On AArch64 or x86, compiling with -O3, there is no output.
On AArch64_be or PowerPC (compiling with -O3 -maltivec), it prints "Failed!".

The output from dom2 shows the problem:

Optimizing statement vect_sum_13.10_27 = [reduc_plus_expr] vect_sum_13.8_4;
  Replaced 'vect_sum_13.8_4' with constant '{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15 }'
  Folded to: vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
LKUP STMT vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }
  vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 };
 ASGN vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }
Optimizing statement stmp_sum_13.9_28 = BIT_FIELD_REF ;
  Replaced 'vect_sum_13.10_27' with constant '{ 120, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0 }'
  Folded to: stmp_sum_13.9_28 = 0;
LKUP STMT stmp_sum_13.9_28 = 0
  stmp_sum_13.9_28 = 0;
 ASGN stmp_sum_13.9_28 = 0
Optimizing statement vect_sum_13.11_29 = stmp_sum_13.9_28;
  Replaced 'stmp_sum_13.9_28' with constant '0'
LKUP STMT vect_sum_13.11_29 = 0
  vect_sum_13.11_29 = 0;
 ASGN vect_sum_13.11_29 = 0
Optimizing statement if (vect_sum_13.11_29 != 120)
  Replaced 'vect_sum_13.11_29' with constant '0'
  Folded to: if (1 != 0)

[Bug libstdc++/60037] SIGFPE in std::generate_canonical

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037

--- Comment #12 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Tue Jul 29 14:56:45 2014
New Revision: 213207

URL: https://gcc.gnu.org/viewcvs?rev=213207&root=gcc&view=rev
Log:
2014-07-29  Ed Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/60037 - SIGFPE in std::generate_canonical
* include/bits/random.h (_Adaptor): static_assert for non floating-point
result type.
* include/bits/random.tcc (generate_canonical): Ditto.
* include/ext/random.tcc (hypergeometric_distribution::operator()):
Use double as a rng result type.
* testsuite/26_numerics/random/pr60037-neg.cc: New.
* testsuite/ext/random/hypergeometric_distribution/pr60037.cc: New.


Added:
trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
   
trunk/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/pr60037.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc
trunk/libstdc++-v3/include/ext/random.tcc

[Bug c++/61953] New: [C++11] The template parameter pack of a function template should be the last template parameter

[kariya_mitsuru at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61953

Bug ID: 61953
   Summary: [C++11] The template parameter pack of a function
template should be the last template parameter
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com

The both sample codes below should cause compilation error but they are
compiled successfully by gcc.

==
template void f() { }
==

===
template void g() { }
===

According to C++11 standard 14.1 Template parameters [temp.param] paragraph 11,
"A template parameter pack of a function template shall not be followed by
another template parameter unless that template parameter can be deduced from
the parameter-type-list of the function template or has a default argument."

The latest draft is more clarified using the following example.

===
// U can be neither deduced from the parameter-type-list nor specified
template void f() { } // error
template void g() { } // error
===

cf. http://melpon.org/wandbox/permlink/zO14UQDvxpXwRfYm

[Bug ipa/61885] [4.10 Regression] ICE: in types_same_for_odr, at ipa-devirt.c:383 with LTO

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61885

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-29
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Also happens during Firefox libxul link:

lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:386
0x773632 types_same_for_odr(tree_node const*, tree_node const*)
../../gcc/gcc/ipa-devirt.c:386
0x773c1b get_class_context
../../gcc/gcc/ipa-devirt.c:1810
0x7741c1 contains_type_p
../../gcc/gcc/ipa-devirt.c:1960
0x773e33 get_class_context
../../gcc/gcc/ipa-devirt.c:1789
0x77b478 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc/gcc/ipa-devirt.c:2585
0x7a1463 possible_polymorphic_call_targets
../../gcc/gcc/ipa-utils.h:134
0x7a1463 walk_polymorphic_call_targets
../../gcc/gcc/ipa.c:151
0x7a1463 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
../../gcc/gcc/ipa.c:380
0x549e54 read_cgraph_and_symbols
../../gcc/gcc/lto/lto.c:3091
0x549e54 lto_main()
../../gcc/gcc/lto/lto.c:3415
Please submit a full bug report,

[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734

--- Comment #13 from Eric Botcazou  ---
> Before your last fix both 32bit and 64bit versions of .original look similar
> except a condition. We have (a - b > 0) for 64 bit and (a > b) for 32bit.

That's obsolete though, you should look at what happens after the fix, which
should be equivalent to what happened before r210979.  But the reason is very
likely the cast to (long unsigned int), which can be stripped for 32-bit but
not for 64-bit long ints, which blocks the pattern matching in the latter case.

[Bug ada/61954] New: Ada fails to properly pass pointer arguments on x32

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954

Bug ID: 61954
   Summary: Ada fails to properly pass pointer arguments on x32
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

Pointers in x32 are 32 bits.  When 32-bit pointers passed as argument
in register, they must be zero-extended to 64 bits.  Flush_Buffer in
output.adb has

   if Cur_Indentation = 0
  or else Cur_Indentation + Len > Buffer_Max
  or else Buffer (1 .. Len) = (1 => ASCII.LF)
then
   Write_Buffer (Buffer (1 .. Len));

which is compiled into:

   0x00797849 <+169>:lea-0x40(%rbp),%edi
   0x0079784c <+172>:movl   $0x1,-0x40(%ebp)
   0x00797854 <+180>:shl$0x20,%rdi
   0x00797858 <+184>:mov%eax,-0x3c(%ebp)
   0x0079785c <+188>:mov$0x1cddf80,%eax
   0x00797861 <+193>:or %rax,%rdi
   0x00797864 <+196>:mov-0x48(%ebp),%eax
   0x00797868 <+200>:mov%rax,-0x60(%ebp)
   0x0079786d <+205>:mov$0x1335fd8,%eax
   0x00797872 <+210>:mov%rax,-0x50(%ebp)
   0x00797877 <+215>:mov$0x1335ff0,%eax
   0x0079787c <+220>:mov%rax,-0x58(%ebp)
   0x00797881 <+225>:callq  0x797530 

DI register is used to pass a pointer, which should be zero-extended
from 32 bits to 64 bits.  But we got

(gdb) si
0x00797849136   Write_Buffer (Buffer (1 .. Len));
(gdb) si
0x0079784c136   Write_Buffer (Buffer (1 .. Len));
(gdb) p/x $rdi
$14 = 0xcba0
(gdb) si
0x00797854136   Write_Buffer (Buffer (1 .. Len));
(gdb) si
0x00797858136   Write_Buffer (Buffer (1 .. Len));
(gdb) p/x $rdi
$15 = 0xcba0
(gdb) 

RTL expand looks strange:

;; D.3473.P_BOUNDS = &D.3474;

(insn 143 142 144 (parallel [
(set (reg:SI 156)
(plus:SI (reg/f:SI 78 virtual-stack-vars)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) /export/gnu/import/git/gcc/gcc/ada/output.adb:136 -1
 (nil))

(insn 144 143 145 (set (reg:DI 157)
(zero_extend:DI (reg:SI 156)))
/export/gnu/import/git/gcc/gcc/ada/output.adb:136 -1
 (nil))

(insn 145 144 146 (parallel [
(set (reg:DI 158)
(ashift:DI (reg:DI 157)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) /export/gnu/import/git/gcc/gcc/ada/output.adb:136 -1
 (nil))

(insn 147 146 148 (parallel [
(set (reg:DI 160)
(ior:DI (reg:DI 159)
(reg:DI 158)))
(clobber (reg:CC 17 flags))
]) /export/gnu/import/git/gcc/gcc/ada/output.adb:136 -1
 (nil))

(insn 148 147 0 (set (reg:DI 120 [ D.3473 ])
(reg:DI 160)) /export/gnu/import/git/gcc/gcc/ada/output.adb:136 -1
 (nil))

;; output.flush_buffer.write_buffer (D.3473);

(insn 149 148 150 (set (reg:DI 5 di)
(reg:DI 120 [ D.3473 ]))
/export/gnu/import/git/gcc/gcc/ada/output.adb:136 -1
 (nil))

[Bug bootstrap/61914] [4.10 Regression] wide-int change breaks bootstrap

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61914

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jul 29 15:19:22 2014
New Revision: 213213

URL: https://gcc.gnu.org/viewcvs?rev=213213&root=gcc&view=rev
Log:
Replace strtok with strtoken

PR bootstrap/61914
* gengtype.c (strtoken): New function.
(create_user_defined_type): Replace strtok with strtoken.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gengtype.c

[Bug bootstrap/61914] [4.10 Regression] wide-int change breaks bootstrap

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61914

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed.

[Bug sanitizer/61955] New: libsanitizer fails to compile on RHEL4

[tortoise_74 at yahoo dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955

Bug ID: 61955
   Summary: libsanitizer fails to compile on RHEL4
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tortoise_74 at yahoo dot co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

gcc 4.9.0 fails to compile on a standard Red Hat 4 system due to problems
compiling libsantiser. 
See also https://gcc.gnu.org/ml/gcc/2014-05/msg00219.html

The work around of configuring gcc --disable-libsanitizer progresses the build
(which then fails for other reasons see below)

I would have thought this was a reasonably popular target still but there do
not seem to be any other reports.
I tried again using gcc 4.9.1 and the problem still occurs.
This target build successfully using the same method for gcc 4.8.1

brucea@:development/brucea/gcc>lsb_release -a
LSB Version:   
:core-3.0-amd64:core-3.0-ia32:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-ia32:graphics-3.0-noarch
Distributor ID:RedHatEnterpriseES
Description:Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
Release:4
Codename:NahantUpdate5

brucea@:development/brucea/gcc>uname -a
Linux uktnswg-tvdev01.tnsad.com 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT
2007 x86_64 x86_64 x86_64 GNU/Linux

Build using configure/make/install for each of the following in turn
gmp-5.0.2.tar.bz2
mpfr-3.1.0.tar.bz2
mpc-0.9.tar.gz
gcc-4.9.0.tar.bz2   or gcc-4.9.1.tar.bz2


libtool: compile:  /development/brucea/gcc/build/build/./gcc/xgcc
-shared-libgcc -B/development/brucea/gcc/build/build/./gcc -
nostdinc++
-L/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/development/brucea/gcc/build/bui
ld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libstdc++-v3
/libsupc++/.libs -B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/bin/
-B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/lib/ -
isystem /home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/include -isystem
/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/sys-inc
lude -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -I. -I../../../../gcc-4.9.1/
libsanitizer/sanitizer_common -I.. -I
../../../../gcc-4.9.1/libsanitizer/include -isystem
../../../../gcc-4.9.1/libsanitizer/i
nclude/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-
rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstd
c++-v3/include/x86_64-unknown-linux-gnu
-I../../../../gcc-4.9.1/libsanitizer/../libstdc++-v3/libsupc++
-DSANITIZER_LIBBACKTRAC
E -DSANITIZER_CP_DEMANGLE -I ../../../../gcc-4.9.1/libsanitizer/../libbacktrace
-I ../libbacktrace -I ../../../../gcc-4.9.1/li
bsanitizer/../include -include
../../../../gcc-4.9.1/libsanitizer/libbacktrace/backtrace-rename.h -g -O2
-D_GNU_SOURCE -MT san
itizer_platform_limits_linux.lo -MD -MP -MF
.deps/sanitizer_platform_limits_linux.Tpo -c
../../../../gcc-4.9.1/libsanitizer/sa
nitizer_common/sanitizer_platform_limits_linux.cc  -fPIC -DPIC -o
.libs/sanitizer_platform_limits_linux.o
In file included from
../../../../gcc-4.9.1/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:49:0:
../../../../gcc-4.9.1/libsanitizer/include/system/linux/aio_abi.h:2:32: fatal
error: linux/aio_abi.h: No such file or director
y
 #include_next 
^
compilation terminated.
make[3]: *** [sanitizer_platform_limits_linux.lo] Error 1
make[3]: Leaving directory
`/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libsanitizer/sanitizer_common'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
`/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libsanitizer'
make[1]: *** [install-target-libsanitizer] Error 2
make[1]: Leaving directory `/development/brucea/gcc/build/build'
make: *** [install] Error 2

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

[tortoise_74 at yahoo dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955

--- Comment #1 from Bruce Adams  ---
configuring with --disable-libsantizer progresses the build but it fails later
on linking cilk. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956

[Bug c++/61956] New: problem links cilk on RHEL4

[tortoise_74 at yahoo dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956

Bug ID: 61956
   Summary: problem links cilk on RHEL4
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tortoise_74 at yahoo dot co.uk

Following on from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
I tried compiling gcc4.9 on RHEL4 using configure --disable-libsanitizer.
It progresses the build which subsequently fails when linking cilk.
Building worked with the previous version gcc 4.8.1

brucea@:development/brucea/gcc>lsb_release -a
LSB Version:   
:core-3.0-amd64:core-3.0-ia32:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-ia32:graphics-3.0-noarch
Distributor ID:RedHatEnterpriseES
Description:Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
Release:4
Codename:NahantUpdate5

brucea@:development/brucea/gcc>uname -a
Linux uktnswg-tvdev01.tnsad.com 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT
2007 x86_64 x86_64 x86_64 GNU/Linux

Build using configure/make/install for each of the following in turn
gmp-5.0.2.tar.bz2
mpfr-3.1.0.tar.bz2
mpc-0.9.tar.gz
gcc-4.9.0.tar.bz2   or gcc-4.9.1.tar.bz2

Output:

libtool: link:  /development/brucea/gcc/build/./gcc/xg++
-B/development/brucea/gcc/build/./gcc/ -nostdinc++ -nostdinc++
-I/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/development/brucea/gcc/gcc-4.9.1/libstdc++-v3/libsupc++
-I/development/brucea/gcc/gcc-4.9.1/libstdc++-v3/include/backward
-I/development/brucea/gcc/gcc-4.9.1/libstdc++-v3/testsuite/util
-L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/bin/
-B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/lib/ -isystem
/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/include -isystem
/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/sys-include-shared -nostdlib
/usr/lib/../lib64/crti.o /development/brucea/gcc/build/./gcc/crtbeginS.o 
.libs/cilk-abi-vla.o .libs/os-unix-sysdep.o .libs/bug.o .libs/cilk-abi.o
.libs/cilk-abi-cilk-for.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o
.libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o
.libs/c_reducers.o .libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o
.libs/global_state.o .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o
.libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o
.libs/reducer_impl.o .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o
.libs/stats.o .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o  
-Wl,-rpath
-Wl,/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-Wl,-rpath -Wl,/home/brucea/gcc4.9.1/lib/../lib64
-L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-lpthread -ldl -L/development/brucea/gcc/build/./gcc -L/lib/../lib64
-L/usr/lib/../lib64
/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
-lm -lc -lgcc_s /development/brucea/gcc/build/./gcc/crtendS.o
/usr/lib/../lib64/crtn.o  -Wl,--version-script
-Wl,../../../gcc-4.9.1/libcilkrts/runtime/linux-symbols.ver   -Wl,-soname
-Wl,libcilkrts.so.5 -o .libs/libcilkrts.so.5.0.0
/usr/bin/ld: .libs/cilk-abi.o: relocation R_X86_64_PC32 against
`__cilkrts_get_tls_worker' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libcilkrts.la] Error 1
make[2]: Leaving directory
`/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libcilkrts'
make[1]: *** [install-target-libcilkrts] Error 2
make[1]: Leaving directory `/development/brucea/gcc/build'
make: *** [install] Error 2
Command exited with non-zero status 2

[Bug c++/61956] problem linking cilk on RHEL4

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956

--- Comment #1 from Andrew Pinski  ---
Can you try a newer binutils?

[Bug libstdc++/60037] SIGFPE in std::generate_canonical

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from emsr at gcc dot gnu.org ---
Fixed on trunk.

OK also for 4.9?

[Bug libstdc++/60037] SIGFPE in std::generate_canonical

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037

--- Comment #14 from Jonathan Wakely  ---
Yes, OK for 4.9 - thanks again

[Bug c/61957] New: Wrong -Warray-bounds warning depending on parameter types

[tavianator at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61957

Bug ID: 61957
   Summary: Wrong -Warray-bounds warning depending on parameter
types
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tavianator at gmail dot com

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

On x86-64 Linux, the attached testcase produces the duplicate spurious warning
with -O3 and -Wall:

$ gcc -std=c11 -O3 -Wall -c array-bounds.c
array-bounds.c: In function 'cofactor':
array-bounds.c:9:10: warning: array subscript is above array bounds
[-Warray-bounds]
 n[k] = A[i][j];
  ^
array-bounds.c:9:10: warning: array subscript is above array bounds
[-Warray-bounds]

Interestingly, if the 'row' and 'col' parameters are changed to 'unsigned
long', the warning goes away.

[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 29 17:30:34 2014
New Revision: 213221

URL: https://gcc.gnu.org/viewcvs?rev=213221&root=gcc&view=rev
Log:
PR libstdc++/61947
* include/std/tuple (_Head_base): Use allocator_arg_t parameters to
disambiguate unary constructors.
(_Tuple_impl): Pass allocator_arg_t arguments.
* testsuite/20_util/tuple/61947.cc: New.
* testsuite/20_util/uses_allocator/cons_neg.cc: Adjust dg-error line.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/61947.cc
  - copied, changed from r213220,
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc

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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 29 17:30:25 2014
New Revision: 213220

URL: https://gcc.gnu.org/viewcvs?rev=213220&root=gcc&view=rev
Log:
PR libstdc++/61946
* include/ext/rope (rope::rope(char_producer<_CharT>*, size_t, bool,
const allocator_type&)): Pass non-const allocator to
_S_new_RopeFunction.
* testsuite/ext/rope/61946.cc: New.

Added:
trunk/libstdc++-v3/testsuite/ext/rope/61946.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/rope

[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.10.0

--- Comment #5 from Jonathan Wakely  ---
Fixed on the trunk so far.

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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far

[Bug c/61958] function arbitrarily placed in .text.unlikely section

[jpoimboe at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958

--- Comment #1 from Josh Poimboeuf  ---
Created attachment 33207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33207&action=edit
gzipped .i file for the good case

[Bug c/61958] New: function arbitrarily placed in .text.unlikely section

[jpoimboe at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958

Bug ID: 61958
   Summary: function arbitrarily placed in .text.unlikely section
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpoimboe at redhat dot com

Created attachment 33206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33206&action=edit
gzipped .i file for the bad case

When making changes to a certain source file in the Linux kernel, gcc is
unexpectedly moving two functions from the .text section to the .text.unlikely
section.

When compiling the original version of the source file, the two functions are
placed in the .text section:

$ cd linux
$ git describe
v3.16-rc7-7-g31dab71
$ make net/ipv4/fib_trie.o
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
  CC  net/ipv4/fib_trie.o
$ eu-readelf -s net/ipv4/fib_trie.o |grep 'insert_leaf_info\|leaf_info_new'
6: 136 FUNCLOCAL  DEFAULT1 insert_leaf_info
   37: 0dc0 88 FUNCLOCAL  DEFAULT1 leaf_info_new
$ eu-readelf -S net/ipv4/fib_trie.o |grep '\[ 1\]'
[ 1] .textPROGBITS  0040 38c0  0 AX
0   0 16


However, when I apply the following patch, the two functions get unexpectedly
moved to .text.unlikely:

$ cat /tmp/fib_trie.patch
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 5afeb5a..cc5e3d3 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1187,6 +1187,7 @@ int fib_table_insert(struct fib_table *tb, struct
fib_config *cfg)

 key = key & mask;

+printk("foo\n");
 fi = fib_create_info(cfg);
 if (IS_ERR(fi)) {
 err = PTR_ERR(fi);
$ patch -p1 < /tmp/fib_trie.patch
patching file net/ipv4/fib_trie.c
$ make net/ipv4/fib_trie.o
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
  CC  net/ipv4/fib_trie.o
$ eu-readelf -s net/ipv4/fib_trie.o |grep 'insert_leaf_info\|leaf_info_new'
6: 111 FUNCLOCAL  DEFAULT5 insert_leaf_info
   28: 006f 82 FUNCLOCAL  DEFAULT5 leaf_info_new
$ eu-readelf -S net/ipv4/fib_trie.o |grep '\[ 5\]'
[ 5] .text.unlikely   PROGBITS  3770 00c1  0 AX
0   0  1


Both of the moved functions are called by fib_insert_node(), which is inlined
by fib_table_insert(), which was modified by the patch.  As far as I can tell,
it seems likely that the moved functions would be called, especially
insert_leaf_info() which is called in the main control path of the function. 
Also it seems odd that adding a call to printk would change the likelihood of a
function being called, since it doesn't change control flow.


Using gcc from Fedora rawhide:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.1-20140717/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.1-20140717/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.1 20140717 (Red Hat 4.9.1-2) (GCC) 

Full gcc cmdline:
  gcc -Wp,-MD,net/ipv4/.fib_trie.o.d  -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/4.9.1/include -I./arch/x86/include
-Iarch/x86/include/generated  -Iinclude -I./arch/x86/include/uapi
-Iarch/x86/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi
-include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security -m64 -mno-mmx
-mno-sse -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3
-mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time
-maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno

[Bug tree-optimization/61938] Vectorization not happening .

[harmeeksingh at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938

--- Comment #3 from harmeeksingh at gmail dot com ---
#include 

#define VEC 1024

typedef long  int int64;
typedef  int int32;

void foo (int   arraysize,
  int   *__restrict  result,
  int   *__restrict  selectvector,
  int   selectelements,
  int64 *__restrict array,
  int64 compval)
{
  int k, i;
  for (k =0,i=0; i < arraysize; ++i) {
  result[k] = i; k += (array[i] == compval);
  }
}

main()
{
  int   result[VEC];
  int   selectvector[VEC];
  int   selectelements;
  int64 array[VEC];

  int k, i;
  foo(VEC, result, selectvector, VEC, array, 1);
}

Even the above does not vectorize 

gcc -fPIC -shared -DCLS=64 -ffast-math -mfpmath=sse -mmmx -msse -msse2
-ftree-vectorize -ftree-vectorizer-verbose=7 -O3 -march=native /tmp/x.c -o
/tmp/x

Analyzing loop at /tmp/x.c:17

17: not vectorized: data ref analysis failed *D.2502_9 = i_27;

/tmp/x.c:9: note: vectorized 0 loops in function.

[Bug tree-optimization/61938] Vectorization not happening .

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938

--- Comment #4 from Marc Glisse  ---
Please show what you would like the code to look like after vectorization.

[Bug middle-end/61958] functions arbitrarily placed in .text.unlikely section

[jpoimboe at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958

--- Comment #2 from Josh Poimboeuf  ---
I see a similar issue with another patch to a different kernel file:

diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index b10cd43a..40c275f 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -797,6 +797,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
 #endif

err = -ENOBUFS;
+   printk("foo\n");
if (fib_info_cnt >= fib_info_hash_size) {
unsigned int new_size = fib_info_hash_size << 1;
struct hlist_head *new_info_hash;


This results in fib_info_hashfn() no longer being inlined (despite its static
inline directive), and being placed in .text.unlikely.  Other functions are
also moved to .text.unlikely: fib_info_hash_free(), kzalloc.constprop.19(), and
fib_info_hash_alloc()  I can also provide the data for this error if needed,
but it looks like the same issue.

[Bug middle-end/61958] functions arbitrarily placed in .text.unlikely section

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958

--- Comment #3 from Andrew Pinski  ---
(In reply to Josh Poimboeuf from comment #2)
> This results in fib_info_hashfn() no longer being inlined (despite its
> static inline directive), and being placed in .text.unlikely. 

This sounds like a heuristic is saying this function is cold and has become too
big to inline.

[Bug target/61844] ICE when building libgcc for sh64 cross-compiler

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-29
 Ever confirmed|0   |1

[Bug c++/61959] New: "internal compiler error: Segmentation fault" when building Mozilla code

[botond at mozilla dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959

Bug ID: 61959
   Summary: "internal compiler error: Segmentation fault" when
building Mozilla code
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: botond at mozilla dot com

Created attachment 33208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33208&action=edit
preprocessed source, zipped

I ran into an internal compiler error while trying to compile the Gecko
codebase with the patch at [1].

The output was:

/home/botond/dev/mozilla/refactoring/dom/events/EventStateManager.cpp:5609:1:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc7rD5Nc.out file, please attach this to
your bugreport.

Attached is the preprocessed source; I had to zip it to stay within the
attachment size limit.

My GCC version is 4.7.3; OS is Linux Mint 15 (Olivia).

Please let me know if there is any further informative I can provide.

[1] https://bug923512.bugzilla.mozilla.org/attachment.cgi?id=8464279

[Bug middle-end/61958] functions arbitrarily placed in .text.unlikely section

[andi-gcc at firstfloor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #4 from Andi Kleen  ---
It's because printk is marked cold. That is intentional, as normally only error
paths have printk.

asmlinkage __printf(1, 2) __cold
int printk(const char *fmt, ...);

->INVALID.

[Bug c++/61959] "internal compiler error: Segmentation fault" when building Mozilla code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959

--- Comment #1 from Andrew Pinski  ---
>See  for instructions.

[Bug c++/61959] "internal compiler error: Segmentation fault" when building Mozilla code

[botond at mozilla dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959

--- Comment #2 from Botond Ballo  ---
(In reply to Andrew Pinski from comment #1)
> >See  for instructions.

Here is the output of g++ -v:

Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)

Here is the complete command that triggers the bug:

  g++ -c -std=c++11 esm-ice.ii

Anything else I missed?

[Bug c++/61959] "internal compiler error: Segmentation fault" when building Mozilla code

[botond at mozilla dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959

Botond Ballo  changed:

   What|Removed |Added

Version|4.7.3   |4.9.0

--- Comment #3 from Botond Ballo  ---
Tried this with 4.9.0. I still get an ICE, but the error message is more
informative now:

/home/botond/dev/mozilla/refactoring/dom/events/EventStateManager.cpp:5609:1:
internal compiler error: in tree_to_uhwi, at tree.h:3657
0xb22aab tree_to_uhwi
../../src/gcc/tree.h:3657
0xb22aab output_constructor_regular_field
../../src/gcc/varasm.c:4894
0xb22aab output_constructor
../../src/gcc/varasm.c:5231
0xb21c7e assemble_variable(tree_node*, int, int, int)
../../src/gcc/varasm.c:2139
0xb238a5 varpool_assemble_decl(varpool_node*)
../../src/gcc/varpool.c:455
0x6de59d output_in_order
../../src/gcc/cgraphunit.c:2010
0x6de59d compile()
../../src/gcc/cgraphunit.c:2247
0x6de864 finalize_compilation_unit()
../../src/gcc/cgraphunit.c:2329
0x593f1b cp_write_global_declarations()
../../src/gcc/cp/decl2.c:4611

[Bug c++/61959] "internal compiler error: in tree_to_uhwi, at tree.h:3657" when building Mozilla code

[botond at mozilla dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959

--- Comment #4 from Botond Ballo  ---
Reduced code that triggers the ICE:


template 
struct BasePoint {
  Coord x, y;

  constexpr BasePoint(Coord aX, Coord aY) : x(aX), y(aY) {}
};

template 
struct BaseCoord {
  T value;

  explicit constexpr BaseCoord(T aValue) : value(aValue) {}
};

template
struct IntCoordTyped :
  public BaseCoord< int, IntCoordTyped >,
  public units {

  typedef BaseCoord< int, IntCoordTyped > Super;

  constexpr IntCoordTyped(int aValue) : Super(aValue) {}
};

template
struct IntPointTyped :
  public BasePoint< int, IntPointTyped, IntCoordTyped >,
  public units {

  typedef IntCoordTyped Coord;
  typedef BasePoint< int, IntPointTyped, IntCoordTyped > Super;

  constexpr IntPointTyped(int aX, int aY) : Super(Coord(aX), Coord(aY)) {}
};

struct LayoutDevicePixel {};
typedef IntPointTyped LayoutDeviceIntPoint;

static const LayoutDeviceIntPoint kInvalidRefPoint =
LayoutDeviceIntPoint(-1,-1);

[Bug ada/61954] Ada fails to properly pass pointer arguments on x32

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954

--- Comment #1 from H.J. Lu  ---
Ada seems to use a struct for pointers, something
like

struct pointer
{
  void *p;
  void *b;
};

But it fails to properly zero-extend pointers when calling
C functions:

[hjl@gnu-6 tmp]$ cat p.c
struct pointer
{
  void *p;
  void *b;
};

extern void foo (struct pointer);
extern void bar (void *p);

void
xxx (struct pointer p)
{
  foo (p);
}

void
yyy (struct pointer p)
{
  bar (p.p);
}
[hjl@gnu-6 tmp]$ gcc -mx32 -O2 p.c -S
[hjl@gnu-6 tmp]$ cat p.s
.file"p.c"
.text
.p2align 4,,15
.globlxxx
.typexxx, @function
xxx:
.LFB0:
.cfi_startproc
jmpfoo
.cfi_endproc
.LFE0:
.sizexxx, .-xxx
.p2align 4,,15
.globlyyy
.typeyyy, @function
yyy:
.LFB1:
.cfi_startproc
movl%edi, %edi
jmpbar
.cfi_endproc
.LFE1:
.sizeyyy, .-yyy

It treats C functions, like

   ssize_t write(int fd, const void *buf, size_t count);

as Ada functions.

[Bug libstdc++/60037] SIGFPE in std::generate_canonical

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037

--- Comment #15 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Wed Jul 30 00:25:17 2014
New Revision: 213231

URL: https://gcc.gnu.org/viewcvs?rev=213231&root=gcc&view=rev
Log:
2014-07-29  Ed Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/60037 - SIGFPE in std::generate_canonical
* include/bits/random.h (_Adaptor): static_assert for non floating-point
result type.
* include/bits/random.tcc (generate_canonical): Ditto.
* include/ext/random.tcc (hypergeometric_distribution::operator()):
Use double as a rng result type.
* testsuite/26_numerics/random/pr60037-neg.cc: New.
* testsuite/ext/random/hypergeometric_distribution/pr60037.cc: New.


Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/pr60037.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/random.h
branches/gcc-4_9-branch/libstdc++-v3/include/bits/random.tcc
branches/gcc-4_9-branch/libstdc++-v3/include/ext/random.tcc

[Bug ada/61954] Ada fails to properly pass pointer arguments on x32

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954

--- Comment #2 from H.J. Lu  ---
Maybe Ada fails to tell the backend that a parameter is a pointer:

[hjl@gnu-6 tmp]$ cat p2.c
struct pointer
{
  int p;
  int b;
};

extern void bar (int p);

void
xxx (struct pointer p)
{
  foo (p);
}
[hjl@gnu-6 tmp]$ gcc -mx32 -O2 p2.c -S
[hjl@gnu-6 tmp]$ cat p2.s
.file"p2.c"
.text
.p2align 4,,15
.globlxxx
.typexxx, @function
xxx:
.LFB0:
.cfi_startproc
xorl%eax, %eax
jmpfoo
.cfi_endproc
.LFE0:
.sizexxx, .-xxx

[Bug middle-end/61959] [4.8/4.9/4.10 Regression] ICE: in tree_to_uhwi, at tree.h:3657 when building Mozilla code

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-30
 CC||trippels at gcc dot gnu.org
  Component|c++ |middle-end
   Target Milestone|--- |4.8.4
Summary|"internal compiler error:   |[4.8/4.9/4.10 Regression]
   |in tree_to_uhwi, at |ICE: in tree_to_uhwi, at
   |tree.h:3657" when building  |tree.h:3657 when building
   |Mozilla code|Mozilla code
 Ever confirmed|0   |1

--- Comment #5 from Markus Trippelsdorf  ---
A bit further reduced:

markus@x4 tmp % cat foo.ii
template  struct BasePoint
{
  Coord x, y;
  constexpr BasePoint (Coord, Coord) : x (0), y (0) {}
};
template  struct BaseCoord
{
  int value;
  constexpr BaseCoord (T) : value (1) {}
};
template  struct IntCoordTyped : BaseCoord, units
{
  typedef BaseCoord Super;
  constexpr IntCoordTyped (int) : Super (0) {}
};
template 
struct IntPointTyped : BasePoint >, units
{
  typedef BasePoint > Super;
  constexpr IntPointTyped (int, int) : Super (0, 0) {}
};
struct A
{
};
IntPointTyped a (0, 0);

markus@x4 tmp % g++ -O2 -std=c++11 -c foo.ii
foo.ii:25:26: internal compiler error: tree check: expected field_decl, have
pointer_plus_expr in output_constructor, at varasm.c:5194
 IntPointTyped a (0, 0);
  ^
0xdb4d94 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9169
0xe0a9e4 tree_check
../../gcc/gcc/tree.h:2728
0xe0a9e4 output_constructor
../../gcc/gcc/varasm.c:5194
0xe02817 output_constant
../../gcc/gcc/varasm.c:4735
0xe0b364 assemble_variable(tree_node*, int, int, int)
../../gcc/gcc/varasm.c:2175
0xe0caff varpool_node::assemble_decl()
../../gcc/gcc/varpool.c:544
0xe0d0c5 varpool_node::assemble_decl()
../../gcc/gcc/varpool.c:516
0xe0d0c5 varpool_node::output_variables()
../../gcc/gcc/varpool.c:684
0x844a7c compile()
../../gcc/gcc/cgraphunit.c:2262
0x845184 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2338
0x63330a cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4684
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug middle-end/61958] functions arbitrarily placed in .text.unlikely section

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Agreed.