[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #7 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-04-20 06:48:39 UTC ---
I'm pretty sure that this is not related with functional, but instead with
some interaction between the tuple header and std::is_convertible. The
following variant still demonstrates the problem (I deliberately changed some
of the original names used in the code to be sure that they are not cause of
the problem):
#include tuple
templatebool, class T
struct enable_if
{
typedef T type;
};
template bool...
struct Bs
{
static const bool value = true;
};
template typename... Ts
struct AType {
template typename... Us,
typename enable_if
Bsstd::is_convertibleUs, Ts::value...::value,
bool::type = false
int foo(Us...)
{
return sizeof...(Us);
}
};
int main() {
ATypeint, int t;
return t.foo(1, 1);
}
(You can also add type_traits, but it is already added via tuple). If we
now add upfront
template class, class
struct is_convertible
{
static const bool value = true;
};
and replace the usage of std::is_convertible by is_convertible, the error does
no longer occur.
[Bug go/52586] libgo fails to build for mips*64-linux-gnu (reference to undefined name 'SYS_GETDENTS64')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52586 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-20 07:48:52 UTC --- Fails still as of today: /home/apinski/src/gcc-fsf/local/gcc/libgo/go/syscall/libcall_linux.go:206:26: error: reference to undefined name 'SYS_GETDENTS64' r1, _, errno := Syscall(SYS_GETDENTS64, uintptr(fd), uintptr(unsafe.Pointer(p)), uintptr(len(buf))) ^
[Bug go/52586] libgo fails to build for mips*64-linux-gnu (reference to undefined name 'SYS_GETDENTS64')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52586 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-20 07:52:10 UTC --- SYS_getdents64 does not exist for either N32 or N64 with the version of glibc I have.
[Bug target/43533] IRIX 6.5 bootstrap fails with GNU as and ld 2.20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43533 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-20 07:58:32 UTC --- IRIX 6.5 support was removed so closing as won't fix.
[Bug bootstrap/46776] gogo-tree.cc uses TRAMPOLINE_ALIGNMENT and TRAMPOLINE_SIZE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46776 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-20 07:59:30 UTC --- Yes it was fixed.
[Bug libfortran/53051] I/O: Support reading floating-point numbers which use Q for the exponent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-20 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org 2012-04-20 08:21:05 UTC --- The argument against supporting this, I suppose, is that we never generate a Q|q exponent on output. As a result, the example in c.l.f doesn't try to parse something that was previously written by formatting a floating point number, but rather a hand-crafted string. IOW, it seems rather artificial. That being said, it seems ifort supports it, so maybe we need to as well.. *sigh*.
[Bug libstdc++/53052] New: [C++11] is_explicitly_convertible still part of type_traits header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53052 Bug #: 53052 Summary: [C++11] is_explicitly_convertible still part of type_traits header Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com With the acceptance of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3047.html the previously suggested type trait std::is_explicitly_convertible had been removed from the standard library. This component is still part of the library header type_traits and should be removed or renamed to something in the extension name-space, presumably std::__is_explicitly_convertible.
[Bug libstdc++/53052] [C++11] is_explicitly_convertible still part of type_traits header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53052 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-20 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-20 09:01:29 UTC --- Sure, sure, let's remove it. I'm leaving in for now some has_trivial_* things, I don't know if you noticed already, will go as soon as I find the time to work on the front-end support to has_trivial_constructor and assignment.
[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|hjl.tools at gmail dot com | --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-20 09:06:30 UTC --- Thanks Daniel. If you feel like helping even more here, I would suggest having a look to the output of g++ -E and check that we aren't goofing something in terms of include guards, double inclusions, these kinds of stupid errors which often lean to very poor diagnostics, unfortunately. That done, I can only imagine a front-end issue.
[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-20 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 09:14:14 UTC --- I have a patch.
[Bug c/53053] New: code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053
Bug #: 53053
Summary: code-gen (missing loop-termination test) bug
introduced between April 18 and April 19th
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net
Background, gcc-compiled emacs (bzr trunk) began to segfault
differently when compiled with yesterday's gcc-trunk.
Given this function from emacs' dispnew.c,
(LAST_AREA is an enum with value 3)
static __attribute__((noinline)) void
swap_glyph_pointers (struct glyph_row *a, struct glyph_row *b)
{
unsigned int i;
unsigned hash_tem = a-hash;
for (i = 0; i LAST_AREA + 1; ++i)
{
struct glyph *temp = a-glyphs[i];
short used_tem = a-used[i];
a-glyphs[i] = b-glyphs[i];
b-glyphs[i] = temp;
a-used[i] = b-used[i];
b-used[i] = used_tem;
}
a-hash = b-hash;
b-hash = hash_tem;
}
*** FAILURE: using yesterday's gcc
Compiling dispnew with -O1 or less there is no problem.
Compiling just dispnew.c with -O2 (all the rest is compiled with -ggdb3)
via make CFLAGS='-O2 -ggdb3' CC=/p/p/gcc-2012-04-19.16h18/bin/gcc
* currently-generated code, i increases until segfault:
0120 swap_glyph_pointers:
120:31 c0xor%eax,%eax
122:66 0f 1f 44 00 00nopw 0x0(%rax,%rax,1)
128:48 8b 0c 87 mov(%rdi,%rax,4),%rcx
12c:4c 8b 04 86 mov(%rsi,%rax,4),%r8
130:0f b7 54 07 20 movzwl 0x20(%rdi,%rax,1),%edx
135:4c 89 04 87 mov%r8,(%rdi,%rax,4)
139:48 89 0c 86 mov%rcx,(%rsi,%rax,4)
13d:0f b7 4c 06 20 movzwl 0x20(%rsi,%rax,1),%ecx
142:66 89 4c 07 20 mov%cx,0x20(%rdi,%rax,1)
147:66 89 54 06 20 mov%dx,0x20(%rsi,%rax,1)
14c:48 83 c0 02 add$0x2,%rax
150:eb d6jmp128 swap_glyph_pointers+0x8
152:66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
159:1f 84 00 00 00 00 00
*** SUCCESS: using gcc from Wed April 18
Compiling the same file with gcc built from a snapshot a day earlier,
make CFLAGS='-O2 -ggdb3' CC=/p/p/gcc-2012-04-18.15h00/bin/gcc
* code generated by svn/trunk of gcc-2012-04-18.15h00 (UTC),
This loop terminates normally.
0120 swap_glyph_pointers:
120:44 8b 4f 4c mov0x4c(%rdi),%r9d
124:31 c0xor%eax,%eax
126:48 8b 0c 87 mov(%rdi,%rax,4),%rcx
12a:4c 8b 04 86 mov(%rsi,%rax,4),%r8
12e:0f b7 54 07 20 movzwl 0x20(%rdi,%rax,1),%edx
133:4c 89 04 87 mov%r8,(%rdi,%rax,4)
137:48 89 0c 86 mov%rcx,(%rsi,%rax,4)
13b:0f b7 4c 06 20 movzwl 0x20(%rsi,%rax,1),%ecx
140:66 89 4c 07 20 mov%cx,0x20(%rdi,%rax,1)
145:66 89 54 06 20 mov%dx,0x20(%rsi,%rax,1)
14a:48 83 c0 02 add$0x2,%rax
14e:48 83 f8 08 cmp$0x8,%rax
152:75 d2jne126 swap_glyph_pointers+0x6
154:8b 46 4c mov0x4c(%rsi),%eax
157:89 47 4c mov%eax,0x4c(%rdi)
15a:44 89 4e 4c mov%r9d,0x4c(%rsi)
15e:c3 retq
15f:90 nop
[Bug middle-end/53049] expand/TER unappropriate moving unspec volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53049
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20
09:20:44 UTC ---
It's not easy to restrict movement in this case (and no other tree transform
would bother). Consider sinking and
void test2 (unsigned val, bool flag)
{
val = 65535U / val;
__builtin_avr_cli();
if (flag)
ivar = val;
else
ivar = 0;
__builtin_avr_sei();
}
then you'd get val = 65535U / val; sunk into the if() arm beause its unused
on the else arm.
On the GIMPLE leven we don't have something like a scheduling barrier,
we only have barriers for loads/stores. A scheduling barrier would need
to be implemented by means of providing abnormal entry / exit to a basic-block,
not sure if we'd want to go that way (but this is the only way that would
make it magically work).
So - you certainly could fix TER, but that would not fix the underlying
problem of GIMPLE lacking a scheduling barrier which is what you appearantly
are after at.
[Bug middle-end/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-20 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 09:21:32 UTC --- Confirmed.
[Bug middle-end/53048] [4.8 Regression] 256.bzip2 in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53048 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/53045] Missing loop termination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53045
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20
09:23:09 UTC ---
struct { double d[1]; } foo0, foo1, foo2, foo3, foo4, foo5, foo6, foo7;
int main ()
{
struct { double d; } bar[8]
= { 48.394, 39.3, -397.9, 3484.9, -8.394, -93.3, 7.9, 84.94 };
int i;
for (i = 0; i 8; i++)
foo0.d[i] = bar[i].d;
return 0;
}
This is invalid source - foo0.d[1] is an out-of-bound access. Number of
iteration analysis correctly concludes that i is in the range of [0, 0]
and optimizes away the loop exit test.
[Bug middle-end/53047] [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53047 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/53045] Missing loop termination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53045 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 09:24:06 UTC --- Btw, see how I fixed 2012-04-18 Richard Guenther rguent...@suse.de * gcc.target/x86_64/abi/test_passing_unions.c: Avoid undefined array access. * gcc.target/x86_64/abi/test_passing_structs.c: Likewise. * gcc.target/i386/avx256-unaligned-load-4.c: Fix array sizes. I suppose I didn't see the AVX fails because my testing box doesn't have AVX.
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-20 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 09:25:46 UTC --- Seems to be similar to other existing cases. You very likely have an out-of-bound array access in your loop. No testcase.
[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 --- Comment #2 from Alan Modra amodra at gcc dot gnu.org 2012-04-20 09:33:23 UTC --- Author: amodra Date: Fri Apr 20 09:33:19 2012 New Revision: 186616 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186616 Log: PR target/53040 * config/rs6000/rs6000.c (rs6000_savres_strategy): When using static chain, set REST_INLINE_FPRS too. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug libstdc++/53052] [C++11] is_explicitly_convertible still part of type_traits header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53052 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-20 09:39:25 UTC --- Author: paolo Date: Fri Apr 20 09:39:17 2012 New Revision: 186617 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186617 Log: 2012-04-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/53052 * include/std/type_traits (is_explicitly_convertible): Remove. * testsuite/20_util/is_explicitly_convertible: Likewise. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust dg-error line numbers. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/declval/requirements/1_neg.cc: Likewise. Removed: trunk/libstdc++-v3/testsuite/20_util/is_explicitly_convertible/ Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits
[Bug libstdc++/53052] [C++11] is_explicitly_convertible still part of type_traits header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53052 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-20 09:39:41 UTC --- Author: paolo Date: Fri Apr 20 09:39:29 2012 New Revision: 186618 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186618 Log: 2012-04-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/53052 * include/std/type_traits (is_explicitly_convertible): Remove. * testsuite/20_util/is_explicitly_convertible: Likewise. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust dg-error line numbers. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/declval/requirements/1_neg.cc: Likewise. Modified: trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
[Bug libstdc++/53052] [C++11] is_explicitly_convertible still part of type_traits header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53052 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-20 09:40:47 UTC --- Done.
[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 10:17:54 UTC --- Author: rguenth Date: Fri Apr 20 10:17:46 2012 New Revision: 186620 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186620 Log: 2012-04-20 Richard Guenther rguent...@suse.de PR tree-optimization/53050 * tree-ssa-forwprop.c (ssa_forward_propagate_and_combine): Do only one transform on COND_EXPRs at the same time. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug bootstrap/53054] New: [4.8 Regression] bootstrap failure on x86-64 after rev 186609
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53054 Bug #: 53054 Summary: [4.8 Regression] bootstrap failure on x86-64 after rev 186609 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com Target: x86-64 On x86-64 bootstrap fails with gcc -c -g -fkeep-inline-functions -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 -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber ../../gcc/tree-vect-loop.c -o tree-vect-loop.o ../../gcc/symtab.c: In function ‘dump_symtab_base’: ../../gcc/symtab.c:381:19: error: ‘struct symtab_node_base’ has no member na‘force_output’ make[3]: *** [symtab.o] Error 1 make[3]: Leaving directory `/export/users/izamyati/gcc_wrf_check/build_bootstrap/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/export/users/izamyati/gcc_wrf_check/build_bootstrap' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/export/users/izamyati/gcc_wrf_check/build_bootstrap' make: *** [all] Error 2 Revision 186609 is responsible for this
[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53050 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 10:20:05 UTC --- Fixed.
[Bug bootstrap/53054] [4.8 Regression] bootstrap failure on x86-64 after rev 186609
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53054 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 10:21:01 UTC --- Just fixed by 2012-04-19 Jan Hubicka j...@suse.cz * symtab.c (dump_symtab_base): Revert accidental checkin.
[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-20
10:27:11 UTC ---
Eh, this is *not* a library issue:
#include type_traits
#if 1
templatetypename... _Elements
class tuple
{
templatetypename... _UElements, typename = typename
std::enable_ifstd::__and_std::is_convertible_UElements,
_Elements...::value::type
tuple(_UElements...);
};
#else
templatetypename _Elements
class tuple1
{
templatetypename _UElements, typename = typename
std::enable_ifstd::__and_std::is_convertible_UElements,
_Elements::value::type
tuple1(_UElements);
};
#endif
template bool...
struct Bs
{
static const bool value = true;
};
template typename... Ts
struct AType {
template typename... Us,
typename std::enable_if
Bsstd::is_convertibleUs, Ts::value...::value,
bool::type = false
int foo(Us...)
{
return sizeof...(Us);
}
};
int main() {
ATypeint, int t;
return t.foo(1, 1);
}
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053 --- Comment #2 from jim at meyering dot net 2012-04-20 10:28:35 UTC --- when I add printf (%u\n, i); before the end of the loop, it prints values up to about 128K before segfaulting.
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053 --- Comment #3 from jim at meyering dot net 2012-04-20 10:43:28 UTC --- Created attachment 27201 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27201 preprocessed source PS, gcc was built via this: CC=/usr/bin/gcc ./configure --prefix=$prefix --disable-multilib \ --disable-libmudflap --disable-nls --enable-languages=c make bootstrap
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-20 11:07:43 UTC --- So what Richard says is true. short used[LAST_AREA]; ... for (i = 0; i LAST_AREA + 1; ++i) ... short used_tem = a-used[i]; This reads (and stores) used[LAST_AREA].
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053 --- Comment #5 from jim at meyering dot net 2012-04-20 11:23:21 UTC --- Oh! I'm not used to seeing this sort of transformation (invalid code - effectively-skipped loop-termination test), but it certainly makes sense, given an invalid input. Thank you both. definitely NOTABUG.
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 12:00:55 UTC --- Thanks.
[Bug bootstrap/53021] [4.8 Regression] bootstrap failure on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-20 12:20:07 UTC --- Author: jakub Date: Fri Apr 20 12:19:51 2012 New Revision: 186623 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186623 Log: PR bootstrap/53021 * alias.h (UNIQUE_BASE_VALUE_SP, UNIQUE_BASE_VALUE_ARGP, UNIQUE_BASE_VALUE_FP, UNIQUE_BASE_VALUE_HFP): Define. * alias.c (init_alias_targets): Use UNIQUE_BASE_VALUE_* macros instead of constants. * dse.c (record_store): Check for SP ADDRESS by comparing XWINT to UNIQUE_BASE_VALUE_SP instead of expecting XEXP to be stack_pointer_rtx. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/alias.h trunk/gcc/dse.c
[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521 --- Comment #11 from janus at gcc dot gnu.org 2012-04-20 12:29:34 UTC --- (In reply to comment #10) However, it yields a segfault at runtime (-fdump-tree-original shows that 'test2' is used in both calls). Related to this, it also shows that the specific call print *,test2(2.0) is not being rejected, while print *,test1(cos) is. For for former, we clearly need to add a check in 'compare_parameter' to reject it (which should also solve the segfault in comment #10 by selecting the correct specific function for the generic call).
[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-20
12:37:33 UTC ---
So, the below is my final pure C++ testcase: if 1 is changed to 0 the code
compiles; likewise if 1 and 0 are swapped. Thus, it seems there is something
wrong in global front-end data structures:
template class, class
struct is_convertible
{
static const bool value = true;
};
templatebool, class T
struct enable_if
{
typedef T type;
};
template bool...
struct Xs
{
static const bool value = true;
};
#if 1
templatetypename... Ts
class BType
{
template typename... Us,
typename enable_if
Xsis_convertibleUs, Ts::value...::value,
bool::type = false
void fooX(Us...);
};
#endif
template typename... Ts
struct AType
{
template typename... Us,
typename enable_if
Xsis_convertibleUs, Ts::value...::value,
bool::type = false
void foo(Us...);
};
#if 0
templatetypename... Ts
class CType
{
template typename... Us,
typename enable_if
Xsis_convertibleUs, Ts::value...::value,
bool::type = false
void fooX(Us...);
};
#endif
int main()
{
ATypeint, int t;
t.foo(1, 1);
}
[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44214 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #12 from janus at gcc dot gnu.org 2012-04-20 12:58:24 UTC ---
(In reply to comment #11)
For for former, we clearly need to add a check in 'compare_parameter' to
reject it
Something like:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 186596)
+++ gcc/fortran/interface.c(working copy)
@@ -1663,6 +1667,13 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
the module variables are generated. */
gfc_find_derived_vtab (actual-ts.u.derived);
+ if (formal-attr.flavor == FL_PROCEDURE actual-ts.type != BT_PROCEDURE)
+{
+ if (where)
+gfc_error (Procedure argument expected at %L, actual-where);
+ return 0;
+}
+
if (actual-ts.type == BT_PROCEDURE)
{
char err[200];
This correctly rejects the invalid code in comment #11 and makes the valid code
in comment #10 give the expected output (without segfaulting).
[Bug c++/33925] gcc -Waddress lost some useful warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-20 12:57:59 UTC --- (In reply to comment #6) ... That's not an argument against improving the warning though. GCC's uses occur in system headers so warnings are suppressed, and could be worked around anyway with further extensions such as #pragma GCC diagnostic Or even better, only skip the warning for functions marked as weakref, which I guess is a very small subset. I think a patch that did that would be accepted. Unfortunately, Michael, I don't think there is anyone with enough free time to work on this, so if you submitted a patch, that would be great! Thanks.
[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52891 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-20 12:58:28 UTC --- Created attachment 27202 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27202 gcc48-pr52891.patch Untested fix. Sorry for the delay.
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
Michal Malecki ethouris at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #5 from Michal Malecki ethouris at gmail dot com 2012-04-20
13:33:35 UTC ---
Hey, guys, not too fast.
Why do you say it's not more specialized?
The primary template contains size_t B as the first template parameter, and
the specialization puts explicit 0 in this place. According to the standard,
this IS a specialization.
Of course, it works now if you change the terminal definition into:
templatetypename Type1, typename... Types
struct tuple_sliced0, Type1, Types...
{
typedef tupleType1, Types... type;
};
But it's roughly the same - the only difference is that it doesn't manage an
interesting case of slicing to 0 (actually I should change it to 1). Whether
the specialization really matches the primary template, it should be decided
when the variadic parameters are expanded, so if this is correct, the cited one
should be correct, too.
[Bug c++/53055] New: ICE in cp_build_indirect_ref, at cp/typeck.c:2836
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055 Bug #: 53055 Summary: ICE in cp_build_indirect_ref, at cp/typeck.c:2836 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 27203 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27203 preprocessed source seen with 4.6 and 4.7 branches, and trunk on i686-linux-gnu $ gcc -c -g part-combine-iterator.ii part-combine-iterator.cc: In member function 'virtual void Part_combine_iterator::derived_mark() const': part-combine-iterator.cc:173:40: internal compiler error: in cp_build_indirect_ref, at cp/typeck.c:2836 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-20 14:08:31 UTC --- Created attachment 27204 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27204 unincluded testcase 4.4 rejects it: part-combine-iterator.cc: In member function 'virtual void Part_combine_iterator::derived_mark() const': part-combine-iterator.cc:173: error: invalid use of '' on pointer to member 4.5 also ICEs the same way.
[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44214 --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-20 14:19:23 UTC --- Author: wschmidt Date: Fri Apr 20 14:19:13 2012 New Revision: 186625 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186625 Log: gcc: 2012-04-20 Bill Schmidt wschm...@linux.vnet.ibm.com PR rtl-optimization/44214 * fold-const.c (exact_inverse): New function. (fold_binary_loc): Fold vector and complex division by constant into multiply by recripocal with flag_reciprocal_math; fold vector division by constant into multiply by reciprocal with exact inverse. gcc/testsuite: 2012-04-20 Bill Schmidt wschm...@linux.vnet.ibm.com PR rtl-optimization/44214 * gcc.dg/pr44214-1.c: New test. * gcc.dg/pr44214-2.c: Likewise. * gcc.dg/pr44214-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr44214-1.c trunk/gcc/testsuite/gcc.dg/pr44214-2.c trunk/gcc/testsuite/gcc.dg/pr44214-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44214 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-20 14:21:09 UTC --- Fixed.
[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-20 14:44:29 UTC --- A brutal application of delta gives this short but non-sensical code: void f () ; struct A A :: * p ; int i = p -* f ;
[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055 --- Comment #3 from Launchpad feedback at launchpad dot net 2012-04-20 14:44:50 UTC --- David Kastrup added the following comment to Launchpad bug report 984577: Just for the record: the source code triggering the error is invalid C++. It is just that an internal compiler error is a somewhat intimidating diagnostic. -- http://launchpad.net/bugs/984577
[Bug target/43249] unsigned int arg with no prototype gets full 64-bit reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43249 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||wschmidt at gcc dot gnu.org Resolution||INVALID --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-20 14:45:52 UTC --- Closing per comment #2.
[Bug lto/42534] ICE with -flto when using __attribute__((__aligned__(X)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42534 --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-20 14:53:43 UTC --- No longer reproduces in 4.8.
[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-04-20 14:59:20 UTC --- I am testing my variant of patch on x86_64-linux and intend to commit it if it passes.
[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-04-20 15:18:45 UTC --- Author: hubicka Date: Fri Apr 20 15:18:39 2012 New Revision: 186627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186627 Log: PR target/53042 * decl2.c (maybe_emit_vtables): Do not initialize same_comdat_group list when target has no support for it. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug bootstrap/53042] [4.8 Regression] AIX bootstrap: cgraph symbol table error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53042 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2012-04-20 15:27:53 UTC --- Hopefully fixed by my patch. After some more reading of the code, I do not think verifier update is needed. Verifier checks that only DECL_ONE_ONLY decls are in the comdat group lists and only targets supporting them will set the DECL_ONE_ONLY flag. So we are also effectively checking that targets not supporting them has empty comdat group lists. Honza
[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-20 Ever Confirmed|0 |1
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|SUSPENDED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-20 15:40:09 UTC --- The issue isn't whether it's a specialization or not, but whether it's technically more specialized. I didn't personally check in detail but Jason argued on the ISO reflector that is not ([c++std-core-21739]). And the reason why currently other front-ends accept the code is that they pick the primary for the instantiation. Thus this should be made more explicitly ill-formed in the standard with a DR. Let's suspend the PR for now.
[Bug tree-optimization/53045] Missing loop termination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53045 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-04-20 16:13:49 UTC --- (In reply to comment #2) Btw, see how I fixed 2012-04-18 Richard Guenther rguent...@suse.de * gcc.target/x86_64/abi/test_passing_unions.c: Avoid undefined array access. * gcc.target/x86_64/abi/test_passing_structs.c: Likewise. * gcc.target/i386/avx256-unaligned-load-4.c: Fix array sizes. I suppose I didn't see the AVX fails because my testing box doesn't have AVX. Thanks, I have fixed AVX testcases in the same way.
[Bug middle-end/52997] [4.8 Regression] FAIL: gcc.dg/c99-intconst-1.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997 --- Comment #2 from dave.anglin at bell dot net 2012-04-20 17:18:05 UTC --- On 4/19/2012 10:21 AM, bernds at gcc dot gnu.org wrote: Does this fix it? Yes. Thanks, Dave
[Bug target/51178] FAIL: g++.dg/lookup/builtin5.C scan-assembler _ZSt5atanhd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51178 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-eabi, |arm-none-eabi |arm-linux-gnueabi | --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-04-20 17:42:15 UTC --- Doesn't happen on linux targets. Seems to be related to the absence of NO_IMPLICIT_EXTERN_C.
[Bug target/53056] New: bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056
Bug #: 53056
Summary: bad code generated for ARM NEON with vector types in
structs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com
Consider the following snippet:
typedef int vi16 __attribute__((vector_size(16*sizeof(int;
vi16 add(vi16 a, vi16b) {
return a + b;
}
compile with arm-linux-gnueabi-gcc-4.7 -O2 -march=armv7-a -mhard-float
-mfpu=neon
Some fairly good code is produced:
sub sp, sp, #8
str r4, [sp, #-4]!
fstmfdd sp!, {d8, d9, d10, d11, d12, d13}
add ip, sp, #52
add r4, sp, #116
vldmia r4, {d24-d31}
stmia ip, {r2, r3}
vldmia ip, {d6-d13}
vadd.i32q8, q3, q12
vadd.i32q9, q4, q13
vadd.i32q10, q5, q14
vadd.i32q11, q6, q15
vstmia r0, {d16-d23}
fldmfdd sp!, {d8, d9, d10, d11, d12, d13}
ldmfd sp!, {r4}
add sp, sp, #8
bx lr
However, the the vector is embedded in a struct the code generation becomes
awful.
typedef struct A {
vi16 v;
} A;
vi16 add1(A a, A b) {
return a.v + b.v;
}
// Same code as add1
vi16 add2(A a, A b) {
vi16* av = a.v;
vi16* bv = b.v;
return a.v + b.v;
}
Both add1 and add2 produce the same code:
add1:
@ args = 128, pretend = 8, frame = 128
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
sub sp, sp, #128
add r1, sp, #128
stmia sp, {r2, r3}
stmia r1, {r2, r3}
ldr r3, [sp, #192]
ldr r2, [r1, #8]
str r3, [sp, #64]
ldr r3, [sp, #196]
str r2, [sp, #8]
ldr r2, [r1, #12]
str r3, [sp, #68]
ldr r3, [sp, #200]
... lots and lots of load and store instructions.
But adding an optimization barrier to add2 produces similar code to the
original example, by making the compiler forget the origin of the pointer.
vi16 add3(A a, A b) {
vi16* av = a.v;
vi16* bv = b.v;
asm( : +r(av), +r(bv)); // causes good code to be generated.
return *av + *bv;
}
[Bug bootstrap/52878] [4.8 regression] bootstrap failure: MASK_LONG_DOUBLE_128 redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 --- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2012-04-20 20:15:32 UTC --- (In reply to comment #14) Created attachment 27192 [details] A patch Please try this patch. With this patch I'm able to bootstrap gcc-4.8-20120415 on sparc64-linux.
[Bug target/53056] bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056 --- Comment #1 from D W drwowe at yahoo dot com 2012-04-20 20:16:35 UTC --- Also tested arm-linux-gnueabi-gcc-4.8.0-svn186501. Same results.
[Bug target/53056] bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056
--- Comment #2 from D W drwowe at yahoo dot com 2012-04-20 20:20:46 UTC ---
Typo: add2 should be:
vi16 add2(A a, A b) {
vi16* av = a.v;
vi16* bv = b.v;
return *av + *bv;
}
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #12 from Michael Meissner meissner at gcc dot gnu.org 2012-04-20 23:15:56 UTC --- Created attachment 27205 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27205 ivtops dump from subversion id 183933 (before regression)
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #13 from Michael Meissner meissner at gcc dot gnu.org 2012-04-20 23:16:24 UTC --- I'm attaching the ivopts dump from 4 runs: 1) Subversion id 183933, the revision before the change; 2) Subversion id 183934, the revision that slowed down bwaves; 3) Subversion id 186630, top of the tree this morning; 4) Subversion id 186630 + the experimental patch. The experimental patch does not change the code at all on the PowerPC. 1) The mat_times_vec_ function is 27% slower in subversion id 183934; 2) The mat_times_vec_ function is 24% slower in today's versions.
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #14 from Michael Meissner meissner at gcc dot gnu.org 2012-04-20 23:19:52 UTC --- Created attachment 27207 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27207 ivtops dump from subversion id 183934 (after regression)
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #15 from Michael Meissner meissner at gcc dot gnu.org 2012-04-20 23:21:14 UTC --- Created attachment 27208 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27208 ivtops dump from subversion id 186630 (top of tree on April 20th, 2012)
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #16 from Michael Meissner meissner at gcc dot gnu.org 2012-04-20 23:22:54 UTC --- Created attachment 27209 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27209 ivtops dump from subversion id 186630 + experimental patch from Igor Zamyatin
[Bug tree-optimization/50480] 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 --- Comment #6 from Michael Meissner meissner at gcc dot gnu.org 2012-04-20 23:17:44 UTC --- Created attachment 27206 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27206 ivtops dump from subversion id 183934 (after regression)
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
--- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-04-21
01:46:29 UTC ---
If you rewrite the test so that the two versions are both partial
specializations:
template size_t, typename... struct tuple_sliced;
template size_t B, typename Type1, typename... Types
struct tuple_slicedB, Type1, Types...
{
typedef typename tuple_slicedB-1, Types...::type type;
};
templatetypename... Types
struct tuple_sliced0, Types... // -- line 18
{
typedef tupleTypes... type;
};
and then you try to instantiate it:
tuple_sliced1,int,int,int t;
the instantiation is ambiguous. The second partial specialization is more
specialized for the first argument 0, but the first partial specialization is
more specialized for the parameter pack, because it requires at least one
argument. So neither is more specialized than the other, and so in the same
way in the original testcase the partial specialization is not more specialized
than the primary template.
