Re: possible buffer overflow in calls.c?
Dne 10.02.2009 (tor) ob 17:14 -0800 je Ian Lance Taylor zapisal(a): I don't quite see it. highest_outgoing_args_in_use is at least as large as args_size.constant, and that counts the locate.size for each argument. So it should always include the extra padding. That said, it would not be shocking if there were a bug in this code. It's not particularly common to use emit_library_call_value_1 with code that passes parameters on the stack. And it's even less common to use it with parameters that require padding when they are pushed on the stack. So a miscalculation in such a scenario could survive for quite along time. consider stack slots of 8 bytes, two parameters, one 8-byte, one 4-byte (padded below), all arranged on the stack like this (low addresses at the bottom): 16 8 [ P2 ] 0 [ P1] P1: offset = slot_offset = 0, size = 8 P2: offset = 12, slot_offset = 8, size = 8 highest_outgoing_args_in_use = 16 (sum of sizes) buffer is allocated 16 bytes. lower bound for P2 is 12 (P2.offset). upper bound for P2 is 20 (12 + 8). the loop indexes interval [12, 20) of the buffer, but only 16 bytes were allocated. hopefully this clarifies the issue. that said, this probably belongs to gcc bugzilla: I don't have an exact way to reproduce it with a mainline gcc version, though, as I haven't really tried other targets, while mine is well ... not merged in the mainline ... regards, jaKa -- email: j...@xlab.si w3:http://www.gmajna.net/svojat/jaka
Public archive
Hi i don´t recognize that sending an Email to the mailing list will be stored in a public archive. http://gcc.gnu.org/ml/gcc-help/2009-02/msg00070.html I'm not happy with my email address and my name published there. Can you please delete my email address and my name? Thank you!
Error with libstdc++-v3 compilation
Hello,
I am trying to build a GCC 4.2.4 cross compiler targeted for
sparc-sun-solaris2.10 and hosted on x86_64-unknown-linux-gnu.
The compiler is configured with:
--target=sparc-sun-solaris2.10\
--disable-nls \
--enable-shared \
--enable-debug \
--enable-threads=posix \
--enable-__cxa_atexitx \
--enable-long-long \
--with-gcc \
--with-gnu-as \
--with-gnu-ld \
--with-stabs \
--enable-interwork \
--with-headers=/home/dva/xcompile/sparc-sun-solaris2.10/include \
--with-libs=/home/dva/xcompile/sparc-sun-solaris2.10/lib \
--enable-languages=c,c++ \
--enable-libgcc-rebuild \
--prefix=/usr/local
When (as root) I am executing make install I get the following errors:
make[3]: Leaving directory
`/home/dva/xcompile/build/gcc-4.2.4/libiberty/testsuite'
/bin/sh /home/dva/xcompile/src/gcc-4.2.4/libiberty/../mkinstalldirs
/usr/local/lib/`gcc -g -O2 -print-multi-os-directory`
/usr/bin/install -c -m 644 ./libiberty.a /usr/local/lib/`gcc -g -O2
-print-multi-os-directory`/./libiberty.an
( cd /usr/local/lib/`gcc -g -O2 -print-multi-os-directory` ; chmod 644
./libiberty.an ;ranlib ./libiberty.an )
mv -f /usr/local/lib/`gcc -g -O2 -print-multi-os-directory`/./libiberty.an
/usr/local/lib/`gcc -g -O2 -print-multi-os-directory`/./libiberty.a
if test -n ; then \
case in \
/*)thd=;; \
*) thd=/usr/local/include/;; \
esac; \
/bin/sh /home/dva/xcompile/src/gcc-4.2.4/libiberty/../mkinstalldirs
${thd}; \
for h in /home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/ansidecl.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/demangle.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/dyn-string.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/fibheap.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/floatformat.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/hashtab.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/libiberty.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/objalloc.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/partition.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/safe-ctype.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/sort.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/splay-tree.h
/home/dva/xcompile/src/gcc-4.2.4/libiberty/../include/ternary.h; do \
/usr/bin/install -c -m 644 $h ${thd}; \
done; \
fi
make[3]: Entering directory
`/home/dva/xcompile/build/gcc-4.2.4/libiberty/testsuite'
make[3]: Nothing to be done for `install'.
make[3]: Leaving directory
`/home/dva/xcompile/build/gcc-4.2.4/libiberty/testsuite'
make[2]: Leaving directory `/home/dva/xcompile/build/gcc-4.2.4/libiberty'
/bin/sh: line 3: cd: sparc-sun-solaris2.10/libstdc++-v3: No such file or
directory
make[1]: *** [install-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/dva/xcompile/build/gcc-4.2.4'
make: *** [install] Error 2
However, both gcc and g++ were installed. Gcc works okay and produce the
sparc binaries but g++ gives the following error when compiling:
d...@dl380tm01:~$ export CXX=sparcv9-sun-solaris2.10-g++
d...@dl380tm01:~$ $CXX main.c -o main -Wl,--rpath
-Wl,/usr/local/sparc-sun-solaris2.10/lib/
/usr/local/lib/gcc/sparcv9-sun-solaris2.10/4.2.4/../../../../sparcv9-sun-sol
aris2.10/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
My questions are:
1. How can I generate and install libstdcxx?
2. Is there any tweak to be done on the linker (apart from LD_RUN_PATH, -L
and the above options)?
Regards,
Daniel
Re: Public archive
Hi! Maximilian Nesnidal wrote: i don´t recognize that sending an Email to the mailing list will be stored in a public archive. http://gcc.gnu.org/ml/gcc-help/2009-02/msg00070.html I'm not happy with my email address and my name published there. Can you please delete my email address and my name? For your information, here are relevant quotes from [1]: The GCC project has many mailing lists, which are archived on the web (and searchable). Please make yourself familiar with our policies before subscribing and posting to these lists. And under Policies: We have a strong policy of not editing the web archives. [1] http://gcc.gnu.org/lists.html jlh
Re: possible buffer overflow in calls.c?
Jaka Močnik j...@xlab.si writes: Dne 10.02.2009 (tor) ob 17:14 -0800 je Ian Lance Taylor zapisal(a): I don't quite see it. highest_outgoing_args_in_use is at least as large as args_size.constant, and that counts the locate.size for each argument. So it should always include the extra padding. That said, it would not be shocking if there were a bug in this code. It's not particularly common to use emit_library_call_value_1 with code that passes parameters on the stack. And it's even less common to use it with parameters that require padding when they are pushed on the stack. So a miscalculation in such a scenario could survive for quite along time. consider stack slots of 8 bytes, two parameters, one 8-byte, one 4-byte (padded below), all arranged on the stack like this (low addresses at the bottom): 16 8 [ P2 ] 0 [ P1] P1: offset = slot_offset = 0, size = 8 P2: offset = 12, slot_offset = 8, size = 8 highest_outgoing_args_in_use = 16 (sum of sizes) buffer is allocated 16 bytes. lower bound for P2 is 12 (P2.offset). upper bound for P2 is 20 (12 + 8). the loop indexes interval [12, 20) of the buffer, but only 16 bytes were allocated. hopefully this clarifies the issue. Yes. Thanks for the explanation. that said, this probably belongs to gcc bugzilla: I don't have an exact way to reproduce it with a mainline gcc version, though, as I haven't really tried other targets, while mine is well ... not merged in the mainline ... Assuming you have a copyright assignment, just send a patch to gcc-patches with the explanation. This is code which will never be used for any popular target. Ian
Re: possible buffer overflow in calls.c?
Assuming you have a copyright assignment, just send a patch to gcc-patches with the explanation. This is code which will never be used for any popular target. The patch is probably small enough that it does not require assignment, given the description in his original message. Paolo
[plugins] binary-level or source-level?
Dear GCC developers, I've been following the plugins discussion and have seen various proposals. So far all of them seem to be focusing on plugins as dynamically linkable libraries (with all associated versioning and portability ballast). While you could also easily extend that, and integrate plugins more tightly with the compiler binary as static libraries (thereby creating customized compilers), I was wondering whether in future there might be a need to express tighter dependency between the code and the plugin(s) that the code might require... Or at least the dependency between the code and the plugin configuration options... Should we not have a way to specify a plugin in the source itself? This could be achieved by tagging a function with a __plugin__ attribute (or a #pragma), exporting the PluginAPI as a bunch of built-in functions and having the compiler itself (1) ensure that such functions only call portable built-ins, and (2) compiling/executing or interpreting them as compilation passes. Then, the code can just #include a source-level plugin to have it available just for that translation unit. This is useful for at least one project I am working on... Regards, Pjotr Kourzanov
Re: possible buffer overflow in calls.c?
Dne 11.02.2009 (sre) ob 16:31 +0100 je Paolo Bonzini zapisal(a): Assuming you have a copyright assignment, just send a patch to gcc-patches with the explanation. This is code which will never be used for any popular target. The patch is probably small enough that it does not require assignment, given the description in his original message. lol. don't speak about me in third person when I'm around as well, will you? ;) anyway, thanks for the review and comments, ian. will send the fix to gcc-patches. suppose I don't really need a copyright assignment for a rather obvious two-liner. j -- email: j...@xlab.si w3:http://www.gmajna.net/svojat/jaka
question: suffix for fixed-point literal constant
I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix suffixes in decimal float literal constants for c/33466. While I'm at it I'm fixing suffixes for fixed-point literal constants. Currently for fixed-point GCC accepts any ordering of the letters in the suffix. The technical report (N1169) gives specific strings, not individual letters that can be used in any order. That seems like something obvious to fix but I thought I'd mention it in case they really should be accepted in any order. My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? GCC accepts ll or LL, but not lL or Ll, in fixed-point suffixes. These are not in N1169; is there a later draft TR that includes them or are they simply a GNU extension on top of the draft TR? Janis
Re: question: suffix for fixed-point literal constant
Janis Johnson janis...@us.ibm.com writes: My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? I think you should take it literally. Why not? When it doesn't make any difference, follow the standard. Ian
RE: question: suffix for fixed-point literal constant
Janis Johnson wrote: I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix suffixes in decimal float literal constants for c/33466. While I'm at it I'm fixing suffixes for fixed-point literal constants. Currently for fixed-point GCC accepts any ordering of the letters in the suffix. The technical report (N1169) gives specific strings, not individual letters that can be used in any order. That seems like something obvious to fix but I thought I'd mention it in case they really should be accepted in any order. My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? From my implementation, I allow mixed-case suffixes. We can view this as a GCC feature, if it turns out that the spec doesn't allow this. Thanks! Regards, Chao-ying
Re: proposal for improved management bugzilla priorities/release criteria
Paolo Bonzini wrote: I think the only reasonable release criteria is zero P1 regressions over some period. 50 P2 regressions doesn't make a release blocker, neither is 49 P2 regressions a clear sign for a non-blocked release. I agree. I mostly agree. P1 regressions are, by definition, Really Bad. In the past, we've sometimes had to release in that state because it was clear that there was no reasonable way to get the P1 regression fixed. But, that's not what we want to do. However, I don't agree that P2 regressions aren't a factor. If we have a ton of crashing on wrong-code, etc., regressions that adds up to a release that won't work well for people. I don't think there can be, or need to be, completely bright-line rules. We need human beings to use their judgment about when the release is good enough to go out the door. So, I'm all for guidelines, and I agree that 49 vs. 50 isn't itself a big deal. But, I think that Paolo's criterion should not be interpreted literally. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
RE: question: suffix for fixed-point literal constant
On Wed, 2009-02-11 at 10:42 -0800, Fu, Chao-Ying wrote: Janis Johnson wrote: I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix suffixes in decimal float literal constants for c/33466. While I'm at it I'm fixing suffixes for fixed-point literal constants. Currently for fixed-point GCC accepts any ordering of the letters in the suffix. The technical report (N1169) gives specific strings, not individual letters that can be used in any order. That seems like something obvious to fix but I thought I'd mention it in case they really should be accepted in any order. My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? From my implementation, I allow mixed-case suffixes. We can view this as a GCC feature, if it turns out that the spec doesn't allow this. Thanks! Where do the 'll' and 'LL' come from in fixed-point suffixes? Is there a reason that your implementation requires them to be the same case? Janis
Re: question: suffix for fixed-point literal constant
Janis Johnson wrote: On Wed, 2009-02-11 at 10:42 -0800, Fu, Chao-Ying wrote: Janis Johnson wrote: I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix suffixes in decimal float literal constants for c/33466. While I'm at it I'm fixing suffixes for fixed-point literal constants. Currently for fixed-point GCC accepts any ordering of the letters in the suffix. The technical report (N1169) gives specific strings, not individual letters that can be used in any order. That seems like something obvious to fix but I thought I'd mention it in case they really should be accepted in any order. My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? From my implementation, I allow mixed-case suffixes. We can view this as a GCC feature, if it turns out that the spec doesn't allow this. Thanks! Where do the 'll' and 'LL' come from in fixed-point suffixes? Is there a reason that your implementation requires them to be the same case? Janis The spec doesn't have long long fixed-point types or constants. So, the long long fixed-point support in GCC is an extension to the spec. I just reused C code to enforce ll and LL. We are free to accept any formats. If you like, you can change C code to accept all of ll, LL, Ll, lL. Thanks! Regards, Chao-ying
gcc-4.2-20090211 is now available
Snapshot gcc-4.2-20090211 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090211/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 144111 You'll find: gcc-4.2-20090211.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20090211.tar.bz2 C front end and core compiler gcc-ada-4.2-20090211.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20090211.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20090211.tar.bz2 C++ front end and runtime gcc-java-4.2-20090211.tar.bz2 Java front end and runtime gcc-objc-4.2-20090211.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20090211.tar.bz2The GCC testsuite Diffs from 4.2-20090204 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: question: suffix for fixed-point literal constant
On Wed, 11 Feb 2009, Janis Johnson wrote: I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix suffixes in decimal float literal constants for c/33466. While I'm at it I'm fixing suffixes for fixed-point literal constants. Currently for fixed-point GCC accepts any ordering of the letters in the suffix. The technical report (N1169) gives specific strings, not individual letters that can be used in any order. That seems like something obvious to fix but I thought I'd mention it in case they really should be accepted in any order. I believe you should follow the formal syntax, 6.4.4.2a (at least in N1275, the most recent version I know of, on page 16 of that document). This does not allow them in multiple orders. It uses long-suffix from the C99 syntax. My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? The syntax allows a mix of cases. GCC accepts ll or LL, but not lL or Ll, in fixed-point suffixes. These are not in N1169; is there a later draft TR that includes them or are they simply a GNU extension on top of the draft TR? I presume the extension is to add long-long-suffix somewhere in the syntax, which means ll or LL but not lL or Ll because those aren't in C99 which defines long-long-suffix. -- Joseph S. Myers jos...@codesourcery.com
Re: [plugins] binary-level or source-level?
On Wed, Feb 11, 2009 at 11:46, Pjotr Kourzanov peter.kourza...@xs4all.nl wrote: Should we not have a way to specify a plugin in the source itself? This could be achieved by tagging a function with a __plugin__ attribute (or a #pragma), exporting the PluginAPI as a bunch of built-in functions and having the compiler itself (1) ensure that such functions only call portable built-ins, and (2) compiling/executing or interpreting them as compilation passes. Then, the code can just #include a source-level plugin to have it available just for that translation unit. But then, what would be the difference between this and just adding your pass to the compiler? I'm not sure I understand what this would buy you in terms of simplicity. Perhaps I'm missing something. Diego.
Re: question: suffix for fixed-point literal constant
On Wed, 2009-02-11 at 22:47 +, Joseph S. Myers wrote: On Wed, 11 Feb 2009, Janis Johnson wrote: I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix suffixes in decimal float literal constants for c/33466. While I'm at it I'm fixing suffixes for fixed-point literal constants. Currently for fixed-point GCC accepts any ordering of the letters in the suffix. The technical report (N1169) gives specific strings, not individual letters that can be used in any order. That seems like something obvious to fix but I thought I'd mention it in case they really should be accepted in any order. I believe you should follow the formal syntax, 6.4.4.2a (at least in N1275, the most recent version I know of, on page 16 of that document). This does not allow them in multiple orders. It uses long-suffix from the C99 syntax. Thanks for the reference. I had been looking earlier in the document at a table of suffixes, but this section makes it clear. My question, though, is about the case of the letters in the suffixes. N1169 says note that the suffix is case insensitive; should I take that literally and allow any mix of cases (as GCC currently does), or require that the same case be used within a particular suffix? The syntax allows a mix of cases. Yes, that's also clear in the section you referenced. GCC accepts ll or LL, but not lL or Ll, in fixed-point suffixes. These are not in N1169; is there a later draft TR that includes them or are they simply a GNU extension on top of the draft TR? I presume the extension is to add long-long-suffix somewhere in the syntax, which means ll or LL but not lL or Ll because those aren't in C99 which defines long-long-suffix. That makes sense, I'll go with that. Janis
Re: [plugins] binary-level or source-level?
On Wed, 2009-02-11 at 18:14 -0500, Diego Novillo wrote: On Wed, Feb 11, 2009 at 11:46, Pjotr Kourzanov peter.kourza...@xs4all.nl wrote: Should we not have a way to specify a plugin in the source itself? This could be achieved by tagging a function with a __plugin__ attribute (or a #pragma), exporting the PluginAPI as a bunch of built-in functions and having the compiler itself (1) ensure that such functions only call portable built-ins, and (2) compiling/executing or interpreting them as compilation passes. Then, the code can just #include a source-level plugin to have it available just for that translation unit. But then, what would be the difference between this and just adding your pass to the compiler? Well I guess you don't have to rebuild the compiler, once it supports such JIT plugins. Otherwise you might end up with building lots of compilers with only minor differences and getting a Makefile headache. Also portability can be improved, since JIT plugins can be made as portable as any scripting language. I'm not sure I understand what this would buy you in terms of simplicity. Perhaps I'm missing something. I can imagine a situation when you'll want a set of plugins to apply only to some specific parts of your code. Or specific plugin options for some parts, but not others. For such cases, you'd better just #include an appropriate plugin or supply a parameter via a #pragma to it, rather than solve these issues in the Makefiles. As a bonus, these will have to be distributed in source form, so no illegal proprietary gambles are possible. You might get additional benefits from executing JIT plugins in a restricted or managed mode (only allow usage of some restricted builtins by plugin sourcecode), rather than just allowing random access to whole compiler workspace. Pjotr.
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #23 from bonzini at gnu dot org 2009-02-11 08:01 --- Subject: Re: [4.4 Regression] performance regression of sse code from 4.2/4.3 [xg...@shgcc-9 38824]$ time ./gcc-42.out real0m1.991s [xg...@shgcc-9 38824]$ time ./gcc-44.out real0m1.880s [xg...@shgcc-9 38824]$ time ./gcc-44p.out real0m1.690s Even though you don't observe the reporter's slowdown from 4.2/4.3 to unpatched 4.4, I guess this makes a good case for the patch. Ok for trunk? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #24 from ubizjak at gmail dot com 2009-02-11 08:14 --- (In reply to comment #23) Even though you don't observe the reporter's slowdown from 4.2/4.3 to unpatched 4.4, I guess this makes a good case for the patch. Ok for trunk? OK with a ChangeLog ;) BTW: Please watch benchmarks testers [1] for a couple of days... [1] http://gcc.gnu.org/benchmarks/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #16 from ubizjak at gmail dot com 2009-02-11 08:24 --- (In reply to comment #13) This test case is from Mark Heffernan. When compiling with -O2 -fno-omit-frame-pointer with gcc 4.3, it shows a red zone violation in the epilogue: movl-160(%rbp), %eax popq%r15 leave ret This does not show redzone violation, but following does: popq%rbx popq%r12 popq%r13 popq%r14 movl-160(%rbp), %eax popq%r15 leave ret Anyway, I have a patch. -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2009-02-08 21:00:58 |2009-02-11 08:24:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #17 from ubizjak at gmail dot com 2009-02-11 08:32 --- Created an attachment (id=17280) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17280action=view) Patch This patch inserts _memory_ blockages at the end of function prologue and at the beginning of function epilogue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #11 from ubizjak at gmail dot com 2009-02-11 08:42 --- (In reply to comment #9) Created an attachment (id=17279) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit] A patch to add a new -malign-double= option HJ, there were lots of problems with similar approach, see this revert: 2008-03-23 Uros Bizjak ubiz...@gmail.com Revert: 2008-03-05 H.J. Lu hongjiu...@intel.com * config/i386/i386-modes.def: Use 4 byte alignment on DI for 32bit host. 2008-03-19 Uros Bizjak ubiz...@gmail.com PR target/35496 * stor-layout.c (update_alignment_for_field): Set minimum alignment of the underlying type of a MS bitfield layout to the natural alignment of the type. 2008-03-22 Uros Bizjak ubiz...@gmail.com * config/i386/i386.c (assign_386_stack_local): Align DImode slots to their natural alignment to avoid store forwarding stalls. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #25 from bonzini at gnu dot org 2009-02-11 08:57 --- patch committed (the changelog was in gcc-patches :-). -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #19 from uros at gcc dot gnu dot org 2009-02-11 11:43 --- Subject: Bug 39118 Author: uros Date: Wed Feb 11 11:43:24 2009 New Revision: 144100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144100 Log: PR target/39118 * config/i386/i386.md (UNSPEC_MEMORY_BLOCKAGE): New constant. (memory_blockage): New expander. (*memory_blockage): New insn pattern. * config/i386/i386.c (ix86_expand_prologue): Use memory_blockage instead of general blockage at the end of function prologue when frame pointer is used to access red zone area. Do not emit blockage when profiling, it is emitted in generic code. (ix86_expand_epilogue): Emit memory_blockage at the beginning of function epilogue when frame pointer is used to access red zone area. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #20 from uros at gcc dot gnu dot org 2009-02-11 11:53 --- Subject: Bug 39118 Author: uros Date: Wed Feb 11 11:53:47 2009 New Revision: 144101 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144101 Log: PR target/39118 * config/i386/i386.md (UNSPEC_MEMORY_BLOCKAGE): New constant. (memory_blockage): New expander. (*memory_blockage): New insn pattern. * config/i386/i386.c (ix86_expand_prologue): Use memory_blockage instead of general blockage at the end of function prologue when frame pointer is used to access red zone area. Do not emit blockage when profiling, it is emitted in generic code. (ix86_expand_epilogue): Emit memory_blockage at the beginning of function epilogue when frame pointer is used to access red zone area. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.c branches/gcc-4_3-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #21 from ubizjak at gmail dot com 2009-02-11 11:55 --- Fixed again. -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |02/msg00372.html|02/msg00512.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug middle-end/22448] ICE on dereferencing a label in an asm statement
--- Comment #4 from trick at icculus dot org 2009-02-11 13:38 ---
This also happens when dereferencing void pointers (this is invalid code
though, but I get the same error with the code in the first post):
void foo (void *p)
{
asm( :: g (*p));
}
$ gcc -c foo.c
foo.c: In function foo:
foo.c:3: warning: dereferencing void * pointer
foo.c:3: internal compiler error: in gimplify_expr, at gimplify.c:6288
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.3.3 (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22448
[Bug inline-asm/39078] Registers in on clober list are cloberred when compiled with optimization (x86_64) ?
--- Comment #8 from valery_reznic at yahoo dot com 2009-02-11 14:26 --- (In reply to comment #7) (In reply to comment #5) Any why you say I shouldn't call other function from inside asm ? See for example [1]. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331#c14 I read it. Still I don't get the point. In the inline assembler I MYSELF put arguments in the places where MY (by the way, written in assembler) function expect to get them. I need nothing from gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39078
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-11 14:39 --- (In reply to comment #11) (In reply to comment #9) Created an attachment (id=17279) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit] A patch to add a new -malign-double= option HJ, there were lots of problems with similar approach, see this revert: Another reason for the new option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #22 from ian at airs dot com 2009-02-11 14:49 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug target/39146] Unnecessary stack alignment
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-11 15:15 ---
This is caused by assign_parms in function.c:
/* Estimate stack alignment from parameter alignment. */
if (SUPPORTS_STACK_ALIGNMENT)
{
unsigned int align = FUNCTION_ARG_BOUNDARY (data.promoted_mode,
data.passed_type);
if (TYPE_ALIGN (data.nominal_type) align)
align = TYPE_ALIGN (data.passed_type);
if (crtl-stack_alignment_estimated align)
{
gcc_assert (!crtl-stack_realign_processed);
crtl-stack_alignment_estimated = align;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug inline-asm/39078] Registers in on clober list are cloberred when compiled with optimization (x86_64) ?
--- Comment #9 from ubizjak at gmail dot com 2009-02-11 15:32 --- (In reply to comment #8) In the inline assembler I MYSELF put arguments in the places where MY (by the way, written in assembler) function expect to get them. Then you actually don't need a compiler... ;) I need nothing from gcc. True. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39078
[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics
--- Comment #6 from burnus at gcc dot gnu dot org 2009-02-11 15:36 --- See: http://www.j3-fortran.org/doc/meeting/187/09-006A.txt and there NUMBER: F03/0116. One now only needs to carefully read the text to understand the interpretation. Additionally, it needs to pass some more review (J3 and then WG5). Current STATUS: J3 consideration in progress -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-11 17:11 --- If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help very small functions that need dynamic realignment, but certainly for larger functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even if realignment is done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-11 17:16 --- (In reply to comment #3) If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help Oops. Yes, I meant setting ACCUMULATE_OUTGOING_ARGS to true when stack alignment is needed. very small functions that need dynamic realignment, but certainly for larger functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even if realignment is done. Joey and Xuepeng are running http://www.inf.u-szeged.hu/csibe/ to see how ACCUMULATE_OUTGOING_ARGS affects code size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug c++/38228] [4.2/4.3/4.4 regression] ICE with invalid use of bound member function
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-11 17:52 --- Paolo, should this be assigned to you? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #12 from lucier at math dot purdue dot edu 2009-02-11 18:13 --- I just got the same error with 140 12:54 ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3 --enable-languages=c 141 12:54 make -j 4 bootstrap build.log trying to build gcc-4.3.3 with [luc...@descartes gcc-4.3.3]$ gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) So, if it was fixed on mainline, it wasn't fixed on the branch. Should I just reopen this against 4.3.3, or should I file a new bug report for 4.3.3 and refer back to this one. -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-11 18:27 --- N1169 says that the suffix for a fixed-point literal constant is case insensitive, which to me means that uhk can be uhK/uHk/uHK/Uhk/UhK/UHk as well as UHK. It's easier to implement that way, but if it's really supposed to be a single case then I'd rather fix that now. I asked a question about this, and about GCC's use of ll or LL as a length indicator in fixed-point suffixes, in http://gcc.gnu.org/ml/gcc/2009-02/msg00191.html but there are people copied on this PR who probably don't follow that mailing list. If you're familiar with the fixed-point TR, please let me know your interpretation of this, or whether there's a later draft of the TR than N1169. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug c++/38228] [4.2/4.3/4.4 regression] ICE with invalid use of bound member function
--- Comment #6 from bonzini at gnu dot org 2009-02-11 18:59 --- hm if i didn't look at it so far, i guess no. :-( but if i have time i will look at it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #12 from bonzini at gnu dot org 2009-02-11 19:00 --- /* For -O2 and beyond, turn off -fschedule-insns by default. It tends to make the problem with not enough registers even worse. */ As risky as this may be (for performance, not correctness), what about changing if (level 1) to if (level == 2)? And what about enabling it on x86-64? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug target/39152] New: [4.4 regression] 416.gamess in SPEC CPU 2006 failed
On Linux/ia32, revision 144101 gave: gfortran -m32 -c -o mccas.fppized.o-O2 -ffast-math -mfpmath=sse -mssse3 -ffixed-form mccas.fppized.f mccas.fppized.f: In function 'cashes': mccas.fppized.f:1745: error: unrecognizable insn: (insn 364 296 365 5 mccas.fppized.f:1712 (set (reg/v:SI 4 si [orig:93 ii ] [93]) (mem/s:SI (plus:SI (ashift:SI (reg:SI 3 bx) (const_int 2 [0x2])) (const:SI (plus:SI (symbol_ref:SI (ijpair_) var_decl 0x2b5442f74f00 ijpair) (const_int -4 [0xfffc] [2 ijpair.ia S4 A32])) -1 (nil)) mccas.fppized.f:1745: internal compiler error: in extract_insn, at recog.c:2038 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake: *** [mccas.fppized.o] Error 1 Revision 144092 is OK. -- Summary: [4.4 regression] 416.gamess in SPEC CPU 2006 failed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #36 from bugzilla-gcc at thewrittenword dot com 2009-02-11 19:03 --- (In reply to comment #26) We have filed case #65952072 with Sun to get this backported to Solaris 10. Do you have any news about this? Sun just released patch 139574-03 for SPARC and 139575-03 for x86. We've built gcc-4.2.4 with the x86 patch and it resolved the issue for us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug target/38056] Missed tail calls on ia64
--- Comment #2 from sje at cup dot hp dot com 2009-02-11 19:04 --- This behaviour changed with the patch to fix PR 10907 and I believe that GCC is correct in not doing the tail call optimization. The optimization is not done because ia64_function_ok_for_sibcall returns false and it returns false because bar is defined in a different object file. That object could be in a shared library and could change the GP. Thus GCC needs to save and restore the GP when making calls to another object file and that inhibits the tail call optimization. If bar were defined in the same file GCC could and does do the tail call optimization. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #13 from jv244 at cam dot ac dot uk 2009-02-11 19:25 --- (In reply to comment #12) /* For -O2 and beyond, turn off -fschedule-insns by default. It tends to make the problem with not enough registers even worse. */ As risky as this may be (for performance, not correctness), what about changing if (level 1) to if (level == 2)? And what about enabling it on x86-64? But even on x86-64 this seems to lead to ICEs (see PR38403). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug c++/39153] New: virtual default dtor not defined
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
templatetypename _Tp
class _Impl : public _Impl_base
{ };
int main()
{
_Implint i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh -g -O0 -std=c++0x -fno-inline vague_vs_default.cc
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
Which seems strange, as the base destructor is defined as default.
Also, the vauge linkage/vtable documentation bits here
http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
may need to be updated or expanded to take into account defaulted destructors
vs. key method vtable emission.
--
Summary: virtual default dtor not defined
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug middle-end/39154] New: Miscompilation of VLAs in nested parallel regions
The following testcase segfaults at runtime or ICEs (with checking compiler):
extern void abort (void);
int n = 20;
int
main ()
{
int a[n], b[n][n];
#pragma omp parallel for
for (int i = 0; i n; i++)
{
a[i] = i + 1;
#pragma omp parallel for
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 1)
abort ();
if (a[i] != i + 1)
abort ();
}
#pragma omp parallel for shared (n, a, b)
for (int i = 0; i n; i++)
{
a[i] = i + 3;
#pragma omp parallel for
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 3)
abort ();
if (a[i] != i + 3)
abort ();
}
#pragma omp parallel for
for (int i = 0; i n; i++)
{
a[i] = i + 5;
#pragma omp parallel for shared (n, a, b)
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 5)
abort ();
if (a[i] != i + 5)
abort ();
}
#pragma omp parallel for shared (n, a, b)
for (int i = 0; i n; i++)
{
a[i] = i + 7;
#pragma omp parallel for shared (n, a, b)
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 7)
abort ();
if (a[i] != i + 7)
abort ();
}
return 0;
}
--
Summary: Miscompilation of VLAs in nested parallel regions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39154
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-11 20:24 --- Revision 144098: http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00264.html is the cause. Joey, Xuepeng, can you find a small testcase? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||Joey dot ye at intel dot ||com, xuepeng dot guo at ||intel dot com, bonzini at ||gnu dot org Summary|[4.4 regression] 416.gamess |[4.4 regression] Revision |in SPEC CPU 2006 failed |144098 breaks 416.gamess in ||SPEC CPU 2006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #2 from bonzini at gnu dot org 2009-02-11 20:48 --- Why is this unrecognizable?!? ebx can be an index as well as the base. Anyway, easily fixed. Will post a patch tomorrow. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 20:48:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug bootstrap/39151] If you build and install 'ppl' (and not 'cloog') then files will still link with 'ppl'.
--- Comment #1 from rob1weld at aol dot com 2009-02-11 20:54 --- A workaround is to ./configure using --without-ppl which will cause ppllibs to create an empty variable in the Makefiles. The output from the initial configuring will look the same, but this Bug will be avoided. I'm going to drop this to Minor since this might be an uncommon situation and there are two workarounds (and no fix, yet). The second workaround is to uninstall 'ppl' _or_ install 'cloog' which is not likely near as good a solution as the first workaround (in _these_ particular circumstances). Rob -- rob1weld at aol dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39151
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 20:56 --- How is this major, this is an enhancement to the build system. i386-solaris is a multi arch target so it includes the x86_64 solaris target also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-11 20:59 --- A testcase: [...@gnu-27 Docs]$ cat /tmp/x.f SUBROUTINE CASHES(E,HESS,FC,FA,NORB,NPR) IMPLICIT DOUBLE PRECISION (A-H,O-Z) PARAMETER (MXAO=2047) DIMENSION HESS(NPR),E(NORB,*),FC(*),FA(*) COMMON /IJPAIR/ IA(MXAO) COMMON /MCPAR / NFZC,NCORBS,NCI,NORBS,NORBX,NUM K=0 DO 200 IU = 1,NORB - NCORBS I = IU + NCORBS II=IA(I)+I DO 100 J = 1,NCORBS IF (I.GT.NORBS) THEN HESS(K)=FC(II) + FA(II) - E(J,J) ELSE HESS(K)=FA(II) - E(I,I) - E(J,J) + FC(JJ) + FA(JJ) END IF 100CONTINUE 200 CONTINUE RETURN END [...@gnu-27 Docs]$ /export/gnu/import/rrs/144098/usr/bin/gfortran -m32 -S -O2 -msse2 -mfpmath=sse -ffast-math -ffixed-form /tmp/x.f /tmp/x.f: In function cashes: /tmp/x.f:19: error: unrecognizable insn: (insn 178 144 179 4 /tmp/x.f:10 (set (reg/v:SI 4 si [orig:73 ii ] [73]) (mem/s:SI (plus:SI (ashift:SI (reg:SI 3 bx) (const_int 2 [0x2])) (const:SI (plus:SI (symbol_ref:SI (ijpair_) var_decl 0x2b73b1ef0aa0 ijpair) (const_int -4 [0xfffc] [3 ijpair.ia S4 A32])) -1 (nil)) /tmp/x.f:19: internal compiler error: in extract_insn, at recog.c:2038 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-27 Docs]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug c++/39155] New: Internal compiler error on (invalid) explicit template instantiation of template function
The following code causes an internal compiler error when compiled with g++
without options:
namespace N{templateclass T void foo();}
using namespace N;
templateclass T void foo(){}
template void fooint();
Compiler info:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure
--prefix=/usr/local/compilers/gcc-4.0.1-x86_64-x86_64 --enable-languages=c,c++
--enable-bootstrap
Thread model: posix
gcc version 4.0.1
The code compiles with a useful diagnostic (and no internal error) when
compiled with this newer version of gcc:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
--
Summary: Internal compiler error on (invalid) explicit template
instantiation of template function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cas43 at cs dot stanford dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39155
[Bug c++/39155] Internal compiler error on (invalid) explicit template instantiation of template function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 21:08 --- You reported this against 4.0.1 and 4.0.x and 4.1.x are no longer being supported (meaning no more 4.0.x or 4.1.x release). Since it has been fixed in 4.1.2, I am closing this as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 Version|4.1.2 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39155
[Bug c++/39156] New: Internal compiler error on (invalid) use of undefined type in template function
This line of code causes an internal compiler when compiled with g++ without
options:
class B;templateclass T void foo(B x) {x(0);}
Compiler:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure
--prefix=/usr/local/compilers/gcc-4.0.1-x86_64-x86_64 --enable-languages=c,c++
--enable-bootstrap
Thread model: posix
gcc version 4.0.1
Compiling with this newer version yields a meaningful diagnostic instead of an
internal error:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
--
Summary: Internal compiler error on (invalid) use of undefined
type in template function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cas43 at cs dot stanford dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39156
[Bug c++/39156] Internal compiler error on (invalid) use of undefined type in template function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 21:12 --- You reported this against 4.0.1 and 4.0.x and 4.1.x are no longer being supported (meaning no more 4.0.x or 4.1.x release). Since it has been fixed in 4.1.2, I am closing this as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 Version|4.1.2 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39156
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #4 from bonzini at gnu dot org 2009-02-11 21:20 --- The problem is that inside mems we use MULT not ASHIFT. Can you please test this? Thanks! --- config/i386/i386.md (revision 144098) +++ config/i386/i386.md (working copy) @@ -20722,7 +20722,7 @@ (parallel [(set (match_dup 0) (match_op_dup 3 [(match_dup 0) (match_dup 1)])) (clobber (reg:CC FLAGS_REG))])] - operands[4] = simplify_replace_rtx (operands[2], operands[0], operands[1]);) + operands[4] = replace_rtx (operands[2], operands[0], operands[1]);) (define_peephole2 [(set (match_operand 0 register_operand ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #5 from bonzini at gnu dot org 2009-02-11 21:20 --- There was wrapping, all you have to do is remove simplify_. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-11 21:28 ---
This is still broken inside extern C:
extern C {
void foo (int i, int j = 6);
void foo (int i = 4, int j);
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-11 21:31 --- The extern C testcase passed under the 3.2 compiler; marking as regression. -- jason at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.3.6 3.4.0 3.4.5 4.0.2 |3.3.6 3.4.0 3.4.5 4.0.2 |4.0.4 4.1.2 4.2.0 |4.0.4 4.1.2 Priority|P1 |P2 Summary|[4.0/4.1/4.2 Regression]|[4.2/4.3/4.4 Regression] |Redeclaration with extra|Redeclaration with extra |default argument doesn't|default argument doesn't |work|work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c++/34691] [4.2/4.3/4.4 Regression] Default argument checking not performed after overload resolution with C linkage
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-11 21:31 --- I've reopened PR 28274 with the PR in comment #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #6 from dominiq at lps dot ens dot fr 2009-02-11 21:41 --- With the patch in comment #4 the test in comment #3 compiles without ICE on i686-apple-darwin9 (it gave an ICE before the patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug middle-end/39157] New: Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher
With this compiler [luc...@descartes gambit]$ gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3 --enable-languages=c --with-cpu=default64 Thread model: posix gcc version 4.3.3 (GCC) with the file compiler.i found here: http://www.math.purdue.edu/~lucier/bugzilla/8/ attempting to compile with these options: gcc -m64 -mcpu=970 -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -rdynamic -shared can't compile in 8GB of RAM. With this compiler: euler-77% /pkgs/gcc-4.2.3/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.2.3/configure --prefix=/pkgs/gcc-4.2.3 --enable-checking=release --with-gmp=/pkgs/gmp-4.2.2 --with-mpfr=/pkgs/gmp-4.2.2 Thread model: posix gcc version 4.2.3 and these options: gcc -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared it can't compiler in 20GB of RAM. (That machine has only 16GB of RAM, so I killed the compile when it hit 20GB of physical+virtual memory.) It compiles just fine in about 1GB of RAM with euler-76% gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/pkgs/gcc-4.1.2 Thread model: posix gcc version 4.1.2 compiler.i is the output from the Gambit Scheme-C compiler; the source scheme program is from a standard benchmark suite for Scheme compilers. So I found this by trying to change the code generator for Gambit and running the benchmark suite on x86_64. I don't know how this can be fixed. Basically, the entire middle-end infrastructure since 4.1.* is telling people like me with computer-generated code like this to just go away (to put it very politely). On Mac OS X 10.5.*, Apple bundles their version of 4.0.1, which compiles this just fine; on Red Hat 5.2, they bundle their version of 4.1.2 (I think, my RH5.2 box is down at the moment), which compiles this just fine; but on Ubuntu 8.10 or Fedora 10 you can't compile this because they bundle newer compilers. (I guess I'll see if I can install 4.1.* on both of these.) As a stopgap measure, perhaps someone can tell me what optimization level to use. As you can see, I use -O1 and a few others (mainly -fschedule-insns2). gcc 4.1.* and earlier compiled something like this just fine, but -O1 must mean something different now. -- Summary: Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
[Bug c++/39153] virtual default dtor not defined
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 21:56:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug middle-end/39154] Miscompilation of VLAs in nested parallel regions
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-11 21:58 --- Subject: Bug 39154 Author: jakub Date: Wed Feb 11 21:57:52 2009 New Revision: 144111 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144111 Log: PR middle-end/39154 * gimplify.c (omp_notice_variable): If adding GOVD_SEEN bit to variable length decl's flags, add it also to its pointer replacement variable. * testsuite/libgomp.c/pr39154.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr39154.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39154
[Bug middle-end/39154] Miscompilation of VLAs in nested parallel regions
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-11 22:02 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 22:02:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39154
[Bug c++/36954] Wrong warning with -Wlogical-op
-- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org BugsThisDependsOn||16302 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 22:08:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36954
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-02-11 22:11 --- Is there a reason why this is a P1? I don't see why this should be a P1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug c++/39158] New: virtual default dtor not defined
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
templatetypename _Tp
class _Impl : public _Impl_base
{ };
int main()
{
_Implint i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh -g -O0 -std=c++0x -fno-inline vague_vs_default.cc
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
Which seems strange, as the base destructor is defined as default.
Also, the vauge linkage/vtable documentation bits here
http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
may need to be updated or expanded to take into account defaulted destructors
vs. key method vtable emission.
--
Summary: virtual default dtor not defined
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39158
[Bug target/36513] -Wlogical-op warns about strchr
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-11 22:13 --- We need a reproducible preprocessed testcase. See http://gcc.gnu.org/bugs.html#detailed -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
[Bug c++/39153] virtual default dtor not defined
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-02-11 22:13 --- *** Bug 39158 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug c++/39158] virtual default dtor not defined
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-02-11 22:13 --- Whoops, wrong state in browser *** This bug has been marked as a duplicate of 39153 *** -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39158
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-11 22:38 --- Subject: Bug 30111 Author: jason Date: Wed Feb 11 22:38:37 2009 New Revision: 144112 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144112 Log: PR c++/30111 * init.c (build_value_init_noctor): Split out from... (build_value_init): ...here. (expand_aggr_init_1): Handle value-initialization. * cp-tree.h: Add declaration. * class.c (type_has_user_provided_constructor): Handle non-class arguments. Added: trunk/gcc/testsuite/g++.dg/init/value7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-11 22:50 --- Fixed for 4.4. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c/32061] (Wlogical-op) wording of warning of constant logicials need improvement
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-11 23:04 --- Confirmed. I have a patch for this for 4.5. The new wording will say: warning: logical 'or' applied to non-boolean constant. Are you satisfied with this? BTW, why no warning for this? resp == 0 0 Naturally, all the above constants will hide behind some macros which could indicate a real error, hence the value of the warning. Warning for (x 0) or (x 1) would produce hundreds of false positives. We shouldn't warn about your testcase either. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 23:04:41 date|| Summary|wording of warning of |(Wlogical-op) wording of |constant logicials need |warning of constant |improvement |logicials need improvement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug c++/39054] [4.3 regression] ICE with invalid pseudo-dtor in template
--- Comment #4 from jason at gcc dot gnu dot org 2009-02-11 23:04 --- Fixed for 4.3 as well. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug target/38056] Missed tail calls on ia64
--- Comment #3 from jsworley at qwest dot net 2009-02-11 23:41 --- Accepting Steve Ellcey's analysis, it would seem that the tail call *should* be recognized when -mconstant-gp is specified; however, it isn't. -- jsworley at qwest dot net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug c++/39159] New: unhelpful attribute warning on matching declaration after definition
gcc 4.3 issues a warning for the declaration of struct A below despite the
attribute on the declaration being consistent with that on the definition and
thus benign. While the warning is valuable in cases where the attributes
between the declaration and the definition do not match, it is not useful in
benign cases such as the one below. In these cases the warning makes applying
the attribute difficult in existing C++ libraries that rely heavily but not
completely on forward declarations and that also already make use of the Visual
C++ __declspec(dllexport) feature or the Sun C++ __global or __protected
specifiers, neither of which warns about such benign cases.
$ cat t.C g++ -c t.C
struct __attribute__ ((visibility (default))) A { };
struct __attribute__ ((visibility (default))) A;
t.C:2: warning: type attributes ignored after type is already defined
--
Summary: unhelpful attribute warning on matching declaration
after definition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
[Bug target/39146] Unnecessary stack alignment
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-11 23:59 --- The dynamic stack alignment may not be easy to optimize out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug other/28322] GCC new warnings and compatibility
--- Comment #24 from manu at gcc dot gnu dot org 2009-02-12 00:25 --- Is there anything that remains to be done here? -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-12 00:44 --- I tried -maccumulate-outgoing-args on 2.6 kernel: textdata bss dec hex filename 5136786 600084 1003520 6740390 66d9a6 vmlinux 5086759 600084 1003520 6690363 66163b /tmp/vmlinux.old It does increase binary size. Should we consider to turn on ACCUMULATE_OUTGOING_ARGS when stack is aligned? If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used for stack alignment and it may lead to code size increase due to register spill since ia32 has very few registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug ada/39160] New: Assert_Failure in sinfo.adb
Note that the test code is not semantically correct. Correct code compiles just fine. For me, the bug manifests in both 4.3.2 and the 4.4-20090206 snapshot. Configure options: --disable-multilib --enable-languages=c,ada System type: $ uname -ro 2.6.27.12-170.2.5.fc10.x86_64 GNU/Linux Output: $ gcc -c bug.adb +===GNAT BUG DETECTED==+ | 4.4.0 20090206 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure sinfo.adb:1987| | Error detected at bug.adb:17:26 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- Summary: Assert_Failure in sinfo.adb Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilsons at start dot ca GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39160
[Bug ada/39160] Assert_Failure in sinfo.adb
--- Comment #1 from wilsons at start dot ca 2009-02-12 00:56 --- Created an attachment (id=17282) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17282action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39160
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-12 01:38 --- (In reply to comment #4) The problem is that inside mems we use MULT not ASHIFT. Can you please test this? Thanks! --- config/i386/i386.md (revision 144098) +++ config/i386/i386.md (working copy) @@ -20722,7 +20722,7 @@ (parallel [(set (match_dup 0) (match_op_dup 3 [(match_dup 0) (match_dup 1)])) (clobber (reg:CC FLAGS_REG))])] - operands[4] = simplify_replace_rtx (operands[2], operands[0], operands[1]);) + operands[4] = replace_rtx (operands[2], operands[0], operands[1]);) (define_peephole2 [(set (match_operand 0 register_operand ) I verified that this fixed 416.gamess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug target/39146] Unnecessary stack alignment
--- Comment #5 from Joey dot ye at intel dot com 2009-02-12 01:45 --- Stack realign is finalized by stack_realign = (incoming_stack_boundary (current_function_is_leaf ? crtl-max_used_stack_slot_alignment : crtl-stack_alignment_needed)); since bar is leaf function, it checks max_used_stack_slot_alignment. According to it's definition, max_used_stack_slot_alignment is /* The largest alignment of slot allocated on the stack. */. Parameter x isn't allocated on local stack, so max_used_stack_slot_alignment shouldn't be set to 256 bits. In locate_and_pad_parm, if (crtl-max_used_stack_slot_alignment crtl-stack_alignment_needed) crtl-max_used_stack_slot_alignment = crtl-stack_alignment_needed; sets max_used_stack_slot_alignment to 256 bits, which seems shouldn't happen all the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39146] Unnecessary stack alignment
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-12 01:58 --- locate_and_pad_parm in function.c has /* Remember if the outgoing parameter requires extra alignment on the calling function side. */ if (crtl-stack_alignment_needed boundary) crtl-stack_alignment_needed = boundary; if (crtl-max_used_stack_slot_alignment crtl-stack_alignment_needed) crtl-max_used_stack_slot_alignment = crtl-stack_alignment_needed; if (crtl-preferred_stack_boundary boundary) crtl-preferred_stack_boundary = boundary; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug c++/39153] virtual default dtor not defined
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-12 02:01 --- Subject: Bug 39153 Author: jason Date: Thu Feb 12 02:01:07 2009 New Revision: 144119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144119 Log: PR c++/39153 * decl2.c (cp_write_global_declarations): Check DECL_DEFAULTED_FN, not DECL_ARTIFICIAL. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug libgcj/39161] New: gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.
I am building gcc 4.4.0 20090210 [trunk revision 144083] on OpenSolaris 2009.06 . The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script. # isainfo -k amd64 # uname -a SunOS opensolaris 5.11 snv_106 i86pc i386 i86pc # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --target=i386-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090210 (experimental) [trunk revision 144083] (GCC) # gmake ... (long time) mkdir ../gnu/java/locale ../../../../../gcc_trunk/libjava/classpath/scripts/generate-locale-list.sh ../gnu/java/locale/LocaleData.java true top_builddir=.. top_srcdir=../../../../../gcc_trunk/libjava/classpath /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '../../../../../gcc_trunk/libjava/classpath'. Adding java source files from VM directory /usr/share/src/gcc_trunk/libjava Adding java source files from VM directory /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava Adding generated files in builddir '..'. touch compile-classes mkdir gnu mkdir gnu/javax mkdir gnu/javax/security ... mkdir META-INF mkdir META-INF/services ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/util/logging/: not found [No such file or directory] ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/util/: not found [No such file or directory] ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/util/: not found [No such file or directory] ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/text/: not found [No such file or directory] (many, many more) ... # find ../gcc_build/ -name copy-vmresources.sh i386-pc-solaris2.11/amd64/libjava/classpath/lib/copy-vmresources.sh i386-pc-solaris2.11/libjava/classpath/lib/copy-vmresources.sh # find ../gcc_trunk/ -name mkinstalldirs ../gcc_trunk/libjava/classpath/mkinstalldirs ../gcc_trunk/mkinstalldirs Those errors do _not_ cause the build to fail. The library (and gcc) will continue to build and the Testsuite Results are 'reasonably good'. Rob -- Summary: gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
[Bug target/39162] New: Gcc doesn't warn __m256 when -mavx isn't used
bash-3.2$ cat /tmp/x.i
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
bar (__m256i x)
{
return x;
}
bash-3.2$ gcc -S /tmp/x.i
This is due to type_natural_mode doesn't check 32byte types. If I
add
--- ./i386.c.warn 2009-02-11 06:58:52.0 -0800
+++ ./i386.c2009-02-11 18:03:30.0 -0800
@@ -4729,7 +4729,7 @@ type_natural_mode (const_tree type)
if (TREE_CODE (type) == VECTOR_TYPE !VECTOR_MODE_P (mode))
{
HOST_WIDE_INT size = int_size_in_bytes (type);
- if ((size == 8 || size == 16)
+ if ((size == 8 || size == 16 || size == 32)
/* ??? Generic code allows us to create width 1 vectors. Ignore. */
TYPE_VECTOR_SUBPARTS (type) 1)
{
I got
bash-3.2$ ./xgcc -B./ -O2 /tmp/x.i -S
/tmp/x.i: In function bar:
/tmp/x.i:3: warning: AVX vector argument without AVX enabled changes the ABI
/tmp/x.i:6: internal compiler error: in emit_move_multi_word, at expr.c:3317
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
emit_move_multi_word isn't prepared to deal with it.
--
Summary: Gcc doesn't warn __m256 when -mavx isn't used
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39162
[Bug c++/39153] virtual default dtor not defined
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-12 02:12 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug target/39162] Gcc doesn't warn __m256 when -mavx isn't used
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-12 02:14 --- I think we should make it an error instead. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39162
[Bug target/39146] Unnecessary stack alignment
--- Comment #7 from Joey dot ye at intel dot com 2009-02-12 02:26 --- Created an attachment (id=17283) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17283action=view) A patch to fix this problem Impact to other test unknown. Test undergoing. HJ, can you also help to verify and test this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #6 from Joey dot ye at intel dot com 2009-02-12 02:33 --- (In reply to comment #5) If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used for stack alignment and it may lead to code size increase due to register spill since ia32 has very few registers. The code increase resulted from stack realign are mainly from prologue increase. ECX is only used as hard register in prologue/epilogue and the impact to function body is low. If ACCUMULATE_OUTGOING_ARGS does increase code size, then for big functions, benefit of !ACCUMULATE_OUTGOING_ARGS will offset increase of prologue/epilogue. So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best option for all cases either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug target/39146] Unnecessary stack alignment
--- Comment #8 from hjl dot tools at gmail dot com 2009-02-12 02:33 --- (In reply to comment #7) Created an attachment (id=17283) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17283action=view) [edit] A patch to fix this problem Impact to other test unknown. Test undergoing. HJ, can you also help to verify and test this patch? With your patch, I got .globl bar .type bar, @function bar: pushq %rbp movq%rsp, %rbp leave ret We still have push and mov. I guess it may be the best we can do. But please run full 32 and 64bit testsuite with your patch as well as under emx-avx-sim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-12 02:37 --- (In reply to comment #6) So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best option for all cases either. OK. I am closing as WONTFIX. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug target/39146] Unnecessary stack alignment
--- Comment #9 from Joey dot ye at intel dot com 2009-02-12 02:40 --- (In reply to comment #8) We still have push and mov. I guess it may be the best we can do. I believe so too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #5 from tydeman at tybor dot com 2009-02-12 02:54 --- The latest version of TR 18037 is WG14 document N1275 of 2007/10/01. The suffix really is case insensitive, so 'uhk' has 8 variations. 'll' and 'LL' are not valid suffixes for fixed point constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug target/36480] stack-protector causes bad ARM PIC code generated
--- Comment #1 from dougkwan at google dot com 2009-02-12 03:04 ---
I have a test case now. The toolchain is built with gcc trunk, binutils-2.18,
gdb-6.71 and newlib-1.16.0 for target arm-eabi
---
#include stdlib.h
extern int sprintf (char *, const char*, ...);
int
main (void)
{
char buf[10];
sprintf(buf, );
return 0;
}
#
# Test case exits with an error code if compiled with -fstack-protector -fpic
#
sh-3.1$ arm-eabi-gcc -fstack-protector -fpic bug.csh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 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 --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2af8 vma 0x8018
Loading section .fini, size 0x18 vma 0xab10
Loading section .rodata, size 0xd4 vma 0xab28
Loading section .ARM.exidx, size 0x8 vma 0xabfc
Loading section .eh_frame, size 0x4 vma 0xac04
Loading section .init_array, size 0x8 vma 0x12c08
Loading section .fini_array, size 0x4 vma 0x12c10
Loading section .jcr, size 0x4 vma 0x12c14
Loading section .got, size 0x10 vma 0x12c18
Loading section .data, size 0x930 vma 0x12c28
Start address 0x80ac
Transfer rate: 109248 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited with code 0377.
(gdb) quit
#
# It exits normally with -fstack-protector only
#
sh-3.1$ arm-eabi-gcc -fstack-protector bug.c
sh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 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 --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2adc vma 0x8018
Loading section .fini, size 0x18 vma 0xaaf4
Loading section .rodata, size 0xd4 vma 0xab0c
Loading section .ARM.exidx, size 0x8 vma 0xabe0
Loading section .eh_frame, size 0x4 vma 0xabe8
Loading section .init_array, size 0x8 vma 0x12bec
Loading section .fini_array, size 0x4 vma 0x12bf4
Loading section .jcr, size 0x4 vma 0x12bf8
Loading section .data, size 0x930 vma 0x12c00
Start address 0x80ac
Transfer rate: 108896 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited normally.
(gdb) quit
#
# It also exits normally if -O2 is given in addition to -fstack-protector
-fpic
#
sh-3.1$ arm-eabi-gcc -fstack-protector -fpic -O2 bug.c
sh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 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 --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2ae0 vma 0x8018
Loading section .fini, size 0x18 vma 0xaaf8
Loading section .rodata, size 0xd4 vma 0xab10
Loading section .ARM.exidx, size 0x8 vma 0xabe4
Loading section .eh_frame, size 0x4 vma 0xabec
Loading section .init_array, size 0x8 vma 0x12bf0
Loading section .fini_array, size 0x4 vma 0x12bf8
Loading section .jcr, size 0x4 vma 0x12bfc
Loading section .got, size 0x10 vma 0x12c00
Loading section .data, size 0x930 vma 0x12c10
Start address 0x80ac
Transfer rate: 109056 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited normally.
(gdb) quit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36480
