[Bug middle-end/61913] ICE in common_handle_option with -Wodr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61913 --- Comment #11 from Jan Hubicka hubicka at ucw dot cz --- It seems quite a major deficiency if we are going to keep adding warnings to LTO, which are never tested and there is a high chance they are not working at all. Is there a PR about it? Is Jan or someone else working on it? I don't know about such PR. Neither do I know whether Jan's planning to fix this soon. I am not really dejagnu guru, so I have no immediate plans for fixing this - we need way to test warningserrors and also way to scan dumps. Neither of this is implemented. patches would be very welcome. Honza I added the correct entry in my review. You could use that. It fixes several deficiencies with the current entry. https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01905.html
Re: [Bug middle-end/61913] ICE in common_handle_option with -Wodr
It seems quite a major deficiency if we are going to keep adding warnings to LTO, which are never tested and there is a high chance they are not working at all. Is there a PR about it? Is Jan or someone else working on it? I don't know about such PR. Neither do I know whether Jan's planning to fix this soon. I am not really dejagnu guru, so I have no immediate plans for fixing this - we need way to test warningserrors and also way to scan dumps. Neither of this is implemented. patches would be very welcome. Honza I added the correct entry in my review. You could use that. It fixes several deficiencies with the current entry. https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01905.html
Re: [Bug middle-end/61913] ICE in common_handle_option with -Wodr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61913
--- Comment #6 from Manuel López-Ibá??ez manu at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #5)
(In reply to Manuel López-Ibá??ez from comment #4)
It is pretty strange that you need a Var() if it is not used anywhere.
It is, we have a bug for it: PR61480.
But there is no Init(1) there. In fact, I doubt Wodr is enabled by default as
the documentation says without Init(1).
The warning is triggered by:
jan@linux-ujxe:~/trunk/build/gcc cat tt.C
struct A {int b; virtual void t();};
struct A *a;
void
m()
{
a-t();
}
jan@linux-ujxe:~/trunk/build/gcc cat tt2.C
struct A {short d; virtual void t();};
void
A::t(){
}
jan@linux-ujxe:~/trunk/build/gcc ./xgcc -B ./ -O2 -flto tt.C tt2.C
tt2.C:1:8: warning: type âstruct Aâ violates one definition rule [-Wodr]
struct A {short d; virtual void t();};
^
tt.C:1:8: note: a different type is defined in another translation unit
struct A {int b; virtual void t();};
^
tt2.C:1:17: note: the first difference of corresponding definitions is field
âdâ
struct A {short d; virtual void t();};
^
tt.C:1:15: note: a field with different name is defined in another translation
unit
struct A {int b; virtual void t();};
So my tree shows it by default. I am at a conference and have to go for talks,
but I will try to dig deeper today.
Honza
The issue is that lto.exp does not allow to scan for 'warning:'.
Isn't that a bug/missing feature? It seems crucial if one wants to add
warnings/errors generated by LTO.
[Bug middle-end/61913] ICE in common_handle_option with -Wodr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61913
--- Comment #12 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61913
--- Comment #6 from Manuel López-Ibá??ez manu at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #5)
(In reply to Manuel López-Ibá??ez from comment #4)
It is pretty strange that you need a Var() if it is not used anywhere.
It is, we have a bug for it: PR61480.
But there is no Init(1) there. In fact, I doubt Wodr is enabled by default as
the documentation says without Init(1).
The warning is triggered by:
jan@linux-ujxe:~/trunk/build/gcc cat tt.C
struct A {int b; virtual void t();};
struct A *a;
void
m()
{
a-t();
}
jan@linux-ujxe:~/trunk/build/gcc cat tt2.C
struct A {short d; virtual void t();};
void
A::t(){
}
jan@linux-ujxe:~/trunk/build/gcc ./xgcc -B ./ -O2 -flto tt.C tt2.C
tt2.C:1:8: warning: type âstruct Aâ violates one definition rule [-Wodr]
struct A {short d; virtual void t();};
^
tt.C:1:8: note: a different type is defined in another translation unit
struct A {int b; virtual void t();};
^
tt2.C:1:17: note: the first difference of corresponding definitions is field
âdâ
struct A {short d; virtual void t();};
^
tt.C:1:15: note: a field with different name is defined in another translation
unit
struct A {int b; virtual void t();};
So my tree shows it by default. I am at a conference and have to go for talks,
but I will try to dig deeper today.
Honza
The issue is that lto.exp does not allow to scan for 'warning:'.
Isn't that a bug/missing feature? It seems crucial if one wants to add
warnings/errors generated by LTO.
[Bug tree-optimization/61938] Vectorization not happening .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- array[selectvector[i]] is not handled.
[Bug debug/61923] [4.8/4.9/4.10 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Created attachment 33200
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33200action=edit
original testcase
The issue is more visible with the original attached testcase:
markus@x4 linux % diff -u inode.gkd inode.gk.gkd
--- inode.gkd 2014-07-29 08:52:00.453657959 +0200
+++ inode.gk.gkd2014-07-29 08:52:01.636965368 +0200
@@ -4270,15 +4270,6 @@
(nil
(code_label 158 0 0 16 158 [1 uses])
(note# 0 0 [bb 16] NOTE_INSN_BASIC_BLOCK)
-(insn:TI# 0 0 16 (set (reg:SI 37 r8)
-(const_int 2 [0x2])) fs/ext4/inode.c:1632# {*movsi_internal}
- (nil))
-(insn# 0 0 16 (set (reg:DI 2 cx)
-(const_int -1 [0x])) fs/ext4/inode.c:1632#
{*movdi_internal}
- (nil))
-(insn# 0 0 16 (set (reg:DI 5 di)
-(reg/v/f:DI 44 r15 [orig:208 inode ] [208])) fs/ext4/inode.c:1632#
{*movdi_internal}
- (nil))
(insn:TI# 0 0 16 (set (reg:SI 1 dx)
(mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 28 [0x1c])) [ map.m_len+0 S4 A32]))
fs/ext4/inode.c:1632# {*movsi_internal}
@@ -4287,6 +4278,15 @@
(mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [ map.m_lblk+0 S4 A64]))
fs/ext4/inode.c:1632# {*movsi_internal}
(nil))
+(insn# 0 0 16 (set (reg:SI 37 r8)
+(const_int 2 [0x2])) fs/ext4/inode.c:1632# {*movsi_internal}
+ (nil))
+(insn:TI# 0 0 16 (set (reg:DI 2 cx)
+(const_int -1 [0x])) fs/ext4/inode.c:1632#
{*movdi_internal}
+ (nil))
+(insn# 0 0 16 (set (reg:DI 5 di)
+(reg/v/f:DI 44 r15 [orig:208 inode ] [208])) fs/ext4/inode.c:1632#
{*movdi_internal}
+ (nil))
(call_insn:TI# 0 0 16 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI (ext4_es_insert_extent) [flags 0x41]
function_decl # ext4_es_insert_extent) [ ext4_es_insert_extent S1 A8])
(const_int 0 [0]))) fs/ext4/inode.c:1632# {*call_value}
[Bug c/61942] New: loop-iv.c:2272 signed integer overflow
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123 --- Comment #8 from xuepeng guo xguo at gcc dot gnu.org --- Author: xguo Date: Tue Jul 29 07:11:02 2014 New Revision: 213147 URL: https://gcc.gnu.org/viewcvs?rev=213147root=gccview=rev Log: gcc/c-family/ 2014-07-29 Terry Guo terry@arm.com Backport mainline r211832 2014-06-20 Hale Wang hale.w...@arm.com PR lto/61123 * c.opt (fshort-enums): Add to LTO. * c.opt (fshort-wchar): Likewise. gcc/testsuite/ 2014-07-29 Terry Guo terry@arm.com Backport mainline r211832 2014-06-20 Hale Wang hale.w...@arm.com * 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
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=33201action=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_canonicalunsigned int...
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 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
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 ext/rope
class empty_char_prod : public __gnu_cxx::char_producerchar
{
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::allocatorchar;
std::size_t = long unsigned int; __gnu_cxx::rope_CharT,
_Alloc::allocator_type = std::allocatorchar]’:
./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::ropechar::_S_new_RopeFunction(__gnu_cxx::char_producerchar*,
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::allocatorchar; __gnu_cxx::rope_CharT, _Alloc::_RopeFunction =
__gnu_cxx::_Rope_RopeFunctionchar, std::allocatorchar ; std::size_t = long
unsigned int; __gnu_cxx::rope_CharT, _Alloc::allocator_type =
std::allocatorchar]
_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::allocatorchar}’ to
‘__gnu_cxx::ropechar::allocator_type {aka std::allocatorchar}’
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 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-29 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946
Jonathan Wakely redi at gcc dot gnu.org 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 redi at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #18 from Richard Earnshaw rearnsha at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added CC||manjian2006 at gmail dot com --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org --- *** 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.10.0 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (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
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 tuple
struct ConvertibleToAny {
template class T operator T() const { return T(); }
};
int main() {
std::tupleConvertibleToAny 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_base0UL, (anonymous
namespace)::ConvertibleToAny , __empty_not_finalConvertibleToAny
::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_impl0,
(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::tupleConvertibleToAny 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 class... UTypes
explicit tuple(UTypes... u);
Requires: sizeof...(Types) == sizeof...(UTypes). is_constructibleTi , Ui
::value is true for all i.
Effects: Initializes the elements in the tuple with the corresponding value
in std::forwardUTypes(u).
is_constructibleConvertibleToAny, ConvertibleToAny::value is true, so the
precondition is satisfied.
This bug affects std::bind as it's built on top of std::tuple.
#include functional
struct ConvertibleToAny {
template class T 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_base0UL, (anonymous
namespace)::ConvertibleToAny , __empty_not_finalConvertibleToAny
::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_impl0,
(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::_Bindvoid
(*(std::_Placeholder1))(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
[Bug middle-end/54664] expand_gimple_cond warning for predictably small BRANCH_COST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664 Hans-Peter Nilsson hp at gcc dot gnu.org 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 hp at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52478 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jul 29 11:10:49 2014 New Revision: 213153 URL: https://gcc.gnu.org/viewcvs?rev=213153root=gccview=rev Log: 2014-07-29 Richard Biener rguent...@suse.de 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)
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=33202action=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_shiftdi3_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
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 t.udalova at samsung dot com --- 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)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61868 Bingfeng Mei bmei at broadcom dot com changed: What|Removed |Added Component|driver |lto --- Comment #1 from Bingfeng Mei bmei at broadcom dot com --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725
--- Comment #8 from Marat Zakirov m.zakirov at samsung dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 Jonathan Wakely redi at gcc dot gnu.org 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 redi at gcc dot gnu.org --- stupid allocators
[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 --- Comment #9 from Marat Zakirov m.zakirov at samsung dot com --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #10 from Ilya Enkovich enkovich.gnu at gmail dot com --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Created attachment 33203 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33203action=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 Rainer Orth ro at gcc dot gnu.org 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61929
--- Comment #4 from Charles Greathouse gcc at crg4 dot com ---
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
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 md5_finish_ctx+150: 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 rguent...@suse.de 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
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 rguent...@suse.de 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950 Rainer Orth ro at gcc dot gnu.org 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]
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=33204action=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60652 Arnaud Charlet charlet at gcc dot gnu.org 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 charlet at gcc dot gnu.org --- Should be fixed now (commit rev 213201).
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/16644819
[Bug fortran/61952] New: ICE allocattion of array of type of type
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 http://gcc.gnu.org/bugs.html 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 Ramana Radhakrishnan ramana at gcc dot gnu.org 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 ramana at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734
--- Comment #12 from Ilya Enkovich enkovich.gnu at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60652 --- Comment #2 from Arnaud Charlet charlet at gcc dot gnu.org --- Author: charlet Date: Tue Jul 29 14:46:27 2014 New Revision: 213201 URL: https://gcc.gnu.org/viewcvs?rev=213201root=gccview=rev Log: 2014-07-29 Robert Dewar de...@adacore.com * gnat_rm.texi, sem_prag.adb: Minor reformatting. 2014-07-29 Sergey Rybin ry...@adacore.com frybin * gnat_ugn.texi: gnatmetric: clarify documentation for cyclomatic complexity metrics. 2014-07-29 Thomas Quinot qui...@adacore.com PR ada/60652 * s-oscons-tmplt.c: For Linux, define _BSD_SOURCE in order for CRTSCTS to be visible. 2014-07-29 Bob Duff d...@adacore.com * 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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
Alan Lawrence alan.lawrence at arm dot com changed:
What|Removed |Added
CC||alan.lawrence at arm dot com
--- Comment #8 from Alan Lawrence alan.lawrence at arm dot com ---
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 vect_sum_13.10_27, 8,
120;
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_canonicalunsigned int...
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=213207root=gccview=rev Log: 2014-07-29 Ed Smith-Rowland 3dw...@verizon.net PR libstdc++/60037 - SIGFPE in std::generate_canonicalunsigned int... * 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
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.
==
templateclass... T, class... U void f() { }
==
===
templateclass... T, class U 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
templateclass... T, class... U void f() { } // error
templateclass... T, class U 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61885 Markus Trippelsdorf trippels at gcc dot gnu.org 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 trippels at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 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
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 output__flush_buffer__write_buffer 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61914 --- Comment #4 from hjl at gcc dot gnu.org 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=213213root=gccview=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61914 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug sanitizer/61955] New: libsanitizer fails to compile on RHEL4
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/gcclsb_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/gccuname -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 linux/aio_abi.h ^ 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #1 from Bruce Adams tortoise_74 at yahoo dot co.uk --- 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
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/gcclsb_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/gccuname -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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Can you try a newer binutils?
[Bug libstdc++/60037] SIGFPE in std::generate_canonicalunsigned int...
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_canonicalunsigned int...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, OK for 4.9 - thanks again
[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jul 29 17:30:34 2014 New Revision: 213221 URL: https://gcc.gnu.org/viewcvs?rev=213221root=gccview=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jul 29 17:30:25 2014 New Revision: 213220 URL: https://gcc.gnu.org/viewcvs?rev=213220root=gccview=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.10.0 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug libstdc++/61946] [4.8/4.9/4.10 Regression] rope construction, passing allocator referenct without const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61946 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk so far
[Bug c/61958] function arbitrarily placed in .text.unlikely section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958 --- Comment #1 from Josh Poimboeuf jpoimboe at redhat dot com --- Created attachment 33207 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33207action=edit gzipped .i file for the good case
[Bug c/61958] New: function arbitrarily placed in .text.unlikely section
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=33206action=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-avx
[Bug tree-optimization/61938] Vectorization not happening .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938
--- Comment #3 from harmeeksingh at gmail dot com ---
#include stdio.h
#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 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Please show what you would like the code to look like after vectorization.
[Bug middle-end/61958] functions arbitrarily placed in .text.unlikely section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958
--- Comment #2 from Josh Poimboeuf jpoimboe at redhat dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 Oleg Endo olegendo at gcc dot gnu.org 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
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=33208action=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 file:///usr/share/doc/gcc-4.7/README.Bugs 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
[Bug c++/61959] internal compiler error: Segmentation fault when building Mozilla code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959 --- Comment #2 from Botond Ballo botond at mozilla dot com --- (In reply to Andrew Pinski from comment #1) See file:///usr/share/doc/gcc-4.7/README.Bugs 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959 Botond Ballo botond at mozilla dot com changed: What|Removed |Added Version|4.7.3 |4.9.0 --- Comment #3 from Botond Ballo botond at mozilla dot com --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959
--- Comment #4 from Botond Ballo botond at mozilla dot com ---
Reduced code that triggers the ICE:
template class T, class Sub, class Coord
struct BasePoint {
Coord x, y;
constexpr BasePoint(Coord aX, Coord aY) : x(aX), y(aY) {}
};
template class T, class Sub
struct BaseCoord {
T value;
explicit constexpr BaseCoord(T aValue) : value(aValue) {}
};
templateclass units
struct IntCoordTyped :
public BaseCoord int, IntCoordTypedunits ,
public units {
typedef BaseCoord int, IntCoordTypedunits Super;
constexpr IntCoordTyped(int aValue) : Super(aValue) {}
};
templateclass units
struct IntPointTyped :
public BasePoint int, IntPointTypedunits, IntCoordTypedunits ,
public units {
typedef IntCoordTypedunits Coord;
typedef BasePoint int, IntPointTypedunits, IntCoordTypedunits Super;
constexpr IntPointTyped(int aX, int aY) : Super(Coord(aX), Coord(aY)) {}
};
struct LayoutDevicePixel {};
typedef IntPointTypedLayoutDevicePixel LayoutDeviceIntPoint;
static const LayoutDeviceIntPoint kInvalidRefPoint =
LayoutDeviceIntPoint(-1,-1);
[Bug ada/61954] Ada fails to properly pass pointer arguments on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
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
.filep.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_canonicalunsigned int...
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=213231root=gccview=rev Log: 2014-07-29 Ed Smith-Rowland 3dw...@verizon.net PR libstdc++/60037 - SIGFPE in std::generate_canonicalunsigned int... * 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
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
.filep2.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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959
Markus Trippelsdorf trippels at gcc dot gnu.org 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 trippels at gcc dot gnu.org ---
A bit further reduced:
markus@x4 tmp % cat foo.ii
template class Coord struct BasePoint
{
Coord x, y;
constexpr BasePoint (Coord, Coord) : x (0), y (0) {}
};
template class T struct BaseCoord
{
int value;
constexpr BaseCoord (T) : value (1) {}
};
template class units struct IntCoordTyped : BaseCoordint, units
{
typedef BaseCoord Super;
constexpr IntCoordTyped (int) : Super (0) {}
};
template class units
struct IntPointTyped : BasePointIntCoordTypedunits , units
{
typedef BasePointIntCoordTypedunits Super;
constexpr IntPointTyped (int, int) : Super (0, 0) {}
};
struct A
{
};
IntPointTypedA 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
IntPointTypedA 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Agreed.
