[Bug c++/50478] Internal compiler error when using initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50478 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2011-09-22 07:19:17 UTC --- The problem seem to exist in 4.7.0 20110917 (experimental) as well, pointing to joust, at cp/call.c:7960.
[Bug middle-end/50451] [4.7 regression] internal compiler error at tree-vect-loop.c:3557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50451 --- Comment #5 from irar at gcc dot gnu.org 2011-09-22 07:21:14 UTC --- Author: irar Date: Thu Sep 22 07:21:07 2011 New Revision: 179079 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179079 Log: PR tree-optimization/50451 * tree-vect-slp.c (vect_get_constant_vectors): Don't fail for constant operands in reduction. (vect_get_slp_defs): Don't create vector operand for NULL scalar operand. Added: trunk/gcc/testsuite/gcc.dg/vect/pr50451.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug middle-end/50451] [4.7 regression] internal compiler error at tree-vect-loop.c:3557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50451 Ira Rosen changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Ira Rosen 2011-09-22 07:28:59 UTC --- Fixed.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #18 from Ira Rosen 2011-09-22 07:51:35 UTC --- (In reply to comment #16) > and -3.c fails with an ICE in the vectorizer, Ira, > could you look at that? --- tree-vect-stmts.c 2011-09-22 09:48:34.0 +0200 +++ tree-vect-stmts.c.new 2011-09-22 09:48:14.0 +0200 @@ -4806,7 +4806,8 @@ vectorizable_condition (gimple stmt, gim return false; gcc_assert (ncopies >= 1); - if (reduc_index && ncopies > 1) + if ((reduc_index || STMT_VINFO_COMPOUND_PATTERN (stmt_info)) + && (ncopies > 1)) return false; /* FORNOW */ if (!STMT_VINFO_RELEVANT_P (stmt_info)
[Bug c++/50479] New: Unevaluated usage of parameters in function default arguments is accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50479
Bug #: 50479
Summary: Unevaluated usage of parameters in function default
arguments is 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 20110917 (experimental) accepts the following program with or without
-Wall, -pedantic, or -std=c++0x:
//---
long foo;
void bar(char foo = sizeof(foo)) {}
int main() {
bar();
}
//---
But according to 3.4.1 p11:
"During the lookup for a name used as a default argument (8.3.6) in a function
parameter-declaration-clause or used in the expression of a mem-initializer for
a constructor (12.6.2), the function parameter names are visible and hide the
names of entities declared in the block, class or namespace scopes containing
the function declaration."
and to 8.3.6 p9:
"Consequently, parameters of a function shall not be used in a default
argument,
even if they are not evaluated. Parameters of a function declared before a
default argument are in scope and can hide namespace and class member names."
[The references refer to N3190, but also apply to C++03, 14882:2003(E)]
the name 'foo' in the expression 'sizeof(foo)' should resolve to the parameter
name and after this should make the program ill-formed. Refining this program
to
//---
extern "C" int printf(const char*, ...);
long foo;
void bar(char foo = sizeof(foo)) {
int v = foo;
printf("%d", v);
}
int main() {
bar();
}
//---
produces the output
4
leading to the conclusion that the name 'foo' is resolved to the name of the
global variable, not to the parameter name.
A similar example can be constructed via decltype and compiled successfully
with -std=c++0x:
//---
template
struct A;
template<>
struct A {
static const int value = 1;
};
long foo;
void bar(char foo = A::value) {}
int main() {
bar();
}
//---
This example should also be rejected for similar reasons as above, because the
name 'foo' in the default argument should resolve to the parameter, but again
the global variable name is found instead.
[Bug c/50380] cc1 hangs eating 100% CPU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50380 --- Comment #3 from Mikael Pettersson 2011-09-22 08:51:19 UTC --- Created attachment 25335 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25335 reduced test case Much reduced test case. So far I've only been able to reproduce the looping cc1 with crosses to mips-linux.
[Bug libstdc++/50160] vector comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 --- Comment #27 from Marc Glisse 2011-09-22 09:25:44 UTC --- (In reply to comment #25) [builtins to reverse the bit order] > I think a separate Bugzilla requesting as an enhancement such intrinsics would > be certainly appropriate. Has this RFE already been filed?
[Bug fortran/41733] Proc-pointer conformance checks: Elemental-proc-ptr => non-elemental-proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41733 --- Comment #5 from janus at gcc dot gnu.org 2011-09-22 09:32:14 UTC --- Author: janus Date: Thu Sep 22 09:32:11 2011 New Revision: 179080 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179080 Log: 2011-09-22 Janus Weil PR fortran/41733 * expr.c (gfc_check_pointer_assign): Check for nonintrinsic elemental procedures. * interface.c (gfc_compare_interfaces): Rename 'intent_flag'. Check for PURE and ELEMENTAL attributes. (compare_actual_formal): Remove pureness check here. 2011-09-22 Janus Weil PR fortran/41733 * gfortran.dg/impure_actual_1.f90: Modified error message. * gfortran.dg/proc_ptr_32.f90: New. * gfortran.dg/proc_ptr_33.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_32.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_33.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90
[Bug c++/50478] [C++0x] Internal compiler error when using initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50478 Paolo Carlini changed: What|Removed |Added Severity|major |normal
[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #52 from Iain Sandoe 2011-09-22 09:34:49 UTC --- Created attachment 25336 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25336 remove ranlib special casing from the darwin port so, this has taken a long time... Mike's throw-away comment about Ada took some answering ;) (well, at least we now have Ada bootstrap on powerpc again). Anyway, I have nearly finished testing this on Darwin 9 and Darwin 10 (normal bootstraps). I would appreciate some help with testing on Darwin 11 and with lto-bootstraps on Darwin 10 (since my resources are stretched to the limit right now). === In summary, for current usable toolsets that are able to bootstrap 4.6 or 4.7 on Darwin 8 .. 10, I can see no reason that we should (or need to) retain a special case for ranlib on Darwin. Since Darwin < 8 will _not_ bootstrap 4.6 with its native toolset (it needs at least odcctools from Darwin 8) then it is academic whether the special casing would still apply to an earlier toolset. I am happy for someone else to push this through if time is of concern (not able to devote much right now).
[Bug fortran/41733] Proc-pointer conformance checks: Elemental-proc-ptr => non-elemental-proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41733 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2011-09-22 09:40:07 UTC --- r179080 should fix all issues in the c.l.f. thread. Closing as fixed.
[Bug libstdc++/50160] vector comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 --- Comment #28 from Paolo Carlini 2011-09-22 09:49:18 UTC --- I think we should. Can you do that? Thanks!
[Bug c++/50478] [C++0x] Internal compiler error when using initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50478 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-22 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/50465] [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50465 --- Comment #2 from Georg-Johann Lay 2011-09-22 09:55:20 UTC --- Author: gjl Date: Thu Sep 22 09:55:13 2011 New Revision: 179081 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179081 Log: PR target/50447 PR target/50465 * config/avr/avr-protos.h (avr_out_bitop): New prototype. (avr_popcount_each_byte): New prototype. * config/avr/avr.c (avr_popcount): New static function. (avr_popcount_each_byte): New function. (avr_out_bitop): New function. (adjust_insn_length): ADJUST_LEN_OUT_BITOP dispatches to avr_out_bitop. Cleanup code. * config/avr/constraints.md (Ca2, Co2, Cx2): New constraints. (Ca4, Co4, Cx4): New constraints. * config/avr/avr.md (adjust_len): Add "out_bitop" insn attribute alternative. (andhi3, iorhi3, xorhi3): Rewrite insns using avr_out_bitop. (andsi3, iorsi3, xorsi3): Ditto. (*iorhi3_clobber, *iorsi3_clobber): Remove insns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/constraints.md
[Bug target/50447] [avr] Better support of AND, OR, XOR and PLUS with constant integers for 16- and 32-bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447 --- Comment #1 from Georg-Johann Lay 2011-09-22 09:55:21 UTC --- Author: gjl Date: Thu Sep 22 09:55:13 2011 New Revision: 179081 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179081 Log: PR target/50447 PR target/50465 * config/avr/avr-protos.h (avr_out_bitop): New prototype. (avr_popcount_each_byte): New prototype. * config/avr/avr.c (avr_popcount): New static function. (avr_popcount_each_byte): New function. (avr_out_bitop): New function. (adjust_insn_length): ADJUST_LEN_OUT_BITOP dispatches to avr_out_bitop. Cleanup code. * config/avr/constraints.md (Ca2, Co2, Cx2): New constraints. (Ca4, Co4, Cx4): New constraints. * config/avr/avr.md (adjust_len): Add "out_bitop" insn attribute alternative. (andhi3, iorhi3, xorhi3): Rewrite insns using avr_out_bitop. (andsi3, iorsi3, xorsi3): Ditto. (*iorhi3_clobber, *iorsi3_clobber): Remove insns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/constraints.md
version `GLIBC_2.14' not found (required by build/genhooks)
Hello, I'm building a toolchain in /opt dir. I have already build and installed glibc-2.14 and binutils-2.21.1a in /opt. Now I want to build and install gcc-4.6.1 with gmp, mpfr and mpc also in /opt. Here is my configure: ../gcc-4.6.1/configure --prefix=/tools --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath --disable-target-libiberty --disable-target-zlib --enable-languages=c --without-ppl --without-cloog Here is the last output of my build: build/genhooks > tmp-target-hooks-def.h build/genhooks: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by build/genhooks) make[3]: *** [s-target-hooks-def-h] Error 1 make[3]: *** Waiting for unfinished jobs rm gcc.pod make[3]: Leaving directory `/home/serge/Documents/gcc-build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/serge/Documents/gcc-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/serge/Documents/gcc-build' make: *** [all] Error 2 The problem is very obvious, gcc build is not taking the toolchain glibc-2.14 in /opt/lib but it is taking the one the host uses which is eglibc-2.13 in /usr/lib. I set various flags to the linker and compiler, they are all looking in the right directory. It must be something in the configure script? Can anyone help me please. Thank you
[Bug tree-optimization/50480] New: 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 Bug #: 50480 Summary: 10% performance regression on Spec2006 410.bwaves Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: kirill.yuk...@intel.com Hi, Recently Richard fixed this http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957 According to my measurements, fix for that bug caused (on Spec2006): For SandyBride CPU: * 410.bwaves degradation is -9.54% for peak32 * 410.bwaves degradation is -6.91% for base32 * 410.bwaves improvement is 1.00% for peak64 * 410.bwaves improvement is 0.91% 3or base64 For Corei7 CPU: * 410.bwaves degradation is -3.91% for peak32 * 410.bwaves degradation is -3.91% for base32 * 410.bwaves improvement is 1.94% for peak64 * 410.bwaves improvement is 3.23% 3or base64 For AMD (Phenom(tm) II X3 B75) CPU: * 410.bwaves degradation is -7.32% for peak32 * 410.bwaves degradation is -6.56% for base32 * 410.bwaves improvement is 2.01% for peak64 * 410.bwaves degradation is -1.34% 3or base64
[Bug tree-optimization/50480] 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480 --- Comment #1 from Yukhin Kirill 2011-09-22 10:00:34 UTC --- Checkin URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177368
[Bug middle-end/35860] [4.4/4.5/4.6/4.7 Regression] [avr] code bloat caused by -fsplit-wide-types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860 Georg-Johann Lay changed: What|Removed |Added Keywords||ra Status|NEW |WAITING Component|target |middle-end Host|mingw | Target Milestone|4.4.7 |4.7.0 --- Comment #15 from Georg-Johann Lay 2011-09-22 10:24:45 UTC --- With 4.7 trunk r179081 and the code from comment #0 avr-gcc -mmcu=avr4 -Os -S -dp The output with -fno-split-wide-types is 36 bytes udivr32_7: /* stack size = 0 */ ldi r30,lo8(32) ; 10*movqi/2[length = 1] ldi r21,lo8(0) ; 11*movqi/1[length = 1] .L4: lsl r21 ; 15*ashlqi3/3[length = 1] sbrc r25,7 ; 58*sbrx_and_branchsi[length = 2] subi r21,lo8(-(1)) ; 19addqi3/2[length = 1] .L2: lsl r22 ; 57*ashlsi3_const/2[length = 4] rol r23 rol r24 rol r25 cp r21,r20 ; 23*cmpqi/2[length = 1] brlo .L3 ; 24branch[length = 1] sub r21,r20 ; 26subqi3/1[length = 1] ori r22,1 ; 27iorsi3/2[length = 1] .L3: subi r30,lo8(-(-1)) ; 30addqi3/2[length = 1] brne .L4 ; 33branch[length = 1] movw r30,r18 ; 52*movhi/1[length = 1] st Z,r21 ; 35*movqi/3[length = 1] /* epilogue start */ ret ; 55return[length = 1] The output with -fsplit-wide-types is 62 bytes udivr32_7: push r12 ; 61pushqi1/1[length = 1] push r13 ; 62pushqi1/1[length = 1] push r14 ; 63pushqi1/1[length = 1] push r15 ; 64pushqi1/1[length = 1] /* stack size = 4 */ movw r12,r22 ; 6*movsi/1[length = 2] movw r14,r24 ldi r25,lo8(32) ; 10*movqi/2[length = 1] ldi r24,lo8(0) ; 11*movqi/1[length = 1] .L4: lsl r24 ; 15*ashlqi3/3[length = 1] sbrc r15,7 ; 76*sbrx_and_branchsi[length = 2] subi r24,lo8(-(1)) ; 19addqi3/2[length = 1] .L2: lsl r12 ; 75*ashlsi3_const/2[length = 4] rol r13 rol r14 rol r15 cp r24,r20 ; 23*cmpqi/2[length = 1] brlo .L3 ; 24branch[length = 1] sub r24,r20 ; 26subqi3/1[length = 1] set ; 27iorsi3/3[length = 2] bld r12,0 .L3: subi r25,lo8(-(-1)) ; 30addqi3/2[length = 1] brne .L4 ; 33branch[length = 1] movw r30,r18 ; 60*movhi/1[length = 1] st Z,r24 ; 35*movqi/3[length = 1] movw r22,r12 ; 73*movhi/1[length = 1] movw r24,r14 ; 74*movhi/1[length = 1] /* epilogue start */ pop r15 ; 67popqi[length = 1] pop r14 ; 68popqi[length = 1] pop r13 ; 69popqi[length = 1] pop r12 ; 70popqi[length = 1] ret ; 71return_from_epilogue[length = 1] So there is still code bloat with -fsplit-wide-types. I don't see how the back-end can improve thas situation and IMO the bloat is caused by the register allocation which leads to the 13 additional instructions: all push/pop and moving registers back and forth (and one for a|=1 in a register that cannot operate with constants in insn 27). Therefore, I added RA to the keywords, set component to "middle-end" and changed the status to "waiting" so that someone familiar with the register allocator can tell if it's a RA flaw or not or give better component/keyword.
[Bug middle-end/50481] New: builtin to reverse the bit order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Bug #: 50481 Summary: builtin to reverse the bit order Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: marc.gli...@normalesup.org It would be useful if gcc provided a builtin to reverse the order of the bits (turn abcdefgh into hgfedcba) in objects of all sizes from a byte to an unsigned long long. According to Joseph: "Various processors have an instruction to reverse the bit order in a word (ARMv6T2 and later have RBIT, for example, and C6X has BITR on C64X and above)." This kind of bit manipulation also has various optimizations depending on the architecture (mirroring a byte can be implemented using a 64bit multiplication). It is thus well suited to a builtin with different platform-specific implementations. Such a builtin could be used for instance for Bug 50160.
[Bug libstdc++/50160] vector comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 --- Comment #29 from Marc Glisse 2011-09-22 10:29:07 UTC --- See Bug 50481 about bit-reversal builtins (and feel free to add details there).
[Bug tree-optimization/50480] 10% performance regression on Spec2006 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480
--- Comment #2 from Yukhin Kirill 2011-09-22
10:33:06 UTC ---
Here is optset details:
base=-static -O2 -ffast-math ("-m32 -msse2 -mfpmath=sse" if 32 bit mode)
peak=-static -O3 -funroll-loops -ffast-math ("-m32 -msse2 -mfpmath=sse" if 32
bit mode)
For SandyBridge: += "-mavx -march=corei7"
For Core i7: += "-march=corei7"
For AMD: += "-march=amdfam10" (not sure this is the best)
[Bug target/50482] New: [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482 Bug #: 50482 Summary: [4.7 regression] internal compiler error at recog.c:2137 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: jojel...@gmail.com Created attachment 25337 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25337 preprocessed source $ gcc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_DBUS -DHAVE_BSWAP32 -DHAVE_BYTESWAP_H -O4 -mfpmath=sse -march=native -mtune=native -g -flto -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -DUSE_LIBICONV_GNU -I./psi -I./obj -I./obj -I./base -o ./obj/zimage3.o -c ./psi/zimage3.c -v -save-temps Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl : (reconfigured) ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl --enable-languages=c,c++,lto --no-create --no-recursion Thread model: win32 gcc version 4.7.0 20110922 (experimental) (GCC) COLLECT_GCC_OPTIONS='-D' 'HAVE_MKSTEMP' '-D' 'HAVE_FONTCONFIG' '-D' 'HAVE_LIBIDN' '-D' 'HAVE_SETLOCALE' '-D' 'HAVE_DBUS' '-D' 'HAVE_BSWAP32' '-D' 'HAVE_BYTESWAP_H' '-O4' '-mfpmath=sse' '-march=native' '-mtune=native' '-g' '-flto' '-Wall' '-Wstrict-prototypes' '-Wundef' '-Wmissing-declarations' '-Wmissing-prototypes' '-Wwrite-strings' '-Wno-strict-aliasing' '-Wdeclaration-after-statement' '-fno-builtin' '-fno-common' '-D' 'HAVE_STDINT_H=1' '-D' 'HAVE_SYS_TIME_H=1' '-D' 'GX_COLOR_INDEX_TYPE=unsigned long long' '-D' 'USE_LIBICONV_GNU' '-I' './psi' '-I' './obj' '-I' './obj' '-I' './base' '-o' './obj/zimage3.o' '-c' '-v' '-save-temps' /usr/libexec/gcc/i686-pc-cygwin/4.7.0/cc1.exe -E -quiet -v -I ./psi -I ./obj -I ./obj -I ./base -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api -D HAVE_MKSTEMP -D HAVE_FONTCONFIG -D HAVE_LIBIDN -D HAVE_SETLOCALE -D HAVE_DBUS -D HAVE_BSWAP32 -D HAVE_BYTESWAP_H -D HAVE_STDINT_H=1 -D HAVE_SYS_TIME_H=1 -D GX_COLOR_INDEX_TYPE=unsigned long long -D USE_LIBICONV_GNU ./psi/zimage3.c -march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -msse4.1 -mno-lzcnt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 -mfpmath=sse -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -flto -fno-builtin -fno-common -g -fworking-directory -O4 -fpch-preprocess -o zimage3.i ignoring duplicate directory "/usr/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api" ignoring duplicate directory "./obj" #include "..." search starts here: #include <...> search starts here: ./psi ./obj ./base /usr/lib/gcc/i686-pc-cygwin/4.7.0/include /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.7.0/include-fixed /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/include /usr/
Re: version `GLIBC_2.14' not found (required by build/ge nhooks)â
re http://gcc.gnu.org/ml/gcc-bugs/2011-09/msg01506.html This mailing list is for automated emails from our bug database, people don't use it for discussions via email. To report a bug please use bugzilla, using the instructions at http://gcc.gnu.org/bugs/ To ask for help using or building GCC use the gcc-help mailing list, see http://gcc.gnu.org/lists.html
[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #53 from janus at gcc dot gnu.org 2011-09-22 10:51:49 UTC --- (In reply to comment #52) > Created attachment 25336 [details] > remove ranlib special casing from the darwin port > > [...] > > I would appreciate some help with testing on Darwin 11 and with lto-bootstraps > on Darwin 10 (since my resources are stretched to the limit right now). Is this patch supposed to fix the duplicate symbol issues? On Darwin 11.1 I still get (also with the patch): ld: duplicate symbol _trim_filename in libcommon.a(diagnostic.o) and errors.o for architecture x86_64
[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #54 from Iain Sandoe 2011-09-22 11:01:05 UTC --- (In reply to comment #53) > (In reply to comment #52) > > Created attachment 25336 [details] > > remove ranlib special casing from the darwin port > > > > [...] > > > > I would appreciate some help with testing on Darwin 11 and with > > lto-bootstraps > > on Darwin 10 (since my resources are stretched to the limit right now). > > Is this patch supposed to fix the duplicate symbol issues? On Darwin 11.1 I > still get (also with the patch): yes (assuming that those problems are still the result of the common symbols). > > ld: duplicate symbol _trim_filename in libcommon.a(diagnostic.o) and errors.o > for architecture x86_64 The patch is in the standard form for submission - you will need to regenerate configure and gcc/configure (or it will have essentially no effect). I use: autoconf -I. -Iconfig (in the root) and autoconf -I. -I.. -I../config (in ./gcc) you must use autoconf etc. as per the GCC pre-requisites;
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 vincenzo Innocente changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #3 from vincenzo Innocente 2011-09-22 11:05:21 UTC --- I did a small test removing the visibily just in stl_vector.h grep namespace /afs/cern.ch/user/i/innocent/w2/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h namespace std /* _GLIBCXX_VISIBILITY(default) */ and got ++ -fvisibility=hidden -fvisibility-inlines-hidden -fPIC bha.cc -Wall -shared -o libx.so [vinavx0] ~/public/ctest $ readelf -sW libx.so | grep -v UND | sed 's/.local/ .local/g' | c++filt Symbol table '.dynsym' contains 14 entries: Num:Value Size TypeBind Vis Ndx Name 2: 0540 0 FUNCGLOBAL DEFAULT9 _init 3: 0758 0 FUNCGLOBAL DEFAULT 12 _fini 6: 066c30 FUNCGLOBAL DEFAULT 11 bar() 7: 06fc26 FUNCWEAK DEFAULT 11 std::allocator::allocator() 8: 06fc26 FUNCWEAK DEFAULT 11 std::allocator::allocator() 9: 071610 FUNCWEAK DEFAULT 11 __gnu_cxx::new_allocator::new_allocator() 10: 071610 FUNCWEAK DEFAULT 11 __gnu_cxx::new_allocator::new_allocator() 11: 1ae8 0 NOTYPE GLOBAL DEFAULT ABS _edata 12: 1ae8 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 13: 1af8 0 NOTYPE GLOBAL DEFAULT ABS _end Symbol table '.symtab' contains 39 entries: Num:Value Size TypeBind Vis Ndx Name 1: 05a0 0 FUNCLOCAL DEFAULT 11 call_gmon_start 2: 0 FILELOCAL DEFAULT ABS crtstuff.c 3: 1ac0 0 OBJECT LOCAL DEFAULT 19 __CTOR_LIST__ 4: 1ad0 0 OBJECT LOCAL DEFAULT 20 __DTOR_LIST__ 5: 1ae0 0 OBJECT LOCAL DEFAULT 21 __JCR_LIST__ 6: 05c0 0 FUNCLOCAL DEFAULT 11 __do_global_dtors_aux 7: 1ae8 1 OBJECT LOCAL DEFAULT 22 completed.5901 8: 1af0 8 OBJECT LOCAL DEFAULT 22 dtor_idx.5903 9: 0640 0 FUNCLOCAL DEFAULT 11 frame_dummy 10: 0 FILELOCAL DEFAULT ABS bha.cc 11: 0 FILELOCAL DEFAULT ABS crtstuff.c 12: 1ac8 0 OBJECT LOCAL DEFAULT 19 __CTOR_END__ 13: 0840 0 OBJECT LOCAL DEFAULT 13 __FRAME_END__ 14: 1ae0 0 OBJECT LOCAL DEFAULT 21 __JCR_END__ 15: 0720 0 FUNCLOCAL DEFAULT 11 __do_global_ctors_aux 16: 1ab8 0 OBJECT LOCAL HIDDEN18 __dso_handle 17: 068a26 FUNCLOCAL HIDDEN11 std::vector >::vector() 18: 068a26 FUNCLOCAL HIDDEN11 std::vector >::vector() 19: 06a426 FUNCLOCAL HIDDEN11 std::_Vector_base >::_Vector_base() 20: 06a426 FUNCLOCAL HIDDEN11 std::_Vector_base >::_Vector_base() 21: 06be61 FUNCLOCAL HIDDEN11 std::_Vector_base >::_Vector_impl::_Vector_impl() 22: 06be61 FUNCLOCAL HIDDEN11 std::_Vector_base >::_Vector_impl::_Vector_impl() 23: 1ad8 0 OBJECT LOCAL HIDDEN20 __DTOR_END__ 24: 1880 496 OBJECT LOCAL HIDDEN15 _DYNAMIC 25: 1a8848 OBJECT LOCAL HIDDEN17 _GLOBAL_OFFSET_TABLE_ 27: 0540 0 FUNCGLOBAL DEFAULT9 _init 28: 0758 0 FUNCGLOBAL DEFAULT 12 _fini 31: 066c30 FUNCGLOBAL DEFAULT 11 bar() 32: 06fc26 FUNCWEAK DEFAULT 11 std::allocator::allocator() 33: 06fc26 FUNCWEAK DEFAULT 11 std::allocator::allocator() 34: 071610 FUNCWEAK DEFAULT 11 __gnu_cxx::new_allocator::new_allocator() 35: 071610 FUNCWEAK DEFAULT 11 __gnu_cxx::new_allocator::new_allocator() 36: 1ae8 0 NOTYPE GLOBAL DEFAULT ABS _edata 37: 1ae8 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 38: 1af8 0 NOTYPE GLOBAL DEFAULT ABS _end if I add -flto visibility of the "local symbols is turned again to DEFAULT, not sure if relevant though g++ -fvisibility=hidden -fvisibility-inlines-hidden -fPIC bha.cc -Wall -shared -o libx.so -flto [vinavx0] ~/public/ctest $ readelf -sW libx.so | grep -v UND | sed 's/.local/ .local/g' | c++filt Symbol table '.dynsym' contains 10 entries: Num:Value Size TypeBind Vis Ndx Name 2: 000
[Bug lto/50483] New: lto turns visibility from HIDDEN to DEFAULT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50483
Bug #: 50483
Summary: lto turns visibility from HIDDEN to DEFAULT
Classification: Unclassified
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
Host: x86
Target: x86_64-unknown-linux-gnu
Build: 4.7.0 20110919
not sure how relevant is in practice BUT in the example below one may notice
that the visibility of "bar" is turned to DEFAULT by lto
no lto
17: 059711 FUNCLOCAL HIDDEN11 bar()
lto
11: 059711 FUNCLOCAL DEFAULT 11 bar() .2238
cat vislto.cc
void ext();
void bar() __attribute((visibility( "hidden" )));
void foo() __attribute((visibility( "default" )));
void foo() { bar();}
void bar() { ext();}
g++ -fPIC vislto.cc -Wall -shared -o libvislto.so
[vinavx0] ~/public/ctest $ readelf -sW libvislto.so | grep -v UND | sed 's/\./
\./g' | c++filt
Symbol table ' .dynsym' contains 11 entries:
Num:Value Size TypeBind Vis Ndx Name
2: 0478 0 FUNCGLOBAL DEFAULT9 _init
3: 05e8 0 FUNCGLOBAL DEFAULT 12 _fini
6: 058c11 FUNCGLOBAL DEFAULT 11 foo()
8: 18d0 0 NOTYPE GLOBAL DEFAULT ABS _edata
9: 18d0 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
10: 18e0 0 NOTYPE GLOBAL DEFAULT ABS _end
Symbol table ' .symtab' contains 31 entries:
Num:Value Size TypeBind Vis Ndx Name
1: 04c0 0 FUNCLOCAL DEFAULT 11 call_gmon_start
2: 0 FILELOCAL DEFAULT ABS crtstuff .c
3: 18a8 0 OBJECT LOCAL DEFAULT 19 __CTOR_LIST__
4: 18b8 0 OBJECT LOCAL DEFAULT 20 __DTOR_LIST__
5: 18c8 0 OBJECT LOCAL DEFAULT 21 __JCR_LIST__
6: 04e0 0 FUNCLOCAL DEFAULT 11
__do_global_dtors_aux
7: 18d0 1 OBJECT LOCAL DEFAULT 22 completed .5901
8: 18d8 8 OBJECT LOCAL DEFAULT 22 dtor_idx .5903
9: 0560 0 FUNCLOCAL DEFAULT 11 frame_dummy
10: 0 FILELOCAL DEFAULT ABS vislto .cc
11: 0 FILELOCAL DEFAULT ABS crtstuff .c
12: 18b0 0 OBJECT LOCAL DEFAULT 19 __CTOR_END__
13: 0650 0 OBJECT LOCAL DEFAULT 13 __FRAME_END__
14: 18c8 0 OBJECT LOCAL DEFAULT 21 __JCR_END__
15: 05b0 0 FUNCLOCAL DEFAULT 11
__do_global_ctors_aux
16: 18a0 0 OBJECT LOCAL HIDDEN18 __dso_handle
17: 059711 FUNCLOCAL HIDDEN11 bar()
18: 18c0 0 OBJECT LOCAL HIDDEN20 __DTOR_END__
19: 1670 496 OBJECT LOCAL HIDDEN15 _DYNAMIC
20: 187840 OBJECT LOCAL HIDDEN17
_GLOBAL_OFFSET_TABLE_
22: 0478 0 FUNCGLOBAL DEFAULT9 _init
23: 05e8 0 FUNCGLOBAL DEFAULT 12 _fini
26: 058c11 FUNCGLOBAL DEFAULT 11 foo()
28: 18d0 0 NOTYPE GLOBAL DEFAULT ABS _edata
29: 18d0 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
30: 18e0 0 NOTYPE GLOBAL DEFAULT ABS _end
[vinavx0] ~/public/ctest $ g++ -fPIC vislto.cc -Wall -shared -o libvislto.so
-flto
[vinavx0] ~/public/ctest $ readelf -sW libvislto.so | grep -v UND | sed 's/\./
\./g' | c++filt
Symbol table ' .dynsym' contains 11 entries:
Num:Value Size TypeBind Vis Ndx Name
2: 0478 0 FUNCGLOBAL DEFAULT9 _init
3: 05e8 0 FUNCGLOBAL DEFAULT 12 _fini
6: 058c11 FUNCGLOBAL DEFAULT 11 foo()
8: 18d0 0 NOTYPE GLOBAL DEFAULT ABS _edata
9: 18d0 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
10: 18e0 0 NOTYPE GLOBAL DEFAULT ABS _end
Symbol table ' .symtab' contains 31 entries:
Num:Value Size TypeBind Vis Ndx Name
1: 04c0 0 FUNCLOCAL DEFAULT 11 call_gmon_start
2: 0 FILELOCAL DEFAULT ABS crtstuff .c
3: 18a8 0 OBJECT LOCAL DEFAULT 19 __CTOR_LIST__
4: 18b8 0 OBJECT LOCAL DEFAULT 20 __DTOR_LIST__
5: 18c8 0 OBJECT LOCAL DEFAULT 21 __JCR_LIST__
6: 04e0 0 FUNCLOCAL DEFAULT 11
__do_global_dtors_aux
7: 18d0 1 OBJECT LOCAL DEFAULT 22 completed .5901
8: 18d8 8 OBJECT LOCAL DEFAULT 22 dtor_idx .5903
9: 0560
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 --- Comment #4 from Pawel Sikora 2011-09-22 11:23:14 UTC --- (In reply to comment #3) > I think that, unless not imposed by the standard (why??) the visibility of > "namespace std" SHALL NOT BE forced to default part of the std:: (exceptions typeinfo symbols) must be visible-by-default for proper throw-catch/dynamic_cast working across shared libs boundaries.
[Bug regression/50484] New: [4.6 regression] ia64-portbld-freebsd9.0, conftest.c:16:1: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50484 Bug #: 50484 Summary: [4.6 regression] ia64-portbld-freebsd9.0, conftest.c:16:1: internal compiler error: Segmentation fault: 11 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: me...@bristol.ac.uk ia64-portbld-freebsd9.0 Last working version: gcc-4.6.2.20110902 Building 4.6.2.20110916 fails with: Checking multilib configuration for libgcc... Configuring stage 2 in ia64-portbld-freebsd9.0/libgcc configure: loading cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking for gawk... gawk checking build system type... ia64-portbld-freebsd9.0 checking host system type... ia64-portbld-freebsd9.0 checking for ia64-portbld-freebsd9.0-ar... /usr/local/ia64-portbld-freebsd9.0/bin/ar checking for ia64-portbld-freebsd9.0-lipo... lipo checking for ia64-portbld-freebsd9.0-nm... /usr/ports/lang/gcc46/work/build/./gcc/nm checking for ia64-portbld-freebsd9.0-ranlib... /usr/local/ia64-portbld-freebsd9.0/bin/ranlib checking for ia64-portbld-freebsd9.0-strip... /usr/local/ia64-portbld-freebsd9.0/bin/strip checking whether ln -s works... yes checking for ia64-portbld-freebsd9.0-gcc... /usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/port s/lang/gcc46/work/build/./gcc/ -B/usr/local/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld- freebsd9.0/lib/ -isystem /usr/local/ia64-portbld-freebsd9.0/include -isystem /usr/local/ia64-portbl d-freebsd9.0/sys-include checking for suffix of object files... configure: error: in `/usr/ports/lang/gcc46/work/build/ia64- portbld-freebsd9.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage2-target-libgcc] Error 1 Full work/build/ia64-portbld-freebsd9.0/libgcc/config.log is attached. Here's the relevant extract: configure:3246: checking for suffix of object files configure:3268: /usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./gc c/ -B/usr/local/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld-freebsd9.0/lib/ -isystem /us r/local/ia64-portbld-freebsd9.0/include -isystem /usr/local/ia64-portbld-freebsd9.0/sys-include -c -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing conftest.c >&5 conftest.c: In function 'main': conftest.c:16:1: internal compiler error: Segmentation fault: 11
[Bug regression/50484] [4.6 regression] ia64-portbld-freebsd9.0, conftest.c:16:1: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50484 --- Comment #1 from Anton Shterenlikht 2011-09-22 11:27:26 UTC --- Created attachment 25338 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25338 config.log
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348
--- Comment #5 from vincenzo Innocente
2011-09-22 11:49:29 UTC ---
indeed
and in "exception" header-file is a place where visibility is correctly handled
#pragma GCC visibility push(default)
extern "C++" {
namespace std
{
}
#pragma GCC visibility pop
I would have preferred specific __attribute((visibility( "default" )))
on each exception class though (push and pop and error-prone)
[Bug testsuite/50485] New: gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485
Bug #: 50485
Summary: gcc.target/i386/sse4_1-blendps.c fails spuriously on
i686
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
gcc.target/i386/sse4_1-blendps.c fails spuriously for me on i686. Diego Novillo
mentions something similar in http://gcc.gnu.org/ml/gcc/2011-07/msg00296.html.
The test uses an uninitialized var src3. Initializing part of the var makes the
test fail reliably for me with the same failure mode:
...
Index: sse4_1-blendps.c
===
--- sse4_1-blendps.c (revision 178880)
+++ sse4_1-blendps.c (working copy)
@@ -64,6 +64,7 @@ TEST (void)
} src3;
int i;
+ src3.f[1] = __builtin_nansf ("");
init_blendps (src1.f, src2.f);
/* Check blendps imm8, m128, xmm */
...
The test aborts because the assignment 'tmp[1] = src2[1]' changes the Nan:
...
static int
check_blendps (__m128 *dst, float *src1, float *src2)
{
float tmp[4];
int j;
memcpy (&tmp[0], src1, sizeof (tmp));
for (j = 0; j < 4; j++)
if ((MASK & (1 << j)))
tmp[j] = src2[j];
return memcmp (dst, &tmp[0], sizeof (tmp));
}
...
The assignment is translated as a push/pop on the float stack:
...
#(insn 17 39 42 2 (set (reg:SF 8 st)
#(mem:SF (plus:SI (reg/v/f:SI 2 cx [orig:65 src2 ] [65])
#(const_int 4 [0x4])) [3 MEM[(float *)src2_10(D) + 4B]+0 S4
A32])) sse4_1-blendps.c:46 108 {*movsf_internal}
# (expr_list:REG_DEAD (reg/v/f:SI 2 cx [orig:65 src2 ] [65])
#(expr_list:REG_EQUIV (mem/s/c:SF (plus:SI (reg/f:SI 20 frame)
#(const_int -12 [0xfff4])) [3 tmp+4 S4 A32])
#(nil
flds4(%ecx)# 17*movsf_internal/1[length = 3]
...
#(insn 18 15 21 2 (set (mem/s/c:SF (plus:SI (reg/f:SI 7 sp)
#(const_int 20 [0x14])) [3 tmp+4 S4 A32])
#(reg:SF 8 st)) sse4_1-blendps.c:46 108 {*movsf_internal}
# (expr_list:REG_DEAD (reg:SF 8 st)
#(nil)))
fstps20(%esp)# 18*movsf_internal/2[length = 4]
...
By going through the float stack, the signalling Nan turns into a quiet Nan.
That seems to correspond with what is said at
http://stackoverflow.com/questions/2247447/usefulness-of-signaling-nan .
So after the push/pop tmp[1] contains a quiet Nan, while the corresponding part
of dst contains the bit representation of the signalling Nan, the memcmp
returns != 0 and the test aborts.
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-09-22
Target Milestone|--- |4.7.0
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak 2011-09-22 11:54:40
UTC ---
Confirmed with -O3 -msse4, caused by recent change.
Untested patch:
Index: i386.c
===
--- i386.c(revision 179076)
+++ i386.c(working copy)
@@ -18911,6 +18911,9 @@ ix86_expand_sse_movcc (rtx dest, rtx cmp, rtx op_t
{
rtx (*gen) (rtx, rtx, rtx, rtx) = NULL;
+ if (!nonimmediate_operand (op_true, mode))
+op_true = force_reg (mode, op_true);
+
op_false = force_reg (mode, op_false);
switch (mode)
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 --- Comment #1 from vries at gcc dot gnu.org 2011-09-22 12:25:23 UTC --- Created attachment 25339 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25339 proprocessed sse4_1-blendps.c with patch applied to make failure reproducible To reproduce: $ i686-pc-linux-gnu-gcc sse4_1-blendps.c -O2 -msse4.1 -lm -o ./sse4_1-blendps.exe $ ./sse4_1-blendps.exe Aborted
[Bug middle-end/50113] [4.7 Regression] soft-float MIPS64 compiler is miscompiling ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50113 --- Comment #7 from rsandifo at gcc dot gnu.org 2011-09-22 12:26:48 UTC --- Author: rsandifo Date: Thu Sep 22 12:26:41 2011 New Revision: 179085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179085 Log: gcc/ PR middle-end/50113 PR middle-end/50061 * calls.c (emit_library_call_value_1): Use BLOCK_REG_PADDING to get the locate.where_pad value for register-only arguments. * config/arm/arm.c (arm_pad_arg_upward): Remove HFmode handling. (arm_pad_reg_upward): Handle null types. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/config/arm/arm.c
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 --- Comment #6 from Jonathan Wakely 2011-09-22 12:26:56 UTC --- dup of PR 36022 ?
[Bug middle-end/50061] [4.7 regression] emit_library_call_value_1 change broke SF->TI conversion on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50061 --- Comment #3 from rsandifo at gcc dot gnu.org 2011-09-22 12:26:48 UTC --- Author: rsandifo Date: Thu Sep 22 12:26:41 2011 New Revision: 179085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179085 Log: gcc/ PR middle-end/50113 PR middle-end/50061 * calls.c (emit_library_call_value_1): Use BLOCK_REG_PADDING to get the locate.where_pad value for register-only arguments. * config/arm/arm.c (arm_pad_arg_upward): Remove HFmode handling. (arm_pad_reg_upward): Handle null types. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/config/arm/arm.c
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 --- Comment #7 from Paolo Carlini 2011-09-22 13:23:41 UTC --- Seems so, thanks Jon. The older one also includes some rationale from Benjamin.
[Bug libstdc++/50160] vector comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 --- Comment #30 from Jonathan Schmidt-Dominé 2011-09-22 13:39:22 UTC --- Sorry, thank you for creating the feature-request.
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 --- Comment #8 from Jonathan Wakely 2011-09-22 13:45:10 UTC --- I think before the default visibility was added everywhere it was pretty easy to cause segfaults by using -fvisibility=hidden
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #5 from paolo at gcc dot gnu.org 2011-09-22 14:16:33 UTC --- Author: paolo Date: Thu Sep 22 14:16:27 2011 New Revision: 179088 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179088 Log: /cp 2011-09-22 Jonathan Wakely Paolo Carlini PR c++/50344 * friend.c (make_friend_class): cv-qualification is ok in a friend declaration. /testsuite 2011-09-22 Jonathan Wakely Paolo Carlini PR c++/50344 * g++.dg/template/friend52.C: New. Added: trunk/gcc/testsuite/g++.dg/template/friend52.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/friend.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Paolo Carlini 2011-09-22 14:17:54 UTC --- Done.
[Bug lto/50430] Constructors of static external vars are throwed away leading to missed optimizations (and ipa-cp ICE).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50430
--- Comment #3 from Jan Hubicka 2011-09-22
14:20:07 UTC ---
Created attachment 25340
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25340
reduced testcase
This is somewhat reduced testcase. The problem can be a bit illustrated on C.
We have something like
extern vtable[]={vtable2}
where vtable2 sits in other unit and is static. We however know the
constructor and it is
extern static vtable2[]={function_ptr};
now we can fold vtable[0] to the external vtable2 that we can not reffer in
code, but still can fold references into it into function_ptr.
now with LTO we decide to not stream vtable initializer and replace it by
error_mark losing the knowledge. This is an regression to 4.6 even though it
is not too important one.
[Bug c/50486] New: No warning at signed -> unsigned casting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50486
Bug #: 50486
Summary: No warning at signed -> unsigned casting
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kir...@shutemov.name
$ cat 1.c
enum e {
A,
B,
C
};
int a(enum e e)
{
if (e < 0)
return 1;
return 0;
}
int b(void)
{
return a(-1);
}
Since enum e has only positive values GCC states that enum is unsigned and
eliminates the if-check. I can see warning about it with -Wtype-limits.
But GCC generates no warning at a(-1), so it silently casts -1 to unsigned.
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #9 from Paolo Carlini 2011-09-22 14:42:38 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 36022 ***
[Bug libstdc++/36022] stl templates exported as weak symbols though visibility hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022 --- Comment #7 from Paolo Carlini 2011-09-22 14:42:38 UTC --- *** Bug 50348 has been marked as a duplicate of this bug. ***
[Bug middle-end/50481] builtin to reverse the bit order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-22 Ever Confirmed|0 |1
[Bug c/50486] No warning at signed -> unsigned casting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50486 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-22 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez 2011-09-22 15:02:46 UTC --- -1 is converted to 4294967295 very early in the FE, but I don't know why or where. I think Wsign-conversion could warn about this. I will confirm it then, but I am not working on it.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
Jakub Jelinek changed:
What|Removed |Added
Attachment #25333|0 |1
is obsolete||
--- Comment #19 from Jakub Jelinek 2011-09-22
15:10:34 UTC ---
Created attachment 25341
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25341
gcc47-pr50374.patch
Thanks. Here is an updated patch, with hopefully fixed backend part, which
passes the whole newly added testsuite.
Unfortunately, even with -fno-tree-pre -fno-vect-cost-model, on the *-12.c
testcase it vectorizes just 12 loops (f_*_[fiu]_u), not even with -mavx2 where
e.g. I'd expect f_*_{d,ll,ull}_ull to be vectorized too, or e.g. the [fiu]_i
etc. Seems the pattern recognizer is just too restrictive in finding the IV.
On the other side as I wrote earlier, the check whether the index is strigly
increasing through the whole loop is missing (if the loop bounds are known, I
guess we could check its POLYNOMIAL_CHREC whether it has the expected form and
whether it won't wrap/overflow, and if the loop bound is unknown, if there is
addition done in a signed type, assume it won't wrap, and for unsigned if the
increment is 1 and it has the size bigger or equal to pointer size and init
0/1, then it won't wrap either.
BTW, I think on i?86/x86_64 we could in theory support even mixed size
reductions, e.g. when the index is long long (64-bit) and comparison int or
float, then I think we could use {,v}pmovsxdq instruction to extend the mask
where extremes are present from vector of 4 ints or floats to a vector of 4
long longs.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #26 from Dominique d'Humieres 2011-09-22 15:25:48 UTC --- AFAICT this pr has been fixed since some time. Here are the results I get on x86_64-apple-darwin10 (Core2Duo 2.53Ghz, 3Mb cache, 4Gb RAM) at revision 179079: Compile options : -fprotect-parens -Ofast -funroll-loops -fwhole-program without -flto with -flto Benchmark Compile Executable Ave Run Compile Executable Ave Run Name(secs) (bytes)(secs)(secs) (bytes)(secs) - --- -- --- --- -- --- ac 3.28 54936 8.81 6.64 54968 8.81 aermod 75.46 1184280 18.65131.50 1212648 18.20 air 11.24 106336 7.26 22.38 106904 7.39 capacita 3.87 77152 41.29 7.36 77200 41.31 channel 1.25 34744 3.03 2.39 34864 3.03 doduc 12.40 200016 28.02 22.47 200496 27.69 fatigue 4.06 77400 4.83 8.17 77488 4.84 gas_dyn 9.32 119256 4.92 16.64 119816 4.92 induct 7.37 148840 13.83 14.76 153224 13.84 linpk 0.70 26024 21.64 1.93 26064 21.64 mdbx 3.77 80864 12.46 7.21 81040 12.46 nf 4.08 71848 19.34 8.07 71896 19.35 protein 15.17 131304 35.30 26.05 127224 35.48 rnflow 12.58 130888 28.25 23.76 131000 26.92 test_fpu 4.78 92968 10.63 13.35 93024 10.64 tfft 0.74 22352 3.28 1.98 22432 3.28 Geometric Mean Execution Time = 12.23 secs 12.18 secs Compile options : -fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer --param max-inline-insns-auto=200 -fwhole-program without -flto with -flto Benchmark Compile Executable Ave Run Compile Executable Ave Run Name(secs) (bytes)(secs)(secs) (bytes)(secs) - --- -- --- --- -- --- ac 4.05 54904 8.11 8.18 54920 8.11 aermod101.55 1494688 18.17169.63 1527120 18.12 air 14.46 114328 7.05 30.35 114912 7.04 capacita 5.39 97552 40.24 10.80 97584 40.21 channel 1.68 38792 2.91 3.17 3 2.91 doduc 12.98 208112 27.47 25.77 208584 27.52 fatigue 4.84 81440 2.95 10.27 81504 2.93 gas_dyn 13.55 143776 4.86 25.03 144392 4.86 induct 12.95 189872 13.78 24.32 190176 13.96 linpk 0.73 21856 21.69 2.44 21888 21.69 mdbx 4.32 84928 12.45 9.39 85104 12.54 nf 7.41 92248 18.93 17.82 92272 18.91 protein 17.26 160040 35.51 31.08 155984 35.47 rnflow 15.16 138880 28.27 27.28 139040 26.85 test_fpu 5.05 92872 10.65 14.65 92928 10.65 tfft 0.75 22352 3.28 1.72 22432 3.28 Geometric Mean Execution Time = 11.67 secs 11.64 secs The option -flto improves the run time for rnflow.f90 by ~5% without slowdown for the other tests. Could these results be checked on other platforms and this PR closed if they agree with mine?
[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #55 from Jack Howarth 2011-09-22 15:31:13 UTC --- The proposed patch (with the necessary 177598-pr48108-WIP applied.. hint, hint) completes an lto-boostrap on darwin11 without issues for... Using built-in specs. COLLECT_GCC=gcc-fsf-4.7 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin11.2.0 Configured with: ../gcc-4.7-20110922/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl Thread model: posix gcc version 4.7.0 20110922 (experimental) (GCC) will post regression test later tonight to gcc-testresults.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #20 from Jakub Jelinek 2011-09-22 15:52:11 UTC --- The reason why many of the loops in *-12.c aren't vectorized is that for idxtype other than unsigned int which is the type of i there is a cast from i to the type of pos. OT, one big disadvantage of the latest patch is that the code to compute the extreme is different between normal smin/smax/umin/umax reduction and between the first part of the min/max_loc reduction - the former is faster and only computes the extreme in the lowest element of the vector, while the latter computes it duplicated in all vector elements. Which means if a loop wants to compute both the extreme and position of the extreme, it now results in unnecessary extra instructions. We don't support currently two results operations in GIMPLE, so I wonder how to express that. Perhaps use different min/max reduction expression in that case? Say REDUC_MIN_LOC_VALUE_EXPR etc., which would use reduc_min_loc_* optab to expand as well? That optab would have two targets, and if we wanted to expand REDUC_MIN_LOC_EXPR, we'd use one of the targets and pass a gen_reg_rtx () to the other one, for REDUC_MIN_LOC_VALUE_EXPR the other way around. Thoughts?
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482 --- Comment #2 from Jakub Jelinek 2011-09-22 16:24:34 UTC --- Sorry for that, yeah, the patch looks right. BTW, for CONST_VECTOR containing all bits set we could do better, for VEC_COND_EXPR x < y ? -1 : z we can do mask = x < y; z | mask; and for x < y ? z : -1; and for if the comparison is reversible mask = x >= y; z | mask.
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482
--- Comment #3 from Uros Bizjak 2011-09-22 16:27:01
UTC ---
Shorter testcase:
void
test (int code, unsigned int * image, int * colors)
{
int i;
for (i = 0; i < code; ++i)
image[i] = (colors[i] < 0 ? ~(unsigned int) 0 : colors[i]);
}
gcc -O3 -msse4.
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482
--- Comment #4 from Jakub Jelinek 2011-09-22
16:33:27 UTC ---
unsigned short a[1024], b[1024];
void
foo (void)
{
int i;
for (i = 0; i < 1024; i++)
a[i] = b[i] > 10 ? b[i] : 0x;
}
ICEs too with -O3 -msse4.
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482 --- Comment #5 from Jakub Jelinek 2011-09-22 17:02:14 UTC --- Created attachment 25342 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25342 gcc47-all-ones-cst.patch Patch to optimize vector x < y ? -1 : z and vector and/ior/xor with -1 operand.
[Bug c++/50473] [C++0x] ICE in type_has_nontrivial_copy_init, at cp/tree.c:2574
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50473 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-22 Ever Confirmed|0 |1
[Bug c++/50437] [C++0x] [4.7 regression] ICE for trivial use of lambda in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50437 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-22 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/50371] [C++0x] std::nullptr_t rejected as non-type template-parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50371 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-22 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1
[Bug libfortran/50487] New: FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 Bug #: 50487 Summary: FAIL: gfortran.dg/bessel_6.f90 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, with glibc bug fix for http://sourceware.org/bugzilla/show_bug.cgi?id=11589 which changes jn precision. I got FAIL: gfortran.dg/bessel_6.f90 -O0 execution test FAIL: gfortran.dg/bessel_6.f90 -O1 execution test FAIL: gfortran.dg/bessel_6.f90 -O2 execution test FAIL: gfortran.dg/bessel_6.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/bessel_6.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/bessel_6.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/bessel_6.f90 -O3 -g execution test FAIL: gfortran.dg/bessel_6.f90 -Os execution test gfortran.dg/bessel_6.f90 compares scalar jnf vs bessel_jn_r4 in libgfortran. Since scalar jn is changed in glibc, it fails at YN for X =34.52 -- Epsilon = 1.19209290E-07 24 0.957530737E-02 0.957520306E-020.10E-06 91.3808822632 F F [1]15522 abort (core dumped) ./a.out
[Bug c++/50055] [PATCH] Location information for the throw() specification in a function may be incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50055 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini 2011-09-22 17:27:58 UTC --- Applied.
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482 --- Comment #6 from uros at gcc dot gnu.org 2011-09-22 17:35:06 UTC --- Author: uros Date: Thu Sep 22 17:35:00 2011 New Revision: 179094 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179094 Log: PR target/50482 * config/i386/i386.c (ix86_expand_sse_movcc): When generating blendv, force op_true to register if it doesn't satisfy nonimmediate_operand predicate. testsuite/ChangeLog: PR target/50482 * gcc.target/i386/pr50482.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr50482.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49527] internal compiler error: in mangle_decl_string, at cp/mangle.c:3099
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49527 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini 2011-09-22 17:38:49 UTC --- Invalid then.
[Bug target/50464] Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464 --- Comment #4 from uros at gcc dot gnu.org 2011-09-22 17:41:30 UTC --- Author: uros Date: Thu Sep 22 17:41:25 2011 New Revision: 179095 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179095 Log: PR target/50464 * config/i386/sse.md (xop_pcmov_): Change operand 1 predicate to register_operand and operand 2 predicate to nonimmediate_operand. (xop_pcmov_256): Ditto. * config/i386/i386.c (ix86_expand_sse_movcc): When generating xop_pcmov, force op_true to register. Also, force op_false to register if it doesn't satisfy nonimmediate_operand predicate. testsuite/ChangeLog: PR target/50464 * g++.dg/other/pr50464.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/other/pr50464.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/i386.c branches/gcc-4_6-branch/gcc/config/i386/sse.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/49447] [C++0x] operator= (and compound assignment ops) does not perfectly forward
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49447 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.0 Resolution||WORKSFORME Summary|operator= (and compound |[C++0x] operator= (and |assignment ops) does not|compound assignment ops) |perfectly forward |does not perfectly forward --- Comment #2 from Paolo Carlini 2011-09-22 17:43:02 UTC --- Indeed.
[Bug c++/50488] New: Destructor problem in struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50488
Bug #: 50488
Summary: Destructor problem in struct
Classification: Unclassified
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: inexinfe...@hotmail.com
Hi I have this problem and I'm not sure if it's a bug but I guess you can help
me...
class x{
public:
x(){printf("cok %p\n",this);}
~x(){printf("dok %p\n",this);}
};
static struct _a{
int a;
x b;
}a[]={
{1}
};
int main(void){
x a;
return 0;
}
the result:
cok 0022FF14
cok 0022FF40
dok 0022FF40
dok 0040800C //<-- what???
Regards
[Bug c++/50488] Destructor problem in struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50488 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from Jonathan Wakely 2011-09-22 17:52:00 UTC --- you have two problems, one is that the code won't compile because you're missing a header, the second is that GCC 3.4.5 is ancient, so although this does appear to be a bug it will never be fixed in GCC 3.4 (it's already fixed in current releases)
[Bug libfortran/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-09-22 17:58:19 UTC --- I've had this patch in my tree for nearly a year. I'm surprised that glibc developers took nearly a year to apply a form of my libm patch to their tree. Index: gcc/testsuite/gfortran.dg/bessel_6.f90 === --- gcc/testsuite/gfortran.dg/bessel_6.f90 (revision 179023) +++ gcc/testsuite/gfortran.dg/bessel_6.f90 (working copy) @@ -12,7 +12,7 @@ implicit none real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] real,parameter :: myeps(size(values)) = epsilon(0.0) & - * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 75, 15 ] + * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ] ! The following is sufficient for me - the values above are a bit ! more tolerant ! * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ]
[Bug c++/47627] Internal error at specialization of template class with enum type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47627 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.1, 4.7.0 Resolution||WORKSFORME --- Comment #1 from Paolo Carlini 2011-09-22 18:00:23 UTC --- No ICE in 4.6 and 4.7.
[Bug c++/47436] [C++0x] Variadic base-specifier-list of union rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436 Paolo Carlini changed: What|Removed |Added Summary|Variadic|[C++0x] Variadic |base-specifier-list of |base-specifier-list of |union rejected |union rejected --- Comment #2 from Paolo Carlini 2011-09-22 18:02:45 UTC --- Suggestions about a better error message? (should be easy to change)
[Bug c++/50488] Destructor problem in struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50488 --- Comment #2 from Andrew Pinski 2011-09-22 18:11:03 UTC --- Also I think he forgot about copy constructor happening.
[Bug c++/47436] [C++0x] Variadic base-specifier-list of union rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436 --- Comment #3 from Daniel Krügler 2011-09-22 18:11:24 UTC --- (In reply to comment #2) > Suggestions about a better error message? (should be easy to change) What about: "error: every valid template specialization requires an empty template parameter pack" ? I don't know how much local information is available, if there is more available, so following would be better: "error: every valid specialization of template A requires an empty template parameter pack T"
[Bug c++/50488] Destructor problem in struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50488 --- Comment #3 from karman 2011-09-22 18:12:18 UTC --- (In reply to comment #1) > you have two problems, one is that the code won't compile because you're > missing a header, the second is that GCC 3.4.5 is ancient, so although this > does appear to be a bug it will never be fixed in GCC 3.4 (it's already fixed > in current releases) Yes, the thing is that all my projects are working over GCC 3.4.5 and my attempts to ports to 4.x was with problems, in conclusion, I have to migrate to GCC 4.x or there is a chance to fix? Regards
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 H.J. Lu changed: What|Removed |Added Component|libfortran |testsuite Target Milestone|--- |4.7.0 --- Comment #2 from H.J. Lu 2011-09-22 18:16:35 UTC --- (In reply to comment #1) > I've had this patch in my tree for nearly a year. I'm surprised > that glibc developers took nearly a year to apply a form of my > libm patch to their tree. > > > Index: gcc/testsuite/gfortran.dg/bessel_6.f90 > === > --- gcc/testsuite/gfortran.dg/bessel_6.f90 (revision 179023) > +++ gcc/testsuite/gfortran.dg/bessel_6.f90 (working copy) > @@ -12,7 +12,7 @@ > implicit none > real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, > 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] > real,parameter :: myeps(size(values)) = epsilon(0.0) & > - * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 75, 15 ] > + * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ] > ! The following is sufficient for me - the values above are a bit > ! more tolerant > ! * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ] It works for me. Can you check it in?
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 --- Comment #3 from Steve Kargl 2011-09-22 18:19:07 UTC --- On Thu, Sep 22, 2011 at 06:16:35PM +, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 > > H.J. Lu changed: > >What|Removed |Added > > Component|libfortran |testsuite >Target Milestone|--- |4.7.0 > > --- Comment #2 from H.J. Lu 2011-09-22 18:16:35 > UTC --- > (In reply to comment #1) > > I've had this patch in my tree for nearly a year. I'm surprised > > that glibc developers took nearly a year to apply a form of my > > libm patch to their tree. > > > > > > Index: gcc/testsuite/gfortran.dg/bessel_6.f90 > > === > > --- gcc/testsuite/gfortran.dg/bessel_6.f90 (revision 179023) > > +++ gcc/testsuite/gfortran.dg/bessel_6.f90 (working copy) > > @@ -12,7 +12,7 @@ > > implicit none > > real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, > > 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] > > real,parameter :: myeps(size(values)) = epsilon(0.0) & > > - * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 75, 15 ] > > + * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ] > > ! The following is sufficient for me - the values above are a bit > > ! more tolerant > > ! * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ] > > It works for me. Can you check it in? > Sure, do you want me to apply it to 4.5 and 4.6 as well.
[Bug c++/50371] [C++0x] std::nullptr_t rejected as non-type template-parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50371 --- Comment #1 from paolo at gcc dot gnu.org 2011-09-22 18:20:58 UTC --- Author: paolo Date: Thu Sep 22 18:20:53 2011 New Revision: 179096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179096 Log: /cp 2011-09-22 Paolo Carlini PR c++/50371 * pt.c (invalid_nontype_parm_type_p): Handle NULLPTR_TYPE. /testsuite 2011-09-22 Paolo Carlini PR c++/50371 * g++.dg/cpp0x/nullptr24.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50371] [C++0x] std::nullptr_t rejected as non-type template-parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50371 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Paolo Carlini 2011-09-22 18:22:44 UTC --- Done.
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 --- Comment #4 from H.J. Lu 2011-09-22 18:22:25 UTC --- (In reply to comment #3) > > > > It works for me. Can you check it in? > > > > Sure, do you want me to apply it to 4.5 and 4.6 as well. Yes, please.
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 --- Comment #5 from kargl at gcc dot gnu.org 2011-09-22 18:28:18 UTC --- Author: kargl Date: Thu Sep 22 18:28:14 2011 New Revision: 179097 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179097 Log: 2011-09-22 Steven G. Kargl PR testsuite/50487 * gfortran.dg/bessel_6.f90: Fix tolerance test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_6.f90
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 --- Comment #6 from kargl at gcc dot gnu.org 2011-09-22 18:30:42 UTC --- Author: kargl Date: Thu Sep 22 18:30:36 2011 New Revision: 179098 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179098 Log: 011-09-22 Steven G. Kargl PR testsuite/50487 * gfortran.dg/bessel_6.f90: Fix tolerance test. Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/bessel_6.f90
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from kargl at gcc dot gnu.org 2011-09-22 18:35:30 UTC --- Fixed.
[Bug testsuite/50487] FAIL: gfortran.dg/bessel_6.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 --- Comment #7 from Steve Kargl 2011-09-22 18:35:09 UTC --- On Thu, Sep 22, 2011 at 06:22:25PM +, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50487 > > --- Comment #4 from H.J. Lu 2011-09-22 18:22:25 > UTC --- > (In reply to comment #3) > > > > > > It works for me. Can you check it in? > > > > > > > Sure, do you want me to apply it to 4.5 and 4.6 as well. > > Yes, please. > Fixed on 4.6 and trunk. bessel_6.f90 only exists on these branches.
[Bug c++/50488] Destructor problem in struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50488 --- Comment #4 from Jonathan Wakely 2011-09-22 18:41:41 UTC --- GCC is open source so you can attempt to fix it yourself or pay someone to do it for you, but it will never be fixed in the official GCC 3.4 because that release series is discontinued and unsupported
[Bug c++/50488] Destructor problem in struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50488 --- Comment #5 from karman 2011-09-22 18:43:30 UTC --- ha, ok, thanks.
[Bug c++/47436] [C++0x] Variadic base-specifier-list of union rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436 --- Comment #4 from Johannes Schaub 2011-09-22 19:01:51 UTC --- (In reply to comment #3) > (In reply to comment #2) > > Suggestions about a better error message? (should be easy to change) > > What about: > > "error: every valid template specialization requires an empty template > parameter pack" > > ? I don't know how much local information is available, if there is more > available, so following would be better: > > "error: every valid specialization of template A requires an empty template > parameter pack T" Hmm, this is very technical though. When the user wrote that code, most probably they either don't want an union, but a class/struct, or they don't want to derive from something. For the tiny fraction of users that *do* want to write that exact code, they most probably expect it to be valid because they most probably think that if T is empty, it will expand to nothing. With the proposed wording of the diagnostics, in both cases the diagnostic is suboptimal
[Bug rtl-optimization/50489] New: [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
Bug #: 50489
Summary: [UPC/IA64] mis-schedule of MEM ref with
-ftree-vectorize and -fschedule-insns2
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
Target: IA64
After a change in GUPC's tree-lowering pass made a couple of months back (that
simplified the tree code being generated), we saw regressions where several
small test cases were failing on an IA64 target (SGI Altix, running SUSE).
We have been unable so far to reduce this to a "C" only test case that
demonstrates the problem, so we are submitting this as a "UPC" bug report,
along with a script that will build the UPC compiler from the GUPC branch, and
create the various bug artifacts. Perhaps someone knowledgeable with the
instruction scheduler will understand how this mis-scheduling happens and
either reproduce the issue as a "C" test case, or propose a patch.
We also do not know at this time if the UPC compiler should be generating
memory barriers or generate some other metadata to avoid this mis-scheduling,
and would appreciate any suggestions in that regard.
The attached UPC test case works fine when "-O2 -ftree-vectorize
-fno-schedule-insns2" is asserted, but demonstrates a mis-schedule when "-O2
-ftree-vectorize" is asserted.
The following description is copied from the
README-ia64-upc-sched-insn2-bug.txt file that is included in the attached zip
file as well.
Background
--
On a 64-bit target (using the "struct PTS" configuration),
the UPC compiler represents UPC pointer-to-shared values
as 128-bit structures with three fields: (vaddr, thread, phase)
as shown in the declaration below.
typedef struct shared_ptr_struct
{
void *vaddr;
uint32_t thread;
uint32_t phase;
} upc_shared_ptr_t
__attribute__ ((aligned (16)))
;
In: ia64-upc-vaddr-bug.upc.143t.optimized, there is the following
sequence of tree statements.
unsigned int D.3062;
unsigned int D.3061;
shared [8] struct foo * D.3060;
shared [8] struct foo[1] * D.3059;
struct upc_shared_ptr_t D.3058;
unsigned int D.3057;
D.3057_10 = D.3056_9 * 8;
D.3058.vaddr = &_u_barray;
MEM[(struct upc_shared_ptr_t *)&D.3058 + 8B] = { 0, 0 };
D.3059_11 = VIEW_CONVERT_EXPR(D.3058);
D.3060_12 = (shared [8] struct foo *) D.3059_11;
D.3061_13 = VIEW_CONVERT_EXPR(D.3060_12).phase;
D.3062_14 = D.3057_10 + D.3061_13;
D.3059_11 and D.3060_12 are UPC pointers-to-shared (PTS's);
these are 128-bit "fat" pointers with internal
{vaddr, thread, phase} fields.
D.3058 is a PTS representation struct that is initialized
to {&_u_barray, 0, 0}. Note that D.3059_11 and D.3060_12
are copies of the PTS representation structure, D.3058
that have been recast into a UPC pointer-to-shared (PTS).
The casts above might impose inefficiencies, and there may
be ways to improve the code, but this is the current
tree code that is generated.
This assignment statement:
D.3061_13 = VIEW_CONVERT_EXPR(D.3060_12).phase;
extracts the 'phase' field from D.3060_12, which is a copy
of the value of D.3058.phase. The value of D.3058.phase was
previously initialized to zero by the MEM[] assignment.
The fetched phase value D.3061_13 should be zero when this
assignment is executed.
Bug
---
It is this latter access to D.3060_12.phase that expands
into incorrect RTL after the selective instruction scheduling
pass is run. The access to D.3060_12.phase is scheduled
ahead of the code that sets D.3058.phase.
Valid RTL
-
The 'ok' and 'bug' compilations share the same RTL dump output all
the way through ia64-upc-vaddr-bug.upc.213r.compgotos.
In that file there RTL statements that are affected by the
mis-scheduling of instructions. (additional notes added
as '#' comments):
# D.3058.vaddr = &_u_barray (the base address of barray.
#
# r34 was previously assigned the value of &_u_barray
# r47 = r12 + 32;
# r12 is the stack pointer and r47 points to the beginning
# of the D.3058 structure, which also happens to be the
# address of the first field, D.3058.vaddr.
# Therefore, r47 points to D.3058.vaddr
(insn 46 42 331 4 (set (mem/s/f/c:DI (reg/f:DI 47 r47 [532]) [2 D.3058.vaddr+0
S8 A128])
(reg/f:DI 34 r34 [533])) ia64-upc-vaddr-bug.upc:11 5 {movdi_internal}
(nil))
# This vector op assigns: {D.3058.thread = 0; D.3058.phase = 0;}
#
# This is done by using r46 as the destination address and r36 as the source.
# r46 = r12 + 40, which is the base address of D.3058.thread.
# (D.3058.phase is the field following the D.3058.thread)
# r36 was previously set to {0, 0}.
(insn 52 69 65 4 (set (mem/s/c:V2SI (reg/f:DI 46 r46 [534]) [3 MEM[(struct
upc_shared_ptr_t *)&D.3058 + 8B]+0 S8 A64])
(reg:V2SI 36 r36 [536])) ia6
[Bug c++/47436] [C++0x] Variadic base-specifier-list of union rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436 --- Comment #5 from Jonathan Wakely 2011-09-22 19:19:21 UTC --- I'd go for "error: variadic template A is invalid because every valid specialization requires an empty template parameter pack" but I'm not sure that would be needed if the original error simply said "error: unions cannot have base classes" - I think that's clear enough
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 --- Comment #1 from Gary Funck 2011-09-22 19:21:54 UTC --- Created attachment 25343 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25343 UPC test case that demonstrates instruction mis-schedule
[Bug target/50464] Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464 --- Comment #5 from uros at gcc dot gnu.org 2011-09-22 19:28:03 UTC --- Author: uros Date: Thu Sep 22 19:27:59 2011 New Revision: 179100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179100 Log: PR target/50464 * config/i386/sse.md (xop_pcmov_): Change operand 1 predicate to register_operand and operand 2 predicate to nonimmediate_operand. (xop_pcmov_256): Ditto. * config/i386/i386.c (ix86_expand_sse_movcc): When generating xop_pcmov, force op_true to register. Also, force op_false to register if it doesn't satisfy nonimmediate_operand predicate. testsuite/ChangeLog: PR target/50464 * g++.dg/other/pr50464.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/other/pr50464.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.c branches/gcc-4_5-branch/gcc/config/i386/sse.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/48803] arm: Bad assembler produced by bit extract/shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48803 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson 2011-09-22 19:29:38 UTC --- This test case stopped failing, sort of, for 4.6 by r162943, the introduction of tree-bit-ccp optimization. However that revision merely masked the problem by default, as compiling with 4.6.[01] and -fno-tree-bit-ccp makes it reappear. The bug was finally fixed for 4.7 by r176911, the fix for the similar PR49799. That fix was also applied for 4.6.2 in r176917. Backporting r176917 to 4.5 and 4.4 fixes both PRs there too.
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 --- Comment #2 from Gary Funck 2011-09-22 19:31:04 UTC --- Created attachment 25344 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25344 zipped tar file with build script, readme, test case and test artifacts
[Bug target/50464] Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464 Uros Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-09/msg01262.htm ||l Resolution||FIXED Target Milestone|4.6.2 |4.5.4 --- Comment #6 from Uros Bizjak 2011-09-22 19:31:10 UTC --- Fixed.
[Bug target/50482] [4.7 regression] internal compiler error at recog.c:2137
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50482 Uros Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-09/msg01347.htm ||l Resolution||FIXED --- Comment #7 from Uros Bizjak 2011-09-22 19:32:50 UTC --- Fixed.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #22 from Markus Trippelsdorf 2011-09-22 19:42:44 UTC --- (In reply to comment #20) > For: > > terminate called after throwing an instance of > 'com::sun::star::container::NoSuchElementException' > It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString > const&) () from image/usr/ure/lib/libxmlreader.so. > This happens in xmlreader/source/xmlreader.cxx. > > This is new code, and shouldn't suffer lots of aliasing / compilation > nasties I hope - it is also -fairly- self-standing and relatively simple. If > we > have a problem here - we have a real problem I think. I'd personally focus on > that, it should (I hope) be easier. This problem is fixed in the current git version of LibreOffice. (I cannot reproduce it anymore, even with --with-max-jobs=4 and --with-num-cpus=4) > How did you install though ? run a 'make dev-install' ? and then run > install/program/soffice ? Yes. > this: > > #6 0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 > #7 0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () > from > /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so > #8 0x71892dff in > cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, > _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, > _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from > /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so > #9 0x71893553 in cpp_vtable_call () from > > is altogether more hairy - we create at run-time C++ vtables packed with > trampolines so we can intercept / model native C++ objects and interact with > them via python etc. that would need some more intense debugging love I guess. and this one is the only remaining issue. Issue 3) from Comment 2 was a dup of PR50365 and was fixed by Jason recently.
Re: [Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
> > is altogether more hairy - we create at run-time C++ vtables packed with > > trampolines so we can intercept / model native C++ objects and interact with > > them via python etc. that would need some more intense debugging love I > > guess. > > and this one is the only remaining issue. That sounds promising. I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #23 from Jan Hubicka 2011-09-22 20:29:38 UTC --- > > is altogether more hairy - we create at run-time C++ vtables packed with > > trampolines so we can intercept / model native C++ objects and interact with > > them via python etc. that would need some more intense debugging love I > > guess. > > and this one is the only remaining issue. That sounds promising. I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Honza
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 --- Comment #2 from Andrew Pinski 2011-09-22 20:41:07 UTC --- I get this failure also. At first I thought it was my patch and then I noticed no code changes with my change.
[Bug target/45483] gcc-4.4.3: probably wrong optimization options chosen by "-march=native"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483 --- Comment #8 from Pacho Ramos 2011-09-22 20:47:04 UTC --- It's still using generic in gcc-4.5, -march has moved from prescott to pentium-m: gcc-4.4: \_ /usr/libexec/gcc/i686-pc-linux-gnu/4.4.5/cc1 -quiet - -D_FORTIFY_SOURCE=2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic -quiet -dumpbase - -auxbase-strip /dev/null -o /tmp/ccpMToQG.s gcc-4.5.3: \_ /usr/libexec/gcc/i686-pc-linux-gnu/4.5.3/cc1 -quiet - -D_FORTIFY_SOURCE=2 -march=pentium-m --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic -quiet -dumpbase - -auxbase-strip /dev/null -o /tmp/cc11MaKg.s Should I try with gcc-4.6 to see if it uses something different than "generic" for mtune (or march has changed again)?
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 --- Comment #3 from H.J. Lu 2011-09-22 20:47:01 UTC --- (In reply to comment #0) > > The assignment is translated as a push/pop on the float stack: > ... ... > > So after the push/pop tmp[1] contains a quiet Nan, while the corresponding > part > of dst contains the bit representation of the signalling Nan, the memcmp > returns != 0 and the test aborts. I think it is wrong to convert memcpy to push/pop here.
