[Bug rtl-optimization/52250] [4.7 Regression] ICE: in sel_remove_bb, at sel-sched-ir.c:5213 with -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fselective-scheduling2 and other flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Target Milestone|4.7.0 |4.7.1 Summary|[4.7/4.8 Regression] ICE: |[4.7 Regression] ICE: in |in sel_remove_bb, at|sel_remove_bb, at |sel-sched-ir.c:5213 with|sel-sched-ir.c:5213 with |-fsel-sched-pipelining |-fsel-sched-pipelining |-fsel-sched-pipelining-oute |-fsel-sched-pipelining-oute |r-loops |r-loops |-fselective-scheduling2 and |-fselective-scheduling2 and |other flags |other flags --- Comment #10 from Andrey Belevantsev abel at gcc dot gnu.org 2012-03-06 08:02:27 UTC --- Fixed on trunk, the 4.7 branch will be fixed after 4.7.0.
[Bug target/52500] dwarf2cfi.c fails to build with -Werror for c6x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52500 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 08:14:26 UTC --- c6x backend bug, DBX_REGISTER_NUMBER should be unsigned int, not int.
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 08:26:03 UTC --- Author: jakub Date: Tue Mar 6 08:25:51 2012 New Revision: 184976 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184976 Log: Backported from 4.6 branch 2012-01-25 Jason Merrill ja...@redhat.com PR target/51934 * g++.dg/torture/pr51344.C: Limit to x86. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr51344.C
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-06 08:26:06 UTC --- (In reply to comment #13) On Tue, 2012-03-06 at 08:13 +0900, Kaz Kojima wrote: I've tested your latest patch on sh4-unknown-linux-gnu with trunk revision 184872. It looks that some new failures are poping up: New tests that FAIL: 22_locale/ctype/is/char/3.cc execution test 27_io/basic_filebuf/underflow/wchar_t/9178.cc execution test gfortran.dg/widechar_intrinsics_6.f90 -Os execution test Pehaps failures might be ones you've suggested in #10 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 Could you double check? Of course! Doing so now... I've run the testsuite on rev 184966 (without fortran though), but the failures that you've mentioned did not show up. Usually when I rebuild the whole toolchain including newlib, I have C/CPP/CXXFLAGS_FOR_TARGET set to '-Os -mpretend-cmove'. This time I removed those, but the results seem to be the same. Could you also please try again? This is suspicious...
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 08:26:32 UTC --- Author: jakub Date: Tue Mar 6 08:26:22 2012 New Revision: 184977 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184977 Log: Backported from 4.6 branch 2012-01-25 Jason Merrill ja...@redhat.com PR target/51934 * g++.dg/torture/pr51344.C: Limit to x86. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr51344.C
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #15 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06 08:49:27 UTC --- (In reply to comment #14) I've run the testsuite on rev 184966 (without fortran though), but the failures that you've mentioned did not show up. Usually when I rebuild the whole toolchain including newlib, I have C/CPP/CXXFLAGS_FOR_TARGET set to '-Os -mpretend-cmove'. This time I removed those, but the results seem to be the same. Could you also please try again? This is suspicious... I've seen same failures on sh4-unknown-linux-gnu for trunk rev 184971. With backing r184966 changes out, they went away. Weird.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-06 09:48:31 UTC --- (In reply to comment #15) I've seen same failures on sh4-unknown-linux-gnu for trunk rev 184971. With backing r184966 changes out, they went away. Weird. Can we keep the r184966 changes anyways? I will keep an eye on these failures whether I can reproduce them. If you have some time, could you please send me the intermediate .i and .s files of the failing and passing version of the '22_locale/ctype/is/char/3.cc' test case?
[Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 09:54:11 UTC --- Author: rguenth Date: Tue Mar 6 09:54:06 2012 New Revision: 184981 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184981 Log: 2012-03-06 Richard Guenther rguent...@suse.de PR lto/52097 * lto.c (uniquify_nodes): Merge TYPE_FIELDS of variant types. * gcc.dg/lto/pr52097_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr52097_0.c Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 09:56:32 UTC --- Fixed, for 4.8.
[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-03-06 Component|lto |middle-end CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Using -flto breaks code |Using -fwhole-program |which puts values in .ctors |breaks code which puts |or .init_array |values in .ctors or ||.init_array --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 10:25:53 UTC --- Reproducible with -O -fwhole-program as well. This is IPA references work which does not recognize count as being written to which is because we removed the .init/fini_array section contents. If you mark the section contents with the 'used' attribute it works correctly. Honza, can we apply some magic here? Thus, recognize special section names or so? Or is this a user bug (with -fwhole-program)? Note that the linker plugin gets this wrong as well (somehow).
[Bug middle-end/52493] [4.8 Regression] tree check fail in ptr_derefs_may_alias_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52493 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-06 Component|c |middle-end AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Blocks||52406 Ever Confirmed|0 |1 Summary|tree check fail in |[4.8 Regression] tree check |ptr_derefs_may_alias_p |fail in ||ptr_derefs_may_alias_p Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 10:27:30 UTC --- Confirmed. Fallout of the PR52406 fix.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #17 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06 10:36:01 UTC --- Created attachment 26837 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26837 preprocessed file ctype_configure_char.i
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #18 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06 10:37:13 UTC --- Created attachment 26838 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26838 worked .s file ctype_configure_char_good.s
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06 10:38:22 UTC --- Created attachment 26839 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26839 unworked .s file ctype_configure_char_bad.s
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #20 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06 10:40:31 UTC --- (In reply to comment #16) Can we keep the r184966 changes anyways? I will keep an eye on these failures whether I can reproduce them. If you have some time, could you please send me the intermediate .i and .s files of the failing and passing version of the '22_locale/ctype/is/char/3.cc' test case? I've confirmed that 22_locale/ctype/is/char/3.cc doesn't fail if linking with libstdc++.a which is built with the compiler without r184966 changes. The .s files against 3.cc are same with the both compilers. It looks that the problematic object is libstdc++-v3/src/c++98/ctype_configure_char.o because the error went away if replacing it with another one. I've attached .i and .s files for that file. The option used is COLLECT_GCC_OPTIONS='-shared-libgcc' '-B' '/exp/ldroot/dodes/xsh-gcc/./gcc' '-nostdinc++' '-L/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/src' '-L/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/src/.libs' '-B' '/usr/local/sh4-unknown-linux-gnu/bin/' '-B' '/usr/local/sh4-unknown-linux-gnu/lib/' '-isystem' '/usr/local/sh4-unknown-linux-gnu/include' '-isystem' '/usr/local/sh4-unknown-linux-gnu/sys-include' '-I' '/exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/../libgcc' '-I' '/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/include/sh4-unknown-linux-gnu' '-I' '/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/include' '-I' '/exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/libsupc++' '-fno-implicit-templates' '-Wall' '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-Wabi' '-fdiagnostics-show-location=once' '-ffunction-sections' '-fdata-sections' '-frandom-seed=ctype_configure_char.lo' '-g' '-O2' '-D' '_GNU_SOURCE' '-S' '-fPIC' '-D' 'PIC' '-o'
[Bug middle-end/52493] [4.8 Regression] tree check fail in ptr_derefs_may_alias_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52493
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06
10:58:55 UTC ---
Reduced testcase, fails at -O -ftree-vectorize:
struct Time {
long int sec;
long usec;
};
struct Flow {
unsigned short iif;
struct Time mtime;
};
struct NetFlow {
unsigned MaxFlows;
unsigned HeaderFields;
unsigned short *HeaderFormat;
};
static struct NetFlow *netflow;
static struct Time start_time;
static unsigned char emit_packet[1500];
inline long int cmpmtime(struct Time *t1, struct Time *t2)
{
return (t1-sec - t2-sec) * 1000 + (t1-usec - t2-usec) / 1000;
}
static void fill(int fields, unsigned short *format,
struct Flow *flow, void *p)
{
int i;
for (i = 0; i fields; i++)
if (format[i] == 21)
{
unsigned int __v;
__v = cmpmtime(flow-mtime, start_time);
*((unsigned int *) p) = __v;
}
}
void emit_thread()
{
fill(netflow-HeaderFields, netflow-HeaderFormat, 0, emit_packet);
}
I have a patch.
[Bug target/50970] Function pointer dereferenced twice in if statement on Arm cpu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50970 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0
[Bug target/52505] New: [avr]: __memx address space reading unintentionally from RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52505 Bug #: 52505 Summary: [avr]: __memx address space reading unintentionally from RAM Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr The __memx address space reader must determine at runtime from what memory area to read and what instruction to use. To read one byte, ine sequence might look like: ld r24,Z sbrs r25,7 lpm r24,Z This is not correct because if the read is fram flash memory but the address taken as RAM address points to the I/O area, the read might have an effect on I/O register, for example clear a latch or buffer.
[Bug target/52505] [avr]: __memx address space reading unintentionally from RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52505 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-06 AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.1 Ever Confirmed|0 |1
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #21 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-06 11:29:17 UTC --- (In reply to comment #20) I've confirmed that 22_locale/ctype/is/char/3.cc doesn't fail if linking with libstdc++.a which is built with the compiler without r184966 changes. The .s files against 3.cc are same with the both compilers. It looks that the problematic object is libstdc++-v3/src/c++98/ctype_configure_char.o because the error went away if replacing it with another one. I've attached .i and .s files for that file. The option used is [...] Cool. Thanks a lot! I think I know what the problem is now. Looking into it...
[Bug target/52506] New: [avr]: XMEGA: Wrong order of save/restore of RAMPX/Y/Z/D SFRs in ISR pro-/epilogue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52506 Bug #: 52506 Summary: [avr]: XMEGA: Wrong order of save/restore of RAMPX/Y/Z/D SFRs in ISR pro-/epilogue Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org For XMEGA devices with more than 64 KiB of RAM, the RAMPX, RAMPY, RAMPZ, RAMPD special function registers are saved/restored in ISR if they might be used or have an effect on the ISR code's memory accesses. These save/restores are in the wrong order.
[Bug target/52506] [avr]: XMEGA: Wrong order of save/restore of RAMPX/Y/Z/D SFRs in ISR pro-/epilogue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52506 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-03-06 AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Target Milestone|--- |4.7.1
[Bug target/52507] New: [avr]: movmem loop for __memx address space uses wrong loop label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52507 Bug #: 52507 Summary: [avr]: movmem loop for __memx address space uses wrong loop label Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org The __movmemx_hi and __movmemx_qi functions from libgcc use an incorrect loop label for the RAM-copy part of their code. Effect will be that after the first byte the read will be from Flash and not from RAM.
[Bug target/52507] [avr]: movmem loop for __memx address space uses wrong loop label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52507 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-06 AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.1 Ever Confirmed|0 |1
[Bug target/52508] New: [avr]: HAVE_RAMPZ as condition to set RAMPZ prior to flash-read is no more appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52508 Bug #: 52508 Summary: [avr]: HAVE_RAMPZ as condition to set RAMPZ prior to flash-read is no more appropriate Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr With the new XMEGA architecture the presence of RAMPZ register is no more appropriate to test if this register has to be set before reading from flash.
[Bug target/52508] [avr]: HAVE_RAMPZ as condition to set RAMPZ prior to flash-read is no more appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52508 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-06 AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.1 Ever Confirmed|0 |1
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-06 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-06 11:48:03 UTC --- Please post the patch when you're happy with it. Thanks in advance.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-06 11:48:22 UTC --- Hmm, this looks to me like an boost-issue and seems to me not being related to gcc itself. The cause might be that symbol-mangling has changed and boost doesn't specifies it on its export-table? I will close this bug as invalid.
[Bug tree-optimization/32120] missed PRE/FRE of a*2+4 and (a+2)*2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120 --- Comment #10 from Michael Matz matz at gcc dot gnu.org 2012-03-06 12:06:08 UTC --- (In reply to comment #9) (In reply to comment #8) I still have an unfinished patch to convert SCCVN to http://dl.acm.org/citation.cfm?id=512536 I'm happy to attach the patch if you like :) I think you sent it to me once and Micha has implemented the predication bits ontop of it (well, sort of IIRC). Yep, and I'm supposed to finish it up finally until the GCC cauldron :)
[Bug bootstrap/52509] New: target libstdc++-v3 should not be bootstrapped, libstdc++-v3 should also be a host_module (bootstrapped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52509
Bug #: 52509
Summary: target libstdc++-v3 should not be bootstrapped,
libstdc++-v3 should also be a host_module
(bootstrapped)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
We should not need to bootstrap the target libstdc++ (and it's multilibs),
but we only need a host libstdc++ (of the host multilib variant - does
a canadian cross even work right now with C++ bootstrap?). The host libstdc++
should be a static library only, and it should not build PCH files
(configured with --disable-libstdcxx-pch).
Thus, like simply
Index: Makefile.def
===
--- Makefile.def(revision 184981)
+++ Makefile.def(working copy)
@@ -84,6 +84,8 @@ host_modules= { module= libdecnumber; bo
host_modules= { module= libgui; };
host_modules= { module= libiberty; bootstrap=true;
extra_configure_flags='@extra_host_libiberty_configure_flags@';};
+host_modules= { module= libstdc++-v3; bootstrap=true;
+ extra_configure_flags='--disable-libstdcxx-pch';}
// We abuse missing to avoid installing anything for libiconv.
host_modules= { module= libiconv;
extra_configure_flags='--disable-shared';
@@ -113,7 +115,6 @@ host_modules= { module= lto-plugin; boot
extra_configure_flags=--enable-shared; };
target_modules = { module= libstdc++-v3;
- bootstrap=true;
lib_path=src/.libs;
raw_cxx=true; };
target_modules = { module= libmudflap; lib_path=.libs; };
?
[Bug middle-end/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52472 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 12:35:09 UTC --- convert_debug_memory_address can just return NULL_RTX if it can't handle it. Can't reproduce this though.
[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52461 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-06 12:43:00 UTC --- (In reply to comment #3) This is mostly the same behaviour as described by darkdragon2000 in bug 44940, except that it also happens in the application section if code size is =65536 bytes. device: ATxmega128A1 gcc version 4.5.1 (AVR_8_bit_GNU_Toolchain_3.2.3_314) (from Atmel) Windows 2000 XMEGA support is is added in GCC 4.7.0 and is still tentative an not well tested. If you use a vendor specific GCC port like mentioned above, please report bugs to the respective vendor support address or bug tracker, i.e. a...@atmel.com in this case. This bug tracker if for the official GCC hosted by FSF, not for private ports. This means that this PR refers to the FSF hosted version of the compiler, not to Atmel's fork of the compiler which might or might not expose similar problems.
[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52461 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Target Milestone|4.7.0 |4.7.1
[Bug rtl-optimization/47477] [4.6/4.7/4.8 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 12:48:30 UTC --- Related to PR45397.
[Bug tree-optimization/45397] [4.5/4.6/4.7/4.8 Regression] Issues with integer narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 12:48:19 UTC --- Related to PR47477.
[Bug bootstrap/52509] target libstdc++-v3 should not be bootstrapped, libstdc++-v3 should also be a host_module (bootstrapped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52509 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 12:58:35 UTC --- Well, for profiledbootstrap I think it is nice if target-libstdc++-v3 is actually bootstrapped, because then we are able to train the C++ FE on real C++ code.
[Bug middle-end/52493] [4.8 Regression] tree check fail in ptr_derefs_may_alias_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52493 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 13:13:35 UTC --- Fixed.
[Bug middle-end/52493] [4.8 Regression] tree check fail in ptr_derefs_may_alias_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52493 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 13:13:21 UTC --- Author: rguenth Date: Tue Mar 6 13:13:14 2012 New Revision: 184987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184987 Log: 2012-03-06 Richard Guenther rguent...@suse.de PR middle-end/52493 * tree-ssa-alias.c (ptr_derefs_may_alias_p): Robustify. * gcc.dg/torture/pr52493.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52493.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug bootstrap/52509] target libstdc++-v3 should not be bootstrapped, libstdc++-v3 should also be a host_module (bootstrapped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52509 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-06 13:15:37 UTC --- (In reply to comment #1) Well, for profiledbootstrap I think it is nice if target-libstdc++-v3 is actually bootstrapped, because then we are able to train the C++ FE on real C++ code. Well, we bootstrap the host-libstdc++, that should be enough, no? Bootstrapping libstdc++ multilib and with building the PCHs is excessive waste of resources for building GCC with a C++ compiler.
[Bug bootstrap/52509] target libstdc++-v3 should not be bootstrapped, libstdc++-v3 should also be a host_module (bootstrapped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52509 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 13:31:35 UTC --- I guess bootstrapping of the host libstdc++-v3 if it is performed is fine.
[Bug c++/52510] New: [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52510 Bug #: 52510 Summary: [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: *-*-solaris2* Target: *-*-solaris2* Build: *-*-solaris2* Between 20120302 and 20120306, mainline doesn't bootstrap on Solaris any longer: compiling libitm/config/posix/rwlock.cc fails like this: /vol/gcc/src/hg/trunk/local/libitm/config/posix/rwlock.cc: In constructor 'GTM::gtm_rwlock::gtm_rwlock()': /vol/gcc/src/hg/trunk/local/libitm/config/posix/rwlock.cc:40:17: error: no matching function for call to '_pthread_mutex::_pthread_mutex(brace-enclosed initializer list)' /vol/gcc/src/hg/trunk/local/libitm/config/posix/rwlock.cc:40:17: note: candidates are: In file included from /usr/include/sys/wait.h:20:0, from /usr/include/stdlib.h:22, from /vol/gcc/src/hg/trunk/local/libitm/libitm_i.h:36, from /vol/gcc/src/hg/trunk/local/libitm/config/posix/rwlock.cc:25: /usr/include/sys/types.h:381:16: note: _pthread_mutex::_pthread_mutex() /usr/include/sys/types.h:381:16: note: candidate expects 0 arguments, 1 provided /usr/include/sys/types.h:381:16: note: constexpr _pthread_mutex::_pthread_mutex(const _pthread_mutex) /usr/include/sys/types.h:381:16: note: no known conversion for argument 1 from 'brace-enclosed initializer list' to 'const _pthread_mutex' /usr/include/sys/types.h:381:16: note: constexpr _pthread_mutex::_pthread_mutex(_pthread_mutex) /usr/include/sys/types.h:381:16: note: no known conversion for argument 1 from 'brace-enclosed initializer list' to '_pthread_mutex' and several more. Compiling the preprocessed with with g++ 4.7 works just fine. The issue can be reproduced with the attached testcase: $ cc1plus -fpreprocessed init.ii -quiet -g -O2 -std=gnu++11 -o init.s init.ii: In constructor 'gtm_rwlock::gtm_rwlock()': init.ii:24:46: error: no matching function for call to '_pthread_cond::_pthread_cond(brace-enclosed initializer list)' init.ii:24:46: note: candidates are: init.ii:7:16: note: _pthread_cond::_pthread_cond() init.ii:7:16: note: candidate expects 0 arguments, 1 provided init.ii:7:16: note: constexpr _pthread_cond::_pthread_cond(const _pthread_cond) init.ii:7:16: note: no known conversion for argument 1 from 'brace-enclosed initializer list' to 'const _pthread_cond' init.ii:7:16: note: constexpr _pthread_cond::_pthread_cond(_pthread_cond) init.ii:7:16: note: no known conversion for argument 1 from 'brace-enclosed initializer list' to '_pthread_cond' I suspect that this patch 2012-03-03 Jason Merrill ja...@redhat.com * init.c (perform_member_init): Cope with uninstantiated NSDMI. Core 1270 * call.c (build_aggr_conv): Call reshape_init. (convert_like_real): Likewise. * typeck2.c (process_init_constructor): Clear TREE_CONSTANT if not all constant. is the culprit. Rainer
[Bug c++/52510] [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52510 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-03-06 13:59:33 UTC --- Created attachment 26840 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26840 preprocessed input
[Bug middle-end/52463] libitm.c/memcpy-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52463 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-03-06 14:38:00 UTC --- Author: aldyh Date: Tue Mar 6 14:37:54 2012 New Revision: 184991 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184991 Log: PR middle-end/52463 * trans-mem.c (tm_region_init): Use last_basic_block. Modified: branches/gcc-4_7-branch/gcc/ChangeLog
[Bug middle-end/52463] libitm.c/memcpy-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52463 --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-03-06 14:44:31 UTC --- Author: aldyh Date: Tue Mar 6 14:44:27 2012 New Revision: 184992 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184992 Log: PR middle-end/52463 * trans-mem.c (tm_region_init): Use last_basic_block. Modified: branches/gcc-4_7-branch/gcc/trans-mem.c
[Bug tree-optimization/52511] New: gcc.dg/graphite/interchange-8.c times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52511 Bug #: 52511 Summary: gcc.dg/graphite/interchange-8.c times out on Solaris/SPARC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ebotca...@gcc.gnu.org, gros...@gcc.gnu.org Host: sparc-sun-solaris2* Target: sparc-sun-solaris2* Build: sparc-sun-solaris2* I often find that the gcc.dg/graphite/interchange-8.c test times out on Solaris/SPARC: The compile time picture is quite mixed (all for 32-bit compiler binaries, 32-bit compilation): * s8.mayon (SPARC Enterprise T5220, 8-core 1.2 GHz UltraSPARC T2 CPU. i.e. sun4v): real 2:08.42 user 2:08.06 sys 0.19 * apoc (Sun Fire V890, 1.35 GHz UltraSPARC IV CPU, i.e. sun4u): real 59.67 user 59.37 sys0.19 * for comparison: fuego (ThinkPad W510, 1.6 GHz Core i7 CPU): real 19.79 user 19.73 sys0.02 -ftime-report output (attached) shows that compile time is completely dominated by Graphite data dep analysis. The question is: * Could the testcase be reduced to remain well under the default timeout of 5 minutes? * Is there some codegen problem leading to the factor 2 slowdown from sun4u to sun4v? Rainer
[Bug tree-optimization/52511] gcc.dg/graphite/interchange-8.c times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52511 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2012-03-06 15:01:21 UTC --- Created attachment 26842 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26842 -ftime-report output on apoc
[Bug tree-optimization/52511] gcc.dg/graphite/interchange-8.c times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52511 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-03-06 15:00:50 UTC --- Created attachment 26841 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26841 -ftime-report output on s8.mayon
[Bug tree-optimization/52511] gcc.dg/graphite/interchange-8.c times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52511 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-06 16:02:07 UTC --- * Is there some codegen problem leading to the factor 2 slowdown from sun4u to sun4v? UltraSPARC T1/T2 are just trounced by UltraSPARC III+/IV when it comes to single threaded performances.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #37 from oleg at smolsky dot net 2012-03-06 16:34:27 UTC --- Hey Jakub, is this smaller example digestable? http://gcc.gnu.org/bugzilla/attachment.cgi?id=26814 The asm output is straightforward, but I obviously have no clue about how complex the corresponding compiler's internal state is...
[Bug fortran/52512] New: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Bug #: 52512 Summary: Cannot match namelist object name Classification: Unclassified Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ma...@hulten.org Created attachment 26843 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26843 namelist During run-time I get the error Cannot match namelist object name. This *might* be the same as #51825, but that one is about writing to the namelist, while this is about reading. To not make any confusion if it is indeed different, I created a new bug. I compiled the following code with gfortran 4.4.6 (on RHEL6.2): PROGRAM testje IMPLICIT NONE INTEGER :: getal, jn TYPE PTRACER CHARACTER(len = 8) :: sname !: short name LOGICAL :: lini !: read in a file or not END TYPE PTRACER TYPE(PTRACER) , DIMENSION(3) :: tracer NAMELIST/namtoptrc/ getal,tracer ! Standard values getal = DO jn = 1, 3 tracer(jn)%sname = 'DEFAULT_NAME' tracer(jn)%lini = .FALSE. END DO open (99, file='nml.dat') read (99, nml=namtoptrc) write (*, nml=namtoptrc) END PROGRAM testje I enclosed the namelist. It runs fine with ifort.
[Bug fortran/52452] [4.5/4.6/4.7 Regression] INTRINSIC cannot be applied to gfortran's ETIME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52452 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-06 17:08:07 UTC --- Author: burnus Date: Tue Mar 6 17:08:01 2012 New Revision: 185005 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185005 Log: 2012-03-06 Tobias Burnus bur...@net-b.de Backport from mainline 2012-03-02 Tobias Burnus bur...@net-b.de PR fortran/52452 * resolve.c (resolve_intrinsic): Don't search for a function if we know that it is a subroutine. 2012-03-06 Tobias Burnus bur...@net-b.de Backport from mainline 2012-03-02 Tobias Burnus bur...@net-b.de PR fortran/52452 * gfortran.dg/intrinsic_8.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_8.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/52452] [4.5/4.6/4.7 Regression] INTRINSIC cannot be applied to gfortran's ETIME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52452 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-06 17:09:55 UTC --- Author: burnus Date: Tue Mar 6 17:09:48 2012 New Revision: 185006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185006 Log: 2012-03-06 Tobias Burnus bur...@net-b.de Backport from mainline 2012-03-02 Tobias Burnus bur...@net-b.de PR fortran/52452 * resolve.c (resolve_intrinsic): Don't search for a function if we know that it is a subroutine. 2012-03-06 Tobias Burnus bur...@net-b.de Backport from mainline 2012-03-02 Tobias Burnus bur...@net-b.de PR fortran/52452 * gfortran.dg/intrinsic_8.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/intrinsic_8.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #17 from Michael Meissner meissner at gcc dot gnu.org 2012-03-06 17:15:57 UTC --- Author: meissner Date: Tue Mar 6 17:15:43 2012 New Revision: 185007 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185007 Log: 2012-03-05 Michael Meissner meiss...@linux.vnet.ibm.com PR target/50310 * config/rs6000/vector.md (vector_uneqmode): Add support for UNEQ, LTGT, ORDERED, and UNORDERED IEEE vector comparisons. (vector_ltgtmode): Likewise. (vector_orderedmode): Likewise. (vector_unorderedmode): Likewise. * config/rs6000/rs6000.c (rs6000_emit_vector_compare_inner): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/vector.md
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #38 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 17:26:24 UTC --- Sorry, can't reproduce any performance degradation between 4.1 and 4.6 on the http://gcc.gnu.org/bugzilla/attachment.cgi?id=26814 testcase (-O3 -m64, default -mtune=generic): on i7-2600 4.1 user time is 0m3.833s, 4.6 0m3.411s and 4.7 0m5.102s, on AMD Barcelona 4.1 user time is 0m8.798s, 4.6 0m5.875s and 4.7 0m5.855s.
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-06 CC||burnus at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-06 17:31:32 UTC --- At line 20 of file test.f90 Fortran runtime error: Cannot match namelist object name 'alkalini', (Also fails with GCC 4.1, 4.3 and 4.8.) Cf. PR 51825 and PR 49791.
[Bug fortran/52452] [4.5/4.6/4.7 Regression] INTRINSIC cannot be applied to gfortran's ETIME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52452 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-06 17:36:07 UTC --- Fixed for on the 4.6 branch for 4.6.4 (the 4.6.3 release was missed) and on the 4.5 branch. For 4.7, the backport will happen after the 4.7.0 release (i.e. for 4.7.1).
[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 17:42:29 UTC --- Fixed for 4.8+.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID | --- Comment #14 from Pawel Sikora pluto at agmk dot net 2012-03-06 18:36:06 UTC --- (In reply to comment #13) Hmm, this looks to me like an boost-issue and seems to me not being related to gcc itself. The cause might be that symbol-mangling has changed and boost doesn't specifies it on its export-table? I will close this bug as invalid. 1). please don't close this issue as invalid - orignal topic is fixed on 4.7. will it be backported to 4.6? (i have an adjusted patch). 2). i've found the core issue for problem mentioned in comment 12. the --disable-nls configure option causes missing x64 .dll exports but this is imho a bug (libstdc++ headers allow boost to use locale support but linking fails later). i've --enabled-nls and it works fine.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-06 18:43:19 UTC --- (In reply to comment #14) i've found the core issue for problem mentioned in comment 12. the --disable-nls configure option causes missing x64 .dll exports but this is imho a bug (libstdc++ headers allow boost to use locale support but linking fails later). i've --enabled-nls and it works fine. This is why we ask for configure options in bug reports - you hadn't mentioned anything about --disable-nls I agree it's a bug if --disable-nls has any effect on libstdc++ exports.
[Bug middle-end/52372] [4.7/4.8 regression] gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372 --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-03-06 19:22:14 UTC --- Author: rsandifo Date: Tue Mar 6 19:22:10 2012 New Revision: 185013 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185013 Log: gcc/ PR middle-end/52372 * rtl.h (pc_rtx, ret_rtx, simple_return_rtx, cc0_rtx): Redefine as variables. (GR_PC, GR_CC0, GR_RETURN, GR_SIMPLE_RETURN): Delete. * emit-rtl.c (pc_rtx, ret_rtx, simple_return_rtx, cc0_rtx): New variables. (init_emit_regs): Move associated initialization to... (init_emit_once): ...here. Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c trunk/gcc/rtl.h
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #39 from oleg at smolsky dot net 2012-03-06 19:39:03 UTC --- Hmm... funky. I can reproduce the issue on a newer Intel machine: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU L5410 @ 2.33GHz stepping: 6 cpu MHz : 2327.445 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 $ time ./test41 real0m6.270s user0m6.268s sys 0m0.000s $ time ./test44 real0m5.524s user0m5.523s sys 0m0.000s $ time ./test46 real0m11.721s user0m11.718s sys 0m0.001s P.S. the middle one is made using g++ (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6). The rest are original binaries made a couple of days ago.
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #18 from Michael Meissner meissner at gcc dot gnu.org 2012-03-06 19:46:32 UTC --- Author: meissner Date: Tue Mar 6 19:46:28 2012 New Revision: 185014 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185014 Log: 2012-03-06 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline PR target/50310 * config/rs6000/vector.md (vector_uneqmode): Add support for UNEQ, LTGT, ORDERED, and UNORDERED IEEE vector comparisons. (vector_ltgtmode): Likewise. (vector_orderedmode): Likewise. (vector_unorderedmode): Likewise. * config/rs6000/rs6000.c (rs6000_emit_vector_compare_inner): Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_6-branch/gcc/config/rs6000/vector.md
[Bug target/52503] sh-wrs-vxworks: too many target masks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52503 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||kkojima at gcc dot gnu.org, ||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-06 20:11:43 UTC --- (In reply to comment #0) gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../../gcc/gcc/lto-wrapper.c -o lto-wrapper.o In file included from ../../../gcc/gcc/lto-wrapper.c:47:0: ./options.h:3697:2: error: #error too many target masks This is probably due to the recently added -msoft-atomic option. When I was adding another option (-menable-tas) afterwards I also hit the limit there and went for a Var instead of a Mask to avoid the problem. Could you please try the following? Index: gcc/config/sh/sh.opt === --- gcc/config/sh/sh.opt(revision 184966) +++ gcc/config/sh/sh.opt(working copy) @@ -320,7 +320,7 @@ Follow Renesas (formerly Hitachi) / SuperH calling conventions msoft-atomic -Target Report Mask(SOFT_ATOMIC) +Target Report Var(TARGET_SOFT_ATOMIC) Use software atomic sequences supported by kernel menable-tas I also would like to add Kaz to the CC list.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-03-06 20:19:24 UTC --- I think --disable-nls should be purely a *host* configure option - it's a bug if it affects anything at all about libstdc++.
[Bug go/52218] [4.7/4.8 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 Michael Hope michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #6 from Michael Hope michael.hope at linaro dot org 2012-03-06 20:25:18 UTC --- The getcontext() routines have now landed in glibc-ports and should be available in glibc 2.16: http://sourceware.org/ml/libc-ports/2012-02/msg00079.html I'll ask if they can be included in Ubuntu Precise.
[Bug bootstrap/52513] New: gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513 Bug #: 52513 Summary: gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: scov...@gmail.com The RC doesn't build on i686-pc-cygwin: gcc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions -I. -I../../gcc-4.7.0-RC-20120302/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../gcc-4.7.0-RC-20120302/libiberty/pex-unix.c -o pex-unix.o ../../gcc-4.7.0-RC-20120302/libiberty/pex-unix.c: In function ‘pex_unix_exec_child’: ../../gcc-4.7.0-RC-20120302/libiberty/pex-unix.c:549:2: warning: implicit declaration of function ‘spawnvpe’ [-Wimplicit-function-declaration] ../../gcc-4.7.0-RC-20120302/libiberty/pex-unix.c:549:18: error: ‘_P_NOWAITO’ undeclared (first use in this function) ../../gcc-4.7.0-RC-20120302/libiberty/pex-unix.c:549:18: note: each undeclared identifier is reported only once for each function it appears in ../../gcc-4.7.0-RC-20120302/libiberty/pex-unix.c:551:2: warning: implicit declaration of function ‘spawnve’ [-Wimplicit-function-declaration] Makefile:892: recipe for target `pex-unix.o' failed make[3]: *** [pex-unix.o] Error 1 make[3]: Leaving directory `/home/Ryan/apps/gcc-4.7.0-obj/libiberty' Makefile:8642: recipe for target `all-stage1-libiberty' failed make[2]: *** [all-stage1-libiberty] Error 2 make[2]: Leaving directory `/home/Ryan/apps/gcc-4.7.0-obj' Makefile:15771: recipe for target `stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/Ryan/apps/gcc-4.7.0-obj' Makefile:897: recipe for target `all' failed make: *** [all] Error 2 The needed declarations seem to live in Windows headers (process.h?) This is using all official (and latest) cygwin packages: binutils-2.22.51 cygwin-1.7.11s(0.259/5/3) gcc-4.5.3 gmp-4.3.2 make-3.82.90 mpfr-3.0.1 Configure command: ../gcc-4.7.0-RC-20120302/configure --prefix=$HOME/apps/gcc-4.7 --enable-languages=c,c++,lto
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #19 from Michael Meissner meissner at gcc dot gnu.org 2012-03-06 20:48:56 UTC --- Author: meissner Date: Tue Mar 6 20:48:52 2012 New Revision: 185016 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185016 Log: 2012-03-05 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline 2012-03-06 Michael Meissner meiss...@linux.vnet.ibm.com PR target/50310 * config/rs6000/vector.md (vector_uneqmode): Add support for UNEQ, LTGT, ORDERED, and UNORDERED IEEE vector comparisons. (vector_ltgtmode): Likewise. (vector_orderedmode): Likewise. (vector_unorderedmode): Likewise. * config/rs6000/rs6000.c (rs6000_emit_vector_compare_inner): Likewise. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_5-branch/gcc/config/rs6000/vector.md
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #20 from Michael Meissner meissner at gcc dot gnu.org 2012-03-06 20:56:16 UTC --- Author: meissner Date: Tue Mar 6 20:56:09 2012 New Revision: 185017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185017 Log: Merge up to 185014 to get fix for pr 50310. Added: branches/ibm/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr52286.c - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr52286.c branches/ibm/gcc-4_6-branch/gcc/testsuite/gcc.dg/bf-ms-layout-3.c - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/bf-ms-layout-3.c branches/ibm/gcc-4_6-branch/gcc/testsuite/gcc.dg/noncompile/pr52290.c - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/noncompile/pr52290.c branches/ibm/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr52330.c - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr52330.c branches/ibm/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/pr52457.c - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/pr52457.c branches/ibm/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_8.f90 - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_8.f90 branches/ibm/gcc-4_6-branch/gcc/testsuite/gfortran.dg/io_constraints_10.f90 - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/io_constraints_10.f90 branches/ibm/gcc-4_6-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_13.f90 - copied unchanged from r185014, branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_13.f90 branches/ibm/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/unordered_set/operators/52309.cc - copied unchanged from r185014, branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/unordered_set/operators/52309.cc Modified: branches/ibm/gcc-4_6-branch/ (props changed) branches/ibm/gcc-4_6-branch/ChangeLog branches/ibm/gcc-4_6-branch/boehm-gc/ChangeLog branches/ibm/gcc-4_6-branch/boehm-gc/configure branches/ibm/gcc-4_6-branch/boehm-gc/configure.ac branches/ibm/gcc-4_6-branch/boehm-gc/include/gc_config.h.in branches/ibm/gcc-4_6-branch/boehm-gc/include/private/gcconfig.h branches/ibm/gcc-4_6-branch/config/ChangeLog branches/ibm/gcc-4_6-branch/contrib/ChangeLog branches/ibm/gcc-4_6-branch/contrib/reghunt/ChangeLog branches/ibm/gcc-4_6-branch/contrib/regression/ChangeLog branches/ibm/gcc-4_6-branch/fixincludes/ChangeLog branches/ibm/gcc-4_6-branch/gcc/BASE-VER branches/ibm/gcc-4_6-branch/gcc/ChangeLog branches/ibm/gcc-4_6-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_6-branch/gcc/DATESTAMP branches/ibm/gcc-4_6-branch/gcc/REVISION branches/ibm/gcc-4_6-branch/gcc/ada/ChangeLog branches/ibm/gcc-4_6-branch/gcc/c-decl.c branches/ibm/gcc-4_6-branch/gcc/c-family/ChangeLog branches/ibm/gcc-4_6-branch/gcc/config/arm/thumb2.md branches/ibm/gcc-4_6-branch/gcc/config/i386/i386.c branches/ibm/gcc-4_6-branch/gcc/config/pa/pa.md branches/ibm/gcc-4_6-branch/gcc/config/pa/predicates.md branches/ibm/gcc-4_6-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_6-branch/gcc/config/rs6000/vector.md branches/ibm/gcc-4_6-branch/gcc/config/rs6000/vsx.md branches/ibm/gcc-4_6-branch/gcc/config/s390/s390.md branches/ibm/gcc-4_6-branch/gcc/config/sparc/sparc.c branches/ibm/gcc-4_6-branch/gcc/cp/ChangeLog branches/ibm/gcc-4_6-branch/gcc/dwarf2out.c branches/ibm/gcc-4_6-branch/gcc/fold-const.c branches/ibm/gcc-4_6-branch/gcc/fortran/ChangeLog branches/ibm/gcc-4_6-branch/gcc/fortran/io.c branches/ibm/gcc-4_6-branch/gcc/fortran/resolve.c branches/ibm/gcc-4_6-branch/gcc/fortran/trans-expr.c branches/ibm/gcc-4_6-branch/gcc/go/ChangeLog branches/ibm/gcc-4_6-branch/gcc/gthr.h branches/ibm/gcc-4_6-branch/gcc/java/ChangeLog branches/ibm/gcc-4_6-branch/gcc/lto/ChangeLog branches/ibm/gcc-4_6-branch/gcc/objc/ChangeLog branches/ibm/gcc-4_6-branch/gcc/objcp/ChangeLog branches/ibm/gcc-4_6-branch/gcc/po/ChangeLog branches/ibm/gcc-4_6-branch/gcc/stor-layout.c branches/ibm/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/ibm/gcc-4_6-branch/gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog branches/ibm/gcc-4_6-branch/gcc/testsuite/lib/target-supports.exp branches/ibm/gcc-4_6-branch/gnattools/ChangeLog branches/ibm/gcc-4_6-branch/include/ChangeLog branches/ibm/gcc-4_6-branch/intl/ChangeLog branches/ibm/gcc-4_6-branch/libada/ChangeLog branches/ibm/gcc-4_6-branch/libcpp/ChangeLog branches/ibm/gcc-4_6-branch/libcpp/po/ChangeLog branches/ibm/gcc-4_6-branch/libdecnumber/ChangeLog branches/ibm/gcc-4_6-branch/libffi/ChangeLog branches/ibm/gcc-4_6-branch/libgcc/ChangeLog
[Bug libstdc++/52514] New: --disable-nls changes libstdc++-7.dll export table.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52514 Bug #: 52514 Summary: --disable-nls changes libstdc++-7.dll export table. Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Target: x86_64-w64-mingw32 Build: x86_64-gnu-linux hi, configuring gcc-4.6 with --disable-nls for x86_64-w64-mingw32 target changes the libstdc++-7.dll exports. here's the diff: --- nls-enabled.txt 2012-03-06 09:25:36.450096471 +0100 +++ nls-disabled.txt 2012-03-06 09:25:05.493428971 +0100 @@ -62,39 +62,6 @@ _ZN11__gnu_debug19_Safe_sequence_base18_M_detach_singularEv _ZN11__gnu_debug19_Safe_sequence_base22_M_revalidate_singularEv _ZN11__gnu_debug19_Safe_sequence_base7_M_swapERS0_ - _ZN9__gnu_cxx3__712__atomic_addEPVii - _ZN9__gnu_cxx3__717__pool_alloc_base12_M_get_mutexEv - _ZN9__gnu_cxx3__717__pool_alloc_base16_M_get_free_listEy - _ZN9__gnu_cxx3__717__pool_alloc_base9_M_refillEy - _ZN9__gnu_cxx3__718__exchange_and_addEPVii - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE5uflowEv - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE6xsgetnEPcx - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE6xsputnEPKcx - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE7seekoffExNS2_12_Ios_SeekdirENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE7seekposENS2_4fposIiEENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE8overflowEi - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE9pbackfailEi - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE9underflowEv - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE5uflowEv - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE6xsgetnEPwx - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE6xsputnEPKwx - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE7seekoffExNS2_12_Ios_SeekdirENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE7seekposENS2_4fposIiEENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE8overflowEt - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE9pbackfailEt - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE9underflowEv - _ZN9__gnu_cxx3__727__verbose_terminate_handlerEv - _ZN9__gnu_cxx3__76__poolILb0EE10_M_destroyEv - _ZN9__gnu_cxx3__76__poolILb0EE13_M_initializeEv - _ZN9__gnu_cxx3__76__poolILb0EE16_M_reclaim_blockEPcy - _ZN9__gnu_cxx3__76__poolILb0EE16_M_reserve_blockEyy - _ZN9__gnu_cxx3__76__poolILb1EE10_M_destroyEv - _ZN9__gnu_cxx3__76__poolILb1EE13_M_initializeEv - _ZN9__gnu_cxx3__76__poolILb1EE16_M_get_thread_idEv - _ZN9__gnu_cxx3__76__poolILb1EE16_M_reclaim_blockEPcy - _ZN9__gnu_cxx3__76__poolILb1EE16_M_reserve_blockEyy - _ZN9__gnu_cxx3__79free_list6_M_getEy - _ZN9__gnu_cxx3__79free_list8_M_clearEv _ZNK10__cxxabiv117__class_type_info10__do_catchEPKSt9type_infoPPvj _ZNK10__cxxabiv117__class_type_info11__do_upcastEPKS0_PKvRNS0_15__upcast_resultE _ZNK10__cxxabiv117__class_type_info11__do_upcastEPKS0_PPv @@ -1524,9 +1491,6 @@ _ZNSt3__713runtime_errorD0Ev _ZNSt3__713runtime_errorD1Ev _ZNSt3__713runtime_errorD2Ev - _ZNSt3__714__convert_to_vIdEEvPKcRT_RNS_12_Ios_IostateERKPi - _ZNSt3__714__convert_to_vIeEEvPKcRT_RNS_12_Ios_IostateERKPi - _ZNSt3__714__convert_to_vIfEEvPKcRT_RNS_12_Ios_IostateERKPi _ZNSt3__714basic_ifstreamIcNS_11char_traitsIcEEE4openEPKcNS_13_Ios_OpenmodeE _ZNSt3__714basic_ifstreamIcNS_11char_traitsIcEEE4openERKNS_12basic_stringIcS2_NS_9allocatorIcNS_13_Ios_OpenmodeE _ZNSt3__714basic_ifstreamIcNS_11char_traitsIcEEE5closeEv @@ -2225,8 +2189,6 @@ _ZNSt3__716invalid_argumentD0Ev _ZNSt3__716invalid_argumentD1Ev _ZNSt3__716invalid_argumentD2Ev - _ZNSt3__717__copy_streambufsIcNS_11char_traitsIcxPNS_15basic_streambufIT_T0_EES7_ - _ZNSt3__717__copy_streambufsIwNS_11char_traitsIwxPNS_15basic_streambufIT_T0_EES7_ _ZNSt3__717__gslice_to_indexEyRKNS_8valarrayIyEES3_RS1_ _ZNSt3__717__throw_bad_allocEv _ZNSt3__717__timepunct_cacheIcE12_S_timezonesE @@ -2358,8 +2320,6 @@ _ZNSt3__720__throw_out_of_rangeEPKc _ZNSt3__720__throw_system_errorEi _ZNSt3__721_Rb_tree_rotate_rightEPNS_18_Rb_tree_node_baseERS1_ - _ZNSt3__721__copy_streambufs_eofIcNS_11char_traitsIcxPNS_15basic_streambufIT_T0_EES7_Rb - _ZNSt3__721__copy_streambufs_eofIwNS_11char_traitsIwxPNS_15basic_streambufIT_T0_EES7_Rb _ZNSt3__721__ctype_abstract_baseIcED0Ev _ZNSt3__721__ctype_abstract_baseIcED1Ev _ZNSt3__721__ctype_abstract_baseIwED0Ev @@ -2741,32 +2701,6 @@ _ZNSt3__79basic_iosIwNS_11char_traitsIwEEED0Ev _ZNSt3__79basic_iosIwNS_11char_traitsIwEEED1Ev
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #17 from Pawel Sikora pluto at agmk dot net 2012-03-06 21:04:40 UTC --- (In reply to comment #15) (In reply to comment #14) i've found the core issue for problem mentioned in comment 12. the --disable-nls configure option causes missing x64 .dll exports but this is imho a bug (libstdc++ headers allow boost to use locale support but linking fails later). i've --enabled-nls and it works fine. This is why we ask for configure options in bug reports - you hadn't mentioned anything about --disable-nls I agree it's a bug if --disable-nls has any effect on libstdc++ exports. i've filled this issue as PR52514.
[Bug regression/52515] New: [4.8 Regression]: build fails on cris-elf in unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52515 Bug #: 52515 Summary: [4.8 Regression]: build fails on cris-elf in unwind-dw2.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: rsand...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 26844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26844 repeat with e.g. cc1 -fpreprocessed unwind-dw2.i -O2 -o unwind-dw2.s A patch in the revision range (last_known_working:first_known_failing) 184997:185014 caused the build for cris-elf to fail as follows: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include-g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/tmp/hpautotest-gcc1/gcc/libgcc -I/tmp/hpautotest-gcc1/gcc/libgcc/. -I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc -I/tmp/hpautotest-gcc1/gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /tmp/hpautotest-gcc1/gcc/libgcc/unwind-dw2.c In file included from /tmp/hpautotest-gcc1/gcc/libgcc/unwind-dw2.c:36:0: /tmp/hpautotest-gcc1/gcc/libgcc/unwind-pe.h: In function 'read_sleb128': /tmp/hpautotest-gcc1/gcc/libgcc/unwind-pe.h:174:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [unwind-dw2.o] Error 1 make[4]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/libgcc' Preprocessed unwind-dw2.c attached. Author of one or more suspect patches in revision range CC:ed.
[Bug regression/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52515 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|cris-axis-elf |cris-axis-elf, ||x86_64-unknown-linux-gnu Target Milestone|--- |4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-06 21:42:28 UTC --- This fails on x86_64 too. http://gcc.gnu.org/ml/gcc-regression/2012-03/msg00062.html
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf anlauf at gmx dot de 2012-03-06 21:43:47 UTC --- (In reply to comment #1) At line 20 of file test.f90 Fortran runtime error: Cannot match namelist object name 'alkalini', (Also fails with GCC 4.1, 4.3 and 4.8.) Cf. PR 51825 and PR 49791. Playing around with the namelist, I find: namtoptrc getal = 7 tracer(1:1) = 'DIC ', .true. tracer(2:2) = 'Alkalini', .true. tracer(3:3) = 'O2 ', .true. / works. namtoptrc getal = 7 tracer(1:1) = 'DIC ', .true. tracer(2:2) = 'Alkalini', .true. tracer(3 ) = 'O2 ', .true. / works. namtoptrc getal = 7 tracer(1:1) = 'DIC ', .true. tracer(3 ) = 'O2 ', .true. tracer(2 ) = 'Alkalini', .true. / But many variations fail, producing different error messages.
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #21 from Michael Meissner meissner at gcc dot gnu.org 2012-03-06 21:50:55 UTC --- Author: meissner Date: Tue Mar 6 21:50:45 2012 New Revision: 185018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185018 Log: Merge up to 185016, pick up fix for pr 50310. Added: branches/ibm/gcc-4_5-branch/config/mh-x86-darwin - copied unchanged from r185016, branches/gcc-4_5-branch/config/mh-x86-darwin branches/ibm/gcc-4_5-branch/gcc/testsuite/c-c++-common/pr51768.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/c-c++-common/pr51768.c branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast3.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast3.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast4.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast4.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/eh/cond5.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/eh/cond5.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/eh/cond6.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/eh/cond6.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/init/value9.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/init/value9.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/init/vbase1.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/init/vbase1.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/ipa/pr51759.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/ipa/pr51759.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/other/pr49133.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/other/pr49133.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/other/pr50464.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/other/pr50464.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/pr48660.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/pr48660.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/rtti/anon-ns1.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/rtti/anon-ns1.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr47714.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr47714.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49039.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49039.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49115.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49115.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49615.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49615.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49644.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49644.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr50189.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr50189.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr51344.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr51344.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/tree-ssa/pr49911.C - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/g++.dg/tree-ssa/pr49911.C branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr38752.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr38752.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr49238.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr49238.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr50565-1.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr50565-1.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr50565-2.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr50565-2.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr51767.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr51767.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/20120111-1.c - copied unchanged from r185016, branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/20120111-1.c
[Bug lto/52516] New: FAIL: gfortran.dg/lto/pr45586* f_lto_pr45586*_0.o-f_lto_pr45586_0.o link, -O0 -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52516 Bug #: 52516 Summary: FAIL: gfortran.dg/lto/pr45586* f_lto_pr45586*_0.o-f_lto_pr45586_0.o link, -O0 -flto (internal compiler error) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rguent...@suse.de Target: *86*-*-* At revision 184981, compiling the tests gfortran.dg/lto/pr45586* gives an internal compiler error (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00686.html ): In file included from :0:0: /opt/gcc/work/gcc/testsuite/gfortran.dg/lto/pr45586_0.f90: In function 's1': /opt/gcc/work/gcc/testsuite/gfortran.dg/lto/pr45586_0.f90:14:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) y = D.2440_5-r; /opt/gcc/work/gcc/testsuite/gfortran.dg/lto/pr45586_0.f90:14:0: internal compiler error: verify_gimple failed AFAICT this occurs only with both -O0 and -flto.
[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-06 22:11:41 UTC --- From http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00416.html The 4.4 branch is now frozen, all commits require RM approval. There will be the 4.4.7 release next week released from it and after that the branch will be closed. Any chance to backport the fix to 4.4.7? If no, could this PR be closed as fixed?
[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-06 22:17:46 UTC --- I don't think it is a good idea to backport it, especially when it needs follow-ups. All 4.4 only PRs will be closed when the branch is closed.
[Bug regression/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52515
--- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-03-06
22:19:03 UTC ---
It's obviously the change in how/when cc0 is created:
(gdb) r -O2 -fpreprocessed unwind-dw2.i
Starting program: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/cc1 -O2
-fpreprocessed unwind-dw2.i
size_of_encoded_value base_of_encoded_value read_uleb128 read_sleb128
read_encoded_value_with_base read_encoded_value g
et_cie next_fde last_fde __gthread_active_p __gthread_once __gthread_key_create
__gthread_key_delete __gthread_getspecif
ic __gthread_setspecific __gthread_mutex_destroy __gthread_mutex_lock
__gthread_mutex_trylock __gthread_mutex_unlock __g
thread_recursive_mutex_lock __gthread_recursive_mutex_trylock
__gthread_recursive_mutex_unlock _Unwind_Get_Unwind_Word _
Unwind_Get_Unwind_Context_Reg_Val read_pointer read_1u read_1s read_2u read_2s
read_4u read_4s read_8u read_8s _Unwind_I
sSignalFrame _Unwind_SetSignalFrame _Unwind_IsExtendedContext _Unwind_GetGR
_Unwind_GetPtr _Unwind_GetCFA _Unwind_SetGR
_Unwind_GetGRPtr _Unwind_SetGRPtr _Unwind_SetGRValue _Unwind_GRByValue
_Unwind_GetIP _Unwind_GetIPInfo _Unwind_SetIP _Unwind_GetLanguageSpecificData
_Unwind_GetRegionStart _Unwind_FindEnclosingFunction _Unwind_GetDataRelBase
_Unwind_GetTextRelBase extract_cie_info execute_stack_op execute_cfa_program
uw_frame_state_for __frame_state_for _Unwind_SetSpColumn uw_update_context_1
uw_update_context uw_advance_context init_dwarf_reg_size_table
uw_init_context_1 _Unwind_DebugHook uw_install_context_1 uw_identify_context
_Unwind_RaiseException_Phase2 _Unwind_RaiseException
_Unwind_ForcedUnwind_Phase2 _Unwind_ForcedUnwind _Unwind_Resume
_Unwind_Resume_or_Rethrow _Unwind_DeleteException _Unwind_Backtrace
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups emutls whole-program
profile_estimate cp inline pure-const static-varAssembling functions:
read_sleb128 read_encoded_value_with_base base_of_encoded_value
execute_stack_op execute_cfa_program {GC 5333k - 2776k}
Program received signal SIGSEGV, Segmentation fault.
0x00a45611 in for_each_rtx_1 (exp=0x77dc90b8, n=1769435949,
f=0x9452f5 returnjump_p_1, data=0x0)
at /tmp/hpautotest-gcc1/gcc/gcc/rtlanal.c:2837
2837 for (; format[n] != '\0'; n++)
Missing separate debuginfos, use: debuginfo-install glibc-2.11.1-1.x86_64
(gdb) bt
#0 0x00a45611 in for_each_rtx_1 (exp=0x77dc90b8, n=1769435949,
f=0x9452f5 returnjump_p_1, data=0x0)
at /tmp/hpautotest-gcc1/gcc/gcc/rtlanal.c:2837
#1 0x00a454f6 in for_each_rtx_1 (exp=0x77da76c0, n=0, f=0x9452f5
returnjump_p_1, data=0x0)
at /tmp/hpautotest-gcc1/gcc/gcc/rtlanal.c:2859
#2 0x00a456c1 in for_each_rtx (x=0x77befed8, f=0x9452f5
returnjump_p_1, data=0x0)
at /tmp/hpautotest-gcc1/gcc/gcc/rtlanal.c:2940
#3 0x009453c8 in returnjump_p (insn=0x77befeb0) at
/tmp/hpautotest-gcc1/gcc/gcc/jump.c:935
#4 0x00622f5f in purge_dead_edges (bb=0x77c3d958) at
/tmp/hpautotest-gcc1/gcc/gcc/cfgrtl.c:2326
#5 0x00e37ab3 in find_bb_boundaries (bb=0x77c3d958) at
/tmp/hpautotest-gcc1/gcc/gcc/cfgbuild.c:529
#6 0x00e37e95 in find_many_sub_basic_blocks (blocks=0x15a7640) at
/tmp/hpautotest-gcc1/gcc/gcc/cfgbuild.c:594
#7 0x0060af69 in gimple_expand_cfg () at
/tmp/hpautotest-gcc1/gcc/gcc/cfgexpand.c:4609
#8 0x009c1167 in execute_one_pass (pass=0x142d6e0) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2084
#9 0x009c1355 in execute_pass_list (pass=0x142d6e0) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2139
#10 0x00b3ef14 in tree_rest_of_compilation (fndecl=0x77f8c800)
at /tmp/hpautotest-gcc1/gcc/gcc/tree-optimize.c:422
#11 0x006381d7 in cgraph_expand_function (node=0x77f8ad80)
at /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1837
#12 0x006383a2 in cgraph_expand_all_functions () at
/tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1904
#13 0x00638ee8 in cgraph_optimize () at
/tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:2218
#14 0x00635e76 in cgraph_finalize_compilation_unit () at
/tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1344
#15 0x00496735 in c_write_global_declarations () at
/tmp/hpautotest-gcc1/gcc/gcc/c-decl.c:10032
#16 0x00a88f16 in compile_file () at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:573
#17 0x00a8b27a in do_compile () at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:1937
#18 0x00a8b3f1 in toplev_main (argc=4, argv=0x7fffe128) at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:2013
#19 0x00566300 in main (argc=4, argv=0x7fffe128) at
/tmp/hpautotest-gcc1/gcc/gcc/main.c:36
(gdb) p format
$1 = 0x10ab22c =*3,r
(gdb) p exp
$2 = (rtx) 0x77dc90b8
(gdb) pr
(??? bad code 42405
)
(gdb) up
#1 0x00a454f6 in for_each_rtx_1 (exp=0x77da76c0, n=0, f=0x9452f5
returnjump_p_1, data=0x0)
[Bug middle-end/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52515 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Component|regression |middle-end --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-03-06 22:35:37 UTC --- Better labeled middle-end.
[Bug middle-end/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c, x86_64-unknown-linux-gnu in bid_binarydecimal.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52515 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-06 Ever Confirmed|0 |1
[Bug lto/52516] FAIL: gfortran.dg/lto/pr45586* f_lto_pr45586*_0.o-f_lto_pr45586_0.o link, -O0 -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52516 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Target|*86*-*-*|*86*-*-*, cris-axis-elf Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-06 CC||hp at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-03-06 22:46:54 UTC --- Seen for cris-elf too, 184975:184986, same thing in log.
[Bug target/52503] sh-wrs-vxworks: too many target masks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52503 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06 23:18:16 UTC --- Created attachment 26845 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26845 A patch config/sh/linux.h requires a few changes too.
[Bug target/52517] New: Bug in PPC pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52517 Bug #: 52517 Summary: Bug in PPC pointer arithmetic Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: jdeme...@cage.ugent.be Created attachment 26846 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26846 Testcase, file 1 This happens on an OS X 10.4 PPC machine (powerpc-apple-darwin8.11.0) using GCC 4.6.3. Compile the test program with gcc bug.c magic.c -O2 -o bug I would expect the output to be 42, but instead I get 123456789. Looking at the pointer arithmetic, M should be equal to L. So it seems that GCC assumes that the assignment of L cannot affect M below. The value of x matters a lot (but it clearly should not). So far, I only managed to reproduce the problem when x is a pointer to something, casted to an unsigned long. Replacing M = *(unsigned long*)(B + x); by the equivalent M = ((unsigned long*)(B))[x/4]; solves the problem. Might be related to PR49330? $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/Users/jdemeyer/sage-5.0.beta7-gcc/local/libexec/gcc/powerpc-apple-darwin8.11.0/4.6.3/lto-wrapper Target: powerpc-apple-darwin8.11.0 Configured with: ../src/configure --prefix=/Users/jdemeyer/sage-5.0.beta7-gcc/local --with-local-prefix=/Users/jdemeyer/sage-5.0.beta7-gcc/local --with-gmp=/Users/jdemeyer/sage-5.0.beta7-gcc/local --with-mpfr=/Users/jdemeyer/sage-5.0.beta7-gcc/local --with-mpc=/Users/jdemeyer/sage-5.0.beta7-gcc/local --with-system-zlib --disable-multilib Thread model: posix gcc version 4.6.3 (GCC)
[Bug target/52517] Bug in PPC pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52517 --- Comment #1 from Jeroen Demeyer jdemeyer at cage dot ugent.be 2012-03-06 23:20:23 UTC --- Created attachment 26847 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26847 Testcase, file 2
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-06
23:42:15 UTC ---
This is a reduced test case:
int test (volatile int* a, int b, int c)
{
a[1] = b != 0;
if (b == 0)
a[10] = c;
return b == 0;
}
with '-O2 -m4-single -mb' it gets compiled to:
tst r5,r5 ! b == 0 - T
mov #-1,r1
negcr1,r1 ! b != 0 - T, r1
mov.l r1,@(4,r4)
bf .L2 ! branch if (b == 0)
mov.l r6,@(40,r4)
.L2:
tst r5,r5
rts
movtr0
This is because in the 'movnegt' expander it is not mentioned that the T bit is
modified and the first CSE pass optimizes away the 'b == 0' test before the
branch. I'm trying to come up with some alternative approaches...
[Bug target/52517] Bug in PPC pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52517 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-06 23:49:08 UTC --- Not just related but it is the same issue as PR 49330. *** This bug has been marked as a duplicate of bug 49330 ***
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||jdemeyer at cage dot ||ugent.be --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-06 23:49:08 UTC --- *** Bug 52517 has been marked as a duplicate of this bug. ***
[Bug pch/52518] New: gcc fails to find pch files in subincludes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52518 Bug #: 52518 Summary: gcc fails to find pch files in subincludes Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: ca...@rodarmor.com The attached script shows that gcc 4.5 doesn't use a pch if it is included indirectly. My reading of the documentation suggested that this should work, see http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html. A precompiled header can't be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you can even include a precompiled header from inside another header, so long as there are no C tokens before the #include. On my system g++-mp-4.4 is version gcc 4.5.3 and g++-mp-4.5 is gcc version 4.4.6, both installed by macports. All the best!
[Bug pch/52518] gcc fails to find pch files in subincludes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52518 --- Comment #1 from casey at rodarmor dot com 2012-03-07 00:55:00 UTC --- Created attachment 26848 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26848 A script showing the bug.
[Bug middle-end/52519] New: [4.8 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52519 Bug #: 52519 Summary: [4.8 Regression] Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nos tdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src -L/test/gn u/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include-x c++-header -nostdinc++ -g -O2 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h \ -o hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:95:0: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/valarray: In function 'built-in': /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/valarray:1222:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2g.gch] Error 1 make[5]: *** Waiting for unfinished jobs In file included from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/unordered_set:46:0, from /test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:117: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h: In function 'built-in': /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h:428:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 make[5]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/test/gnu/gcc/objdir' make[1]: *** [stage1-bubble] Error 2 # gdb ../../../gcc/cc1plus GNU gdb (GDB) 7.4.50.20120221-cvs Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as hppa2.0w-hp-hpux11.11. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /test/gnu/gcc/objdir/gcc/cc1plus...done. s --output-pch= hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch (gdb) r Starting program: /test/gnu/gcc/objdir/gcc/cc1plus -quiet -nostdinc++ -nostdinc++ -v -I /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I /test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -iprefix /test/gnu/gcc/objdir/gcc/../lib/gcc/hppa2.0w-hp-hpux11.11/4.8.0/ -isystem /test/gnu/gcc/objdir/./gcc/include -isystem /test/gnu/gcc/objdir/./gcc/include-fixed -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include /test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h -quiet -dumpbase stdc++.h -auxbase stdc++ -g -g -O2 -O2 -std=gnu++11 -version -o /var/tmp//ccEyqVA8.s --output-pch= hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch warning: Private mapping of shared library text was not specified by the executable; setting a breakpoint in a shared library which is not privately mapped will not work. See the HP-UX 11i v3 chatr manpage for methods to privately map shared library text. GNU C++ (GCC) version 4.8.0 20120306 (experimental) [trunk revision 185013] (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.3.6 20110523 (prerelease) [gcc-4_3-branch revision 174094], GMP version 5.0.2, MPFR version 3.1.0-p1, MPC version 0.9 warning: MPFR header version 3.1.0
[Bug bootstrap/52471] ICE bootstrapping GCC 4.7.0-20120302 on x86_64 OpenBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52471 --- Comment #3 from Kyle Markley kyle at arbyte dot us 2012-03-07 02:15:15 UTC --- Another note for my appendix about edits to get things going on x86_64-openbsd. I needed to #include sys/time.h in gcc/libiberty/stack-limit.c before including sys/resource.h. I don't know the correct way to do this in a platform-specific manner.
[Bug pch/52518] gcc fails to find pch files in subincludes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52518 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-07 02:32:04 UTC --- This is expected as the token is #include .
[Bug pch/52518] gcc fails to find pch files in subincludes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52518 --- Comment #3 from casey at rodarmor dot com 2012-03-07 02:34:49 UTC --- (In reply to comment #2) This is expected as the token is #include . The documentation suggests that that shouldn't be a problem: you can even include a precompiled header from inside another header
[Bug middle-end/52519] [4.8 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52519 --- Comment #1 from dave.anglin at bell dot net 2012-03-07 03:05:54 UTC --- Appears to have been introduced by r185013. Dave -- John David Anglindave.ang...@bell.net
