[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51105 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-11-15 08:34:33 UTC --- Please fill in (host and) target fields. I can confirm a wider range for cris-elf cross from x86_64-*-linux*; same behavior and log message (FWIW due to breakage in the tree my observed range is wider, 181187:181254). I have no doubt the regression occurred in 181189:181208 as per the archive link; I'll bisect from that.
[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113
--- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-11-15 08:36:01 UTC ---
Take the first error as an example:
jsoptparse.i_o:jsoptparse.cpp:function vtable for
js::cli::detail::StringOption: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol '_ZN2js3cli6detail12StringOptionD1Ev' is not defined
locally
% c++filt _ZN2js3cli6detail12StringOptionD1Ev
js::cli::detail::StringOption::~StringOption()
This is a virtual destructor that is defined in js/src/shell/jsoptparse.h:
struct StringOption : public ValuedOption
{
const char *value;
StringOption(char shortflag, const char *longflag, const char *help, const
char *metavar)
: ValuedOption(OptionKindString, shortflag, longflag, help, metavar),
value(NULL)
{}
virtual ~StringOption() {}
};
This header is included in js/src/shell/jsoptparse.c. And in there you
find the following line:
StringOption *so = OffTheBooks::new_StringOption(1, name, help, (const char
*) NULL);
[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113 --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-11-15 08:57:41 UTC --- % c++ -o jsoptparse.i_o -c -I../../../dist/system_wrappers_js -include /var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DOSTYPE=\Linux3.2\ -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I.. -I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/usr/include/nspr -fPIC -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native -Wno-delete-non-virtual-dtor -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-generate -O3 -fomit-frame-pointer -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/jsoptparse.pp /var/tmp/mozilla-central/js/src/shell/jsoptparse.cpp Compiled with gcc-4.7.0: % readelf -lSW moz-build-dir/js/src/shell/jsoptparse.i_o | grep 12StringOption [61] .text._ZN2js3cli6detail12StringOptionD0Ev PROGBITS 0041e0 6a 00 AXG 0 0 32 [62] .rela.text._ZN2js3cli6detail12StringOptionD0Ev RELA 01a350 000108 18 207 61 8 [63] .text._ZN2js3cli6detail12StringOptionD2Ev PROGBITS 004260 5b 00 AXG 0 0 32 [64] .rela.text._ZN2js3cli6detail12StringOptionD2Ev RELA 01a458 d8 18 207 63 8 [108] .bss.__gcov0__ZN2js3cli6detail12StringOptionD0Ev NOBITS 006470 10 00 WAG 0 0 16 [109] .data.rel.ro._ZTVN2js3cli6detail12StringOptionE PROGBITS 006480 30 00 WAG 0 0 32 [110] .rela.data.rel.ro._ZTVN2js3cli6detail12StringOptionE RELA 01c9a8 60 18 207 109 8 [113] .bss.__gcov0__ZN2js3cli6detail12StringOptionD2Ev NOBITS 0064f0 08 00 WAG 0 0 8 [161] .data.rel.local.__gcov___ZN2js3cli6detail12StringOptionD0Ev PROGBITS 006d00 38 00 WAG 0 0 32 [162] .rela.data.rel.local.__gcov___ZN2js3cli6detail12StringOptionD0Ev RELA 01d6c8 30 18 207 161 8 [163] .data.rel.local.__gcov___ZN2js3cli6detail12StringOptionD2Ev PROGBITS 006d40 38 00 WAG 0 0 32 [164] .rela.data.rel.local.__gcov___ZN2js3cli6detail12StringOptionD2Ev RELA 01d6f8 30 18 207 163 8 Compiled with gcc-4.6.2: % readelf -lSW moz-build-dir/js/src/shell/jsoptparse.i_o | grep 12StringOption [48] .text._ZN2js3cli6detail12StringOptionD0Ev PROGBITS 003aa0 50 00 AXG 0 0 32 [49] .rela.text._ZN2js3cli6detail12StringOptionD0Ev RELA 00f4d0 d8 18 100 48 8 [50] .text._ZN2js3cli6detail12StringOptionD2Ev PROGBITS 003b00 41 00 AXG 0 0 32 [51] .rela.text._ZN2js3cli6detail12StringOptionD2Ev RELA 00f5a8 a8 18 100 50 8 [88] .data.rel.ro._ZTVN2js3cli6detail12StringOptionE PROGBITS 004b60 30 00 WAG 0 0 32 [89] .rela.data.rel.ro._ZTVN2js3cli6detail12StringOptionE RELA 010580 60 18 100 88 8
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-11-15 09:01:50 UTC --- Author: gjl Date: Tue Nov 15 09:01:46 2011 New Revision: 181378 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181378 Log: gcc/ PR target/49868 * config/avr/avr.h (ADDR_SPACE_PGM): New address spaces. (REGISTER_TARGET_PRAGMAS): New define. * config/avr/avr-protos.h (avr_mem_pgm_p): New. (avr_load_libgcc_p): New. (asm_output_external_libcall): Remove. (avr_register_target_pragmas): New. (avr_log_t): Add field progmem. Order alphabetically. * config/avr/avr-log.c (avr_log_set_avr_log): Set avr_log.progmem. * config/avr/avr-c.c (langhooks.h): New include. (avr_register_target_pragmas): New function. Register address space __pgm. (avr_cpu_cpp_builtins): Add built-in define __PGM. * config/avr/avr.c: Include c-family/c-common.h. (TARGET_LEGITIMATE_ADDRESS_P): Remove define. (TARGET_LEGITIMIZE_ADDRESS): Remove define. (TARGET_ADDR_SPACE_SUBSET_P): Define to... (avr_addr_space_subset_p): ...this new static function. (TARGET_ADDR_SPACE_CONVERT): Define to... (avr_addr_space_convert): ...this new static function. (TARGET_ADDR_SPACE_ADDRESS_MODE): Define to... (avr_addr_space_address_mode): ...this new static function. (TARGET_ADDR_SPACE_POINTER_MODE): Define to... (avr_addr_space_pointer_mode): ...this new static function. (TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P): Define to... (avr_addr_space_legitimate_address_p): ...this new static function. (TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS): Define to... (avr_addr_space_legitimize_address): ...this new static function. (avr_mode_code_base_reg_class): Handle address spaces. (avr_regno_mode_code_ok_for_base_p): Ditto. (lpm_addr_reg_rtx, lpm_reg_rtx, all_regs_rtx): New static variables. (avr_option_override): Initialize them. (output_reload_in_const): Use all_regs_rtx. Fix signedness of loop variables. (avr_pgm_segment): New static function. (avr_decl_pgm_p, avr_mem_pgm_p): New static functions. (avr_out_lpm, avr_out_lpm_no_lpmx): New static functions. (output_movqi, output_movhi, output_movsisf, avr_out_movpsi): Call avr_out_lpm to handle loads from progmem. (avr_load_libgcc_p): New static function. (avr_progmem_p): Test if decl is in flash. (avr_pgm_pointer_const_p): New static function. (avr_nonconst_pointer_addrspace): New static function. (avr_pgm_check_var_decl): New static function. (avr_insert_attributes): Use it. Change error message to report cause (progmem or address space) when code wants to write to flash. (avr_section_type_flags): Unset section flag SECTION_BSS for data in progmem. * config/avr/predicates.md (nop_general_operand): New predicate. (nox_general_operand): New predicate. * config/avr/avr.md (LPM_REGNO): New define_constant. (loadmode_libgcc): New expander. (*load.mode.libgcc): New insn. (movmode): Handle loads from non-generic AS. (movmemhi): Ditto. Propagate address space information to newly created MEM. (movqi_insn, *movhi, *movpsi, *movsi, *movsf): Change predicate #1 to nox_general_operand. (ashrqi3, ashrhi3, ashrsi3): Change predicate #1 to nop_general_operand. (ashlqi3, *ashlqi3, ashlhi3, ashlsi3): Ditto. (lshrqi3, *lshrqi3, lshrhi3, lshrsi3): Ditto. (split-lpmx): New split. (*ashlhi3_const, *ashlsi3_const, *ashrhi3_const, *ashrsi3_const, *lshrhi3_const, *lshrsi3_const): Indent, unquote C. libgcc/ PR target/49868 * config/avr/t-avr (LIB1ASMFUNCS): Add _load_3, _load_4. * config/avr/lib1funcs.S (__load_3, __load_4, __xload_2): New functions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-log.c trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S trunk/libgcc/config/avr/t-avr
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2011-11-15 09:34:00 UTC --- (In reply to comment #16) --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2011-11-14 08:47:16 UTC --- Created attachment 25814 [details] -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25814 adjustment to final.c (just a heads up) although not a bootstrap issue, this revision also caused a fair number of regressions at m64 on i686/powerpc-darwin9. This is where the m32 target has an m64 multilib. I am testing the patch on *-darwin9 and x86-64-darwin10. The patch fixes those particular fails for me on *-darwin9, if it works for you then should it be posted - or does Jason want to amend?
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 09:35:58 UTC --- Thanks. At the moment we don't really have infrastructure to use the whole gsl when running the testsuite (some time ago I adapted a few bits in testsuite_tr1), for now I guess we are going to just apply the patchlet. Looking forward we may want to figure out something..
[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113
--- Comment #7 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-11-15 10:03:05 UTC ---
Here is a small testcase:
% cat test.ii
extern C
{
typedef long unsigned int size_t;
}
extern C
{
static inline void *js_malloc (size_t bytes)
{
}
}
namespace std
{
typedef long unsigned int size_t;
}
extern C++
{
inline void *operator new (std::size_t, void *__p) throw ()
{
}
class OffTheBooks
{
public:
template class T
__attribute__ ((always_inline)) inline static T *new_ () {
}
template class T, class P1, class P2, class P3, class P4
__attribute__ ((always_inline)) inline static T *new_
(P1 p1, P2 p2, P3 p3, P4 p4)
{
void *memory =::js_malloc (sizeof (T));
return memory ? new (memory) T (p1, p2, p3, p4) : __null;
}
};
}
enum OptionKind {
OptionKindBool, OptionKindString, OptionKindInt,
OptionKindMultiString, OptionKindInvalid
};
struct Option {
const char *longflag;
const char *help;
OptionKind kind;
char shortflag;
bool terminatesOptions;
Option (OptionKind kind, char shortflag, const char *longflag,
const char *help):longflag (longflag),
help (help),
kind (kind),
shortflag (shortflag),
terminatesOptions (false) {
}
};
struct ValuedOption:public Option {
const char *metavar;
ValuedOption (OptionKind kind, char shortflag, const char *longflag,
const char *help, const char *metavar):Option (kind,
shortflag,
longflag,
help),
metavar (metavar) {
}
virtual ~ ValuedOption () = 0;
};
struct StringOption:public ValuedOption {
const char *value;
StringOption (char shortflag, const char *longflag,
const char *help, const char *metavar)
:ValuedOption (OptionKindString, shortflag, longflag,
help, metavar), value (__null) { }
virtual ~StringOption() {}
};
class OptionParser
{
bool addStringOption (char shortflag, const char *longflag,
const char *help, const char *metavar);
};
bool
OptionParser::addStringOption (char shortflag, const char *longflag,
const char *metavar, const char *help)
{
StringOption *so =
OffTheBooks::new_ StringOption (shortflag, longflag, help, metavar);
}
With commit 5014df5d02d9d9 reverted:
% c++ -shared -w -o /dev/null -fPIC -fno-rtti -pthread -pipe
-fprofile-generate -O0 test.ii
%
With your patch:
% c++ -shared -w -o /dev/null -fPIC -fno-rtti -pthread -pipe
-fprofile-generate -O0 test.ii
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZnwmPv' which may overflow at runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZN6OptionC2E10OptionKindcPKcS2_' which may overflow at runtime;
recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZN12ValuedOptionC2E10OptionKindcPKcS2_S2_' which may overflow at
runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZN12StringOptionC2EcPKcS1_S1_' which may overflow at runtime;
recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZN12StringOptionD2Ev' which may overflow at runtime; recompile with
-fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZN12StringOptionD0Ev' which may overflow at runtime; recompile with
-fPIC
collect2: error: ld returned 1 exit status
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-15 Ever Confirmed|0 |1 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 10:05:00 UTC --- s/testsuite_tr1/testsuite_random.h Anyway, looking forward, I think it would be great if we could have a compact, reliable (speed isn't a major requirement) integration routine, adapted from GSL or elsewhere GNU of course. In terms of testsuite infrastructure, we could do a lot with it.
[Bug c++/51138] [C++0x] [4.6 Regression] Uninitialized list elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51138
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-11-15
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15
10:08:44 UTC ---
Confirmed.
With -std=c++0x the constructor calls this with an empty parameter pack:
templatetypename... _Args
void
emplace_back(_Args... __args)
{ this-_M_insert(end(), std::forward_Args(__args)...); }
which calls allocator::construct with an empty pack:
_M_get_Node_allocator().construct(__p,
std::forward_Args(__args)...);
which does
templatetypename... _Args
void
construct(pointer __p, _Args... __args)
{ ::new((void *)__p) _Tp(std::forward_Args(__args)...); }
[Bug tree-optimization/51117] [4.7 regression] rev.181172 causes glibc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com 2011-11-15 10:32:30 UTC --- I see the same problem. Anybody else met this issue?
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-15 10:49:23 UTC --- Author: paolo Date: Tue Nov 15 10:49:20 2011 New Revision: 181382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181382 Log: 2011-11-15 Jason Dick dick...@gmail.com PR libstdc++/51133 * include/tr1/poly_hermite.tcc (__poly_hermite_recursion): Fix wrong sign in recursion relation. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/tr1/poly_hermite.tcc
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-15 10:49:04 UTC --- Author: paolo Date: Tue Nov 15 10:49:00 2011 New Revision: 181381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181381 Log: 2011-11-15 Jason Dick dick...@gmail.com PR libstdc++/51133 * include/tr1/poly_hermite.tcc (__poly_hermite_recursion): Fix wrong sign in recursion relation. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/poly_hermite.tcc
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 10:51:42 UTC --- Fixed mainline and 4.6.3.
[Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51078 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 10:52:36 UTC --- I guess we can close this.
[Bug c++/51138] [C++0x] [4.6 Regression] Uninitialized list elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51138 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 10:56:16 UTC --- Maybe we can save time by asking HJ to find the patch which fixed it in mainline...
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 Jason Dick dickphd at gmail dot com changed: What|Removed |Added Attachment #25823|0 |1 is obsolete|| --- Comment #10 from Jason Dick dickphd at gmail dot com 2011-11-15 10:57:49 UTC --- Created attachment 25825 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25825 New test case for hermite() using only standard library Okay, I've coded up a really quick and dirty recursive integration routine and used that instead of the GSL routine. This routine is much slower and less accurate, but it works more or less. The only difficulty is that this particular integration routine isn't able to guarantee the total error very well. But as long as you use a tolerance on the integration that is a few orders of magnitude better than you check, the result works well enough. Here I've used a tolerance of 1e-10, and checked to ensure that the results agree with the expected value at 1e-7. With these parameters, and an integration range of -16.5 to 16.6, I get the expected result up to n=104 (after which an inf is encountered in the integration). As I understand it, you need to be much more clever to produce an integration routine that is able to guarantee total error even on very complex functions. This routine is also susceptible to the possibility of choosing integration values that just happen to be zero, even though the rest of the integration interval is far from zero (this is why my integration interval is not even). If you would like, I would happily support the use of this very simple integration function. If this is not good enough as it is, I wouldn't mind putting a little bit of work into implementing a more complicated routine. I am a bit unfamiliar with the practices and conventions at use within GNU development, though. So please let me know if anything in particular would be required on my part to do this. P.S. I've also noticed that I (foolishly) used both the names hermite_test and test_hermite, so I've fixed that to only use the name hermite_test.
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 11:04:51 UTC --- Thanks, but please, instead of doing this here, for this specific testcase, please collaborate with Ed at integrating this code in the testsuite.
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 --- Comment #12 from Jason Dick dickphd at gmail dot com 2011-11-15 11:08:16 UTC --- (In reply to comment #11) Thanks, but please, instead of doing this here, for this specific testcase, please collaborate with Ed at integrating this code in the testsuite. Sounds good!
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 11:11:47 UTC --- If we do this as part of the general testsuite infrastructure we can also afford having a little more code, separate out-of-line functions, etc. But the code must be formatted according to the GNU rules, etc, Ed knows how to do that.
[Bug c++/51139] New: c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139
Bug #: 51139
Summary: c++11 alias-declarations doasn't work contrary to
relase notes
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@comsulting.de
According to the 4.7 release notes (http://gcc.gnu.org/gcc-4.7/changes.html)
the C++11 feature alias-declarations should work.
However I was not able to compile the example given in the release notes above:
-
template class T using Ptr = T*;
Ptrint ip; // decltype(ip) is int*
-
I get this error:
-
error: expected unqualified-id before 'using'
error: 'Ptr' does not name a type
-
I tried the other C++11 examples like
constexpr long double operator _degrees (long double d) { return d * 0.0175;
}
long double pi = 180_degrees;
and
-
struct A {
int i = 42;
} a; // initializes a.i to 42
-
which all work fine.
This is the output of the version information:
---
/opt/gcc-4.7/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.7/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-4.7/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/gcc-4.7 --enable-languages=c,c++
--enable-threads=posix --enable-tls --enable-libgomp --enable-lto --disable-nls
--disable-checking --disable-multilib --disable-bootstrap
Thread model: posix
gcc version 4.7.0 2005 (experimental) (GCC)
It's an ubuntu system (11.10 64Bit). I compiled the gcc from the then newest
snapshot.
[Bug c++/51139] c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 11:32:21 UTC --- it was only implemented on the 7th, your compiler is too old http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114#c13
[Bug c++/51139] c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|critical|normal --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 11:33:52 UTC --- and severity is never critical for a brand new feature (in the C++11 mode still labelled experimental) in an unreleased compiler
[Bug c++/51139] c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139 --- Comment #3 from Sven Passig sp at comsulting dot de 2011-11-15 11:36:53 UTC --- (In reply to comment #2) and severity is never critical for a brand new feature (in the C++11 mode still labelled experimental) in an unreleased compiler ah ok, thanks for clarifying
[Bug c++/51139] c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139 --- Comment #4 from Sven Passig sp at comsulting dot de 2011-11-15 11:42:45 UTC --- (In reply to comment #1) it was only implemented on the 7th, your compiler is too old http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114#c13 Thanks for this ultrafast answer on this. I tried to figure out this by myself but my svn client is still downloading the subversion log for commit commends (there seams to be no online source of the commit log).
[Bug libfortran/51119] MATMUL slow for large matrices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2011-11-15 12:19:59 UTC --- (In reply to comment #1) I have a cunning plan. It is doable to come within a factor of 2 of highly efficient implementations using a cache-oblivious matrix multiply, which is relatively easy to code. I'm not sure this is worth the effort. I believe it would be more important to have actually highly efficient (inlined) implementations for very small matrices. These would outperform general libraries by a large factor. For CP2K I have written a specialized small matrix multiply library generator which generates code that outperforms e.g. MKL by a large factor for small matrices (32x32). The generation time and library size do not make it a general purpose tool. It also contains an implementation of the recursive multiply of some sort (see http://cvs.berlios.de/cgi-bin/viewvc.cgi/cp2k/cp2k/tools/build_libsmm/)
[Bug libfortran/51119] MATMUL slow for large matrices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2011-11-15 12:31:10 UTC --- Created attachment 25826 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25826 comparison in performance for small matrix multiplies (libsmm vs mkl) added some data showing the speedup of specialized matrix multiply code (small matrices, known bounds, in cache) against general dgemm (mkl).
[Bug libstdc++/51140] New: libstdc++-v3/libsupc++/eh_tm.cc:48: undefined reference to `___sync_sub_and_fetch_4'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51140 Bug #: 51140 Summary: libstdc++-v3/libsupc++/eh_tm.cc:48: undefined reference to `___sync_sub_and_fetch_4' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: cestra...@gmail.com Host: i386-pc-mingw32 Target: i386-pc-mingw32 Build: i386-pc-mingw32 Building 4.7.0 (trunk) on i368-pc-mingw32 fails with: Creating library file: .libs/libstdc++.dll.a../libsupc++/.libs/libsupc++convenience.a(eh_tm.o): In function `free_any_cxa_exception': c:\projetos\gcc\bld\svn\bld\mingw32\libstdc++-v3\libsupc++/../../../../../../gcc-svn/libstdc++-v3/libsupc++/eh_tm.cc:48: undefined reference to `___sync_sub_and_fetch_4' collect2.exe: error: ld returned 1 exit status make[5]: *** [libstdc++.la] Error 1 make[5]: Leaving directory `/projetos/gcc/bld/svn/bld/mingw32/libstdc++-v3/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/projetos/gcc/bld/svn/bld/mingw32/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/projetos/gcc/bld/svn/bld/mingw32/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/projetos/gcc/bld/svn/bld' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/projetos/gcc/bld/svn/bld' make: *** [all] Error 2 The line in question is: if (__sync_sub_and_fetch (h-referenceCount, 1) == 0) There is another use of __sync_sub_and_fetch in libstdc++-v3/libsupc++/eh_tm.cc, and there it is guarded by a #ifdef _GLIBCXX_ATOMIC_BUILTINS_4, which is undefined in my case. I guess this guard is missing from eh_tm.cc. $ gcc -v Using built-in specs. COLLECT_GCC=\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,obj c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo mp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r untime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.2 (GCC)
[Bug target/51134] [4.7 Regression] FAIL: gfortran.fortran-torture/execute/arrayarg.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #3 from Jan Hubicka hubicka at ucw dot cz 2011-11-15 12:37:07 UTC --- gfortran.fortran-torture/execute/arrayarg.f90 is miscompiled. There are 4 expanded memset calls in the testcase, all ends up being unrolled loop. Looks like we misoptmize one of them. I am looking into that. Honza
[Bug libstdc++/51140] libstdc++-v3/libsupc++/eh_tm.cc:48: undefined reference to `___sync_sub_and_fetch_4'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51140 --- Comment #1 from Cesar Strauss cestrauss at gmail dot com 2011-11-15 12:39:50 UTC --- (In reply to comment #0) There is another use of __sync_sub_and_fetch in libstdc++-v3/libsupc++/eh_tm.cc, I meant libstdc++-v3/libsupc++/eh_throw.cc. and there it is guarded by a #ifdef _GLIBCXX_ATOMIC_BUILTINS_4, which is undefined in my case. I guess this guard is missing from eh_tm.cc.
[Bug c++/51139] c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 12:40:22 UTC --- All commits are sent to http://gcc.gnu.org/ml/gcc-cvs/ Or you can look at http://gcc.gnu.org/viewcvs/ at the ChangeLog files. e.g. for the C++ front end: http://gcc.gnu.org/viewcvs/trunk/gcc/cp/ChangeLog (although sometimes fetching that page times out because there are a LOT of revisions to that file)
[Bug c++/51139] c++11 alias-declarations doasn't work contrary to relase notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51139 --- Comment #6 from Sven Passig sp at comsulting dot de 2011-11-15 12:44:45 UTC --- (In reply to comment #5) http://gcc.gnu.org/viewcvs/trunk/gcc/cp/ChangeLog (although sometimes fetching that page times out because there are a LOT of revisions to that file) thanks a lot again, this is a great ressource. It was very easy to find the alias-declaration entry and the further changes on this feature.
[Bug libstdc++/51133] Incorrect implementation of std::tr1::hermite()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51133 --- Comment #14 from Ed Smith-Rowland 3dw4rd at verizon dot net 2011-11-15 12:48:06 UTC --- I'm glad to see renewed interest in this. I wasn't sure if anyone else had used these routines ;-) Anyway, one thing I would like us to look at is ISO/IEC 29123 which is out as of last year. This basically injects these TR1 math functions (excepting the hypergeometric functions) into namespace std. I'll open a separate email thread about that though.
[Bug libstdc++/51140] libstdc++-v3/libsupc++/eh_tm.cc:48: undefined reference to `___sync_sub_and_fetch_4'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51140 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 13:12:20 UTC --- That guard should be added to eh_tm.cc but ... don't build for i386-* because that targets the 80386 processor, which doesn't have the required atomic operations, and I *really doubt you're running on an 80386 so there's no reason to unnecessary cripple your code. you should configure for i486-pc-mingw32 or better, whatever is the lowest spec you want to be able to run the generated code on
[Bug target/51134] [4.7 Regression] FAIL: gfortran.fortran-torture/execute/arrayarg.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2011-11-15 13:28:42 UTC
---
Hi,
the bug is loopy epilogue not being used because promoted value is not
availbale. The non-loopy epilogue does not expect alignments
greater than 16.
I am testing the following patch.
I think we might still have bugs for blocks 8 16. Will try to produce
testcase.
Honza
Index: config/i386/i386.c
===
--- config/i386/i386.c(revision 181357)
+++ config/i386/i386.c(working copy)
@@ -23073,13 +23073,13 @@ ix86_expand_setmem (rtx dst, rtx count_e
rtx tmp;
if (align_unknown unroll_factor 1
epilogue_size_needed = GET_MODE_SIZE (move_mode)
- vec_promoted_val)
+ (vec_promoted_val || gpr_promoted_val))
{
/* Reduce epilogue's size by creating not-unrolled loop. If we won't
do this, we can have very big epilogue - when alignment is statically
unknown we'll have the epilogue byte by byte which may be very slow.
*/
loop_iter = expand_set_or_movmem_via_loop_with_iter (dst, NULL, destreg,
- NULL, vec_promoted_val, count_exp,
+ NULL, vec_promoted_val ? vec_promoted_val : gpr_promoted_val,
count_exp,
loop_iter, move_mode, 1,
expected_size, false);
dst = change_address (dst, BLKmode, destreg);
[Bug c++/51141] New: [4.7 regression] rev181359 causes Chromium build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51141
Bug #: 51141
Summary: [4.7 regression] rev181359 causes Chromium build
failure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de
Please consider:
% cat test.ii
typedef int size_t;
template size_t, size_t struct AlignedBuffer;
template size_t size struct AlignedBuffer
size, 8 {
};
template typename class VectorBufferBase
{
public:
allocateBuffer (size_t) {
}
buffer () {
}
*m_buffer;
size_t m_capacity;
};
template typename T, size_t class VectorBuffer:VectorBufferBase T
{
typedef VectorBufferBase T Base;
public:
VectorBuffer () {
}
allocateBuffer (size_t) {
m_capacity = 0;
}
Base::buffer;
Base::m_buffer;
Base::m_capacity;
size_t m_inlineBufferSize;
AlignedBuffer 0, __alignof__ (T) m_inlineBuffer;
};
template typename T, size_t class Vector
{
typedef VectorBuffer T,
0 Buffer;
public:
void shrinkCapacity (size_t);
clear () {
shrinkCapacity (0);
}
Buffer m_buffer;
};
template typename T, size_t inlineCapacity void Vector T,
inlineCapacity ::shrinkCapacity (size_t)
{
m_buffer.allocateBuffer (0);
}
struct PatternDisjunction;
struct YarrPattern {
reset () {
m_disjunctions.clear ();
}
Vector PatternDisjunction *, 0 m_disjunctions;
};
% g++ -S -fpermissive -w -Werror -O0 -pipe -c test.ii -o /dev/null
test.ii: In instantiation of ‘int VectorBufferT, anonymous
::allocateBuffer(size_t) [with T = PatternDisjunction*; int anonymous = 0;
size_t = int]’:
test.ii:52:5: required from ‘void VectorT, anonymous
::shrinkCapacity(size_t) [with T = PatternDisjunction*; int anonymous = 0;
size_t = int]’
test.ii:44:9: required from ‘int VectorT, anonymous ::clear() [with T =
PatternDisjunction*; int anonymous = 0]’
test.ii:58:31: required from here
test.ii:26:9: error: no match for ‘operator=’ in ‘#‘using_decl’ not supported
by dump_expr#expression error = 0’
test.ii:26:9: note: candidate is:
test.ii:7:29: note: VectorBufferBasePatternDisjunction*
VectorBufferBasePatternDisjunction*::operator=(const
VectorBufferBasePatternDisjunction*)
test.ii:7:29: note: no known conversion for argument 1 from ‘int’ to ‘const
VectorBufferBasePatternDisjunction*’
This happens because of:
commit 807f85cfb63c455ad591e9786293e05fe725b9ab
Author: jason jason@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Nov 14 17:55:57 2011 +
PR c++/6936
PR c++/25994
PR c++/26256
PR c++/30195
* search.c (lookup_field_1): Look through USING_DECL.
(lookup_field_r): Call lookup_fnfields_slot instead of
lookup_fnfields_1.
* semantics.c (finish_member_declaration): Remove the check that
prevents USING_DECLs from being verified by
pushdecl_class_level. Call add_method for using declarations that
designates functions if the using declaration is in a template
class. Set DECL_IGNORED_P on class-scope using declarations.
* typeck.c (build_class_member_access_expr): Handle USING_DECLs.
* class.c (check_field_decls): Keep using declarations.
(add_method): Remove two diagnostics about conflicting using
declarations.
* parser.c (cp_parser_nonclass_name): Handle USING_DECLs.
* decl.c (start_enum): Call xref_tag whenever possible.
* cp-tree.h (strip_using_decl): Declare, and reident the previous
function.
* name-lookup.c (strip_using_decl): New function.
(supplement_binding_1): Call strip_using_decl on decl and
bval. Perform most of the checks with USING_DECLs stripped. Also
check that the target decl and the target bval does not refer to
the same declaration. Allow pushing an enum multiple times in a
template class. Adjustment to diagnose using redeclarations. Call
diagnose_name_conflict.
(push_class_level_binding): Call strip_using_decl on decl and
bval. Perform most of the checks with USING_DECLs stripped. Return
true if both decl and bval refer to USING_DECLs and are dependent.
(diagnose_name_conflict): New function.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181359
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/51136] [4.7 Regression] ICE: SIGSEGV in unlink_virtual_phi (tree-flow-inline.h:427) with -O2 -fno-tree-dominator-opts (-ftree-tail-merge)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51136 --- Comment #1 from vries at gcc dot gnu.org 2011-11-15 14:00:44 UTC --- Created attachment 25827 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25827 tentative patch The problem is that in update_vuses, we're removing the def of the def-use-chain we're walking with FOR_EACH_IMM_USE_STMT/FOR_EACH_IMM_USE_ON_STMT. Postponing the removal till after we've walked all the uses fixes the problem.
[Bug tree-optimization/51136] [4.7 Regression] ICE: SIGSEGV in unlink_virtual_phi (tree-flow-inline.h:427) with -O2 -fno-tree-dominator-opts (-ftree-tail-merge)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51136 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from vries at gcc dot gnu.org 2011-11-15 14:09:38 UTC --- The problem is in update_vuses, which is obsolete since the fix for PR51005. Marking it resolved, fixed.
[Bug c++/20681] [4.4/4.5/4.6/4.7 Regression] wrong control reaches warning with switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--- Comment #31 from Dmitry G. Dyachenko dimhen at gmail dot com 2011-11-15
14:10:33 UTC ---
gcc -Wreturn-type -c r.c
r.c: In function 'bar':
r.c:8:1: warning: control reaches end of non-void function [-Wreturn-type]
enum foo { e_1 };
int bar(enum foo x)
{
switch(x) {
case e_1:
return 0;
}
}
gcc version 4.7.0 2015 (experimental) [trunk revision 181378] (GCC)
[Bug c/51101] i386-rtems fails to compile dwarf2asm.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51101 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2011-11-15 14:16:04 UTC --- Still present.. Tue Nov 15 14:08:04 UTC 2011 (revision 181384)
[Bug rtl-optimization/17838] spills are not re-used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17838 --- Comment #10 from Tom St Denis tstdenis at elliptictech dot com 2011-11-15 14:20:07 UTC --- Another update ... We've just profiled our crypto library and across the board [cipher, hashes, PK functions like RSA/ECC] GCC is a complete loser against ARMcc [r713]. And it's not that GCC is faster and that's at least a price worth paying... In most cases ARMcc and GCC are dead even [arm faster for some things, slower for others]. This is with gcc 4.4.5 and 4.5.1 on an ARM. This is not a new bug. This is not a misfeature. This is actually something worth working on. This was filed in 2004 and hasn't been addressed since ... What is the hold up? If GCC is to be used in embedded platforms it can't go around taking 150% of the stack space as it's competitors...
[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51105 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-11-15 14:19:40 UTC --- Please fill in (host and) target fields. What for? AFAICT the field should be *-*-* with lto enabled. If I fill a bug report, it is because I see it on one of the machines I use: x86_64-apple-darwin10 (181046:181258) or powerpc-apple-darwin9 (181105:181301). Then I check the bots' results at http://gcc.gnu.org/ml/gcc-testresults/2011-11/ to see if the failure is darwin/ppc specific. In the later case I fill the triplet, but I don't if the failure appears generic as this one.
[Bug c++/51141] [4.7 regression] rev181359 causes Chromium build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51141 fabien at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | --- Comment #1 from fabien at gcc dot gnu.org 2011-11-15 14:29:26 UTC --- I'll look into it this evening.
[Bug c++/20681] [4.4/4.5/4.6/4.7 Regression] wrong control reaches warning with switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--- Comment #32 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15
14:53:13 UTC ---
(In reply to comment #31)
gcc -Wreturn-type -c r.c
r.c: In function 'bar':
r.c:8:1: warning: control reaches end of non-void function [-Wreturn-type]
enum foo { e_1 };
int bar(enum foo x)
{
switch(x) {
case e_1:
return 0;
}
}
Not a bug, enum foo can have other values except e_1.
What happens if you call bar( (foo)1 ) ?
[Bug middle-end/50823] [4.7 Regression] ICE in inline_small_functions, at ipa-inline.c:1407
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50823 --- Comment #11 from Toshiro K. Ohsumi ohsumit at molbio dot mgh.harvard.edu 2011-11-15 15:13:04 UTC --- When compiling an empty program, but with a large include with many templates, I note that there is a failure at line 1421 on ipa-inline.c. However, it seems only to occur when -O2 or -O3 is set. (Are these the only times inline optimizations are performed?) Unfortunately, I do not have a small test case. The includes come out to be about 2M in size. ohsumit@mothra:~ g++ --version g++ (GCC) 4.7.0 2015 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ohsumit@mothra:~ g++ -Wall -DDEBUG -ggdb -O3 t1.cpp -o t1 t1.cpp:7:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1421 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ohsumit@mothra:~ g++ -Wall -DDEBUG -ggdb -O2 t1.cpp -o t1 t1.cpp:7:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1421 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ohsumit@mothra:~ g++ -Wall -DDEBUG -ggdb -O t1.cpp -o t1
[Bug bootstrap/51086] [4.7 regression] ICE in move_insn, at haifa-sched.c:3437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51086 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-15 15:19:45 UTC --- --- Comment #5 from Alan Modra amodra at gmail dot com 2011-11-14 22:00:20 UTC --- Please try http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01685.html Works like a charm: an all,ada,obj-c++,go bootstrap on sparc-sun-solaris2.11 just completed, and there seem to be no outstanding/unexpected testsuite failures. Thanks. Rainer
[Bug fortran/51056] [4.7 Regression][OOP] Bogus Unused module variable '__vtab_domain_Domain_container'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51056 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 #5 from janus at gcc dot gnu.org 2011-11-15 15:22:10 UTC --- Taking this. The patch in comment #4 is not particularly pretty, but at least it's simple, it works and shows no testsuite regressions. I should probably include a small comment, though.
[Bug libfortran/51119] MATMUL slow for large matrices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-15 15:47:54 UTC --- (In reply to comment #3) I believe it would be more important to have actually highly efficient (inlined) implementations for very small matrices. There's already PR 37131 for that.
[Bug tree-optimization/51117] [4.7 regression] rev.181172 causes glibc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||MOVED --- Comment #2 from Michael Matz matz at gcc dot gnu.org 2011-11-15 15:50:21 UTC --- See http://sourceware.org/bugzilla/show_bug.cgi?id=13411 for analysis and possible patch. The newly emitted calls to _Unwind_Resume suck in new object files that weren't included before leading to these multiple defined symbols. glibc needs to deal with this in one or the other way.
[Bug libstdc++/51142] New: [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 Bug #: 51142 Summary: [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG. Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Created attachment 25828 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25828 testcase $ LANG=C make g++ -Wall -std=c++0x t.cpp -c --save-temps -D_GLIBCXX_DEBUG In file included from /usr/include/c++/4.6.2/debug/map:34:0, from /usr/include/c++/4.6.2/map:66, from t.cpp:2: /usr/include/c++/4.6.2/debug/map.h: In member function 'std::__debug::map_Key, _Tp, _Compare, _Allocator::size_type std::__debug::map_Key, _Tp, _Compare, _Allocator::erase(const key_type) [with _Key = boost::variantbool, _Tp = unsigned int, _Compare = std::lessboost::variantbool , _Allocator = std::allocatorstd::pairconst boost::variantbool, unsigned int , std::__debug::map_Key, _Tp, _Compare, _Allocator::size_type = long unsigned int, std::__debug::map_Key, _Tp, _Compare, _Allocator::key_type = boost::variantbool]': t.cpp:10:15: instantiated from here /usr/include/c++/4.6.2/debug/map.h:295:6: error: call of overloaded 'erase(std::__debug::mapboost::variantbool, unsigned int::_Base_iterator)' is ambiguous /usr/include/c++/4.6.2/debug/map.h:295:6: note: candidates are: /usr/include/c++/4.6.2/bits/stl_map.h:613:7: note: std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::iterator std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::erase(std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::const_iterator) [with _Key = boost::variantbool, _Tp = unsigned int, _Compare = std::lessboost::variantbool , _Alloc = std::allocatorstd::pairconst boost::variantbool, unsigned int , std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::iterator = std::_Rb_tree_iteratorstd::pairconst boost::variantbool, unsigned int , std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::const_iterator = std::_Rb_tree_const_iteratorstd::pairconst boost::variantbool, unsigned int ] /usr/include/c++/4.6.2/bits/stl_map.h:643:7: note: std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::size_type std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::erase(const key_type) [with _Key = boost::variantbool, _Tp = unsigned int, _Compare = std::lessboost::variantbool , _Alloc = std::allocatorstd::pairconst boost::variantbool, unsigned int , std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::size_type = long unsigned int, std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::key_type = boost::variantbool] make: *** [all] Error 1
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-15 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 16:26:15 UTC --- due to the change in signature from erase(iterator) to erase(const_iterator) easily fixed by using a _Base_const_iterator in __gnu_debug::map::erase(key_type)
[Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50775
denisc at gcc dot gnu.org changed:
What|Removed |Added
CC||denisc at gcc dot gnu.org,
||vmakarov at redhat dot com
--- Comment #2 from denisc at gcc dot gnu.org 2011-11-15 16:32:58 UTC ---
Just a copy of my analysis from mailing list:
Can anyone give me some advice how to proceed with this issue?
Can be said if this is a target issue or IRA/reload flaw?
It's not a costs related problem.
I think that I can explain a problem.
I think that it's an IRA bug.
Spilling for insn 11.
Using reg 26 for reload 0
Spilling for insn 17.
Using reg 30 for reload 0
Spilling for insn 23.
Using reg 30 for reload 0
Try Assign 60(a6), cost=16000
Wrong thing starts here...
ira-color.c:4120 allocno_reload_assign (a, forbidden_regs);
changing reg in insn 2
changing reg in insn 9
changing reg in insn 13
changing reg in insn 19
Assigning 60(freq=4000) a new slot 0
Register 60 now on stack.
Call trace:
allocno_reload_assign() - assign_hard_reg() - get_conflict_profitable_regs()
The `get_conflict_profitable_regs' calculates wrong `profitable_regs[1]'
(Special for Vladimir)
AVR is an 8 bits microcontroller.
The AVR has only 3 pointer registers X, Y, and Z with the
following addressing capabilities:
*X, *X++, *--X (R27:R26, call-clobbered)
*Y, *Y++, *--Y, *(Y+const) (R28:R29, call-saved, frame pointer)
*Z, *Z++, *--Z, *(Z+const) (R30:R31, call-clobbered)
Also, all modes larger than 8 bits should start in an even register.
So, `get_conflict_profitable_regs' trying to calculate two arrays:
- profitable_regs[0] for first word of register 60(a6)
- profitable_regs[1] for second word of register 60(a6)
Values of `profitable_regs':
(gdb) p print_hard_reg_set (stderr,profitable_regs[0] , 01)
0-2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
$63 = void
(gdb) p print_hard_reg_set (stderr,profitable_regs[1] , 01)
0-2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
They are equal !
It's wrong because second word of register 60(a6) must be allocated to
odd register.
This is a wrong place in `get_conflict_profitable_regs':
...
nwords = ALLOCNO_NUM_OBJECTS (a);
for (i = 0; i nwords; i++)
{
obj = ALLOCNO_OBJECT (a, i);
COPY_HARD_REG_SET (conflict_regs[i],
OBJECT_TOTAL_CONFLICT_HARD_REGS (obj));
if (retry_p)
{
COPY_HARD_REG_SET (profitable_regs[i],
reg_class_contents[ALLOCNO_CLASS (a)]);
AND_COMPL_HARD_REG_SET (profitable_regs[i],
ira_prohibited_class_mode_regs
[ALLOCNO_CLASS (a)][ALLOCNO_MODE (a)]);
-^
}
ALLOCNO_MODE (a) is a right mode for first word (word = 8bits register)
But it's wrong mode for second word of allocno.
Even more, ALLOCNO_MODE (a) is a right mode only for whole allocno.
If we want to spill/load/store separate parts(IRA objects) of allocno
we must use mode of each part(object).
`ira_prohibited_class_mode_regs' derived only from HARD_REGNO_MODE_OK.
So, the second word of 60(a6) permitted to any register after first
word of 60(a6).
For AVR: profitable_regs[1] = profitable_regs[0] 1
Also, I have a question about the following fields of `ira_allocno':
/* The number of objects tracked in the following array. */
int num_objects;
/* An array of structures describing conflict information and live
ranges for each object associated with the allocno. There may be
more than one such object in cases where the allocno represents a
multi-word register. */
ira_object_t objects[2];
--^
The SImode for AVR consists of 4 words, but only 2 objects in allocno
structure.
Is this right ?
Denis.
[Bug target/51134] [4.7 Regression] FAIL: gfortran.fortran-torture/execute/arrayarg.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-11-15 16:34:22 UTC --- (In reply to comment #4) Hi, the bug is loopy epilogue not being used because promoted value is not availbale. The non-loopy epilogue does not expect alignments greater than 16. I am testing the following patch. I think we might still have bugs for blocks 8 16. Will try to produce testcase. I believe so. If you configure GCC for Linux/x86-64 with --with-arch=core2 --with-cpu=atom you will get gengtype: malloc.c:3840: _int_malloc: Assertion `(unsigned long)(size) = (unsigned long)(nb)' failed. make[6]: *** [s-gtype] Aborted
[Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50775 --- Comment #3 from denisc at gcc dot gnu.org 2011-11-15 16:35:05 UTC --- Created attachment 25829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25829 RA dump
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15
16:36:30 UTC ---
reduced:
#include debug/map
struct X { X(...); };
bool operator(X,X);
typedef __gnu_debug::map X, unsigned M;
int main()
{
M m;
m.erase( X() );
}
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 16:42:16 UTC --- Shouldn't we just implement LWG 2059? Very simple, by the way.
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 16:59:32 UTC --- oh yeah, I forgot about that!
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot | |com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com
Different linking behavior between g++ 4.5.2 and 4.6.1
Dear forum,
I have a problem with linking of a program I have wrote. Instead of giving
you the entire program, which is pretty large, I have prepared a basic
example that you can find attached to this message. The example uses CMake
to compile.
I have three files:
= LIB2.CPP =
#include iostream
class Lib2 {
public:
Lib2() {
std::cout Lib2 std::endl;
}
};
Lib2 lib2;
= LIB1.CPP =
#include iostream
class Lib1 {
Lib1() {
std::cout Lib1 std::endl;
}
};
= MAIN.CPP
#include iostream
int main() {
std::cout Ciao std::endl;
return 0;
}
The file lib2.cpp is compiled into a dynamic library called lib2. The file
lib1.cpp is compiled into a dynamic library called lib1 and that links to
lib2. Finally, main.cpp is compiled into an executable that links to lib1.
The dependencies are thus:
lib2 -- lib1 -- testing
Now: if I compile the program with g++ 4.5.2, the programs outputs:
Lib2
Ciao
whereas if I compile with g++ 4.6.1, the program outputs:
Ciao
For me this is a problem, as my program depends on the behavior of g++
4.5.2. I would like to ask you if:
1. this is a new feature - in which case, how do fix the problem?
2. this is a known bug - in which case I apologize for asking, but I
couldn't find it in the bug list.
Thanks a lot in advance for your help.
Cheers,
Carlo
--
View this message in context:
http://old.nabble.com/Different-linking-behavior-between-g%2B%2B-4.5.2-and-4.6.1-tp32849125p32849125.html
Sent from the gcc - bugs mailing list archive at Nabble.com.
Re: Different linking behavior between g++ 4.5.2 and 4.6.1
This is the gcc-bugs list, for automated mails from our Bugzilla database. Your email should probably have been sent to the gcc-help list. http://gcc.gnu.org/lists.html
Re: Different linking behavior between g++ 4.5.2 and 4.6.1
On Tue, Nov 15, 2011 at 9:34 AM, Carlo Pinciroli ilpi...@gmail.com wrote: Dear forum, I have a problem with linking of a program I have wrote. Instead of giving you the entire program, which is pretty large, I have prepared a basic example that you can find attached to this message. The example uses CMake to compile. I have three files: Sounds like --as-needed is the default with the linker you are using. That is GCC is not the issue but rather the defaults with the distros you are using are different. Thanks, Andrew Pinski
[Bug c++/39658] [C++0x] wrong number of template arguments in variadic template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39658
Meador Inge meadori at gmail dot com changed:
What|Removed |Added
CC||meadori at gmail dot com
--- Comment #1 from Meador Inge meadori at gmail dot com 2011-11-15 18:35:55
UTC ---
The example case really only is passing 3 arguments. A comma is missing in
between 'found_sign' and 'found_endian' on the specialization. Also, this has
nothing to do with variadic templates. You can see the same error like:
[meadori@motherbrain gnu]$ cat repros/pr39658.cpp
template bool a, bool b, bool c
struct T {};
template bool b, bool c
struct Ttrue, b c {};
[meadori@motherbrain gnu]$ ./install/bin/g++ -std=c++11 -c repros/pr39658.cpp
repros/pr39658.cpp:5:19: error: wrong number of template arguments (2, should
be 3)
repros/pr39658.cpp:2:8: error: provided for ‘templatebool a, bool b, bool c
struct T’
[Bug c++/51138] [C++0x] [4.6 Regression] Uninitialized list elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51138 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-11-15 18:36:09 UTC --- It is fixed by revision 175640: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg01131.html
Re: Different linking behavior between g++ 4.5.2 and 4.6.1
Thank you very much Andrew, your suggestion indeed solved the problem. And thanks also for your fast answer! :-) Cheers, Carlo On Tue, Nov 15, 2011 at 6:49 PM, Andrew Pinski pins...@gmail.com wrote: On Tue, Nov 15, 2011 at 9:34 AM, Carlo Pinciroli ilpi...@gmail.com wrote: Dear forum, I have a problem with linking of a program I have wrote. Instead of giving you the entire program, which is pretty large, I have prepared a basic example that you can find attached to this message. The example uses CMake to compile. I have three files: Sounds like --as-needed is the default with the linker you are using. That is GCC is not the issue but rather the defaults with the distros you are using are different. Thanks, Andrew Pinski -- Guarda l'apina che vola gaudente A questo e quel ramo lei passa radente Poi vede qualcosa, si posa su un fiore Io prendo il giornale, la schiaccio e lei muore. Invia il necrologio a ilpi...@gmail.com. Look at the bee that happily flits From tree to tree no branches she hits Then something she sees, to the flower she flies I take the newspaper, swat her and she dies. Send the necrology to ilpi...@gmail.com.
[Bug c++/51138] [C++0x] [4.6 Regression] Uninitialized list elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51138 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 19:08:43 UTC --- Ah nice, very small, thanks. But I have no idea whether the patch has dependencies. Jason?
[Bug bootstrap/51144] New: r181279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51144 Bug #: 51144 Summary: r181279 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org With revision 181279 GCC stopped bootstrapping on s390 (31 bit). genmddeps complains about a missing [ altough it is there. The s390.md file didn't change in that revision. build/genmddeps /build/regtest/gcc-bisect/gcc/config/s390/s390.md tmp-mddeps /build/regtest/gcc-bisect/gcc/config/s390/s390.md:60: expected character `[', found ` ' /build/regtest/gcc-bisect/gcc/config/s390/s390.md:60: following context is `[' s390.md: 60: (define_c_enum unspec [ Perhaps a miscompilation of genmddeps?!
[Bug c++/51143] New: [C++11][DR1159] Alias template allows class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51143
Bug #: 51143
Summary: [C++11][DR1159] Alias template allows class definition
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 2012 (experimental) in C++11 mode accepts the following program
(if variable a2 is commented out):
//---
templateint N
using A1 = struct B1 { static auto constexpr value = N; };
A10 a1;
templateclass T
using A2 = struct B2 { void f(T){} };
A2bool a2; // Causes ICE
int main() { } // Line 11
//---
If a2 is commented in (as shown) an ICE is produced:
main.cpp|11|internal compiler error: in is_base_type, at dwarf2out.c:9643
According to 7.1.6 [dcl.type] p3 both alias template definitions should be
rejected:
A type-specifier-seq shall not define a class or enumeration unless it
appears in the type-id of an alias-declaration (7.1.3) that is not the
declaration of a template-declaration.
This sentence was added to honor NB comment US 74 via:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1159
The current implementation correctly rejects enumeration definitions and
unnamed class definitions, though.
[Bug bootstrap/51144] r181279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51144 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Target||s390-ibm-linux Priority|P3 |P1 Keywords||wrong-code CC||jason at gcc dot gnu.org Host||s390-ibm-linux Build||s390-ibm-linux
[Bug middle-end/51144] r181279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51144 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build Component|bootstrap |middle-end Target Milestone|--- |4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-15 19:33:18 UTC --- IA64-hpux fails the same way according to http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01742.html .
[Bug c++/51145] New: [C++11][DR1131] Alias template in elaborated-type-specifier accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51145
Bug #: 51145
Summary: [C++11][DR1131] Alias template in
elaborated-type-specifier accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 2012 (experimental) in C++11 mode accepts the following code:
//---
struct A {};
templateclass
using X = A;
struct Xint* px;
templateint
using Y = A;
struct Y0* py;
//---
According to 7.1.6.3 [dcl.type.elab] p2 both elaborated-type-specifier usages
in the definition of px and py should be rejected:
If the identifier resolves to a typedef-name or the simple-template-id
resolves to an alias template specialization, the elaborated-type-specifier is
ill-formed.
This sentence was added to honor NB comment US 41 via:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1131
[Bug c++/51146] New: The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146
Bug #: 51146
Summary: The name clog for a global variable triggers a
segfault inside std::pow
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alpha...@hotmail.com
Adding a global variable to the code with a name like clog, while using
std::pow on a std::complexdouble triggers a segfault when std::pow is
reached. A simple example ( http://codepad.org/4Ekpgj91 ):
#include iostream
#include complex
#include cmath
int clog=0;
int main()
{
std::couttest1std::endl;
std::complexdouble b(1,-1);
std::couttest std::pow(b,2.0)std::endl;
std::couttest2std::endl;
}
This behavior has first been noticed on MinGW with gcc 4.5.2, but as soon as I
found out where the bug came from it was checked on codepad, and from various
gcc users in irc.freenode.net . I rate this bug as major because there might be
something deeper behind it.
[Bug libstdc++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |libstdc++ Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-15 19:52:04 UTC --- Well the issue is clog is a C99 name for complex log. I don't have my C++ standard in front of me but I do know some names are reserved even at the top level.
[Bug libstdc++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #2 from alpha_lc at hotmail dot com 2011-11-15 19:56:15 UTC --- (In reply to comment #1) Well the issue is clog is a C99 name for complex log. I don't have my C++ standard in front of me but I do know some names are reserved even at the top level. In case it helps on that side, I've asked a VC++ user to try this code and it worked perfectly.
[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.0 Summary|[4.7 Regression] FAIL: |[4.7 Regression] x86 |gfortran.fortran-torture/ex |memset/memcpy expansion is |ecute/arrayarg.f90 |broken
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 20:07:35 UTC --- For sure in the library there is nothing to fix, note in particular that the implementation does not include complex.h, neither names clog, only __builtin_clog.
[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113
--- Comment #8 from Nathan Sidwell nathan at acm dot org 2011-11-15 20:12:33
UTC ---
On 11/15/11 10:03, markus at trippelsdorf dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113
With your patch:
% c++ -shared -w -o /dev/null -fPIC -fno-rtti -pthread -pipe
-fprofile-generate -O0 test.ii
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
'__gcov0__ZnwmPv' which may overflow at runtime; recompile with -fPIC
Ok, I think I understand what's going on here. Here's a piece of code to
explain:
inline int *Foo ()
{
static int x = 2;
return x;
}
int *(*Bar ()) ()
{
return Foo;
}
although Foo::x is in the same comdat group as Foo, it is separately
overridable
at load time by another shared object. (of course such overriding completely
breaks language semantics, but not ELF semantics). The linker's adhering to
ELF
semantics, and in this example the compiler emits:
movq_ZZ3FoovE1x@GOTPCREL(%rip), %rax
to get Foo::x's address. In the gcov case, it's emitting:
movq__gcov0_js_malloc(%rip), %rax
to access the first counter value. Although I think that's ok in a well-formed
program, it's confusing the linker. that's unfortunate. (If you compile the
above example with -fprofile-generate you'll see different access sequences for
_ZZ3FoovE1x and __gcov0__Z3Foov.)
I'm going to have to figure out why the right PIC sequence isn't being emitted.
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 20:26:23 UTC --- I suppose, yes.
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-15 20:20:48 UTC --- (In reply to comment #3) For sure in the library there is nothing to fix, note in particular that the implementation does not include complex.h, neither names clog, only __builtin_clog. But __builtin_clog always expands to extern C clog. There is not much to be done in the compiler here or libstdc++ really. Just have to understand clog is a reserved name under C99.
[Bug c++/51145] [C++11][DR1131] Alias template in elaborated-type-specifier accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51145 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC|jason at redhat dot com |dodji at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-11-15 20:30:38 UTC --- Please add Dodji to CC for alias issues.
[Bug c++/51143] [C++11][DR1159] Alias template allows class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51143 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC|jason at redhat dot com |dodji at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-11-15 20:32:02 UTC --- Also, please use ja...@gcc.gnu.org for me in Bugzilla, thanks.
[Bug c++/51138] [C++0x] [4.6 Regression] Uninitialized list elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51138 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-11-15 20:58:12 UTC --- Backporting that patch doesn't fix the testcase in 4.6.
[Bug bootstrap/48879] Compilation cannot find file asm/errno.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48879 davek at 6thstreetradio dot org changed: What|Removed |Added CC||davek at 6thstreetradio dot ||org --- Comment #6 from davek at 6thstreetradio dot org 2011-11-15 21:11:04 UTC --- On Ubuntu 11.10 (oneiric), linux-libc-dev installs to /usr/include/i386-linux-gnu (or whatever your arch is, I suspect). In order to get gcc to build, I had to symlink the dir: sudo ln -s /usr/include/i386-linux-gnu/asm /usr/include/asm Whether it's a bug in ubuntu gcc, or the libc-dev package, I dunno.
[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113 Nathan Sidwell nathan at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-15 Ever Confirmed|0 |1
[Bug bootstrap/51006] bootstrap fails on NetBSD 5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51006 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||kristerw at gcc dot ||gnu.org, thorpej at gcc dot ||gnu.org --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 21:47:12 UTC --- CCing NetBSD maintainers - do you guys know if the patch attached to this bug is correct for all versions of NetBSD? It works for netbsd5.1 which is all I have access to.
[Bug rtl-optimization/51051] [4.7 Regression]: build fails on cris-elf building libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51051 --- Comment #9 from Alan Modra amodra at gcc dot gnu.org 2011-11-15 22:10:51 UTC --- Author: amodra Date: Tue Nov 15 22:10:46 2011 New Revision: 181391 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181391 Log: PR rtl-optimization/51051 PR bootstrap/51086 * function.c (thread_prologue_and_epilogue_insns): Guard emitting return with single_succ_p test. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug rtl-optimization/51051] [4.7 Regression]: build fails on cris-elf building libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51051 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Alan Modra amodra at gmail dot com 2011-11-15 22:11:25 UTC --- Fixed
[Bug bootstrap/51086] [4.7 regression] ICE in move_insn, at haifa-sched.c:3437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51086 --- Comment #7 from Alan Modra amodra at gcc dot gnu.org 2011-11-15 22:10:51 UTC --- Author: amodra Date: Tue Nov 15 22:10:46 2011 New Revision: 181391 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181391 Log: PR rtl-optimization/51051 PR bootstrap/51086 * function.c (thread_prologue_and_epilogue_insns): Guard emitting return with single_succ_p test. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug bootstrap/51086] [4.7 regression] ICE in move_insn, at haifa-sched.c:3437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51086 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Alan Modra amodra at gmail dot com 2011-11-15 22:11:54 UTC --- Fixed
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-11-15 22:28:38 UTC --- I think this is really a duplicate of an issue discussed in various places before: libstdc++ relies on C library symbols that are not necessarily reserved by the selected version of standard C++, and in particular it relies on them in inline code in headers. This means (a) g++ predefines _GNU_SOURCE, causing headers included by the user to make visible symbols the user didn't want and (b) the use of symbols in the headers conflicts with any symbols of the same name defined by the user. Fixing this would be pretty involved and require close cooperation with libc to provide implementation-namespace versions of every such symbol the library needs, as I said in bug 36231; a lot of work to get this exactly in accordance with the various standards.
[Bug c/51147] New: attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 Bug #: 51147 Summary: attribute((mode(byte))) on an enum generates wrong code Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 25830 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25830 Test case file In an attempt to work around bug 49459, I tried putting attribute(mode_byte)) on the enum declaration (instead of on the typedef as in that bug). While that fixes the wrong debug output, it instead gives me seriously invalid code. The attached testcase shows the issue. The compiler appears to handle the functions foo and bar as if they return 1 unconditionally, so foo is called, bar is not, and test returns 1 unconditionally. Looking at the tree dump files, I see in the 001t.tu file something odd about the return type of foo() -- it is showing up as an enum (unsigned) whose min value is 0 and max value is -1. I'm not sure how that causes the specific failure but it makes me wonder. The mishandling of the function return values shows up right away (in the 003t.original dump file). The bug has been seen in 4.5.1 and 4.6.1. I also tried 3.3.3 because I happen to have it handy, but there the compiler crashes). A 4.1.2 compiler (stock gcc on my Linux) gets it wrong also, with the addition that it warns Comparison is always true due to limited range of data type. 4.5.1 does not say so (not even with -Wall). All this is with -O2.
[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 Paul Koning pkoning at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to fail||4.1.2, 4.5.1, 4.6.1 Severity|normal |major
[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 23:05:17 UTC --- I just want to reiterate that the c++ library headers never name clog, only __builtin_clog (and of course only when the underlying libc provides the corresponding clog, in case runtime library calls are actually required). I don't see why this way of using a __builtin* facility should give problems. Would it be difficult to change the compiler to decouple completely, eg, __builtin_clog from clog, in such a way that if the user or anything else fiddles with the latter, the former is not affected, as if it were a completely different, unrelated, name?
[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51147 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-15 23:06:26 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15224 fixed the ICE .. Note using attribute packed is more likely what you want to do rather than using mode.
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-15 23:10:37 UTC --- (N.B. we do name clog, but only for std::clog, the standard ostream ;) If you link dynamically to libm.so then the clog symbol can be replaced by symbol interposition. If a user does that and the symbol isn't the right type, it goes boom.
[Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-15 23:27:43 UTC --- Jon, I think I understand what you are saying, but then we have one more reason to not consider this sort of issue as library, because linking libm, with a clog in user code with a different meaning, etc, can certainly happen even with no headers included.
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-15 23:28:54 UTC --- Author: paolo Date: Tue Nov 15 23:28:49 2011 New Revision: 181394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181394 Log: 2011-11-15 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/51142 * include/debug/unordered_map (unordered_map::erase(iterator), unordered_multimap::erase(iterator)): Add, consistently with LWG 2059. * include/debug/unordered_set (unordered_set::erase(iterator), unordered_multiset::erase(iterator)): Likewise. * include/debug/map.h (map::erase(iterator)): Likewise. * include/debug/multimap.h (multimap::erase(iterator)): Likewise. * include/profile/map.h (map::erase(iterator)): Likewise. * include/profile/multimap.h (multimap::erase(iterator)): Likewise. * include/bits/hashtable.h (_Hashtable::erase(iterator)): Likewise. * include/bits/stl_map.h (map::erase(iterator)): Likewise. * include/bits/stl_multimap.h (multimap::erase(iterator)): Likewise. * include/bits/stl_tree.h (_Rb_tree::erase(iterator)): Likewise. * testsuite/23_containers/unordered_map/erase/51142.cc: New. * testsuite/23_containers/multimap/modifiers/erase/51142.cc: Likewise. * testsuite/23_containers/set/modifiers/erase/51142.cc: Likewise. * testsuite/23_containers/unordered_multimap/erase/51142.cc: Likewise. * testsuite/23_containers/unordered_set/erase/51142.cc: Likewise. * testsuite/23_containers/multiset/modifiers/erase/51142.cc: Likewise. * testsuite/23_containers/unordered_multiset/erase/51142.cc: Likewise. * testsuite/23_containers/map/modifiers/erase/51142.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/modifiers/erase/ trunk/libstdc++-v3/testsuite/23_containers/multiset/modifiers/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/erase/ trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/erase/51142.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/erase/51142.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/include/debug/map.h trunk/libstdc++-v3/include/debug/multimap.h trunk/libstdc++-v3/include/debug/unordered_map trunk/libstdc++-v3/include/debug/unordered_set trunk/libstdc++-v3/include/profile/map.h trunk/libstdc++-v3/include/profile/multimap.h
[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51105 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-11-16 00:11:37 UTC --- (In reply to comment #4) Please fill in (host and) target fields. What for? AFAICT the field should be *-*-* with lto enabled. A *-*-* would certainly be better than empty, which just says that someone forgot or didn't know what to write, which is usually the case when that field is empty.
[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51144 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added Target|s390-ibm-linux |s390-ibm-linux,ia64-hp-hpux ||11.23 CC||jimis at gmx dot net, sje ||at cup dot hp.com Host|s390-ibm-linux |s390-ibm-linux,ia64-hp-hpux ||11.23 Build|s390-ibm-linux |s390-ibm-linux,ia64-hp-hpux ||11.23 --- Comment #2 from Steve Ellcey sje at cup dot hp.com 2011-11-16 00:34:16 UTC --- Yes, this started failing on 181279 for ia64-hp-hpux11.23 as well. Adding Dimitrios to CC list.
[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51144 --- Comment #3 from Steve Ellcey sje at cup dot hp.com 2011-11-16 00:43:15 UTC --- I think this is a big-endian bug in fprint_whex, etc. IA64 HP-UX is big endian and I think s390-ibm-linux is too.
[Bug c++/51148] New: [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51148
Bug #: 51148
Summary: [C++0x] Unexpanded template param packs wrongly
accepted in friend class declarations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 25831
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25831
Outputs by -v option and preprocessed source.
GCC 4.7-2012 with -std=c++11 wrongly accepts the following ill-formed code.
===
templatetypename... Types
struct S
{};
templatetypename... Types
struct T
{
friend class STypes;
};
int main()
{}
===
