[Bug target/49202] MMIX: Wrong debugging information generated (UNKNOWN: length 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49202 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-08 06:43:25 UTC --- If you have very old binutils/gdb, you might want to use -gstrict-dwarf, then gcc won't emit the various debug info extensions, including discriminators.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-07-08 07:54:33 UTC --- Please add all information and especially preprocessed source, as explained in http://gcc.gnu.org/bugs/#detailed
[Bug c++/49673] New: [C++0x] const variables initialised with constexpr constructor placed in .data not .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49673
Summary: [C++0x] const variables initialised with constexpr
constructor placed in .data not .rodata
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thi...@kde.org
This bug is similar but not exactly like bug 4131. That bug is requesting that
regular, unmarked constructors be discovered to be trivial and pre-initialised
into .data or even .rodata. In this case here, we have the C++0x constexpr
marker added to the constructor already.
Given the following source code:
8-
struct Data
{
int i;
};
extern const Data test_data = { 1 };
8-
Compiled with
g++ -O3 -S
produces as expected (trimmed):
8-
.section.rodata
test_data:
.long 1
8-
However, if we add a constexpr constructor and make the code as:
8-
struct Data
{
int i;
constexpr inline Data(int i = 0) : i(i+1) {}
};
extern const Data test_data = { 1 };
8-
The +1 is added to confirm that the constexpr constructor was evaluated at
compile time. Compiled the same way produces no errors, however, it generates
the code:
8-
.data
test_data:
.long 2
8-
The constructor was evaluated and the result was properly calculated. However,
the result is stored in .data instead of .rodata as expected.
Compiler information:
Target: i586-mandriva-linux-gnu
Configured with: ./configure --build=i586-mandriva-linux-gnu --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --x-includes=/usr/include
--x-libraries=/usr/lib --disable-libjava-multilib
--with-java-home=/usr/lib/jvm/java-rpmbuild
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-java-awt=qt,gtk
--enable-gtk-cairo --with-cloog --with-ppl --enable-cloog-backend=ppl
--disable-libssp --disable-libunwind-exceptions --disable-werror
--enable-__cxa_atexit --enable-bootstrap --enable-checking=release
--enable-gnu-unique-object
--enable-languages=c,ada,c++,fortran,go,java,lto,objc,obj-c++
--enable-linker-build-id --enable-plugin --enable-shared --enable-threads=posix
--with-system-zlib --with-bugurl=https://qa.mandriva.com/ --with-tune=generic
--with-arch=i686 --host=i586-mandriva-linux-gnu
--target=i586-mandriva-linux-gnu
Thread model: posix
gcc version 4.6.1 20110627 (Mandriva) (GCC)
[Bug c++/4131] The C++ compiler don't place a const class object to .rodata section with non trivial constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 Thiago Macieira thiago at kde dot org changed: What|Removed |Added CC||thiago at kde dot org --- Comment #26 from Thiago Macieira thiago at kde dot org 2011-07-08 08:03:50 UTC --- Using GCC 4.6, which does support constexpr in C++0x mode, it turns out that the compiler does place initialised variables in the .data section. However, const variables are still in .data, not in .rodata. I don't think they are the same issues, so I reported Bug 49673.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #4 from Jeffrey Walton noloader at gmail dot com 2011-07-08 08:07:43 UTC --- (In reply to comment #0) Sorry if this was previously reported. Searching returned an error stating I used an invalid file extension. I was attempting to compile the latest Crypto++ (svn checkout https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5 cryptopp) on a Dell GX280 (32 bit Pentium 4). Here's the internal compiler error: $ export PREFIX=/usr/local; make g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c 3way.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c adler32.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c algebra.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c algparam.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c arc4.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c asn.cpp asn.cpp: In member function ‘void CryptoPP::OID::DEREncode(CryptoPP::BufferedTransformation) const’: asn.cpp:254:1: error: unrecognizable insn: (insn 194 178 195 2 asn.cpp:248 (set (reg:SI 2 cx) (mem:QI (plus:SI (reg/f:SI 1 dx [orig:61 D.44160 ] [61]) (const_int 4 [0x4])) [16 S1 A32])) -1 (nil)) asn.cpp:254:1: internal compiler error: in extract_insn, at recog.c:2104 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions. make: *** [asn.o] Error 1 [SNIP] $ g++ --version g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It looks like removing `-mtune=native` fixed it: $cat GNUMakefile ... ifneq ($(GCC42_OR_LATER),0) ifeq ($(UNAME),Darwin) CXXFLAGS += -arch x86_64 -arch i386 else # CXXFLAGS += -march=native endif endif ... $ make g++ -DNDEBUG -g -O2 -pipe -c 3way.cpp g++ -DNDEBUG -g -O2 -pipe -c adler32.cpp g++ -DNDEBUG -g -O2 -pipe -c algebra.cpp g++ -DNDEBUG -g -O2 -pipe -c algparam.cpp g++ -DNDEBUG -g -O2 -pipe -c arc4.cpp g++ -DNDEBUG -g -O2 -pipe -c asn.cpp g++ -DNDEBUG -g -O2 -pipe -c authenc.cpp g++ -DNDEBUG -g -O2 -pipe -c base32.cpp g++ -DNDEBUG -g -O2 -pipe -c base64.cpp ...
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #5 from Jeffrey Walton noloader at gmail dot com 2011-07-08 08:35:11 UTC --- Created attachment 24710 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24710 File asn.s from class file causing internal compiler error
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #6 from Jeffrey Walton noloader at gmail dot com 2011-07-08 08:35:55 UTC --- Created attachment 24711 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24711 File asn.ii from class causing internal compiler error
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #7 from Jeffrey Walton noloader at gmail dot com 2011-07-08 08:36:08 UTC --- (In reply to comment #3) Please add all information and especially preprocessed source, as explained in http://gcc.gnu.org/bugs/#detailed Crypto++ sources: `svn checkout https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5 cryptopp` Output from command is below, and asn.s attached: jeffrey@bruno:~/Desktop/cryptopp$ make clean ... jeffrey@bruno:~/Desktop/cryptopp$ gcc -v -save-temps -DNDEBUG -g -O2 -march=native -pipe -c asn.cpp gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/i386-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DNDEBUG' '-g' '-O2' '-pipe' '-c' /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/cc1plus -E -quiet -v -D_GNU_SOURCE -DNDEBUG asn.cpp -D_FORTIFY_SOURCE=2 -march=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=prescott -g -fworking-directory -O2 -fpch-preprocess -fstack-protector -o asn.ii ignoring nonexistent directory /usr/local/include/i386-linux-gnu ignoring nonexistent directory /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../../../../i686-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.5 /usr/include/c++/4.5/i686-linux-gnu /usr/include/c++/4.5/backward /usr/local/include /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DNDEBUG' '-g' '-O2' '-pipe' '-c' /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/cc1plus -fpreprocessed asn.ii -march=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=prescott -quiet -dumpbase asn.cpp -auxbase asn -g -O2 -version -fstack-protector -o asn.s GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (i686-linux-gnu) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (i686-linux-gnu) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 0c5cb630517b5952f4898dfa56d7e8e5 asn.cpp: In member function ‘void CryptoPP::OID::DEREncode(CryptoPP::BufferedTransformation) const’: asn.cpp:254:1: error: unrecognizable insn: (insn 191 175 192 2 asn.cpp:248 (set (reg:SI 2 cx) (mem:QI (plus:SI (reg/f:SI 1 dx [orig:60 D.44160 ] [60]) (const_int 4 [0x4])) [16 S1 A32])) -1 (nil)) asn.cpp:254:1: internal compiler error: in extract_insn, at recog.c:2104 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions. jeffrey@bruno:~/Desktop/cryptopp$
[Bug middle-end/49662] [4.7 Regression] FAIL: gcc.dg/graphite/interchange-XX.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-08 08:42:36 UTC --- Author: rguenth Date: Fri Jul 8 08:42:31 2011 New Revision: 176031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176031 Log: 2011-07-08 Richard Guenther rguent...@suse.de PR tree-optimization/49662 * gcc.dg/graphite/interchange-14.c: XFAIL. * gcc.dg/graphite/interchange-15.c: Likewise. * gcc.dg/graphite/interchange-mvt.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/interchange-14.c trunk/gcc/testsuite/gcc.dg/graphite/interchange-15.c trunk/gcc/testsuite/gcc.dg/graphite/interchange-mvt.c
[Bug tree-optimization/49662] [4.7 Regression] XFAIL: gcc.dg/graphite/interchange-XX.c, PRE confuses loop interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, xfail Component|middle-end |tree-optimization Summary|[4.7 Regression] FAIL: |[4.7 Regression] XFAIL: |gcc.dg/graphite/interchange |gcc.dg/graphite/interchange |-XX.c |-XX.c, PRE confuses loop ||interchange --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-08 08:43:44 UTC --- Now XFAILed.
[Bug c/40528] Add a new ifunc attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
--- Comment #16 from Agner Fog agner at agner dot org 2011-07-08 08:52:32 UTC
---
(In reply to comment #15)
(In reply to comment #14)
(In reply to comment #13)
What is the status of this issue?
It is implemented on ifunc branch.
Is option 3 implemented?
Yes, on ifunc branch.
Which versions of Linux and binutils support IFUNC?
Still doesn't work.
warning: ‘ifunc’ attribute directive ignored
GNU Binutils for Ubuntu 2.21.0.20110327
The ifunc attribute is described in
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html but it doesn't work
(see my previous comment). After some experimentation I found that the method
described below works. Either the compiler should be fixed or the onlinedocs
should be changed.
// Example of gnu indirect function
#include stdio.h
#include time.h
// Define different versions of my function
int myfunc1() {
return 1;
}
int myfunc2() {
return 2;
}
// Type definition for pointer to my function
typedef int (*MyFunctionPointer)(void);
// Prototype for the common entry point
extern C // remove this line if not C++
int myfunc();
__asm__ (.type myfunc, @gnu_indirect_function);
// Make the dispatcher function
MyFunctionPointer myfunc_dispatch (void) __asm__ (myfunc);
MyFunctionPointer myfunc_dispatch (void) {
if (time(0) 1) {
// If time is odd at first call, use version 1
return myfunc1;
}
else {
// else use version 2
return myfunc2;
}
}
int main() {
// Test the call to myfunc
printf(\nCalled function number %i\n, myfunc());
return 0;
}
[Bug c/49674] New: Improve documentation for __attribute__ __section__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49674 Summary: Improve documentation for __attribute__ __section__ Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: rdiezmail-...@yahoo.de Can someone please improve the documentation for __attribute__ __section__ ? Only functions are mentioned, but I know it works for variables too. This is the documentation page on the Web: http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Function-Attributes.html Apparently, there are checks in GCC against the section properties. For example, you cannot place a non-const variable in a const section, you get a section type conflict error message. Documentation about this would be an extra bonus. I wonder how documentation bugs are handled in this project, I couldn't find any documentation category in Bugzilla. Many thanks in advance.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2011-07-08 09:42:59 UTC --- The included source compiles OK for me with: ~/gcc-build/gcc/cc1plus -quiet -O2 -m32 -g -fstack-protector -march=prescott -mtune=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 asn.ii Tried with: GNU C++ (GCC) version 4.5.4 20110525 (prerelease) GNU C++ (GCC) version 4.6.1 20110611 (prerelease) GNU C++ (GCC) version 4.7.0 20110707 (experimental) The bug is either fixed or local to: g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 Please try to reproduce the bug with latest FSF compiler. Alternatively, please report the bug to Ubuntu.
[Bug rtl-optimization/47918] [4.6/4.7 Regression] noreturn discovery broke non local gotos on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918
--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-07-08
09:42:26 UTC ---
I can trigger the bug on i386 too, if I tweak the i386 backend to push function
parameters rather than moving them to pre-allocated stack space, and to
disallow regparm promotion for calls to non-exported functions, via this patch:
--- gcc-4.6-r160123/gcc/config/i386/i386.h.~1~ 2010-05-29 16:03:31.0
+0200
+++ gcc-4.6-r160123/gcc/config/i386/i386.h 2011-07-08 10:43:46.0
+0200
@@ -1513,13 +1513,21 @@ enum reg_class
prologue and apilogue. This is not possible without
ACCUMULATE_OUTGOING_ARGS. */
+#if 0
#define ACCUMULATE_OUTGOING_ARGS \
(TARGET_ACCUMULATE_OUTGOING_ARGS || ix86_cfun_abi () == MS_ABI)
+#else
+#define ACCUMULATE_OUTGOING_ARGS 0
+#endif
/* If defined, a C expression whose value is nonzero when we want to use PUSH
instructions to pass outgoing arguments. */
+#if 0
#define PUSH_ARGS (TARGET_PUSH_ARGS !ACCUMULATE_OUTGOING_ARGS)
+#else
+#define PUSH_ARGS 1
+#endif
/* We want the stack and args grow in opposite directions, even if
PUSH_ARGS is 0. */
@@ -1804,7 +1812,11 @@ typedef struct ix86_args {
#define X86_64_REGPARM_MAX 6
#define X86_64_MS_REGPARM_MAX 4
+#if 0
#define X86_32_REGPARM_MAX 3
+#else
+#define X86_32_REGPARM_MAX 0
+#endif
#define REGPARM_MAX\
(TARGET_64BIT ? (TARGET_64BIT_MS_ABI ? X86_64_MS_REGPARM_MAX \
With that in place gcc still bootstraps ok on i686-linux, but r160124 now
miscompiles non-local-goto-4.c just like on m68k (see the changed and now
incorrect stack offset in the first insn after L4):
--- non-local-goto-4.s-r160123 2011-07-08 10:58:40.0 +0200
+++ non-local-goto-4.s-r160124 2011-07-08 11:24:05.0 +0200
@@ -25,19 +25,17 @@
movl%esp, 8(%esp)
pushl 36(%esp)
cally.1220
- popl%eax
+ .p2align 4,,7
+ .p2align 3
+.L2:
.L4:
- movl36(%esp), %eax
+ movl40(%esp), %eax
movl16(%esp), %ebx
movl20(%esp), %esi
movl24(%esp), %edi
movl28(%esp), %ebp
addl$32, %esp
ret
- .p2align 4,,7
- .p2align 3
-.L2:
- jmp .L4
.size x, .-x
.p2align 4,,15
.globl main
When I look at dumps everything looks ok up to .188r.asmcons, but in .191r.ira
I see a new load from the stack with the wrong offset.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #9 from Jeffrey Walton noloader at gmail dot com 2011-07-08 09:51:21 UTC --- (In reply to comment #8) The included source compiles OK for me with: ~/gcc-build/gcc/cc1plus -quiet -O2 -m32 -g -fstack-protector -march=prescott -mtune=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 asn.ii Tried with: GNU C++ (GCC) version 4.5.4 20110525 (prerelease) GNU C++ (GCC) version 4.6.1 20110611 (prerelease) GNU C++ (GCC) version 4.7.0 20110707 (experimental) Interesting. If it matters, the hardware is a Dell GX280. The bug is either fixed or local to: g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 Please try to reproduce the bug with latest FSF compiler. Alternatively, please report the bug to Ubuntu. OK, thanks. The folks at Ubuntu are aware: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/807156. Thanks for the quick response and help.
[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48727 --- Comment #7 from Rainer Orth ro at gcc dot gnu.org 2011-07-08 10:20:39 UTC --- Author: ro Date: Fri Jul 8 10:20:36 2011 New Revision: 176034 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176034 Log: PR testsuite/48727 * g++.dg/opt/devirt2.C: Use specific pattern for sparc*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/devirt2.C
[Bug c/49674] Improve documentation for __attribute__ __section__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49674 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.08 10:23:58 Ever Confirmed|0 |1
[Bug middle-end/49671] [4.6/4.7 Regression] volatile goes missing after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49671 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-08 10:30:32 UTC --- Doesn't the outermost component also need TREE_THIS_VOLATILE? So I suppose sink the TREE_THIS_VOLATILE (*tp) = TREE_THIS_VOLATILE (old); from the else branch as well.
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Attachment #24705|0 |1 is obsolete|| --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org 2011-07-08 10:33:47 UTC --- Created attachment 24712 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24712 updated work in progress there were a couple of hunks in the previous from another LTO patch, that reportedly gave problems on x86-64-darwin11. The attached is OK AFAICT, on 4.6, trunk x86-64-darwin10, *-darwin9. (still incomplete).
[Bug rtl-optimization/47918] [4.6/4.7 Regression] noreturn discovery broke non local gotos on m68k and i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
Target|m68k-linux |m68k-linux,
||i686-pc-linux-gnu
Known to work||4.5.3
Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression]
|noreturn discovery broke|noreturn discovery broke
|non local gotos on m68k |non local gotos on m68k and
||i386
Known to fail||4.6.1
--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2011-07-08
10:56:32 UTC ---
I don't even have to tweak the i386 backend to trigger the error on i386, just
make the nested function y() regparm(0)
--- non-local-goto-4.c.~1~ 2011-07-07 20:04:29.0 +0200
+++ non-local-goto-4.c 2011-07-08 12:49:36.0 +0200
@@ -15,7 +15,7 @@ int
x(a)
{
__label__ xlab;
- void y(a)
+ void __attribute__((regparm(0))) y(a)
{
if (a==0)
goto xlab;
and compile with options to force the use of PUSH for parameter passing:
gcc -O3 -fomit-frame-pointer -fno-asynchronous-unwind-tables -mpush-args
-mno-accumulate-outgoing-args non-local-goto-4.c
./a.out
Abort
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-08 11:01:06 UTC --- I believe I'm making good progress in analyzing, thus fixing, the issue with inplace_merge: what I see clearly now is that - as noticed in Comment 9 for the first time - __move_merge, for the purpose of __merge_adaptive, can be safely changed to simply end with: return _GLIBCXX_MOVE3(__first1, __last1, __result); and the self-move assignment issue is solved. The reason being that when the main while loop is exited with __first2 != __last2, __first2 always points to the same position pointed by __result: indeed, in the case of inplace_merge the overall source and destination ranges coincide and nothing else is possible. However, __move_merge is also used by __merge_sort_loop, where different assumptions hold. I don't know at the moment if we can do something better than just specializing __move_merge for __merge_adaptive per the above. Also, remains to be analyzed the *_backward case. Chris, any help is welcome.
[Bug target/49398] [4.7 Regression] bootstrap broken for arm-linux-gnueabi with thumb mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49398 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-07-08 11:10:54 UTC --- This is now fixed.
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-08 11:18:25 UTC --- (In reply to comment #14) Created attachment 24712 [details] updated work in progress there were a couple of hunks in the previous from another LTO patch, that reportedly gave problems on x86-64-darwin11. The attached is OK AFAICT, on 4.6, trunk x86-64-darwin10, *-darwin9. (still incomplete). http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00877.html No serious regressions other than objc and friends when applied to gcc 4.6.1.
[Bug rtl-optimization/47918] [4.6/4.7 Regression] noreturn discovery broke non local gotos on m68k and i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.08 11:21:08 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-08 11:21:08 UTC --- This looks like a missing stack adjustment. do_pending_stack_adjust needs to be called before any potential control flow change. Maybe such a call is missing?
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-08 11:46:10 UTC --- The *_backward case seems rather straightforward, with the roles of the __first1, __last1 and __first2, __last2 ranges swapped.
[Bug fortran/49675] New: jacobi.F90:90:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49675 Summary: jacobi.F90:90:0: internal compiler error: Segmentation fault Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kapi...@rz.rwth-aachen.de Created attachment 24713 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24713 the reproducer (MPI needed) Hi, the 4.6.1 (and 4.6.0) versions of gfortran compiler suffers from a SIGSEGV if compiling the attached Fortran code jacobi.F90. The bug does NOT apper with 4.5.1 version of gfortran. The error hangs together with the -finstrument-functions option. Since the attached code snippets are MPI programs, you need a version of e.g. OpenMPI (we use 1.4.3). Best wishes -PK
[Bug debug/49676] New: inefficiency: DW_AT_GNU_call_site_value calculates everything 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49676
Summary: inefficiency: DW_AT_GNU_call_site_value calculates
everything 32
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
CC: ja...@redhat.com
Target: x86_64-unknown-linux-gnu
It works but it is a bit size-inefficient/overcomplicated.
extern void d (int);
void __attribute__((noinline, noclone))
self (int i)
{
if (i == 200)
self (i + 1);
else
d (i + 2);
}
-g -O2
gcc (GCC) 4.7.0 20110708 (experimental)
DW_AT_GNU_call_site_value: 26 byte block: f3 1 55 23 2 8 cb f3 1 55 8 20 24 10
80 80 80 80 80 19 2e 28 1 0 16 13(DW_OP_GNU_entry_value: (DW_OP_reg5
(rdi)); DW_OP_plus_uconst: 2; DW_OP_const1u: 203; DW_OP_GNU_entry_value:
(DW_OP_reg5 (rdi)); DW_OP_const1u: 32; DW_OP_shl; DW_OP_constu: 858993459200;
DW_OP_ne; DW_OP_bra: 1; DW_OP_swap; DW_OP_drop)
this is:
DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi))
DW_OP_plus_uconst: 2
= 202
DW_OP_const1u: 203
DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi))
DW_OP_const1u: 32
32, 200, 203, 202
DW_OP_shl
200 32, 203, 202
DW_OP_constu: 858993459200
200 32, 200 32, 203, 202
DW_OP_ne
DW_OP_bra: 1
DW_OP_swap
DW_OP_drop
858993459200 = 200 32
There should not be a need to shl by 32 and calculate it everything 32.
unrelated: function was inlined by `cmovne' despite there is `noinline'.
[Bug target/43118] vld4 and vst4 intrinsics are not handled correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
Known to fail||
--- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-07-08
11:57:04 UTC ---
A recent version of 4.6.1 at O1 appears to give me . That would indicate this
is fixed in trunk.
blend4:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vld4.8{d16-d19}, [r0]
vst4.8{d16-d19}, [r1]
bxlr
.sizeblend4, .-blend4
.identGCC: (GNU) 4.7.0 20110616 (experimental)
.section.note.GNU-stack,,%progbits
Ramana
[Bug middle-end/49675] [4.6/4.7 Regression] ICE (segfault) with -finstrument-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49675 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Component|fortran |middle-end Target Milestone|--- |4.6.2 Summary|jacobi.F90:90:0: internal |[4.6/4.7 Regression] ICE |compiler error: |(segfault) with |Segmentation fault |-finstrument-functions --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-08 12:08:22 UTC --- Minimal test case: subroutine one() end subroutine one compiled with gfortran -finstrument-functions. Valgrind shows: ==4467== Invalid read of size 2 ==4467==at 0x76C5C4: gimple_build_call (gimple.c:262) ==4467==by 0x7A1DB8: gimplify_function_tree (gimplify.c:7938) ==4467==by 0x642EA7: cgraph_analyze_function (cgraphunit.c:890) ==4467==by 0x643697: cgraph_analyze_functions (cgraphunit.c:1108) ==4467==by 0x645544: cgraph_finalize_compilation_unit (cgraphunit.c:1294) ==4467==by 0x7F1C3C: write_global_declarations (langhooks.c:303) ==4467==by 0x8E9283: toplev_main (toplev.c:564) ==4467==by 0x645200C: (below main) (libc-start.c:226) The ICE occurs in gimple_build_call (gimple.c:262) for: gcc_assert (TREE_CODE (fn) == FUNCTION_DECL || is_gimple_call_addr (fn)); The problem is that the argument is fn == NULL. The callee (gimplify_function_tree (gimplify.c:7938)) is: x = implicit_built_in_decls[BUILT_IN_RETURN_ADDRESS]; call = gimple_build_call (x, 1, integer_zero_node); The problem is that implicit_built_in_decls[BUILT_IN_RETURN_ADDRESS] is NULL.
[Bug c++/49673] [C++0x] const variables initialised with constexpr constructor placed in .data not .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49673 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.08 12:21:03 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130
--- Comment #11 from Jan Kratochvil jan.kratochvil at redhat dot com
2011-07-08 12:33:19 UTC ---
I do not see any functionality problem from it, neither now and neither in the
future.
(In reply to comment #7)
But DW_AT_name really represents the name of the operator as written in the
source code[2], with its template parameters replaced with their
corresponding arguments.
Both variants of this code:
#include string
template typename T
void f () {}
//int main () { fstd::string (); }
int main () { fstd::basic_stringchar (); }
produce the same DWARF output:
2afa DW_AT_name: fstd::basic_stringchar
So one cannot say that one or the other matches the source code more.
One can only argue whether DWARF DW_AT_name should be compressed or not.
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 --- Comment #24 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-08 13:12:05 UTC --- Author: hjl Date: Fri Jul 8 13:12:03 2011 New Revision: 176042 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176042 Log: Fix PR middle-end/49519. gcc/ 2011-07-08 Kirill Yukhin kirill.yuk...@intel.com PR middle-end/49519 * calls.c (mem_overlaps_already_clobbered_arg_p): Additional check if address is stored in register. If so - give up. (check_sibcall_argument_overlap_1): Do not perform check of overlapping when it is call to address. gcc/tessuite/ 2011-07-08 Kirill Yukhin kirill.yuk...@intel.com PR middle-end/49519 * g++.dg/torture/pr49519.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr49519.C Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog
[Bug debug/49676] inefficiency: DW_AT_GNU_call_site_value calculates everything 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49676 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 2011-07-08 14:06:53 UTC --- The reason for that is that, when not emitting typed DWARF, we have the call site value of %edi: (if_then_else:SI (ne (entry_value:SI (reg:SI 5 di [ i ])) (const_int 200 [0xc8])) (plus:SI (entry_value:SI (reg:SI 5 di [ i ])) (const_int 2 [0x2])) (const_int 203 [0xcb])) and x86-64 has 64-bit DWARF2_ADDR_SIZE and we want to compare just the low 32 bits of the register. DW_OP_ne compares whole 64-bit (untyped) integers, so by shifting it up by 32 bits it can be compared easily. In this exact case when it can be done as unsigned comparison too we could very well do: @@ -134,11 +134,11 @@ self: .byte 0xf3# DW_OP_GNU_entry_value .uleb128 0x1 .byte 0x55# DW_OP_reg5 - .byte 0x8 # DW_OP_const1u - .byte 0x20 - .byte 0x24# DW_OP_shl - .byte 0x10# DW_OP_constu - .uleb128 0xc8 + .byte 0xc # DW_OP_const4u + .long 0x + .byte 0x1a# DW_OP_and + .byte 0x10# DW_OP_const1u + .byte 0xc8 .byte 0x2e# DW_OP_ne .byte 0x28# DW_OP_bra .value 0x1 and save 2 bytes instead. But if it would be /=//= signed comparison instead, I think comparing in most significant bits is still shorter. BTW, self isn't inlined, it is tail recursion optimized.
[Bug c++/49673] [C++0x] const variables initialised with constexpr constructor placed in .data not .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49673 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-07-08 14:24:17 UTC --- Author: jason Date: Fri Jul 8 14:24:14 2011 New Revision: 176045 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176045 Log: PR c++/49673 gcc/c-family/ * c-common.c (c_apply_type_quals_to_decl): Don't check TYPE_NEEDS_CONSTRUCTING. gcc/cp/ * typeck.c (cp_apply_type_quals_to_decl): Don't check TYPE_NEEDS_CONSTRUCTING. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49673] [C++0x] const variables initialised with constexpr constructor placed in .data not .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49673 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-07-08 14:28:32 UTC --- Fixed for 4.7.
[Bug debug/49676] inefficiency: DW_AT_GNU_call_site_value calculates everything 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49676 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-07-08 14:40:54 UTC --- Therefore func (int i) is correct to call with value 1 as: movq $0xdeaddead0001, %rdi I did not realize. Thanks for the explanation. DW_OP_shl vs. DW_OP_and inefficiency I would not file.
[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Version|unknown |4.6.0 Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-07-08 14:52:17 UTC --- This was fixed in 4.6.1 . Ramana
[Bug c++/45697] __restrict__ inconsistent in presence of typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45697 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-07-08 14:53:33 UTC --- C++ ignores inappropriate cv-qualifications introduced through the use of a typedef or template type parameter: int i; typedef int IR; IR const ir1 = i; // OK int const ir2 = i; // error G++ is treating restrict the same way. It's not clear to me that this is the right thing to do, but it's not clear that it's wrong, either.
[Bug lto/49677] New: GCC 4.6.0 LTO files not compatible with GCC 4.6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677 Summary: GCC 4.6.0 LTO files not compatible with GCC 4.6.1 Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Created attachment 24714 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24714 test.o Using gcc 4.6.1 to link objects compiled with GCC 4.6.0 -flto produces this error: $ gcc test.o -flto -shared lto1: error: bad value (generic) for -mtls-dialect= switch lto-wrapper: /usr/bin/gcc returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status There is no -mtls-dialect=generic flag, (and there wasn't either). Instead there is an -mtune=generic flag: COLLECT_GCC_OPTIONS='-flto' '-shared' '-v' '-mtune=generic' '-march=x86-64' I think 4.6.1 confuses -mtune and -mtls-dialect when loading 4.6.0 LTO objects. Maybe the LTO version should be bumped to make these objects incompatible? Fixing this compile error is possible if: - make clean in all the projects that you link in - ccache -C, ccache -c to delete all cached objects from previous version It'd be better if GCC automatically detected that a certain LTO object file is not compatible, and say which one it is. In any case it'd be useful if there would be a -Wlto-mismatch, that would warn if LTO objects were produced with different GCC versions (.comment section should contain full version), or if the LTO objects and current compiler version are different. gcc -v output: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-2) I'm attaching the test.o file, because it the bug doesn't reproduce if I compile it again from source with 4.6.1, only if I use the object file compiled by 4.6.0.
[Bug c++/45697] __restrict__ inconsistent in presence of typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45697 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-07-08 14:57:52 UTC --- Created attachment 24715 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24715 patch But here's a patch against pre-4.7 to do what you want.
[Bug rtl-optimization/49169] ARM: optimisations strip the Thumb/ARM mode bit off function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.08 15:04:22 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #25 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-07-08 15:28:08 UTC --- Jakub, While this fixes it for 4.6 should this also be backported to the 4.5 branch ? Ramana
[Bug debug/49676] inefficiency: DW_AT_GNU_call_site_value calculates everything 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49676 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-08 15:31:38 UTC --- Created attachment 24716 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24716 gcc47-pr49676.patch Attached patch saves those 2 bytes. To answer the general question, for DWARF2_ADDR_SIZE size types entry_value is just untyped, and assuming whether it is signed or unsigned is error-prone, especially if it is in another CU where we can't check it. In some ABIs the registers in which stuff is passed are sign-extended or zero-extended, on other ABIs they may contain garbage in the upper bits, in other ABIs it is a mess (e.g. x86_64 unfortunately).
[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-08 15:35:01 UTC --- It could, but I don't have time to do it myself. So, if somebody goes ahead and tests the backport, fine.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Attachment #24613|0 |1 is obsolete|| --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-08 15:46:35 UTC --- Created attachment 24717 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24717 Draft patch, passes testing. This is what I have so far. Looks pretty good to me.
[Bug middle-end/43460] internal compiler error: Segmentation fault on __builtin_unreachable() after asm goto()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43460 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-07-08 16:09:06 UTC --- This looks like a DUP of PR44071 and I can confirm that this testcase doesn't ICE any more on the 4.5 branch Ramana *** This bug has been marked as a duplicate of bug 44071 ***
[Bug middle-end/44071] ICE with asm goto and __builtin_unreachable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44071 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||mirq-gccboogs at rere dot ||qmqm.pl --- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-07-08 16:09:06 UTC --- *** Bug 43460 has been marked as a duplicate of this bug. ***
[Bug target/49678] New: scan for mov fails in gcc.target/arm/pr42575.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49678 Summary: scan for mov fails in gcc.target/arm/pr42575.c Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.target/arm/pr42575.c was added on 2010-08-18 in r163334. The scan for no mov started failing a few days later with: r163601 | bernds | 2010-08-27 22:11:50 + (Fri, 27 Aug 2010) The test specifies -march=armv7-a, which is overridden for multilibs that specify -march=, but it fails even for the default multilib. It passes for a few multilibs. Here are results for the scan for current trunk with the multilibs I've been using for compile-only tests, in case that provides useful clues: default: FAIL march_armv4t: FAIL march_armv5: FAIL march_armv5te: FAIL march_armv5te-mfloat-abi_softfp: FAIL march_armv5te-mfloat-abi_softfp-mbig-endian: FAIL march_armv5t: FAIL march_armv6: FAIL march_armv6j: FAIL march_armv6t2: PASS march_armv6z: PASS march_armv6zk: PASS march_armv7-a: FAIL march_armv7-a-mfloat-abi_hard-mfpu_neon: FAIL march_armv7-a-mfloat-abi_softfp-mfpu_neon: FAIL march_armv7-r: FAIL march_iwmmxt2: FAIL march_iwmmxt: FAIL mbig-endian: FAIL mcpu_xscale: PASS mfloat-abi_soft-mfpu_neon-fp16: FAIL mfloat-abi_soft-mfpu_vfpv3xd-fp16: FAIL mfpu_vfpv4: FAIL mthumb: PASS mthumb-march_armv4t: PASS mthumb-march_armv5te: PASS mthumb-march_armv5t: PASS mthumb-march_armv6: PASS mthumb-march_armv6j: PASS mthumb-march_armv6-m: PASS mthumb-march_armv6t2: PASS mthumb-march_armv6z: PASS mthumb-march_armv6zk: PASS mthumb-march_armv7-a: PASS mthumb-march_armv7: PASS mthumb-march_armv7-mfix-cortex-m3-ldrd: PASS mthumb-march_armv7-m: PASS mthumb-march_armv7-r: FAIL mthumb-march_iwmmxt2: PASS mthumb-march_iwmmxt: PASS mthumb-mcpu_cortex-a8: PASS With the 4.6 branch the only difference is that mcpu_xscale fails.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #9 from Gary Funck gary at intrepid dot com 2011-07-08 16:20:50
UTC ---
This note is both a ping for this rather old bug report, as well as a follow up
with some additional information.
For the ping side of things, we have been using this patch for the past 5/so
years in GCC/UPC without problems (in both the build 'gcc' and 'upc'
compilers).
+++ ./gcc/config/i386/i386.hWed Jul 6 10:11:16 2011
@@ -1755,6 +1755,10 @@
#define BRANCH_COST(speed_p, predictable_p) \
(!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)
+/* An integer expression for the size in bits of the largest integer machine
+ mode that should actually be used. We allow pairs of registers. */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
/* Define this macro as a C expression which is nonzero if accessing
less than a word of memory (i.e. a `char' or a `short') is no
faster than accessing a word of memory, i.e., if such access
Although I haven't run any benchmarks, I think that this patch will improve
performance for some applications (that make use of 128 bit structures), and
recommend that it be applied to the GCC trunk.
Recently, however, we ran the torture tests against the 'gcc' built from the
GUPC branch with those built from the trunk (checks enabled and bootstrap
disabled, CFLAGS='-O0 -g'). We found a regression. This test produced an ICE:
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o compile, (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_y_tst.o compile, (internal
compiler error)
This can be reproduced with the following command, run in the built 'gcc'
directory:
make check-gcc RUNTESTFLAGS=struct-layout-1.exp=*t001*
The following is a boiled down test case:
union S160
{
long double a;
};
union S160 s160;
extern union S160 a160[5];
extern union S160 check160 (union S160, union S160 *, union S160);
extern void checkx160 (union S160);
void
test160 (void)
{
checkx160 (check160 (s160, a160[1], a160[2]));
}
The assertion check occurred at line 3097 below:
0x006390fe in expand_call (exp=0x714a51e0, target=0x7107b980,
ignore=0) at gcc/calls.c:3097
3097 gcc_assert (GET_MODE (target) == pmode);
(gdb) p pmode
$1 = TImode
(gdb) l
3092 enum machine_mode pmode;
3093
3094 /* Ensure we promote as expected, and get the new
unsignedness. */
3095 pmode = promote_function_mode (type, TYPE_MODE (type),
unsignedp,
3096 funtype, 1);
3097 gcc_assert (GET_MODE (target) == pmode);
3098
3099 if ((WORDS_BIG_ENDIAN || BYTES_BIG_ENDIAN)
3100 (GET_MODE_SIZE (GET_MODE (target))
3101 GET_MODE_SIZE (TYPE_MODE (type
(gdb) p GET_MODE (target)
$2 = XFmode
(gdb) p expand_location(input_location)-file
$3 = 0x1ab5b40 gcc/testsuite/gcc/gcc.dg-struct-layout-1/t001_test.h
(gdb) p expand_location(input_location)-line
$4 = 161
The gist of what happens here is:
1) Because of the change in the definition of MAX_FIXED_MODE_SIZE, the compiler
assigned TImode (rather than BLKmode) as the mode for the union type (it
contains only a single field, a long double, of mode XFmode).
2) The expand_call logic decided that the target mode of the value to be
returned is equal to that of the first (and only) field: XFmode.
3) The assertion (GET_MODE (target) == pmode) fails.
As far as we know, this is the only (x86_64) failure introduced by the
MAX_FIXED_MODE_SIZE patch. It seems that the logic in expand_call() will need
to be adjusted to handle this test case, if the patch is applied.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Attachment #24717|0 |1 is obsolete|| --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-08 16:20:59 UTC --- Created attachment 24718 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24718 Slightly better, testcases fixed.
[Bug target/49678] scan for mov fails in gcc.target/arm/pr42575.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49678 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.08 16:47:18 CC||rearnsha at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-07-08 16:47:18 UTC --- I think the problem here is that sched1 is re-arranging the insns in a way that makes register allocation without using a mov pretty much impossible. Running the test at -Os seems to work because the code reorg doesn't happen. However, looking at the code generated after sched1 has run doesn't seem to be any better than before (indeed it often looks worse); but I'm not sure yet why this happens.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #10 from Gary Funck gary at intrepid dot com 2011-07-08 16:58:55 UTC --- Note: I don't know how this fix fits in with the x86_64 ABI, and obviously once this fix is in place, the binary call interface will change for 128 bit struct/union arguments. As noted in the previous reply, expand_call tried passing the argument (of TImode) in an XFmode (SSE) register. That may or may not be permitted by the call ABI.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #11 from Gary Funck gary at intrepid dot com 2011-07-08 17:20:32 UTC --- (In reply to comment #10) Note: I don't know how this fix fits in with the x86_64 ABI, and obviously once this fix is in place, the binary call interface will change for 128 bit struct/union arguments. Actually, the call ABI can be preserved, and this fix/improvement can still be made in order to gain some potential benefit in copying struct's and perhaps accessing their fields. The main reason we made the fix however, was to insure that 128 arguments (and function return values) fit into TImode registers on x86_64 targets.
[Bug c++/45603] crash in build_addr_func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/45603] crash in build_addr_func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2011-07-08 17:39:23 UTC --- Author: jason Date: Fri Jul 8 17:39:17 2011 New Revision: 176054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176054 Log: PR c++/45603 * decl.c (expand_static_init): Don't get confused by user declaration of __cxa_guard_acquire. Added: trunk/gcc/testsuite/g++.dg/abi/guard3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-08 17:38:43 UTC --- Author: gjl Date: Fri Jul 8 17:38:39 2011 New Revision: 176053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176053 Log: PR target/46779 * config/avr/avr.c (avr_hard_regno_mode_ok): Rewrite. In particular, allow 8-bit values in r28 and r29. (avr_hard_regno_scratch_ok): Disallow any register that might be part of the frame pointer. (avr_hard_regno_rename_ok): Same. (avr_legitimate_address_p): Don't allow SUBREGs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug c++/45603] crash in build_addr_func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2011-07-08 17:39:54 UTC --- Fixed for 4.7.
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-08 17:46:42 UTC --- Author: gjl Date: Fri Jul 8 17:46:38 2011 New Revision: 176055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176055 Log: PR target/46779 Backport from mainline SVN 176053. 2011-07-08 Georg-Johann Lay * config/avr/avr.c (avr_hard_regno_mode_ok): Rewrite. In particular, allow 8-bit values in r28 and r29. (avr_hard_regno_scratch_ok): Disallow any register that might be part of the frame pointer. (avr_hard_regno_rename_ok): Same. (avr_legitimate_address_p): Don't allow SUBREGs. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/avr/avr.c
[Bug target/45291] avr miscompilations related to frame pointer registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45291 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.6.2 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-08 17:52:08 UTC --- This is same artifact as PR46779: IRA generates subreg of hard-reg that's not handled by reload. *** This bug has been marked as a duplicate of bug 46779 ***
[Bug c++/49679] New: Increment/decrement operator (++/--) not working as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49679
Summary: Increment/decrement operator (++/--) not working as
expected
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jordan_2...@hotmail.de
#include cstdlib
#include iostream
using namespace std;
int main(int argc, char *argv[])
{
int a=2;
int b=2;
a+=++a+a++;
b+=++b+b++;
cout a= a endl b= b endl;
cin a;
return EXIT_SUCCESS;
}
result
a=4
b=10
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||otaylor at redhat dot com --- Comment #13 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-08 17:52:08 UTC --- *** Bug 45291 has been marked as a duplicate of this bug. ***
[Bug c++/49679] Increment/decrement operator (++/--) not working as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49679 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-08 17:55:35 UTC --- You are invoking undefined behavior because C++ does not specify what order of the operands happen first.
[Bug c++/45437] Loses reference during update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/49679] Increment/decrement operator (++/--) not working as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49679 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-08 17:57:09 UTC --- The code has undefined behaviour because there are no sequence points between the increments, see http://c-faq.com/expr/seqpoints.html GCC even warns you: seq.cc: In function 'int main(int, char**)': seq.cc:19:15: warning: operation on 'a' may be undefined [-Wsequence-point] seq.cc:19:15: warning: operation on 'a' may be undefined [-Wsequence-point] seq.cc:20:15: warning: operation on 'b' may be undefined [-Wsequence-point] seq.cc:20:15: warning: operation on 'b' may be undefined [-Wsequence-point] You should use -Wall if the compiler seems to be doing something you don't understand, it might explain why.
[Bug c++/49679] Increment/decrement operator (++/--) not working as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49679 --- Comment #3 from Jordan jordan_2000 at hotmail dot de 2011-07-08 18:32:55 UTC --- I know the warnings, but look the code a+=++a+a++; b+=++b+b++; cout a= a endl b= b endl; cin a; a and b must be the same. if i remove cin a; everything is ok.
[Bug c++/49679] Increment/decrement operator (++/--) not working as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49679 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-08 18:37:41 UTC --- (In reply to comment #3) a and b must be the same. No, it's undefined behaviour. Anything can happen. http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
[Bug bootstrap/49680] New: [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 Summary: [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: r...@gcc.gnu.org, rdsandif...@googlemail.com Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 Between 20110704 (r175811) and 20110708 (r176045), IRIX 6.5 bootstrap got broken. A trivial a.out SEGVs in __register_frame_info_bases: Program received signal SIGSEGV, Segmentation fault. __register_frame_info_bases (begin=0x10004604, ob=0x1000, tbase=0x0, dbase=0x0) at /vol/gcc/src/hg/trunk/irix/libgcc/unwind-dw2-fde.c:80 80ob-pc_begin = (void *)-1; (gdb) where #0 __register_frame_info_bases (begin=0x10004604, ob=0x1000, tbase=0x0, dbase=0x0) at /vol/gcc/src/hg/trunk/irix/libgcc/unwind-dw2-fde.c:80 #1 0x100014a0 in ?? () #2 0x100014a0 in ?? () Backtrace stopped: frame did not save the PC I could trace this down to some change to crtbegin.o. I found that a couple of .set macro/.set reorder and .set noreorder/.set .nomacro pairs got lost, which causes gas warnings: crtstuff.s: Assembler messages: crtstuff.s:114: Warning: Macro instruction expanded into multiple instructions crtstuff.s:115: Warning: Macro instruction expanded into multiple instructions crtstuff.s:171: Warning: Macro instruction expanded into multiple instructions crtstuff.s:172: Warning: Macro instruction expanded into multiple instructions Also, a block of EH info was removed: - .byte 0x4 # DW_CFA_advance_loc4 - .4byte .LCFI4-.LCFI2 - .byte 0x90 # DW_CFA_offset, column 0x10 - .uleb128 0x8 - .byte 0x5 # DW_CFA_offset_extended - .uleb128 0x40 - .uleb128 0x2 Thus, one of rth's dwarf2cfi patches might be a candidate. I'm attaching the preprocessed input and good/bad assembler output.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-07-08 19:04:13 UTC --- Created attachment 24720 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24720 working assembler output
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-07-08 19:04:45 UTC --- Created attachment 24721 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24721 broken assembler output
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-07-08 19:03:37 UTC --- Created attachment 24719 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24719 preprocessed input
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/49681] New: 4.6.1 cross-build fails in libquadmath/libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49681 Summary: 4.6.1 cross-build fails in libquadmath/libiberty Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: manuel.la...@googlemail.com cross-building 4.6.1 for mips on x64 fails in stage2 configuration of libquadmath/libiberty: checking command to parse /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/nm output from /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includeobject... failed checking for dlfcn.h... no checking for objdir... .libs checking if /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includesupports -fno-rtti -fno-exceptions... no checking for /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includeoption to produce PIC... -fPIC -DPIC checking if /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includePIC flag -fPIC -DPIC works... yes checking if /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includestatic flag -static works... no checking if /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includesupports -c -o file.o... yes checking if /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includesupports -c -o file.o... (cached) yes checking whether the /tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/xgcc -B/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/ -B/usr/mipsel-softfloat-linux-gnu/bin/ -B/usr/mipsel-softfloat-linux-gnu/lib/ -isystem /usr/mipsel-softfloat-linux-gnu/include -isystem /usr/mipsel-softfloat-linux-gnu/sys-includelinker (/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libquadmath] Error 1 make[1]: Leaving directory `/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/build' make: *** [all] Error 2 configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/mipsel-softfloat-linux-gnu/gcc-bin/4.6.1 --includedir=/usr/lib/gcc/mipsel-softfloat-linux-gnu/4.6.1/include --datadir=/usr/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1 --mandir=/usr/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1/man --infodir=/usr/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1/info --with-gxx-include-dir=/usr/lib/gcc/mipsel-softfloat-linux-gnu/4.6.1/include/g++-v4 --host=x86_64-pc-linux-gnu --target=mipsel-softfloat-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --with-float=soft --disable-nls --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --enable-cld
[Bug rtl-optimization/49682] New: [alpha] gcc-4.6.1: ICE at -O2 and -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49682 Summary: [alpha] gcc-4.6.1: ICE at -O2 and -O3 Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: matts...@gmail.com Created attachment 24722 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24722 preprocessed crl.i (from openssl-1.0.0d) The attached preprocessed file from openssl-1.0.0d causes an internal compiler error on Alpha with -O2 or -O3 optimization level. # gcc -O2 -c crl.i crl.c: In function crl_main: crl.c:403:2: internal compiler error: in ready_remove_first, at haifa-sched.c:1414 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions.
[Bug target/49621] [4.5/4.6/4.7 regression] ICE in trunc_int_for_mode, at explow.c:57
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49621 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-08 20:10:22 UTC --- Author: jakub Date: Fri Jul 8 20:10:18 2011 New Revision: 176064 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176064 Log: PR target/49621 * config/rs6000/rs6000.c (rs6000_emit_vector_cond_expr): Use CONST0_RTX (dest_mode) instead of const0_rtx as second operand of NE. * config/rs6000/vector.md (vector_select_mode, vector_select_mode_uns): Change second operand of NE to CONST0_RTX (MODEmode) instead of const0_rtx. * config/rs6000/altivec.md (*altivec_vselmode, *altivec_vselmode_uns): Expect second operand of NE to be zero_constant of the corresponding vector mode. * config/rs6000/vsx.md (*vsx_xxselmode, *vsx_xxselmode_uns): Likewise. * gcc.target/powerpc/altivec-34.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/altivec-34.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/rs6000/altivec.md branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_6-branch/gcc/config/rs6000/vector.md branches/gcc-4_6-branch/gcc/config/rs6000/vsx.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/49621] [4.5/4.6/4.7 regression] ICE in trunc_int_for_mode, at explow.c:57
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49621 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-08 20:10:16 UTC --- Author: jakub Date: Fri Jul 8 20:09:58 2011 New Revision: 176063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176063 Log: PR target/49621 * config/rs6000/rs6000.c (rs6000_emit_vector_cond_expr): Use CONST0_RTX (dest_mode) instead of const0_rtx as second operand of NE. * config/rs6000/vector.md (vector_select_mode, vector_select_mode_uns): Change second operand of NE to CONST0_RTX (MODEmode) instead of const0_rtx. * config/rs6000/altivec.md (*altivec_vselmode, *altivec_vselmode_uns): Expect second operand of NE to be zero_constant of the corresponding vector mode. * config/rs6000/vsx.md (*vsx_xxselmode, *vsx_xxselmode_uns): Likewise. * gcc.target/powerpc/altivec-34.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/altivec-34.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/vector.md trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog
[Bug target/49621] [4.5 regression] ICE in trunc_int_for_mode, at explow.c:57
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49621 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.5/4.6/4.7 regression]|[4.5 regression] ICE in |ICE in trunc_int_for_mode, |trunc_int_for_mode, at |at explow.c:57 |explow.c:57 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-08 20:18:30 UTC --- Fixed for 4.6+ so far.
[Bug target/47230] [4.6/4.7 Regression] gcc fails to bootstrap on alpha in stage2 with relocation truncated to fit: GPREL16 against ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47230 Matt Turner mattst88 at gmail dot com changed: What|Removed |Added CC||mattst88 at gmail dot com --- Comment #11 from Matt Turner mattst88 at gmail dot com 2011-07-08 20:42:37 UTC --- gcc-4.6.1 fails to boostrap gcc-4.6.1 even with binutils-2.21.1 + fixes for 12608 and 12610 for me.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-07-08 21:02:53 UTC --- I see a similar build failure for cris-elf, FWIW so I take a wild guess and assume it's the same issue. Narrower revision range; last known working 176012, first known failing r176032. Build failure: /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-fde.o -MT unwind-dw2-fde.o -MD -MP -MF unwind-dw2-fde.dep -fexceptions -c /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/unwind-dw2-fde.c In file included from /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/unwind-dw2-fde.c:35:0: /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/unwind-pe.h: In function 'size_of_encoded_value': /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/unwind-pe.h:89:1: internal compiler error: Segmentation fault
[Bug tree-optimization/49513] DOM inhibits if-conversion and vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49513 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #4 from Jeffrey A. Law law at redhat dot com 2011-07-08 21:11:09 UTC --- Prohibiting this in DOM would effectively prevent DOM from doing any loop rotations. I don't see a good way to solve this... Ideally we'd have a way to know if a particular IF is convertable and we could avoid threading through it. Jeff
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680
--- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-07-08
21:27:01 UTC ---
(In reply to comment #4)
I see a similar build failure for cris-elf, FWIW so I take a wild guess and
assume it's the same issue.
...but in the case for cris-elf it seems the immediate cause of the SEGV is the
appearance of notes between the case-insns and the jump-table, which is
probably fixed by using prev_nonnote_insn instead of PREV_INSN in
cris.c:cris_asm_output_case_end. This may or may not be related to the build
failure in this PR, but I thought better mentioned than not.
(jump_insn 18 17 76 (parallel [
(set (pc)
(if_then_else (ltu (reg:SI 10 r10 [34])
(const_int 5 [0x5]))
(plus:SI (sign_extend:SI (mem:HI (plus:SI (mult:SI (reg:SI
10 r10 [34])
(const_int 2 [0x2]))
(pc)) [0 S2 A8]))
(pc))
(label_ref 30)))
(use (label_ref 19))
]) /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/unwind-pe.h:77 116
{*casesi_adds_w}
(expr_list:REG_BR_PRED (const_int 12 [0xc])
(expr_list:REG_DEAD (reg:SI 10 r10 [34])
(insn_list:REG_LABEL_TARGET 30 (nil
- 19)
(note 76 18 74 NOTE_INSN_CFI_LABEL)
(note 74 76 19
.cfi_offset 16, -4
NOTE_INSN_CFI)
(code_label 19 74 20 36 [1 uses])
(jump_insn 20 19 21 (addr_diff_vec:HI (label_ref:SI 19)
[
(label_ref:SI 22)
(label_ref:SI 30)
(label_ref:SI 51)
(label_ref:SI 22)
(label_ref:SI 26)
]
(const_int 0 [0])
(const_int 0 [0]))
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/unwind-pe.h:77 -1
(expr_list:REG_BR_PRED (const_int 12 [0xc])
(nil)))
This seems like it'd be fixed by using prev_nonnote_insn instead of PREV_INSN
in cris.c:cris_asm_output_case_end, which is where the SEGV is. This may or
may not be related to the build failure in this PR, but I thought better
mentioned than not. (No, not the case-table thingy, but maybe notes appearing
where there used to be none.)
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.08 21:58:17 AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Richard Henderson rth at gcc dot gnu.org 2011-07-08 21:58:17 UTC --- I see the problem wrt cris -- we really shouldn't delay the output of the CFI note that late. I'll fix that and see if I can still reproduce the irix problem.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-07-08 22:08:31 UTC --- (In reply to comment #6) I see the problem wrt cris -- we really shouldn't delay the output of the CFI note that late. I'll fix that and see if I can still reproduce the irix problem. Thanks. Still, I don't think there's anything wildly wrong with the quoted rtx so I'm going to do s/PREV_INSN/prev_nonnote_nondebug_insn/g and assert that the right insns and code_label is seen in cris_asm_output_case_end anyway. The current PREV_INSNs are a little too presumptious (QED); there are no documented promises broken at the SEGV.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #8 from Richard Henderson rth at gcc dot gnu.org 2011-07-08 22:14:52 UTC --- I'm pretty sure that tablejumps are required to be adjacent, and that the notes are Really In the Wrong Place.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #9 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-07-08 22:30:34 UTC --- (In reply to comment #8) I'm pretty sure that tablejumps are required to be adjacent, and that the notes are Really In the Wrong Place. No real insns are supposed to be there, as in always the last insn before the jump table it uses (at tablejump, md.texi) but I couldn't find anything in the docs to throw at you regarding notes. :) There may be, but not where I looked; casesi, tablejump and ASM_OUTPUT_CASE_END.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-07-08 22:46:42 UTC --- (In reply to comment #7) I'm going to do s/PREV_INSN/prev_nonnote_nondebug_insn/g and assert that the right insns and code_label is seen in cris_asm_output_case_end anyway. And with that fixed, I get assembler errors from crtstuff.s so I'll step back and wait. /tmp/ice176012/gccobj/./gcc/xgcc -B/tmp/ice176012/gccobj/./gcc/ -nostdinc -B/tmp/ice176012/gccobj/cris-elf/newlib/ -isystem /tmp/ice176012/gccobj/cris-elf/newlib/targ-include -isystem /tmp/ice176012/gcc/newlib/libc/include -B/tmp/ice176012/gccobj/cris-elf/libgloss/cris -L/tmp/ice176012/gccobj/cris-elf/libgloss/libnosys -L/tmp/ice176012/gcc/libgloss/cris -B/tmp/ice176012/pre/cris-elf/bin/ -B/tmp/ice176012/pre/cris-elf/lib/ -isystem /tmp/ice176012/pre/cris-elf/include -isystem /tmp/ice176012/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 -I. -I. -I/tmp/ice176012/gcc/gcc -I/tmp/ice176012/gcc/gcc/. -I/tmp/ice176012/gcc/gcc/../include -I/tmp/ice176012/gcc/gcc/../libcpp/include -I/tmp/ice176012/gccobj/./gmp -I/tmp/ice176012/gcc/gmp -I/tmp/ice176012/gccobj/./mpfr -I/tmp/ice176012/gcc/mpfr -I/tmp/ice176012/gcc/mpc/src -I/tmp/ice176012/gcc/gcc/../libdecnumber -I/tmp/ice176012/gcc/gcc/../libdecnumber/dpd -I../libdecnumber-g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/tmp/ice176012/gcc/libgcc -I/tmp/ice176012/gcc/libgcc/. -I/tmp/ice176012/gcc/libgcc/../gcc -I/tmp/ice176012/gcc/libgcc/../include -o crtbegin.o -MT crtbegin.o -MD -MP -MF crtbegin.dep -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 -moverride-best-lib-options \ -c /tmp/ice176012/gcc/libgcc/../gcc/crtstuff.c -DCRT_BEGIN /tmp/ice176012/gcc/libgcc/../gcc/crtstuff.c:50:0: warning: IN_LIBGCC2 redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition /tmp/ice176012/gcc/libgcc/../gcc/crtstuff.c: In function 'frame_dummy': /tmp/ice176012/gcc/libgcc/../gcc/crtstuff.c:381:19: warning: array subscript is above array bounds [-Warray-bounds] /tmp/ccjObd8e.s: Assembler messages: /tmp/ccjObd8e.s:228: Error: operation combines symbols in different segments /tmp/ccjObd8e.s:260: Error: operation combines symbols in different segments make[4]: *** [crtbegin.o] Error 1
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680
--- Comment #11 from Richard Henderson rth at gcc dot gnu.org 2011-07-08
23:03:59 UTC ---
HP, the CRIS problem is something else.
Basically, nonsense like
static void __attribute__((__used__)) call___do_global_dtors_aux (void) { asm
(\t.section\t.fini); __do_global_dtors_aux (); asm (\t.text); }
only accidentally worked before. I guess it continues to work
so long as debug info is not enabled. Please just implement the
CRT_CALL_STATIC_FUNCTION macro for CRIS.
If you still have a problem, open a different bug.
Back to MIPS herein...
[Bug fortran/49683] New: The system cannot execute the specified program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49683 Summary: The system cannot execute the specified program Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: mgr...@shaw.ca I have a G77 program called mike.f that works with no issues on my XP machine. I installed G77 on my laptop that runs Vista. I ran a test on mytest1.f and it works fine, no problems at all. I then compile my program mike.f on the laptop and it compiles with no issues. However when I try to run it I get the following message: The system cannot execute the specified program. How can I fix this? Thanks
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #12 from Richard Henderson rth at gcc dot gnu.org 2011-07-08 23:36:57 UTC --- Rainer, please give me the command-line for this. I can't seem to reproduce the assembler warnings from a cross-compiler.
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #25 from Janis Johnson janis at gcc dot gnu.org 2011-07-08 23:36:25 UTC --- Test gcc.target/arm/sibcall-1.c starts failing with r176042 for arm-none-linux-gnueabi configured with defaults for arch and cpu. The failure can be reproduced with a simple cross cc1.
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #14 from Richard Henderson rth at gcc dot gnu.org 2011-07-08 23:49:01 UTC --- Author: rth Date: Fri Jul 8 23:48:59 2011 New Revision: 176066 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176066 Log: dwarf2cfi: Flush queued saves at the end of the prologue. There's little point at holding onto these saves indefinitely. PR bootstrap/49680 * dwarf2cfi.c (create_cfi_notes): Flush queued saves at the end of the prologue. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2cfi.c
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680 --- Comment #13 from Richard Henderson rth at gcc dot gnu.org 2011-07-08 23:48:56 UTC --- Author: rth Date: Fri Jul 8 23:48:53 2011 New Revision: 176065 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176065 Log: dwarf2cfi: Insert notes correctly wrt tablejumps. PR bootstrap/49680 * dwarf2cfi.c (dwarf2out_frame_debug): Insert cfi notes after any tablejump vector. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2cfi.c
[Bug bootstrap/49680] [4.7 regression] IRIX 6.5 bootstrap broken: SEGV in __register_frame_info_bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49680
--- Comment #15 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-07-09
00:32:08 UTC ---
(In reply to comment #11)
Basically, nonsense like
static void __attribute__((__used__)) call___do_global_dtors_aux (void) { asm
(\t.section\t.fini); __do_global_dtors_aux (); asm (\t.text); }
only accidentally worked before. I guess it continues to work
so long as debug info is not enabled.
So, the documentation for CRT_CALL_STATIC_FUNCTION should be amended something
like this?
Index: tm.texi.in
===
--- tm.texi.in(revision 175272)
+++ tm.texi.in(working copy)
@@ -6878,6 +6880,8 @@ sections. By default, this macro uses a
ports need hand-crafted assembly code to avoid dependencies on
registers initialized in the function prologue or to ensure that
constant pools don't end up too far way in the text section.
+Also, the default value will not work for targets using DWARF 2
+debugging information.
@end defmac
@defmac TARGET_LIBGCC_SDATA_SECTION
I'll take further discussion to gcc-patches@.
[Bug regression/49684] New: [4.7 Regression]: build fails on crtstuff.c / crtbegin using default CRT_CALL_STATIC_FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49684 Summary: [4.7 Regression]: build fails on crtstuff.c / crtbegin using default CRT_CALL_STATIC_FUNCTION Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: r...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf A patch in the revision range last known working 176012, first known failing r176032, caused the build for cris-elf to fail as described in bug 49680 (first quote). After the immediate problem is fixed there's a second problem which seems to be that the default definition of CRT_CALL_STATIC_FUNCTION doesn't work anymore (messages also quoted in bug 49680), due to a change in the mentioned range. A documentation patch is suggested as a general fix. An alternative would be to provide a better default definition of CRT_CALL_STATIC_FUNCTION.
[Bug c/49685] New: libgcc_s.so not compiled without optimization when requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49685 Summary: libgcc_s.so not compiled without optimization when requested Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I need to have libgcc_s.so without optimization and with debug info. Following documentation on GCC own site http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html, I ran make with overriding compilation flags: make CXXFLAGS='-g3 -fno-inline -O0' CFLAGS='-g3 -fno-inline -O0' all But the resulting libgcc_s.so is still optimized. I could see that -O 2 was passed to all compiles. Actually, gcc build process should respect the given to the top-level make CFLAGS and CXXFLAGS and propagate them to all levels.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #10 from Jeffrey Walton noloader at gmail dot com 2011-07-09 03:32:20 UTC --- (In reply to comment #8) The included source compiles OK for me with: ~/gcc-build/gcc/cc1plus -quiet -O2 -m32 -g -fstack-protector -march=prescott -mtune=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 asn.ii Tried with: GNU C++ (GCC) version 4.5.4 20110525 (prerelease) GNU C++ (GCC) version 4.6.1 20110611 (prerelease) GNU C++ (GCC) version 4.7.0 20110707 (experimental) The bug is either fixed or local to: g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 Please try to reproduce the bug with latest FSF compiler. Alternatively, please report the bug to Ubuntu. I just tried using Fedora 15, which offers GCC 4.6 - OK. Jeff [jeffrey@studio cryptopp]$ gcc --version gcc (GCC) 4.6.0 20110530 (Red Hat 4.6.0-9) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [jeffrey@studio cryptopp]$ make g++ -DNDEBUG -g -O2 -march=native -pipe -c cryptlib_bds.cpp g++ -DNDEBUG -g -O2 -march=native -pipe -c hmac.cpp g++ -DNDEBUG -g -O2 -march=native -pipe -c hex.cpp g++ -DNDEBUG -g -O2 -march=native -pipe -c esign.cpp ... g++ -DNDEBUG -g -O2 -march=native -pipe -c asn.cpp g++ -DNDEBUG -g -O2 -march=native -pipe -c rw.cpp g++ -DNDEBUG -g -O2 -march=native -pipe -c cast.cpp g++ -DNDEBUG -g -O2 -march=native -pipe -c tiger.cpp ...
[Bug c++/45437] Loses reference during update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437 --- Comment #17 from Jason Merrill jason at gcc dot gnu.org 2011-07-09 03:33:56 UTC --- Author: jason Date: Sat Jul 9 03:33:54 2011 New Revision: 176072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176072 Log: PR c++/45437 gcc/ * gimplify.c (goa_stabilize_expr): Handle RHS preevaluation in compound assignment. gcc/c-family/ * c-omp.c (check_omp_for_incr_expr): Handle preevaluation. gcc/cp/ * typeck.c (cp_build_modify_expr): Preevaluate RHS. Added: trunk/gcc/testsuite/g++.dg/expr/compound-asn1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-omp.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/sequence-pt-1.C
[Bug c++/45437] Loses reference during update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #18 from Jason Merrill jason at gcc dot gnu.org 2011-07-09 03:34:53 UTC --- Fixed for 4.7.0.
