[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #7 from Markus Trippelsdorf
2012-07-24 06:49:57 UTC ---
(In reply to comment #5)
> What are the callers of gt_pch_p_9line_maps?
It is only called from gt_pch_nx_line_maps of ./gcc/gtype-desc.c (generated):
gt_pch_nx_line_maps (void *x_p)
{
struct line_maps * const x = (struct line_maps *)x_p;
if (gt_pch_note_object (x, x, gt_pch_p_9line_maps, gt_ggc_e_9line_maps))
{
{
size_t l0 = (size_t)(((*x).info_ordinary).used);
if ((*x).info_ordinary.maps != NULL) {
size_t i0;
for (i0 = 0; i0 != (size_t)(l0); i0++) {
switch (((*x).info_ordinary.maps[i0]).reason == LC_ENTER_MACRO)
{
case 0:
gt_pch_n_S ((*x).info_ordinary.maps[i0].d.ordinary.to_file);
break;
case 1:
{
size_t l1 = (size_t)(2 *
((*x).info_ordinary.maps[i0].d.macro).n_tokens);
{
union tree_node * const x2 =
((*x).info_ordinary.maps[i0].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_ordinary.maps[i0].d.macro.macro))) :
NULL;
gt_pch_n_9tree_node (x2);
}
if ((*x).info_ordinary.maps[i0].d.macro.macro_locations !=
NULL) {
size_t i1;
for (i1 = 0; i1 != (size_t)(l1); i1++) {
}
gt_pch_note_object
((*x).info_ordinary.maps[i0].d.macro.macro_locations, x, gt_pch_p_9line_maps,
gt_types_enum_last);
}
}
break;
default:
break;
}
}
gt_pch_note_object ((*x).info_ordinary.maps, x, gt_pch_p_9line_maps,
gt_types_enum_last);
}
}
{
size_t l3 = (size_t)(((*x).info_macro).used);
if ((*x).info_macro.maps != NULL) {
size_t i3;
for (i3 = 0; i3 != (size_t)(l3); i3++) {
switch (((*x).info_macro.maps[i3]).reason == LC_ENTER_MACRO)
{
case 0:
gt_pch_n_S ((*x).info_macro.maps[i3].d.ordinary.to_file);
break;
case 1:
{
size_t l4 = (size_t)(2 *
((*x).info_macro.maps[i3].d.macro).n_tokens);
{
union tree_node * const x5 =
((*x).info_macro.maps[i3].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i3].d.macro.macro))) :
NULL;
gt_pch_n_9tree_node (x5);
}
if ((*x).info_macro.maps[i3].d.macro.macro_locations != NULL)
{
size_t i4;
for (i4 = 0; i4 != (size_t)(l4); i4++) {
}
gt_pch_note_object
((*x).info_macro.maps[i3].d.macro.macro_locations, x, gt_pch_p_9line_maps,
gt_types_enum_last);
}
}
break;
default:
break;
}
}
gt_pch_note_object ((*x).info_macro.maps, x, gt_pch_p_9line_maps,
gt_types_enum_last);
}
}
}
}
[Bug target/53914] poor code generated for offset addressing on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53914 Alan Modra changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/53914] poor code generated for offset addressing on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53914 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Alan Modra 2012-07-24 06:11:01 UTC --- Fixed mainline
[Bug target/54009] incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009 --- Comment #1 from Alan Modra 2012-07-24 05:55:56 UTC --- Author: amodra Date: Tue Jul 24 05:55:50 2012 New Revision: 189801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189801 Log: PR target/53914 PR target/54009 * config/rs6000/constraints.md (Y): Use mem_operand_gpr. * config/rs6000/predicates.md (word_offset_memref_operand): Delete. Adjust all rs6000_legitimate_offset_address_p calls. * config/rs6000/rs6000-protos.h (mem_operand_gpr): Declare. (rs6000_secondary_reload_gpr): Declare. (rs6000_legitimate_offset_address_p): Update prototype. (rs6000_offsettable_memref_p): Delete. (rs6000_secondary_reload_ppc64): Delete. * config/rs6000/rs6000.c (address_offset): New function. (mem_operand_gpr): Likewise. (rs6000_legitimate_offset_address_p): Add worst_case param. When not worst_case assume class of regs with least restrictive offsets. Adjust all calls. (legitimate_lo_sum_address_p): Simplify register mode tests. (rs6000_legitimize_address): Likewise. Assume best case offset addressing. Combine ELF and MACHO lo_sum code. (rs6000_mode_dependent_address): Correct offset addressing limits. (rs6000_offsettable_memref_p): Make static, add reg_mode param. Use reg_mode to help rs6000_legitimate_offset_address_p. (rs6000_secondary_reload): Use address_offset. Handle 32-bit multi gpr load/store when offset too large. (rs6000_secondary_reload_gpr): Renamed rs6000_secondary_reload_ppc64. (rs6000_split_multireg_move): Adjust rs6000_offsettable_memref_p calls. * config/rs6000/rs6000.md (movdf_hardfloat32): Use 'Y' constraint for gpr load/store. Order alternatives as r->Y,Y->r,r->r and d->m,m->d,d->d. Correct size of gpr load/store. (movdf_softfloat32): Use 'Y' constraint for gpr load/store. Order alternatives. (movti_ppc64): Likewise. (movdi_internal32): Likewise. Also disparage fprs. (movdi_mfpgpr, movdi_internal64): Likewise. (movtf_internal): Use 'm' for fpr load/store. Order alternatives. (movtf_softfloat): Order alternatives. (extenddftf2_internal): Use 'm' and 'Y' for store. (movti_power, movti_string): Use 'Y' for gpr load/store. Order. (stack_protect_setdi, stack_protect_testdi): Likewise. (movdf_hardfloat64_mfpgpr, movdf_hardfloat64): Order alternatives. (movdf_softfloat64): Likewise. (reload__store): Adjust reload_di_store to provide reload_si_store as well. (reload__load): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/constraints.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md
[Bug target/53914] poor code generated for offset addressing on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53914 --- Comment #2 from Alan Modra 2012-07-24 05:55:56 UTC --- Author: amodra Date: Tue Jul 24 05:55:50 2012 New Revision: 189801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189801 Log: PR target/53914 PR target/54009 * config/rs6000/constraints.md (Y): Use mem_operand_gpr. * config/rs6000/predicates.md (word_offset_memref_operand): Delete. Adjust all rs6000_legitimate_offset_address_p calls. * config/rs6000/rs6000-protos.h (mem_operand_gpr): Declare. (rs6000_secondary_reload_gpr): Declare. (rs6000_legitimate_offset_address_p): Update prototype. (rs6000_offsettable_memref_p): Delete. (rs6000_secondary_reload_ppc64): Delete. * config/rs6000/rs6000.c (address_offset): New function. (mem_operand_gpr): Likewise. (rs6000_legitimate_offset_address_p): Add worst_case param. When not worst_case assume class of regs with least restrictive offsets. Adjust all calls. (legitimate_lo_sum_address_p): Simplify register mode tests. (rs6000_legitimize_address): Likewise. Assume best case offset addressing. Combine ELF and MACHO lo_sum code. (rs6000_mode_dependent_address): Correct offset addressing limits. (rs6000_offsettable_memref_p): Make static, add reg_mode param. Use reg_mode to help rs6000_legitimate_offset_address_p. (rs6000_secondary_reload): Use address_offset. Handle 32-bit multi gpr load/store when offset too large. (rs6000_secondary_reload_gpr): Renamed rs6000_secondary_reload_ppc64. (rs6000_split_multireg_move): Adjust rs6000_offsettable_memref_p calls. * config/rs6000/rs6000.md (movdf_hardfloat32): Use 'Y' constraint for gpr load/store. Order alternatives as r->Y,Y->r,r->r and d->m,m->d,d->d. Correct size of gpr load/store. (movdf_softfloat32): Use 'Y' constraint for gpr load/store. Order alternatives. (movti_ppc64): Likewise. (movdi_internal32): Likewise. Also disparage fprs. (movdi_mfpgpr, movdi_internal64): Likewise. (movtf_internal): Use 'm' for fpr load/store. Order alternatives. (movtf_softfloat): Order alternatives. (extenddftf2_internal): Use 'm' and 'Y' for store. (movti_power, movti_string): Use 'Y' for gpr load/store. Order. (stack_protect_setdi, stack_protect_testdi): Likewise. (movdf_hardfloat64_mfpgpr, movdf_hardfloat64): Order alternatives. (movdf_softfloat64): Likewise. (reload__store): Adjust reload_di_store to provide reload_si_store as well. (reload__load): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/constraints.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #7 from likan_999.student at sina dot com 2012-07-24 00:42:57 UTC --- @Paolo Carlini: the problem is, with different max_load_factor in range [0.2-5], the *best* result of 4.7.1 is still 2x slower than the *worst* of 4.6.2. I printed out the average load factor during the insertion. Looks like 4.7.1's load factor is very close to the max_load_factor, and the average for 4.6.2 is about 1/4 of the max_load_factor. But what conclusion can we get from this result?
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #6 from Paolo Carlini 2012-07-24 00:29:38 UTC --- In some cases 4.6.x was handling max_load_factor incorrectly. Thus, the idea isn't comparing 4.6.x to 4.7.x with the same max_load_factor (I don't think it's useful), instead, actually measure load_factor(s), see if for some values of max_load_factor, the actual load_factor(s) are different in 4.6.x vs 4.7.x. In any case, measure the actual load_factor while the map grows.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #5 from likan_999.student at sina dot com 2012-07-24 00:17:10 UTC --- @Paolo Carlini: can you talk more about how to experiment with max_load_factor? As long as I use the same max_load_factor for 4.6 and 4.7, I can still see the performance difference (3x slower is the best result): max_load_factor gcc-4.6.2 gcc-4.7.1 0.2 1.600s 7.650s 0.5 1.125s 4.251s 1.0 1.004s 3.378s 2.0 0.914s 20.471s 5.0 0.917s 29.132s
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 --- Comment #9 from Paolo Carlini 2012-07-23 23:35:42 UTC --- Weird indeed, thanks Daniel. Tomorrow I will have a look and either will send a patch or will post an analysis (if I will get stuck).
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #43 from Oleg Endo 2012-07-23 23:29:02 UTC --- I have noticed that on SH the CANONICALIZE_COMPARISON macro is not defined, although it seems to be useful for the combine pass. Another thing that I'd like to try out is using zero-displacement branches to implement conditional execution patterns and see how it performs.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #4 from Paolo Carlini 2012-07-23 23:23:27 UTC --- I wonder, anyway, if the apparent slow down is just an artifact caused by a different handling of the load factor in the reworked unordered containers which we have been delivering since 4.7.0. I would suggest submitter to experiment a bit with max_load_factor, and see if when 4.6.x seems faster at insertion time actually the load factor is higher (too searching would be slower).
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-23 CC||fdumont at gcc dot gnu.org Ever Confirmed|0 |1 Severity|critical|normal --- Comment #3 from Paolo Carlini 2012-07-23 23:12:15 UTC --- Francois, can you have a look? Thanks!
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #2 from likan_999.student at sina dot com 2012-07-23 23:09:43 UTC --- Created attachment 27862 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27862 Profiling of gcc-4.6.2 using google-perftools
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #1 from likan_999.student at sina dot com 2012-07-23 23:08:07 UTC --- Created attachment 27861 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27861 Profiling using google-perftools
[Bug libstdc++/54075] New: [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
Bug #: 54075
Summary: [4.7.1] unordered_map 3x slower than 4.6.2
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: likan_999.stud...@sina.com
The following piece of code shows 3x performance regression from 4.6.2 to
4.7.1. The reason should come from the change in libstdc++. The code is
compiled with -O2 -std=c++0x. -O3 doesn't make much difference; with or without
the call to reserve doesn't make much difference. The attachment contains
profiling using google-perftool. Looks like the major cost comes from the
rehashing. Does anyone aware of the issue, or I am the first one to report
this?
#include
using namespace std;
int main() {
const int N = 1000;
unordered_map m;
m.reserve(2 * N);
for (int i = 0; i < N; i++) {
m[i] = i;
}
}
Timing:
[hidden]$ time ./a-4.6.2.out
real0m1.029s
user0m0.787s
sys0m0.239s
[hidden]$ time ./a-4.7.1.out
real0m3.364s
user0m2.596s
sys0m0.761s
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 Oleg Endo changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Oleg Endo 2012-07-23 23:00:36 UTC --- Should be OK now.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #42 from Oleg Endo 2012-07-23 22:57:42 UTC --- Author: olegendo Date: Mon Jul 23 22:57:36 2012 New Revision: 189797 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189797 Log: PR target/51244 * config/sh/predicates.md (general_movsrc_operand, general_movdst_operand): Reject T_REG. * config/sh/sh.md (*extendqisi2_compact_reg, *extendhisi2_compact_reg, movsi_i, movsi_ie, movsi_i_lowpart, *movqi_reg_reg, *movhi_reg_reg): Remove T_REG alternatives. (*negtstsi): New insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.md
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #14 from Oleg Endo 2012-07-23 22:54:13 UTC --- Author: olegendo Date: Mon Jul 23 22:54:06 2012 New Revision: 189796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189796 Log: PR target/53511 * config/sh/sh.md (mulsf3_ie): Delete. (mulsf3_i4): Rename to mulsf3_i. (mulsf3): Emit mulsf3_i insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #6 from Steven Bosscher 2012-07-23 22:46:19 UTC --- FWIW this shows up in GCC's own libstdc++ PCHs also.
[Bug c++/54074] New: [C++0x] initializer list accepts incorrect nested input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54074
Bug #: 54074
Summary: [C++0x] initializer list accepts incorrect nested
input
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebewo...@gmail.com
#include
#include
using namespace std;
struct S1 {
int i;
string str;
};
//nested
struct S2 {
int i;
string str;
S1 s1;
};
int main() {
//should be S2 s22{ 3, "Hello3", {4,"Hello4"} };
//but it compiles
S2 s22{ 3, "Hello3", 4,"Hello4" };
FINISH_TEST();
}
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-23 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #5 from Steven Bosscher 2012-07-23 21:28:56 UTC --- What are the callers of gt_pch_p_9line_maps?
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Daniel Krügler changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #8 from Daniel Krügler
2012-07-23 21:01:09 UTC ---
I agree that the actual test examples work now, but I also found that only
*slight* variations of the call context of the test expression
"sizeof(f(0))" again lead to access errors. The following variants
demonstrate this:
//---
class C {
typedef int type; // Line 2
};
template
auto f(int) -> char;
template
auto f(...) -> char (&)[2];
static_assert(sizeof(f(0)) == 2, ""); // OK
typedef int test[sizeof(f(0)) == 2 ? 1 : -1]; // Error
template
struct I {};
I(0))> i; // Error
enum E { e1 = sizeof(f(0)) }; // Error
//---
"13|error: size of array 'test' is negative|
2|error: 'typedef int C::type' is private|
5|error: within this context|
2|error: 'typedef int C::type' is private|
18|error: within this context|
2|error: 'typedef int C::type' is private|
5|error: within this context|
"
Jason suggested to reopen the issue, so I did.
[Bug web/51195] upgrade request for viewvc to version 1.1.13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51195 Sean McGovern changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Sean McGovern 2012-07-23 19:16:26 UTC --- seems to work OK now.
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #21 from Daniel Richard G. 2012-07-23
18:52:06 UTC ---
(In reply to comment #20)
> You could try adding this to ctype.cc around line 54
--- libstdc++-v3/src/c++98/ctype.cc.orig2012-01-23 18:12:01.2 -0500
+++ libstdc++-v3/src/c++98/ctype.cc2012-07-23 13:31:55.2 -0400
@@ -52,6 +52,8 @@
const size_t ctype::table_size;
+ inline template class ctype;// added by skunk
+
ctype::~ctype()
{
_S_destroy_c_locale(_M_c_locale_ctype);
I rebuilt ctype.o and the libraries it goes into. Unfortunately, I still get
the link error. If I compare the output of "nm -A" on the old and new ctype.o
objects, I don't see a difference in the defined symbols.
The mangled form of "vtable for std::ctype" is "_ZTVSt5ctypeIcE". If I
grep for that in "nm -A ctype.o", I see
ctype.o:17c0 d _ZTVSt5ctypeIcE.P8
but no instances without the ".P8" suffix. Looking through all the objects of
libstdc++, grep only turns up these:
ctype_configure_char.o: U _ZTVSt5ctypeIcE
ctype_configure_char.o:08a4 d _ZTVSt5ctypeIcE.P8
For comparison, I grepped for "_ZTVNSt6locale5facetE", the mangled form of
"vtable for std::locale::facet", and got the below:
time_members.o: U _ZTVNSt6locale5facetE
time_members.o:1778 d _ZTVNSt6locale5facetE.P8
codecvt.o: U _ZTVNSt6locale5facetE
codecvt.o:15d0 d _ZTVNSt6locale5facetE.P8
locale-inst.o: U _ZTVNSt6locale5facetE
locale-inst.o:00023974 d _ZTVNSt6locale5facetE.P8
wlocale-inst.o: U _ZTVNSt6locale5facetE
wlocale-inst.o:00023c2c d _ZTVNSt6locale5facetE.P8
numeric_members.o: U _ZTVNSt6locale5facetE
numeric_members.o:0e64 d _ZTVNSt6locale5facetE.P8
ctype.o: U _ZTVNSt6locale5facetE
ctype.o:17bc d _ZTVNSt6locale5facetE.P8
monetary_members.o: U _ZTVNSt6locale5facetE
monetary_members.o:1b80 d _ZTVNSt6locale5facetE.P8
locale_init.o: U _ZTVNSt6locale5facetE
locale_init.o:4a50 d _ZTVNSt6locale5facetE.P8
ctype_configure_char.o: U _ZTVNSt6locale5facetE
ctype_configure_char.o:08a0 d _ZTVNSt6locale5facetE.P8
locale.o:2b08 d _ZTVNSt6locale5facetE
locale.o:2b08 D _ZTVNSt6locale5facetE
locale.o:2b3c d _ZTVNSt6locale5facetE.P8
The fact of the symbol being a vtable for a template class appears to be
relevant. Maybe a different kind of explicit instantiation is needed?
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 --- Comment #18 from uros at gcc dot gnu.org 2012-07-23 16:04:30 UTC --- Author: uros Date: Mon Jul 23 16:04:23 2012 New Revision: 189787 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189787 Log: PR target/53961 * config/i386/i386.md (*lea): Add asserts to detect invalid addresses. * config/i386/i386.c (ix86_print_operand_address): Ditto. (ix86_decompose_address): Allow (zero_extend:DI (subreg:SI (...))) addresses. Prevent zero extensions of CONST_INT operands. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md
[Bug tree-optimization/54073] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 --- Comment #1 from Artem S. Tashkinov 2012-07-23 15:43:50 UTC --- The results are obtained from here: http://openbenchmarking.org/result/1207077-SU-GCCPERFOR59 Benchmarking of GCC 4.2 through GCC 4.8 when building the compiler the same and setting CFLAGS/CXXFLAGS of -O3 and -march=native prior to test installation and execution. Benchmarking for a future article on Phoronix.com by Michael Larabel. Testing on an Intel Core i7 and AMD Opteron 2384 when using the 64-bit (x86_64 target) build of Ubuntu Linux. The CPU is: Nehalem microarchitecture, "Clarksfield" (45 nm), Intel® Core™ i7-720QM Processor (6M Cache, 1.60 GHz) http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-%286M-Cache-1_60-GHz%29
[Bug tree-optimization/54073] New: SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 Bug #: 54073 Summary: SciMark Monte Carlo test performance has seriously decreased in recent GCC releases Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: t.ar...@mailcity.com Created attachment 27860 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27860 Sci Mark Monte Carlo test On an Intel Core i7 CPU (see the attached screenshot): GCC 4.2.x - 380 GCC 4.7.x - 265 i.e. 44% slower. SciMark 2.0 sources can be fetched here: http://math.nist.gov/scimark2/download_c.html
[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 sebastian changed: What|Removed |Added CC||oeste.sebastian at ||googlemail dot com --- Comment #2 from sebastian 2012-07-23 14:49:46 UTC --- I've make a similar observation, with the function __mm_xor_si128 from emmintrin.h and the flag -finstrument-functions. gcc Version 4.7.0 (same results with 4.7.1) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/oeste/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/oeste/gcc/ Thread model: posix gcc version 4.7.0 (GCC) $ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -save-temps -finstrument-functions ./test.c test.o: In function `main': test.c:(.text+0x50): undefined reference to `_mm_xor_si128' test.c:(.text+0x61): undefined reference to `_mm_xor_si128' collect2: error: ld returned 1 exit status When compile without -finstrument-functions all will be done.
[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 --- Comment #1 from sebastian 2012-07-23 14:47:00 UTC --- Created attachment 27859 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27859 preprocessed minimal reproduction of the bug
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #4 from Paolo Carlini 2012-07-23 13:46:43 UTC --- Dodji, just in case isn't clear already, this is the PR about -ftrack-macro-expansion + PCHs which I mentioned in Prague...
[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072 --- Comment #3 from Tobias Burnus 2012-07-23 13:44:47 UTC --- (In reply to comment #1) > Misleading error message: >Error: Extension: BOZ literal at (1) outside a DATA statement and outside > INT/REAL/DBLE/CMPLX > As comment 0 shows, there are now many more intrinsics where BOZ literals are > allowed. The message text should be updated. http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html has a similar issue: It also only lists the 4 Fortran 2003 intrinsics; one should mention that some additional Fortran 2008 intrinsics also accept BOZ.
[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #12 from Richard Guenther 2012-07-23 13:29:22 UTC --- Thanks for the detective work! Mine.
[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072 --- Comment #2 from Tobias Burnus 2012-07-23 13:17:33 UTC --- Currently, gfortran prints the following error message if the BOZ exceeds (for integers) the positive value: Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check That perfectly matches the behaviour of Fortran 95, which had: "If a data-statement-constant is a boz-literal-constant, the corresponding object shall be of type integer. A data-stmt-constant that is a boz-literal-constant is treated as if the constant were an int-literalconstant with a kind-param that specifies the representation method with the largest decimal exponent range supported by the processor." I am not sure that the message text is the best for Fortran 2008, which has for DATA: "If a data-stmt-constant is a boz-literal-constant, the corresponding variable shall be of type integer. The boz-literal-constant is treated as if it were converted by the intrinsic function INT (13.7.81) to type integer with the kind type parameter of the variable" And for INT see the text quoted in comment 0, i.e. it is "is processor dependent".
[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616 Vladimir Yakovlev changed: What|Removed |Added CC||vbyakovl23 at gmail dot com --- Comment #11 from Vladimir Yakovlev 2012-07-23 12:53:13 UTC --- Miscompare in 416 .games is caused by a wrong transformation of a loop in file grd2b.f, lines 113-121. DO 110 M=1,3 P12(M,1)= C(M,IAT) P12(M,2)= C(M,JAT) P12(M,3)= P12(M,2)-P12(M,1) R12= R12+P12(M,3)*P12(M,3) P34(M,1)= C(M,KAT) P34(M,2)= C(M,LAT) P34(M,3)= P34(M,2)-P34(M,1) 110 R34= R34+P34(M,3)*P34(M,3) After transformation we have P12(:,1) = C(:,IAT) P12(:,2) = C(:,jAT) DO 110 M=1,3 P12(M,3)= P12(M,2)-P12(M,1) R12= R12+P12(M,3)*P12(M,3) P34(M,3)= P34(M,2)-P34(M,1) 110 R34= R34+P34(M,3)*P34(M,3) P34(:,1) = C(:,KAT) P34(:,2) = C(:,LAT) That is we changed order of operators in the loop. Right transformation should be P12(:,1) = C(:,IAT) P12(:,2) = C(:,jAT) DO 110 M=1,3 P12(M,3)= P12(M,2)-P12(M,1) 110 R12= R12+P12(M,3)*P12(M,3) P34(:,1) = C(:,KAT) P34(:,2) = C(:,LAT) DO 111 M=1,3 P34(M,3)= P34(M,2)-P34(M,1) 111 R34= R34+P34(M,3)*P34(M,3) I attached a reduced test case and dumps with and without transformations. Command line to compile is gfortran m.f t.f -O3 The result of run is differed from a result of code compiled with -O0 opt level. I used compiler Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse --enable-languages=c,c++,fortran --enable-bootstrap=no Thread model: posix gcc version 4.8.0 20120606 (experimental) (GCC)
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 Christopher Hite changed: What|Removed |Added CC||Christopher.Hite at partner ||dot commerzbank.com --- Comment #10 from Christopher Hite 2012-07-23 12:54:04 UTC --- So this fix will be in gcc 4.7.2? Could you check if it fixes #52900 too?
[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616 --- Comment #10 from Vladimir Yakovlev 2012-07-23 12:48:59 UTC --- Created attachment 27858 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27858 Reduced test case
[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-07-23 12:46:18 UTC --- Misleading error message: Error: Extension: BOZ literal at (1) outside a DATA statement and outside INT/REAL/DBLE/CMPLX As comment 0 shows, there are now many more intrinsics where BOZ literals are allowed. The message text should be updated.
[Bug fortran/54072] New: BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072 Bug #: 54072 Summary: BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Motivated by the question at http://www.rhinocerus.net/forum/lang-fortran/710304-why-does-boz-literal-work-ok-transfer-call-but-not-declarationwith-gfortran.html Note that for INT() the standard has: "If A is a boz-literal-constant, the value of the result is the value whose bit sequence according to the model in 13.3 is the same as that of A as modified by padding or truncation according to 13.3.3. The interpretation of a bit sequence whose most significant bit is 1 is processor dependent." - Thus, printing an error should be fine. * * * Fortran 2008 only allows BOZ at: "C4102 (R463) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, or where explicitly allowed in subclause 13.7 as an actual argument of an intrinsic procedure." If one looks for "BOZ" for TRANSFER, one finds nothing: SOURCE shall be a scalar or array of any type. Thus, I think one has to conclude that it is not allowed. - But gfortran silently accepts it. Similarly for, e.g., ABS. * * * The following is accepted print *, ior(z'111',z'010') However, the standard requires: I and J shall not both be boz-literal-constants. Similarly for iand and ieor. However, two BOZ to dshiftr are properly rejected.
[Bug c++/54043] [C++11] cout << nullptr does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 --- Comment #11 from Aryeh Gregor 2012-07-23 11:00:01 UTC --- (In reply to comment #3) > You can submit an issue, see > http://cplusplus.github.com/LWG/lwg-active.html#submit_issue I sent an e-mail to Alisdair Meredith per the instructions on that page.
[Bug c/54071] New: out data in object file is correct only for -s0 optimize flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54071
Bug #: 54071
Summary: out data in object file is correct only for -s0
optimize flag
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arkadiusz.krysiak.wroc...@gmail.com
Created attachment 27857
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27857
object file with bad optymalisation
ut block command is made by part of source functions.
some functionss have no prolog and epilog.
out data in object file is correct only for -s0 optimize flag
I have in big source code for atmega644p functions:
//==
void console_process(console_st *base)
{
do
{
base->temp=(uint16_t)cgetc((&base->com_port) );
base->char_in=(uint8_t)base->temp;
if (EOF==(int)base->temp)
{
base->char_in=0;
}
if (0x00!=base->char_in)
{
if (base->status.console_enable)
{
if (sizeof(console_lock_string)>base->status.locker_match)
{
if(pgm_read_byte
((&console_lock_string[0])+base->status.locker_match)
==
base->char_in
)
{ /*char in is in accord to unlock string char from
base->locker_match position*/
base->status.locker_match++;
if ((sizeof(console_lock_string)-1)==base->status.locker_match)
{
base->status.console_enable=false;
base->status.locker_match=0;
}
}
else
{
base->status.locker_match=0;
}
}
if (0x00!=base->char_in)
{
base->time_out_ticks=base->timeout;
if (user_log_in_test(base)){console_embedded_cmd_run(base);}
console_ansi_process(base);
if (
(!(base->status.esc))
&&
(C_ESC!=base->char_in)
&&
(base->status.passwd!=true)
)
{
console_process_to_lowercase(base);
console_auto_fill_cmd(base);
console_fn_key_select(base);
}
}
base->status.hold_char=0;/*false*/
}
else
{
if (sizeof(console_unlock_string)>base->status.locker_match)
{
if (
pgm_read_byte
(
(&console_unlock_string[0])
+
base->status.locker_match
)
==
base->char_in
)
{
base->status.locker_match++;
if (
(sizeof(console_unlock_string)-1)
==
base->status.locker_match
)
{
base->status.console_enable=true;
base->status.locker_match=0;
}
}
else
{
base->status.locker_match=0;
}
}
}
}
}while( (EOF) != (int)(base->temp) );
}
void set_new_passwd(console_st *base)
{
//zapisz haslo
switch (base->priviledge)
{
case 0x80 :{base->temp=6; break;}
case 0x40 :{base->temp=5; break;}
case 0x20 :{base->temp=4; break;}
case 0x10 :{base->temp=3; break;}
case 0x08 :{base->temp=2; break;}
case 0x04 :{base->temp=1; break;}
case 0x02 :{base->temp=0; break;}
default :{base->temp=255; break;}
}
if (base->temp<255)
{
pass_tab[base->temp].hash=base->temp_val;
}
if (base->temp<255)
{
cfseek( /*ustaw w odpowiednim miejscu w pliku*/
EEFILE,
(uint8_t
*)(&ee_pass_tab[0])+(base->temp*sizeof(user_st)),
0
);
cfputc(*((uint8_t *)(&base->temp_val)+0),EEFILE);
cfputc(*((uint8_t *)(&base->temp_val)+1),EEFILE);
cfputc(*((uint8_t *)(&base->temp_val)+2),EEFILE);
cfputc(*((uint8_t *)(&base->temp_val)+3),EEFILE);
}
}
void console_ansi_process(console_st *base)
{
if (
(C_ESC==base->char_in)
&&
(true!=base->status.passwd)
&&
(true!=base->status.passwd_ask)
&&
(true!=base->st
[Bug translation/54067] arm-none-eabi with -mapcs and attribute((interrupt)) generates wrong stack alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54067 --- Comment #2 from Richard Earnshaw 2012-07-23 10:26:06 UTC --- Hmm, I got myself confused with the undocumented option. -mapcs has the same behaviour as -mapcs-frame, which should work (generate code that will execute correctly) even in this context; though back-tracing through an interrupt frame is probably never going to work.
[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-07-23 10:23:15 UTC --- (In reply to comment #0) > function f() > character(len=:),allocatable :: f > f ="ABC" > end function Here, one has for the internal length assignment: .__result = 3 The RHS is a simple "3", but the LHS is a pointer to an integer ... * * * (In reply to comment #0) > One gets the same ICE for the original example. Looking at the dump, there is > no (re)allocation - but there should be one! Pilot error of mine: As that code also lacks an ALLOCATE, it is also invalid without an explicit ALLOCATE statement. (The real-world program uses an array on the RHS. When the result_string has no "dimension(:)", it compiled. For both, cf. email.)
[Bug middle-end/54068] Compiler passes wrong argument to function when using optimize attribute with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54068 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #2 from Steven Bosscher 2012-07-23 10:17:07 UTC --- (In reply to comment #1) > I suppose this is the known issue with tail-call optimization which > may get upset if you have parts compiled with -O0 and parts with -O3. If this is a known issue, then I'd expect there is already a PR for this...?
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Steven Bosscher 2012-07-23 10:12:28 UTC --- This should be fixed now. No, really. Fixed! BE FIXED!!!
[Bug translation/54067] arm-none-eabi with -mapcs and attribute((interrupt)) generates wrong stack alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54067 --- Comment #1 from Richard Earnshaw 2012-07-23 10:00:41 UTC --- The -mapcs option isn't expected to work on AAPCS based targets. We should fix the compiler to reject this combination.
[Bug fortran/54070] New: Wrong code with allocatable deferred-length (array) function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Bug #: 54070 Summary: Wrong code with allocatable deferred-length (array) function results Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: dam...@rouson.net, pa...@gcc.gnu.org As reported by Damian at http://gcc.gnu.org/ml/fortran/2012-07/msg00117.html , allocatable deferred-length (array) function results have issues. The following code gives a segfault - or with tree checking: gfc_add_modify_loc, at fortran/trans.c:160 function f() character(len=:),allocatable :: f f ="ABC" end function The following (invalid) program gives an ICE: in gimplify_var_or_parm_decl, at gimplify.c:2048 (the program is invalid as one assigns a scalar to an unallocated array) function f(a) character(len=*) :: a character(len=:),allocatable :: f(:) f = a end function One gets the same ICE for the original example. Looking at the dump, there is no (re)allocation - but there should be one! module deferred_length_char_array contains function return_string(argument) character(*) :: argument character(:), dimension(:), allocatable :: return_string return_string = argument end function end module
[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881 --- Comment #12 from Steven Bosscher 2012-07-23 09:26:46 UTC --- Author: steven Date: Mon Jul 23 09:26:41 2012 New Revision: 189779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189779 Log: gcc/ PR tree-optimization/53881 * tree-cfg.c (group_case_labels_stmt): Look up the basic block for each label and compare them instead of labels. testsuite/ PR tree-optimization/53881 * gcc.dg/pr53881.c: Renamed to ... * gcc.dg/pr53881-1.c: ... this. * gcc.dg/pr53881-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr53881-1.c - copied unchanged from r189758, trunk/gcc/testsuite/gcc.dg/pr53881.c trunk/gcc/testsuite/gcc.dg/pr53881-2.c Removed: trunk/gcc/testsuite/gcc.dg/pr53881.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug plugins/54069] linkage type of plugin API wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54069 --- Comment #3 from Jonathan Wakely 2012-07-23 08:49:16 UTC --- (In reply to comment #0) > Looking at the generated compiler (libgcc, gcc-executable, etc.) it seems that > presumably all functions from tree.h, input.h, and many others seem to have > C++-linkage though they are part of a C-API. They're not part of a C API, they're part of a C++ API.
[Bug plugins/48425] installed plugin headers fail to compile, include non-existent files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48425 Andrew Pinski changed: What|Removed |Added Severity|critical|normal
[Bug plugins/53258] Many symbols cannot lookup when loading plugin in configured with --enable-build-with-cxx.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53258 Andrew Pinski changed: What|Removed |Added CC||wein...@gns-mbh.com --- Comment #3 from Andrew Pinski 2012-07-23 08:46:22 UTC --- *** Bug 54069 has been marked as a duplicate of this bug. ***
[Bug plugins/54069] linkage type of plugin API wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54069 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Severity|major |normal --- Comment #2 from Andrew Pinski 2012-07-23 08:46:22 UTC --- This is expected. See PR 53258. *** This bug has been marked as a duplicate of bug 53258 ***
[Bug plugins/54069] linkage type of plugin API wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54069 --- Comment #1 from wein...@gns-mbh.com 2012-07-23 08:39:51 UTC --- oh... forgot to mention... system is: linux x86-64 (openSuSe 10.3)
[Bug plugins/54069] New: linkage type of plugin API wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54069
Bug #: 54069
Summary: linkage type of plugin API wrong
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wein...@gns-mbh.com
Created attachment 27856
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27856
plugin source
gcc 4.7.0 and 4.7.1
created with:
./configure --prefix=/usr/local --program-suffix=-4.7.1 --with-mpc=/usr/local
--with-mpfr=/usr/local --with-gmp=/usr/local --enable-serial-configure
--enable-languages=c,c++,fortran,objc,obj-c++
plugin (see attached source) compiled with:
gcc-4.7.1 -I`gcc -print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o
plugin.so
try to use with:
gcc-4.7.1 -fplugin=./plugin.so test.c
where test.c is simply:
int main(int argc, char *argv[]) { return 0; }
or may be any other source, doesn't matter, the test plugin does nothing...
generates following error lines:
cc1: error: cannot load plugin ./plugin.so
./plugin.so: undefined symbol: list_length
Looking at the generated compiler (libgcc, gcc-executable, etc.) it seems that
presumably all functions from tree.h, input.h, and many others seem to have
C++-linkage though they are part of a C-API. Using
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
declarations
#ifdef __cplusplus
} /* extern "C" */
#endif /* __cplusplus */
in those headers cures the problem (after long recompile)...
the function used in the plugin is only example, there are tons(!!) of others
there that have the same problem..
it would be great if you could restore ability to use C for the plugin-API..
thanks...
[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/54068] Compiler passes wrong argument to function when using optimize attribute with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54068
Richard Guenther changed:
What|Removed |Added
Target||i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-07-23
CC||hubicka at gcc dot gnu.org
Ever Confirmed|0 |1
Known to fail||4.4.7, 4.5.4, 4.6.3, 4.7.1,
||4.8.0
--- Comment #1 from Richard Guenther 2012-07-23
08:25:58 UTC ---
Confirmed. Note that I would not expect
void myfn (int a, int b) __attribute__((optimize("-O3")));
to work reliably. Attribute optimize is supposed to be used for debugging
only. C testcase, compile with -O0 -m32:
extern void abort (void);
void myfn (int a, int b) __attribute__((optimize("-O3")));
static inline void showme (int b)
{
if (b != 12)
abort ();
}
void myfn (int a, int b)
{
showme (b);
}
int main ()
{
myfn (5, 12);
return 0;
}
I suppose this is the known issue with tail-call optimization which
may get upset if you have parts compiled with -O0 and parts with -O3.
[Bug c++/54053] [4.7 Regression] g++ accepts (invalid?) ""0; expression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54053 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #40 from Richard Guenther 2012-07-23 08:12:55 UTC --- tree if-conversion happily executes both arms of the conditional unconditionally with -ffast-math, so for example if (x != 0) tem = y / x; else tem = 0.; ... do sth with tem ... will execute y / x unconditionally based on the fact that it cannot trap. So simply generation of NaNs is not what you should check for, but "usage" of 'tem' with NaN in the above should be (it shouldn't be used if x is zero).
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #20 from Jonathan Wakely 2012-07-23 08:11:48 UTC --- The vtable should be defined in the same file as ctype::~ctype() i.e. in libstdc++-v3/src/c++98/ctype.cc You could try adding this to ctype.cc around line 54 inline template class ctype; That's a GCC extension that explicitly instantiates the vtable.
