[Bug lto/44899] New: --with-build-config=bootstrap-lto fails
--with-build-config=bootstrap-lto ... ; make -j8 fails here in the second stage with several configure errors in multiple subdirs (zlib, lto-plugin) -- Summary: --with-build-config=bootstrap-lto fails Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug lto/44899] --with-build-config=bootstrap-lto fails
--- Comment #1 from andi-gcc at firstfloor dot org 2010-07-10 08:15 --- Error happens even without -j8, so no race -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug lto/44899] --with-build-config=bootstrap-lto fails
--- Comment #2 from andi-gcc at firstfloor dot org 2010-07-10 08:15 --- Created an attachment (id=21171) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21171&action=view) zlib config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug c++/44900] New: The variable of SSE will be broken
I'm using gcc-4.5.0-1 of MinGW with Intel x86.
When I execute the following test code with '-O -msse' compiler options, it
outputs the wrong value.
I'm expecting that v2.e[3] will be 7.0f.
And, when I exclude LINE_A, LINE_B, LINE_C or LINE_D as a comment, the program
outputs the expected value.
-- begin test code --
// g++ -O -msse test.cpp
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set_ps (const float __Z, const float __Y, const float __X, const float __W)
{
return __extension__ (__m128)(__v4sf){ __W, __X, __Y, __Z };
}
struct vec
{
union {
__m128 v;
float e[4];
};
static const vec & zero()
{
static const vec v = _mm_set_ps(0, 0, 0, 0);
return v;
}
vec() {}
vec(const __m128 & a) : v(a) {}
operator const __m128&() const { return v; }
};
struct vec2
{
vec _v1;
vec _v2;
vec2() {}
vec2(const vec & a, const vec & b) : _v1(a), _v2(b) {}
static vec2 load(const float * a)
{
return vec2(
__builtin_ia32_loadups(&a[0]),
__builtin_ia32_loadups(&a[4]));
}
const vec & v1() const { return _v1; }
const vec & v2() const { return _v2; }
};
extern "C" {
int* _errno(void);
int printf (const char*, ...);
}
inline bool test_assert( bool is_succeed, const char * file_name, int line_num
)
{
if ( !is_succeed )
{
printf("error: %s(%d)\n", file_name, line_num);
if ( *_errno() ) // LINE_A
{
printf("errno: %d\n", *_errno());
}
}
return is_succeed;
}
inline bool operator==(const vec & a, const vec & b)
{ return 0xf == __builtin_ia32_movmskps(__builtin_ia32_cmpeqps(a, b)); }
#define test(x, y) test_assert( (x)==(y), __FILE__, __LINE__ )
int main( int argc, char * argv[] )
{
__attribute__((aligned(16))) float data[] =
{ 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5 };
float * p = &data[2];
vec2 a;
a = vec2::load(p);
vec v1 = a.v1();
vec v2 = a.v2();
printf(
"v1: %f, %f, %f, %f\n"
"v2: %f, %f, %f, %f\n",
v1.e[0], v1.e[1], v1.e[2], v1.e[3],
v2.e[0], v2.e[1], v2.e[2], v2.e[3]);
test(_mm_set_ps(11, 12, 13, 14), a.v1()); // LINE_B
test(_mm_set_ps( 7, 8, 9, 10), a.v2()); // LINE_C
a._v1 = vec::zero();
test(_mm_set_ps(0, 0, 0, 0), a.v1()); // LINE_D
return 0;
}
-- end test code --
-- begin output --
v1: 14.00, 13.00, 12.00, 11.00
v2: 10.00, 9.00, 8.00, 0.00
error: test.cpp(92)
-- end output --
--
Summary: The variable of SSE will be broken
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yottui at yahoo dot co dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug lto/44899] --with-build-config=bootstrap-lto fails
--- Comment #3 from andi-gcc at firstfloor dot org 2010-07-10 08:30 ---
What happens during the config stage is:
configure:2978: checking for C compiler default output file name
configure:3000: /home/andi/gcc/git/obj/./prev-gcc/xgcc
-B/home/andi/gcc/git/obj/./prev-gcc/
-B/pkg/gcc-4.6-100710/x86_64-unknown-linux-gnu/bin/
-B/pkg/gcc-4.6-100710/x86_64-unknown-linux
-gnu/bin/ -B/pkg/gcc-4.6-100710/x86_64-unknown-linux-gnu/lib/ -isystem
/pkg/gcc-4.6-100710/x86_64-unknown-linux-gnu/include -isystem
/pkg/gcc-4.6-100710/x86_64-unknown-linux-gnu/sys-inclu
de-g -O2 -fltoconftest.c >&5
cc1: error: LTO support has not been enabled in this configuration
configure:3004: $? = 1
configure:3041: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3047: error: in `/home/andi/gcc/git/obj/intl':
configure:3051: error: C compiler cannot create executables
Full configure arguments:
'--prefix=/pkg/gcc-4.6-100710' '--enable-checking=release' '--disable-nls'
'--enable-lto' '--enable-gold' '--with-plugin-ld=/usr/local/bin/gold'
'--with-build-config=bootstrap-lto' '--with-elf-include=/usr/include/libelf'
'--enable-languages=c,c++,lto (the lto is added by configure)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug lto/44899] --with-build-config=bootstrap-lto fails
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-10 08:32 --- Please specify what "..." is. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug fortran/44863] [OOP] Fortran runtime error: internal error: bad hash value in dynamic dispatch
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-10 08:35 --- Closing as fixed. -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Known to fail||4.5.1 Known to work||4.6.0 Resolution||FIXED Summary|Fortran runtime error: |[OOP] Fortran runtime error: |internal error: bad hash|internal error: bad hash |value in dynamic dispatch |value in dynamic dispatch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44863
[Bug fortran/44864] [OOP] ICE: Segmentation fault
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-10 08:38 --- Closing as fixed. -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Known to fail||4.5.1 Known to work||4.6.0 Resolution||FIXED Summary|internal compiler error:|[OOP] ICE: Segmentation |Segmentation fault |fault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44864
[Bug lto/44889] Bogus "type of �nsLayoutModule_NSModule� does not match original declaration" waning compiling Mozilla
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-10 08:40 --- Subject: Bug 44889 Author: rguenth Date: Sat Jul 10 08:39:46 2010 New Revision: 162032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162032 Log: 2010-07-10 Richard Guenther PR lto/44889 * gimple.c (gimple_fixup_complete_and_incomplete_subtype_p): New helper function. (gimple_types_compatible_p): Similar to pointed-to types allow and merge a mix of complete and incomplete aggregate. Use gimple_fixup_complete_and_incomplete_subtype_p for that. (iterative_hash_gimple_type): Adjust for that. * gcc.dg/lto/20100709-1_0.c: New testcase. * gcc.dg/lto/20100709-1_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/20100709-1_0.c trunk/gcc/testsuite/gcc.dg/lto/20100709-1_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44889
[Bug lto/44899] --with-build-config=bootstrap-lto fails
--- Comment #5 from andi-gcc at firstfloor dot org 2010-07-10 08:40 --- See comment #3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
[Bug lto/44889] Bogus "type of �nsLayoutModule_NSModule� does not match original declaration" waning compiling Mozilla
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-10 08:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44889
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #8 from bugtrack at roumenpetrov dot info 2010-07-10 08:56 --- Bug cannot be resolved with updates in libjava/Makefile. You could see my comments in issue #40868 (clone of #30591) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #9 from bugtrack at roumenpetrov dot info 2010-07-10 08:57 --- *** Bug 42311 has been marked as a duplicate of this bug. *** -- bugtrack at roumenpetrov dot info changed: What|Removed |Added CC||bugtrack at roumenpetrov dot ||info http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug java/42311] Cross build fails because native gcj needed to build ecjx
--- Comment #2 from bugtrack at roumenpetrov dot info 2010-07-10 08:57 --- *** This bug has been marked as a duplicate of 40868 *** -- bugtrack at roumenpetrov dot info changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42311
[Bug fortran/44869] [OOP] Missing TARGET check - and wrong code or accepts-invalid?
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-10 09:38 --- The patch in comment #4 regresses on select_type_4.f90 in the test suite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44869
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #54 from amylaar at gcc dot gnu dot org 2010-07-10 09:40 --- Subject: Bug 44832 Author: amylaar Date: Sat Jul 10 09:40:36 2010 New Revision: 162035 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162035 Log: 2010-07-10 Richard Guenther Joern Rennecke PR debug/44832 * tree-ssa-live.c (mark_all_vars_used_1): Set TREE_USED for LABEL_DECL. (remove_unused_scope_block_p): Don't drop TREE_USED LABEL_DECLs unless they have DECL_IGNORED_P set. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-live.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #2 from mikpe at it dot uu dot se 2010-07-10 10:06 --- This test now also fails with 4.5 branch on powerpc64. It's a recent regression, introduced somewhere between 20100701 and 20100708. The -fdump-tree-vect-details file shows: > fgrep vectorized vect-109.c.110t.vect vect-109.c:33: note: not vectorized: control flow in loop. vect-109.c:26: note: === vect_mark_stmts_to_be_vectorized === vect-109.c:26: note: not vectorized: unsupported unaligned store. vect-109.c:20: note: vectorized 0 loops in function. vect-109.c:55: note: not vectorized: control flow in loop. vect-109.c:48: note: === vect_mark_stmts_to_be_vectorized === vect-109.c:48: note: not vectorized: unsupported unaligned store. vect-109.c:42: note: vectorized 0 loops in function. so it's not the common problem with too many vectorized loops. I'll try reverting the PR44284 backport. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug lto/44894] bogus warning: Use of type �struct nsNodeInfoManager� with two mismatching declarations at field �mDocument� [enabled by default]
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-10 10:08 --- Created an attachment (id=21172) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21172&action=view) somewhat reduced testcase Two files, but still way too large (reduced at topflatform level 0 to not mess up types). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44894
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #3 from mikpe at it dot uu dot se 2010-07-10 10:30 ---
It now also fails with 4.5 branch on sparc64-linux, with identical
-fdump-tree-vect-details as for powerpc64. With 4.6 it fails on ARM with
identical reason since 20100529.
I'm thinking this hunk in the PR44284 fix is to blame:
--- trunk/gcc/testsuite/gcc.dg/vect/vect-109.c 2010/05/27 12:08:51 159919
+++ trunk/gcc/testsuite/gcc.dg/vect/vect-109.c 2010/05/27 13:23:45 159920
@@ -72,7 +72,7 @@
return 0;
}
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */
/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned
store" 2 "vect" { xfail vect_hw_misalign } } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 10
"vect" { target vect_hw_misalign } } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
That is, the changed expectation that vectorization now will succeed should
probably depend on target vect_hw_misalign.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-10 10:38 --- Created an attachment (id=21173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21173&action=view) improve robustness of runtime option choices. This should resolve the case where -fnext-runtime would be considered valid (for compile tests) because the target (non-darwin) system happened to have objc headers in the same place as a standard darwin installation. Tested on i686-apple-darwin9 [build --enable-build-with-cxx] , cris-elf (sim) and mipsabi64-elf (sim) with no changes in fails or counts on make check-gcc-objc. let me know if it solve that aspect of the problem for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug lto/44894] bogus warning: Use of type �struct nsNodeInfoManager� with two mismatching declarations at field �mDocument� [enabled by default]
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-10 10:40 --- We fail to merge unit size align 64 symtab 0 alias set -1 canonical type 0x759f6a80 fields ignored BLK file tc/nsCopySupport.3.ii line 3158 col 7 size unit size align 64 offset_align 128 offset bit offset context chain >> public BLK file tc/nsCopySupport.3.ii line 3158 col 7 and unit size align 64 symtab 0 alias set -1 canonical type 0x75af30a8 fields ignored BLK file tc/nsContentUtils.3.3.ii line 3647 col 7 size unit size align 64 offset_align 128 offset bit offset context chain > pointer_to_this > public BLK file tc/nsContentUtils.3.3.ii line 3647 col 7 align 8> Looks like sth recursive as my debug fn is crashing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44894
[Bug debug/44901] New: [4.6 Regression] -fcompare-debug failure for C++ i386.c
We currently have a bootstrap-lean failure on tree-predcom.c . The preprocessed file shows a compare-debug failure for gcc (GCC) 4.6.0 20100708 (experimental), but not for gcc (GCC) 4.6.0 20100705 (experimental), gcc (GCC) 4.6.0 20100630 (experimental) or gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10). -- Summary: [4.6 Regression] -fcompare-debug failure for C++ i386.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44901
[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-10 10:53 --- Created an attachment (id=21174) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21174&action=view) test case - compressed with xz $ ./bld-20100708/gcc/xgcc -B./bld-20100708/gcc -c -fpreprocessed -g -O2 -fomit-frame-pointer -fcompare-debug -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common treepred.c xgcc: error: treepred.c: -fcompare-debug failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44901
[Bug lto/44894] bogus warning: Use of type �struct nsNodeInfoManager� with two mismatching declarations at field �mDocument� [enabled by default]
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-10 11:00 --- Field types not compatible. field 0x75754d10 mNextSibling field 0x75974428 mNextSibling Field types not compatible. field 0x75754da8 mPreviousSibling field 0x759744c0 mPreviousSibling Field types not compatible. field 0x75754e40 mFirstChild field 0x75974558 mFirstChild which is because Pointed-to types mismatching. 0x759ff7e0 struct nsIContent 0x75b01690 struct nsIContent which is because Field types not compatible. field 0x759f4ed8 D.6847 field 0x75b00980 D.2414 Field types not compatible. field 0x75a02000 mPrimaryFrame field 0x75b00a18 mPrimaryFrame the latter because of Pointed-to types mismatching. 0x759ff930 struct nsIFrame 0x75b01000 struct nsIFrame (and we recurse, which means this one is not the issue) the former because of Field types not compatible. field 0x75754d10 mNextSibling field 0x75974428 mNextSibling Field types not compatible. field 0x75754da8 mPreviousSibling field 0x759744c0 mPreviousSibling Field types not compatible. field 0x75754e40 mFirstChild field 0x75974558 mFirstChild (and we recurse, which means this one is not the issue) should be not an issue. Appearantly the cache doesn't work for us here. Hm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44894
[Bug lto/44894] bogus warning: Use of type �struct nsNodeInfoManager� with two mismatching declarations at field �mDocument� [enabled by default]
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-10 11:21 ---
Somewhere down in type
0x757497e0 struct nsRefreshDriver
0x75964348 struct nsRefreshDriver
(gdb) call debug_type_differences (0x757497e0, 0x75964348)
Hashes differ.
Field types not compatible.
type 0x759fb690 struct nsPresContext *
type 0x75af9d20 struct nsPresContext *
field 0x7574b688 mPresContext
field 0x75941ab0 mPresContext
Field types not compatible.
type 0x7574c150 struct nsTObserverArray[3]
type 0x75964dc8 struct nsTObserverArray[3]
field 0x7574b7b8 mObservers
field 0x75941be0 mObservers
(gdb) call debug_type_differences (0x7574c150, 0x75964dc8)
Hashes differ.
Because the array types have different size:
unit size
align 64 symtab 0 alias set -1 canonical type 0x7574c0a8
fields
ignored BLK file tc/nsCopySupport.3.ii line 2745 col 25 size
unit size
align 64 offset_align 128
offset
bit offset context
>>
needs-constructing BLK
size constant 384>
unit size
constant 48>
align 64 symtab 0 alias set -1 canonical type 0x7574c150
domain
unit size
align 64 symtab 0 alias set -1 canonical type 0x77ee5000
precision 64 min max >
DI size unit size
align 64 symtab 0 alias set -1 canonical type 0x759f1930 precision
64 min max >>
unit size
align 64 symtab 0 alias set -1 canonical type 0x75b283f0
fields
ignored BLK file tc/nsContentUtils.3.3.ii line 3624 col 25 size
unit size
align 64 offset_align 128
offset
bit offset context
>>
needs-constructing BLK
size constant 576>
unit size
constant 72>
align 64 symtab 0 alias set -1 canonical type 0x75964dc8
domain
unit size
align 64 symtab 0 alias set -1 canonical type 0x77ee5000
precision 64 min max >
DI size unit size
align 64 symtab 0 alias set -1 canonical type 0x759f1930 precision
64 min max >>
because the array element types differ:
(gdb) call debug_type_differences (0x7574c0a8, 0x75b283f0)
Hashes differ.
Field types not compatible.
type 0x75749e70 struct nsAutoTObserverArray
type 0x75b28498 struct nsAutoTObserverArray
field 0x7574b850 D.11101
field 0x75b1cd10 D.2705
(gdb) call debug_type_differences (0x75749e70, 0x75b28498)
Hashes differ.
Field types not compatible.
type 0x75749f18 struct nsAutoTArray
type 0x75b28930 struct nsAutoTArray
field 0x7574b980 mArray
field 0x75b2a098 mArray
(gdb) call debug_type_differences (0x75749f18, 0x75b28930)
Hashes differ.
Different number of fields.
Type decls:
unit size
align 64 symtab 0 alias set -1 canonical type 0x75749f18
fields
ignored BLK file tc/nsCopySupport.3.ii line 2126 col 25 size
unit size
align 64 offset_align 128
offset
bit offset context
>>
public BLK file tc/nsCopySupport.3.ii line 2106 col 37
align 8>
and
unit size
align 64 symtab 0 alias set -1 canonical type 0x75b28930
fields
ignored BLK file tc/nsContentUtils.3.3.ii line 1757 col 37
size
unit size
align 64 offset_align 128
offset
bit offset context
chain >>
public BLK file tc/nsContentUtils.3.3.ii line 1757 col 37
align 8>
One type misses the protected union member (both sources are identical
though):
template class nsAutoTArray : public nsTArray {
public:
typedef nsTArray base_type;
typedef typename base_type::Header Header;
typedef typename base_type::elem_type elem_type;
nsAutoTArray() {
base_type::mHdr = reinterpret_cast(&mAutoBuf);
base_type::mHdr->mLength = 0;
base_type::mHdr->mCapacity = N;
base_type::mHdr->mIsAutoArray = 1;
do {
}
while (0) ;
}
protected:
union {
char mAutoBuf[sizeof(Header) + N * sizeof(elem_type)];
PRUint64 dummy;
};
};
One source misses the specialization for N == 0 (maybe an error of my
reduction though).
template class nsAutoTArray : public nsTArray {
public:
nsAutoTArray() {
}
};
most definitely. :/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44894
[Bug testsuite/44898] The guality testsuite has system-load dependent results
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-10 11:26 --- gcc 4.5+ requires gdb 7.0+, so I'd say this is a user error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44898
[Bug lto/44894] bogus warning: Use of type �struct nsNodeInfoManager� with two mismatching declarations at field �mDocument� [enabled by default]
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-10 12:10 --- On the unreduced testcase: struct PLHashTable Hashes differ. Field names do not compare equal. field 0x75651da8 allocPool field 0x753beed8 allocPriv both PLHashTables declared at ../../../dist/include/plhash.h line 80 col 8 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44894
[Bug libstdc++/44902] New: eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language l
gcc 4.6.0 20100709 trunk + newlib 1.18 HEAD (as cygnus build) configured as: configure --target=arm-unknown-eabi --prefix=/home/joty/projects/gccsdk/riscos7/cross --with-gmp=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-mpfr=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --with-mpc=/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/installed-libs-for-cross-gcc --disable-threads --disable-multilib --disable-shared --with-newlib --with-pkgversion=GCCSDK GCC 4.6trunk Release 1 Development --with-bugurl=http://gccsdk.riscos.info/ --enable-maintainer-mode --enable-interwork --disable-nls --enable-checking=no --enable-languages=c,c++ Compiled with: GNU C version 4.4.3, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 results in: libtool: compile: /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc/xgcc -shared-libgcc -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/./gcc -nostdinc++ -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/src -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/src/.libs -nostdinc -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/ -isystem /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/newlib/targ-include -isystem /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/newlib/libc/include -B/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/arm -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libgloss/libnosys -L/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libgloss/arm -B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/bin/ -B/home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/lib/ -isystem /home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/include -isystem /home/joty/projects/gccsdk/riscos7/cross/arm-unknown-eabi/sys-include -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/../gcc -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/include/arm-unknown-eabi -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/include -I/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/eh_arm.cc -o eh_arm.o /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/eh_arm.cc: In function '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)': /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage [-Werror] /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/unwind-cxx.h:199:17: error: conflicts with previous declaration 'bool __cxxabiv1::__cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' [-Werror] /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/eh_arm.cc: In function 'bool __cxa_begin_cleanup(_Unwind_Control_Block*)': /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/eh_arm.cc:96:49: error: declaration of 'bool __cxa_begin_cleanup(_Unwind_Control_Block*)' with C language linkage [-Werror] /home/joty/projects/gccsdk/gccsdk_svn7/gcc4/srcdir/gcc/libstdc++-v3/libsupc++/unwind-cxx.h:201:17: error: conflicts with previous declaration 'void __cxxabiv1::__cxa_begin_cleanup(_Unwind_Control_Block*)' [-Werror] cc1plus: all warnings being treated as errors make[6]: *** [eh_arm.lo] Error 1 make[6]: Leaving directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3/libsupc++' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc/arm-unknown-eabi/libstdc++-v3' make[3]: *** [all-target-libstdc++-v3] Error 2 make[3]: Leaving directory `/home/joty/projects/gccsdk/gccsdk_svn7/gcc4/builddir/cross-gcc' make[2]: *** [all] Error 2 -- Summary: eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage [-Werror] Produc
[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.6 Regression] -fcompare- |[4.6 Regression] -fcompare- |debug failure for C++ i386.c|debug failure for tree- ||predcom.c Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44901
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #17 from pault at gcc dot gnu dot org 2010-07-10 14:57 --- Subject: Bug 44773 Author: pault Date: Sat Jul 10 14:57:25 2010 New Revision: 162038 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162038 Log: 2010-07-10 Paul Thomas PR fortran/44773 * trans-expr.c (arrayfunc_assign_needs_temporary): No temporary if the lhs has never been host associated, as well as not being use associated, a pointer or a target. * resolve.c (resolve_variable): Mark variables that are host associated. * gfortran.h: Add the host_assoc bit to the symbol_attribute structure. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug c++/44900] The variable of SSE will be broken
--- Comment #1 from yottui at yahoo dot co dot jp 2010-07-10 15:12 ---
Also, I reproduced it on gcc45 of MacPorts 1.9.1 with '-O -m32 -msse' compiler
options.
At that time, I modified errno of the test code.
--- test.old.cpp2010-07-10 23:27:22.0 +0900
+++ test.new.cpp2010-07-10 23:32:57.0 +0900
@@ -48,7 +48,7 @@
};
extern "C" {
-int* _errno(void);
+extern int errno;
int printf (const char*, ...);
}
@@ -58,9 +58,9 @@
if ( !is_succeed )
{
printf("error: %s(%d)\n", file_name, line_num);
-if ( *_errno() ) // LINE_A
+if ( errno ) // LINE_A
{
-printf("errno: %d\n", *_errno());
+printf("errno: %d\n", errno);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test
Wrong code is generated causing bus error in test(gdb):
(gdb) r
Program received signal SIGBUS, Bus error.
0x2b48 in bar ()
(gdb) disass
Dump of assembler code for function bar:
0x2b40 <+0>: addil L%-800,dp,r1
0x2b44 <+4>: ldo 780(r1),r1
=> 0x2b48 <+8>: ldw 1(r1),ret0
0x2b4c <+12>:extrw,u ret0,15,16,r19
0x2b50 <+16>:sth r19,2(r1)
0x2b54 <+20>:sth ret0,4(r1)
0x2b58 <+24>:ldi 2e,ret0
0x2b5c <+28>:bv r0(rp)
0x2b60 <+32>:stb ret0,1(r1)
Register r1 points to str which has 4-byte alignment. So,
the memory address for the ldw instruction is misaligned.
The test would also fail on linux if the unaligned handler
was disabled.
We have the following for function bar after coalescing:
bar ()
{
unsigned int D.1980;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
D.1980_3 = MEM[(char * {ref-all})&str + 1B];
MEM[(char * {ref-all})&str + 2B] = D.1980_3;
str[1] = 46;
return;
# SUCC: EXIT [100.0%]
}
--
Summary: FAIL: gcc.dg/pr35258.c execution test
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa*-*-hpux*
GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug lto/44904] New: Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla
These seems to be last kind of warnings I can not debug in Mozilla. Might be bogus but I don't see how. Honza j...@evans:/abuild/jh/mozilla-central/build10/layout/style> /abuild/jh/trunk-install/bin/g++ -O2 -flto -r -nostdlib tc/*.ii ../../../layout/style/nsCSSStyleRule.cpp: In member function ?DOMCSSStyleRuleImpl* DOMCSSDeclarationImpl::DomRule()?: ../../../layout/style/nsCSSStyleRule.cpp:1037:53: warning: invalid access to non-static data member ?DOMCSSStyleRuleImpl::mDOMDeclaration? of NULL object [-Winvalid-offsetof] ../../../layout/style/nsCSSStyleRule.cpp:1037:53: warning: (perhaps the ?offsetof? macro was used incorrectly) [-Winvalid-offsetof] In file included from ../../../layout/style/nsCSSRuleProcessor.h:52:0, from ../../../layout/style/nsCSSStyleSheet.cpp:48: ../../../layout/style/nsCSSRules.h: In member function ?nsCSSFontFaceRule* nsCSSFontFaceStyleDecl::ContainingRule()?: ../../../layout/style/nsCSSRules.h:292:77: warning: invalid access to non-static data member ?nsCSSFontFaceRule::mDecl? of NULL object [-Winvalid-offsetof] ../../../layout/style/nsCSSRules.h:292:77: warning: (perhaps the ?offsetof? macro was used incorrectly) [-Winvalid-offsetof] ../../../layout/style/nsCSSRules.h: In member function ?const nsCSSFontFaceRule* nsCSSFontFaceStyleDecl::ContainingRule() const?: ../../../layout/style/nsCSSRules.h:299:83: warning: invalid access to non-static data member ?nsCSSFontFaceRule::mDecl? of NULL object [-Winvalid-offsetof] ../../../layout/style/nsCSSRules.h:299:83: warning: (perhaps the ?offsetof? macro was used incorrectly) [-Winvalid-offsetof] In member function ?__base_ctor ?: ../../../layout/style/nsCSSStyleSheet.cpp:1001:23: warning: Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? [enabled by default] ../../../layout/style/nsCSSStyleSheet.h:128:7: note: original type declared here ../../../layout/style/nsCSSStyleSheet.h:294:41: note: field in mismatching type declared here In member function ?__base_ctor ?: ../../../layout/style/nsCSSStyleSheet.cpp:981:23: warning: Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? [enabled by default] ../../../layout/style/nsCSSStyleSheet.h:128:7: note: original type declared here ../../../layout/style/nsCSSStyleSheet.h:294:41: note: field in mismatching type declared here In member function ?__base_dtor ?: ../../../layout/style/nsCSSStyleSheet.cpp:1044:3: warning: Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? [enabled by default] ../../../layout/style/nsCSSStyleSheet.h:128:7: note: original type declared here ../../../layout/style/nsCSSStyleSheet.h:294:41: note: field in mismatching type declared here ../../../layout/style/nsCSSStyleSheet.cpp:1046:27: warning: Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? [enabled by default] ../../../layout/style/nsCSSStyleSheet.h:128:7: note: original type declared here ../../../layout/style/nsCSSStyleSheet.h:294:41: note: field in mismatching type declared here -- Summary: Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44904
[Bug lto/44904] Maybe bogus Use of type ?struct nsCSSStyleSheet? with two mismatching declarations at field ?mRuleProcessors? warnings in Mozilla
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-10 15:24 --- Created an attachment (id=21175) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21175&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44904
[Bug rtl-optimization/44659] Combiner fails to match QI cmp patterns with upper 8bit register
--- Comment #6 from hjl at gcc dot gnu dot org 2010-07-10 15:35 --- Subject: Bug 44659 Author: hjl Date: Sat Jul 10 15:35:04 2010 New Revision: 162040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162040 Log: Fix combine to match QI cmp patterns with upper 8bit register. gcc/ 2010-07-09 H.J. Lu Backport from mainline 2010-06-29 Eric Botcazou PR rtl-optimization/44659 * combine.c (make_compound_operation) : Do not return the result of force_to_mode if it partially re-expanded the compound. gcc/testsuite/ 2010-07-09 H.J. Lu Backport from mainline 2010-06-29 H.J. Lu PR rtl-optimization/44659 * gcc.target/i386/extract-1.c: New. * gcc.target/i386/extract-2.c: Likewise. * gcc.target/i386/extract-3.c: Likewise. * gcc.target/i386/extract-4.c: Likewise. * gcc.target/i386/extract-5.c: Likewise. * gcc.target/i386/extract-6.c: Likewise. Added: branches/ix86/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/extract-1.c branches/ix86/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/extract-2.c branches/ix86/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/extract-3.c branches/ix86/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/extract-4.c branches/ix86/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/extract-5.c branches/ix86/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/extract-6.c Modified: branches/ix86/gcc-4_5-branch/gcc/ChangeLog.ix86 branches/ix86/gcc-4_5-branch/gcc/combine.c branches/ix86/gcc-4_5-branch/gcc/testsuite/ChangeLog.ix86 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-10 15:37 --- It is caused by revision 161862: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00216.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||froydnj at codesourcery dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-10 15:37:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44901
[Bug bootstrap/44905] New: --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c
With the proposed fix for building gcc trunk with --enable-build-with-cxx on darwin applied... 2009-10-02 Jack Howarth PR target/44862 * Makefile.tpl (POSTSTAGE1_CXX_EXPORT): Provide -B option to allow for link spec %s substitutions for libstdc++.a on darwin. * Makefile.in: Regenerate. Index: Makefile.tpl === --- Makefile.tpl(revision 162037) +++ Makefile.tpl(working copy) @@ -238,6 +238,7 @@ POSTSTAGE1_CXX_EXPORT = \ CXX="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/g++$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \ + -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \ -I$$s/libstdc++-v3/libsupc++ \ a new bootstrap failure is exposed... /Users/howarth/work/./prev-gcc/g++ -B/Users/howarth/work/./prev-gcc/ -B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -nostdinc++ -B/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/src/.libs -I/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/include/x86_64-apple-darwin10.4.0 -I/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/include -I/Users/howarth/gcc/libstdc++-v3/libsupc++ -L/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/src/.libs -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/sw/include -I/sw/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -I/sw/include -DCLOOG_PPL_BACKEND -I/sw/include \ -DGCC_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/include\" -DFIXED_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/include-fixed\" -DGPLUSPLUS_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../include/c++/4.6.0\" -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../include/c++/4.6.0/x86_64-apple-darwin10.4.0\" -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../include/c++/4.6.0/backward\" -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" -DCROSS_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../x86_64-apple-darwin10.4.0/sys-include\" -DTOOL_INCLUDE_DIR=\"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../x86_64-apple-darwin10.4.0/include\" -DPREFIX=\"/Users/howarth/dist/\" -DSTANDARD_EXEC_PREFIX=\"/Users/howarth/dist/lib/gcc/\" \ -c ../../gcc/gcc/cppdefault.c -o cppdefault.o In file included from ../../gcc/gcc/config/i386/i386.c:31581:0: ../../gcc/gcc/config/i386/i386.c: In function tree_node* ix86_vectorize_builtin_vec_perm(tree, tree_node**): ../../gcc/gcc/config/i386/i386.c:30005:30: error: fcode is used uninitialized in this function [-Werror=uninitialized] The workaround suggested by Iain Sandoe of... Index: gcc/config/i386/i386.c === --- gcc/config/i386/i386.c (revision 162037) +++ gcc/config/i386/i386.c (working copy) @@ -30002,7 +30002,7 @@ tree itype = TREE_TYPE (vec_type); bool u = TYPE_UNSIGNED (itype); enum machine_mode vmode = TYPE_MODE (vec_type); - enum ix86_builtins fcode = fcode; /* Silence bogus warning. */ + enum ix86_builtins fcode = IX86_BUILTIN_MAX; bool ok = TARGET_SSE2; switch (vmode) eliminates the bootstrap failure on x86_64-apple-darwin10. -- Summary: --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44905
[Bug c++/44906] New: g++ is giving error: parse error in template argument list while using a c++ code.
amita...@whileliesent-lm:~/data/prog/c++/template_ptr$g++ -v -o template
template.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-o' 'template' '-shared-libgcc' '-mtune=generic'
'-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -quiet -v -D_GNU_SOURCE template.cpp
-D_FORTIFY_SOURCE=2 -quiet -dumpbase template.cpp -mtune=generic -march=i486
-auxbase template -version -fstack-protector -o /tmp/ccZiqQ9b.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/i486-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 35224f2c24023afb0a5be7befe8d5f3f
template.cpp: In member function void MISC::add(int):
template.cpp:55: error: parse error in template argument list
template.cpp:58: error: parse error in template argument list
template.cpp:61: error: parse error in template argument list
template.cpp:64: error: parse error in template argument list
template.cpp: In member function void MISC::print(int):
template.cpp:72: error: parse error in template argument list
template.cpp:75: error: parse error in template argument list
template.cpp:78: error: parse error in template argument list
template.cpp:81: error: parse error in template argument list
Following is the content of template.cpp (please let me know whats wrong with
the following program):
#include
#include
#include
#include
using namespace std;
template
class MISC{
private:
vector vec1;
vector vec2;
set st1;
set st2;
vector *ptr;
private:
template* vc>
void addVecVals(){
for(T i=0; i<10;i++)
{
vc->push_back(i);
}
}
template* st>
void addStVals(){
for(T i=0; i<10;i++)
{
st->insert(i);
}
}
template* vc>
void printVecVals(){
for(typename vector::iterator i=vc->begin(),
j=vc->end(); i!=j;++i)
{
cout<<"val = "<<*i<<" , ";
}
}
template* st>
void printStVals(){
for(typename set::iterator i=st->begin(),
j=st->end(); i!=j;++i)
{
cout<<"val = "<<*i<<" , ";
}
}
public:
void add(int vecNum) {
switch(vecNum) {
case 0: //vecs.
addVecVals<&vec1>();
break;
case 1:
addVecVals<&vec2>();
break;
case 2: //sets
addStVals<&st1>();
break;
c
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
--- Comment #1 from raychaudhuri_amitava at yahoo dot com 2010-07-10 15:44 --- Created an attachment (id=21176) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21176&action=view) Code which is failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
--- Comment #2 from raychaudhuri_amitava at yahoo dot com 2010-07-10 15:44 --- Created an attachment (id=21177) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21177&action=view) .s file generated by -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
--- Comment #3 from raychaudhuri_amitava at yahoo dot com 2010-07-10 15:45 --- Created an attachment (id=21178) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21178&action=view) .ii file generated by -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #2 from iains at gcc dot gnu dot org 2010-07-10 16:43 --- is this still current? I can't reproduce any compile problems on arm-unknown-eabi or armel-unknown-gnueabi (as cross-tools hosted under i686-apple-darwin). -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #11 from pault at gcc dot gnu dot org 2010-07-10 16:46 --- (In reply to comment #10) > Note that I did not apply the patch to 4.4 as I said that I would. What do > you > think? 4.4 is sufficiently different from 4.5/6 that I am closing this as fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #20 from pault at gcc dot gnu dot org 2010-07-10 17:09 --- Subject: Bug 44582 Author: pault Date: Sat Jul 10 17:08:48 2010 New Revision: 162041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162041 Log: 2010-07-10 Paul Thomas PR fortran/44582 * trans-expr.c (arrayfunc_assign_needs_temporary): New function to determine if a function assignment can be made without a temporary. (gfc_trans_arrayfunc_assign): Move all the conditions that suppress the direct function call to the above new functon and call it. PR fortran/44773 * trans-expr.c (arrayfunc_assign_needs_temporary): No temporary if the lhs has never been host associated, as well as not being use associated, a pointer or a target. * resolve.c (resolve_variable): Mark variables that are host associated. * gfortran.h: Add the host_assoc bit to the symbol_attribute structure. 2010-07-10 Paul Thomas PR fortran/44582 * gfortran.dg/aliasing_array_result_1.f90 : New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/aliasing_array_result_1.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/gfortran.h branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/fortran/trans-expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #18 from pault at gcc dot gnu dot org 2010-07-10 17:09 --- Subject: Bug 44773 Author: pault Date: Sat Jul 10 17:08:48 2010 New Revision: 162041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162041 Log: 2010-07-10 Paul Thomas PR fortran/44582 * trans-expr.c (arrayfunc_assign_needs_temporary): New function to determine if a function assignment can be made without a temporary. (gfc_trans_arrayfunc_assign): Move all the conditions that suppress the direct function call to the above new functon and call it. PR fortran/44773 * trans-expr.c (arrayfunc_assign_needs_temporary): No temporary if the lhs has never been host associated, as well as not being use associated, a pointer or a target. * resolve.c (resolve_variable): Mark variables that are host associated. * gfortran.h: Add the host_assoc bit to the symbol_attribute structure. 2010-07-10 Paul Thomas PR fortran/44582 * gfortran.dg/aliasing_array_result_1.f90 : New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/aliasing_array_result_1.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/gfortran.h branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/fortran/trans-expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-10 17:46 --- The error message is not clear. The issue is that you are not using a constant expression for a template arugment. Template arguments are either constant expressions or types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-07-10 18:20 --- (In reply to comment #2) > is this still current? > I can't reproduce any compile problems on arm-unknown-eabi or > armel-unknown-gnueabi (as cross-tools hosted under i686-apple-darwin). You might have fixed them when you fixed the LTO issues :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug middle-end/42505] [4.4/4.5/4.6 Regression] loop canonicalization causes a lot of unnecessary temporary variables
--- Comment #12 from sandra at gcc dot gnu dot org 2010-07-10 18:43 --- Subject: Bug 42505 Author: sandra Date: Sat Jul 10 18:43:29 2010 New Revision: 162043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162043 Log: 2010-07-10 Sandra Loosemore PR middle-end/42505 gcc/ * tree-inline.c (estimate_num_insns): Refactor builtin complexity lookup code into * builtins.c (is_simple_builtin, is_inexpensive_builtin): ...these new functions. * tree.h (is_simple_builtin, is_inexpensive_builtin): Declare. * cfgloopanal.c (target_clobbered_regs): Define. (init_set_costs): Initialize target_clobbered_regs. (estimate_reg_pressure_cost): Add call_p argument. When true, adjust the number of available registers to exclude the call-clobbered registers. * cfgloop.h (target_clobbered_regs): Declare. (estimate_reg_pressure_cost): Adjust declaration. * tree-ssa-loop-ivopts.c (struct ivopts_data): Add body_includes_call. (ivopts_global_cost_for_size): Pass it to estimate_reg_pressure_cost. (determine_set_costs): Dump target_clobbered_regs. (loop_body_includes_call): New function. (tree_ssa_iv_optimize_loop): Use it to initialize new field. * loop-invariant.c (gain_for_invariant): Adjust arguments to pass call_p flag through. (best_gain_for_invariant): Likewise. (find_invariants_to_move): Likewise. (move_single_loop_invariants): Likewise, using already-computed has_call field. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/cfgloop.h trunk/gcc/cfgloopanal.c trunk/gcc/loop-invariant.c trunk/gcc/tree-inline.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
--- Comment #5 from raychaudhuri_amitava at yahoo dot com 2010-07-10 18:45 --- (In reply to comment #4) > The error message is not clear. The issue is that you are not using a > constant > expression for a template arugment. Template arguments are either constant > expressions or types. > Whenever I will be using this kind of template in a class, the variable name is predefined. Now when I create an object and call the function, it will get the address offset and thus should be able to create an instance of that function with same prototype but different body, else for such cases we have to create different functions for each member. Can it be a new feature in g++ compiler? This will make function and objects as first class citizen in C++. We can create function at runtime with different object embedded in it. (I know it can be done by #define, but this is a better way I think.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #4 from mikpe at it dot uu dot se 2010-07-10 18:49 --- The issue is still very much there with 4.[456] on arm-linux-gnueabi, see e.g. the test results I post. In my 4.4 production compiler I apply Ramana's fix, and it eliminates all objc test failures for me. Haven't checked how it fares with 4.5 yet (I forgot that it was only a proposed fix and not a backport from trunk). -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #5 from iains at gcc dot gnu dot org 2010-07-10 19:40 --- I do not see the fails shown in: http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00563.html with my current tree [162035] - but I'm using simulator combined tree build - with glibc from a Debian distribution (I forget which, but can check if it's important). -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know why it fixed them ... ).. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug tree-optimization/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2010-07-10 19:46 --- Introduced in revision 161655. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Summary|FAIL: gcc.dg/pr35258.c |[4.6 Regression] FAIL: |execution test |gcc.dg/pr35258.c execution ||test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #24 from iains at gcc dot gnu dot org 2010-07-10 19:48 --- AFAIK this has been cleared for some time now. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug c++/44907] New: SFINAE vs ambiguous base (the real one ;)
OK, this time is for real. I have almost ready a library-only is_convertible
which purely uses SFINAE and noticed that apparently we have a remaining issue
with ambiguous bases, not fixed by your recent patch. The testcase goes like
this, I already checked that ICC likes it:
// #include
struct A { };
struct B
: A { };
struct C
: A { };
struct D
: B, C { };
template struct enable_if { typedef T type; };
template struct enable_if { };
template
class mini_is_convertible
{
typedef char one;
typedef struct { char arr[2]; } two;
template
static void test_aux(To1);
template
// static decltype(test_aux(std::declval()), one())
static typename
enable_if<(sizeof(test_aux(From1()), 1) > 0), one>::type
test(int);
template
static two test(...);
public:
static const bool value = sizeof(test(0)) == 1;
};
int main()
{
mini_is_convertible::value; // compiles with 4.6 (false)
mini_is_convertible::value; // does not compile (ok with ICC (false))
}
I would suggest double-checking the C++0x version too, using decltype and, more
correctly, declval.
--
Summary: SFINAE vs ambiguous base (the real one ;)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44907
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-10 20:20 --- ARM maintainers, could you please help me triaging this? Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||richard dot earnshaw at arm ||dot com, nickc at redhat dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
--- Comment #11 from sandra at codesourcery dot com 2010-07-10 21:07
---
I just checked to see if this is still a problem. As of r162042, the example
in comment #1 produces the same (bad) output as GCC 4.4.1. However, the example
in comment #4 looks fixed to me, with this output:
test:
push{r0, r1, r2, lr}
mov r3, #0
str r3, [sp, #4]
.L2:
add r0, sp, #4
bl func
ldr r3, [sp, #4]
cmp r3, #12
ble .L2
@ sp needed for prologue
pop {r0, r1, r2, pc}
As it was the latter test case that caused this to be marked as a duplicate of
PR 36758, maybe the original test case is tripping over a different problem and
needs to be re-examined?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #4 from mikpe at it dot uu dot se 2010-07-10 21:10 --- This is fixed on trunk since r161797. However, this is now a 4.5 regression. A patch to backport the fix to 4.5 has been posted: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00877.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-10 21:29 --- I get for all memory accesses an alignment of 8 at expansion time which looks correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos looks conservative enough. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|tree-optimization |target Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-10 21:38 --- Subject: Bug 44325 Author: rguenth Date: Sat Jul 10 21:38:32 2010 New Revision: 162044 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162044 Log: 2010-07-10 Mikael Pettersson PR testsuite/44325 Backport from mainline 2010-07-04 Ira Rosen Revital Eres * gcc.dg/vect/vect-109.c: Expect vectorization only on targets that support misaligned stores. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-109.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-10 21:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-07-10 21:44 --- This still looks broken. Under a normal bootstrap, on x86_64-apple-darwin10, these new testcases are silently executed against the system compiler rather than the newly built compiler... Executing on build: gcc -g -O2 /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100709/gcc/testsuite/g++.dg/plugin/attribute_plugin.c -I. -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100709/gcc/testsuite -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100709/gcc/testsuite/../../gcc -I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../../gcc -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100709/gcc/testsuite/../../include -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100709/gcc/testsuite/../../libcpp/include -I/sw/include -I/sw/include -DIN_GCC -fPIC -shared -undefined dynamic_lookup -o attribute_plugin.so(timeout = 300) When using a --enable-build-with-cxx bootstrap on x86_64-apple-darwin10, this exposed with actual testcase failures... Executing on build: g++ -g -O2 /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c -I. -I/Users/howarth/gcc/gcc/testsuite -I/Users/howarth/gcc/gcc/testsuite/../../gcc -I/Users/howarth/work/gcc/testsuite/g++/../../../gcc -I/Users/howarth/gcc/gcc/testsuite/../../include -I/Users/howarth/gcc/gcc/testsuite/../../libcpp/include -I/sw/include -I/sw/include -DIN_GCC -fPIC -shared -undefined dynamic_lookup -o attribute_plugin.so(timeout = 300) /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c: In function 'void register_attributes(void*, void*)':^M /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c:35: error: 'warning' was not declared in this scope^M /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c: In function 'void handle_pre_generic(void*, void*)':^M /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c:55: error: 'warning' was not declared in this scope^M -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug c++/44908] New: SFINAE vs pointer to member via virtual base
This is another case where we have a compile-time errors (Ok with ICC). Note,
with swapped From and To types compiles.
struct A { };
struct E
: virtual A { };
template struct enable_if { typedef T type; };
template struct enable_if { };
template
class mini_is_convertible
{
typedef char one;
typedef struct { char arr[2]; } two;
template
static void test_aux(To1);
template
// static decltype(test_aux(std::declval()), one())
static typename
enable_if<(sizeof(test_aux(From1()), 1) > 0), one>::type
test(int);
template
static two test(...);
public:
static const bool value = sizeof(test(0)) == 1;
};
int main()
{
mini_is_convertible::value; // compiles
mini_is_convertible::value; // compiles
mini_is_convertible::value; // doesn't
mini_is_convertible::value; // doesn't
}
--
Summary: SFINAE vs pointer to member via virtual base
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44908
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
--- Comment #6 from paolo dot carlini at oracle dot com 2010-07-10 22:19 --- Honestly, nothing similar will happen any time soon, it means changing completely the semantics of templates. Maybe we can produce a better diagnostics, let's add Manuel in CC to hear his opinion... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||manu at gcc dot gnu dot org Severity|major |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-10
23:34 ---
Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c
execution test
On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote:
> I get for all memory accesses an alignment of 8 at expansion time which looks
> correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos
> looks conservative enough.
The rtl in question is the following:
(insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI
28 %r28 [orig:94 D.1980 ] [94])
(mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95])
(const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str +
1B]+0 S4 A8])) 37 {*pa.md:2102} (nil))
An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets
that define STRICT_ALIGNMENT. We need an alignment of 32.
I believe the i?86 hardware allows unaligned addresses, so you wouldn't
see the problem.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #13 from iains at gcc dot gnu dot org 2010-07-11 00:25 --- this is still present, AFAICT, for *-*-darwin* at r162047. Honza, since it was your patch that triggered this, any ideas on what we could do to debug/solve this one? in particular this; "error: Inline clone with address taken " is still happening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-07-11 01:01 --- (In reply to comment #7) > Created an attachment (id=21173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21173&action=view) [edit] ... > let me know if it solve that aspect of the problem for you. Yes, it does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug tree-optimization/39839] [4.3/4.4/4.5/4.6 regression] loop invariant motion causes stack spill
--- Comment #13 from sandra at codesourcery dot com 2010-07-11 01:22 --- Some further analysis: The part of my PR42505 patch that made the difference was the change to estimate_register_pressure_cost in cfgloopanal.c, to make it exclude the call-clobbered registers. This part was finally committed separately in a revised version as r162043. I'm still looking into what to do about the test case and 4.5 backport. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39839
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-11 01:58 --- (In reply to comment #6) > This still looks broken. Under a normal bootstrap, on x86_64-apple-darwin10, > these new testcases are silently executed against the system compiler rather > than the newly built compiler... I see. We really should be using the same BUILD->HOST compiler that was used to build the last stage of the build. In the case of a native bootstrap (assuming stage2/3 comparison succeeded), that should be interchangeable with the newly built compiler. Feel free to re-open the PR; I have no plans to work on it, though. > /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c: In function > 'void register_attributes(void*, void*)':^M > /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c:35: error: > 'warning' was not declared in this scope^M > /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c: In function > 'void handle_pre_generic(void*, void*)':^M > /Users/howarth/gcc/gcc/testsuite/g++.dg/plugin/attribute_plugin.c:55: error: > 'warning' was not declared in this scope^M Looking at the source makes me wonder why it succeeds elsewhere. It should be including diagnostic.h or disgnostic-core.h to get a declaration for warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-07-11 02:36 --- Perhaps we just need something like... Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 162051) +++ gcc/Makefile.in (working copy) @@ -330,12 +330,15 @@ LTO_BINARY_READER = @LTO_BINARY_READER@ LTO_USE_LIBELF = @LTO_USE_LIBELF@ -# Compiler needed for plugin support -PLUGINCC = $(COMPILER) +# Compiler and flags needed for plugin support +ifneq ($(ENABLE_BUILD_WITH_CXX),yes) +PLUGINCC = $(CC) +PLUGINCFLAGS = $(CFLAGS) +else +PLUGINCC = $(CXX) +PLUGINCFLAGS = $(CXXFLAGS) +endif -# Flags needed for plugin support -PLUGINCFLAGS = $(COMPILER_FLAGS) - # Libs and linker options needed for plugin support PLUGINLIBS = @pluginlibs@ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #9 from amylaar at gcc dot gnu dot org 2010-07-11 04:22 --- (In reply to comment #8) > Perhaps we just need something like... No, COMPILER uses CC, too. The issue is the the toplevel Makefile check-gcc rule forces CC in the gcc/Makefile via EXTRA_HOST_FLAGS In the native boostrap case, you probably want CC_FOR_TARGET / CFLAGS_FOR_TARGET / CXX_FOR_TARGET / CXXFLAGS_FOR_TARGET, but you still need COMPILER COMPILER_FLAGS (or its equivalent) in the case of non-bootstrap builds (native or otherwise). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #14 from dominiq at lps dot ens dot fr 2010-07-11 04:58 --- *** Bug 44590 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug c++/44590] [4.6 Regression] Revision 159362 caused multiple failures on the libstdc++-v3 tests
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-11 04:58 --- *** This bug has been marked as a duplicate of 44121 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44590
[Bug tree-optimization/43567] linear loop transform
--- Comment #4 from tjvries at xs4all dot nl 2010-07-11 06:10 --- submitted patch for review: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00879.html -- tjvries at xs4all dot nl changed: What|Removed |Added CC||tjvries at xs4all dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43567
