Re: Use of FLAGS_REGNUM clashes with generates insn
Quoting Paulo J. Matos pa...@matos-sorge.com: My addition instruction sets all the flags. So I have: This is annoying, but can be handled. Been there, done that. dse.c needs a small patch, which I intend to submit sometime in the future. And all my (define_insn *mov... are tagged with a (clobber (reg:CC RCC)). This generates all kinds of trouble since GCC generates moves internally without the clobber that fail to match. I don't think that can be overcome without cc0. Unless you want to hide your flags register altogether.
Question on _GLIBCXX_HOSTED macro libstdc++ and libsupc++
Hi, In libstdc++-v3/libsupc++/eh_term_handler.cc, it says by default the demangler things are pulled in, according to whether _GLIBCXX_HOSTED is defined. the demangler exception terminating handler are really big, especially for embedded system. Secondly, _GLIBCXX_HOSTED is now defined if --enable-hosted-libstdcxx is given(by default it is). This option also controls whether libstdc++.a itself is built for target system. So, for an embedded system, how could I provide the earlier silent death handler by defining _GLIBCXX_HOSTED, also with libstdc++ built? Any suggestion? Thanks in advance. FYI, all above are talking about cross-toolchain. -- Best Regards.
Re: Question on _GLIBCXX_HOSTED macro libstdc++ and libsupc++
On 23 September 2011 09:14, Amker.Cheng wrote: Hi, In libstdc++-v3/libsupc++/eh_term_handler.cc, it says by default the demangler things are pulled in, according to whether _GLIBCXX_HOSTED is defined. the demangler exception terminating handler are really big, especially for embedded system. Secondly, _GLIBCXX_HOSTED is now defined if --enable-hosted-libstdcxx is given(by default it is). This option also controls whether libstdc++.a itself is built for target system. So, for an embedded system, how could I provide the earlier silent death handler by defining _GLIBCXX_HOSTED, also with libstdc++ built? Any suggestion? Thanks in advance. FYI, all above are talking about cross-toolchain. (Any reason this wasn't sent to the libstdc++ list?) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 proposes a quiet mode which would reduce code size by disabling some of the code in eh_term_handler.cc and pure.cc - would that do what you want? I've not had time to do anything about it, but I think Sebastian (CC'd) has a copyright assignment in place now, and he's provided a patch implementing it.
Re: Question on _GLIBCXX_HOSTED macro libstdc++ and libsupc++
(Any reason this wasn't sent to the libstdc++ list?) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 proposes a quiet mode which would reduce code size by disabling some of the code in eh_term_handler.cc and pure.cc - would that do what you want? I've not had time to do anything about it, but I think Sebastian (CC'd) has a copyright assignment in place now, and he's provided a patch implementing it. Sorry for missing the list, cced now. It is exactly what I meant, thanks very much. -- Best Regards.
Re: Volatile qualification on pointer and data
On 22/09/11 22:15, Richard Guenther wrote: Btw, I think this is an old bug that has been resolved. Did you make sure to test a recent 4.6 branch snapshot or svn head? Should have tested git head. Compiling git head now to check the current status of this issue. -- PMatos
Re: Volatile qualification on pointer and data
On 23/09/11 12:33, Paulo J. Matos wrote: On 22/09/11 22:15, Richard Guenther wrote: Btw, I think this is an old bug that has been resolved. Did you make sure to test a recent 4.6 branch snapshot or svn head? Should have tested git head. Compiling git head now to check the current status of this issue. Git head 36181f98f doesn't compile (x86_64, --enable-checking=all, GCC 4.5.2): gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../repositories/gcc/gcc -I../../../repositories/gcc/gcc/. -I../../../repositories/gcc/gcc/../include -I../../../repositories/gcc/gcc/../libcpp/include -I../../../repositories/gcc/gcc/../libdecnumber -I../../../repositories/gcc/gcc/../libdecnumber/bid -I../libdecnumber ../../../repositories/gcc/gcc/fold-const.c -o fold-const.o ../../../repositories/gcc/gcc/fold-const.c: In function ‘fold_overflow_warning’: ../../../repositories/gcc/gcc/fold-const.c:326:5: warning: format not a string literal and no format arguments ../../../repositories/gcc/gcc/fold-const.c: In function ‘fold_checksum_tree’: ../../../repositories/gcc/gcc/fold-const.c:13803:3: error: invalid application of ‘sizeof’ to incomplete type ‘struct tree_type’ -- PMatos
Re: Use of FLAGS_REGNUM clashes with generates insn
On 23/09/11 08:21, Joern Rennecke wrote: Quoting Paulo J. Matos pa...@matos-sorge.com: My addition instruction sets all the flags. So I have: This is annoying, but can be handled. Been there, done that. dse.c needs a small patch, which I intend to submit sometime in the future. Ok. Actually I was quite happy with my solution too which avoided having to change the core. However, it was not heavily tested. And all my (define_insn *mov... are tagged with a (clobber (reg:CC RCC)). This generates all kinds of trouble since GCC generates moves internally without the clobber that fail to match. I don't think that can be overcome without cc0. Unless you want to hide your flags register altogether. That's seriously annoying. The idea was to ditch cc0 and explicitly represent CC in a register to perform optimizations like splitting add and addc for a double word addition. If by hiding my register flags means going back to cc0, then it seems that the only way to go unless I get it to work somehow. If you having anything else in mind to get it to work let me know. What I currently have in mind is to have a backend macro listing all the move for which a move clobber CC_REG, then whenever GCC generates a move, it queries the macro to know if the move requires clobbering and emits the clobber if required. However, I am unsure how deep the rabbit hole goes. -- PMatos
Re: RFC: Improving support for known testsuite failures
On Thu, Sep 22, 2011 at 20:06, Hans-Peter Nilsson h...@bitrange.com wrote: On Thu, 8 Sep 2011, Diego Novillo wrote: On Thu, Sep 8, 2011 at 04:31, Richard Guenther richard.guent...@gmail.com wrote: I think it would be more useful to have a script parse gcc-testresults@ postings from the various autotesters and produce a nice webpage with revisions and known FAIL/XPASSes for the target triplets that are tested. Sure, though that describes a different tool. I'm after a tool that will 'exit 0' if the testsuite finished with nominal results. Not to stop you from (partly) reinventing the wheel, but that's pretty much what contrib/regression/btest-gcc.sh already does, though you have to feed it a baseline a set of processed .sum files which could (for a calling script or a modified btest-gcc.sh) live in, say, contrib/target-results/target. It handles duplicate test names by marking it as failing if any of them has failed. Works good enough. Yeah, I actually considered using it by extracting the actual .sum file processing out of it (I was not interested in it running the build nor the tests). However, I also needed to add support for marking flaky tests and putting an expiration date on failures. Additionally, I needed versioned failure manifests, and I could not justify storing in SVN multiple directories with 12Mb worth of .sum files in them. The small manifest file also has the local advantage of serving as release documentation for what we expect to fail and why. Diego.
Re: Volatile qualification on pointer and data
On 22/09/11 22:15, Richard Guenther wrote: Btw, I think this is an old bug that has been resolved. Did you make sure to test a recent 4.6 branch snapshot or svn head? My hopes were high but unfortunately it is not fixed yet. git head 36181f98 still generates the same unexpected code. Cheers, -- PMatos
Re: Use of FLAGS_REGNUM clashes with generates insn
Quoting Paulo J. Matos pa...@matos-sorge.com: That's seriously annoying. The idea was to ditch cc0 and explicitly represent CC in a register to perform optimizations like splitting add and addc for a double word addition. If by hiding my register flags means going back to cc0, then it seems that the only way to go unless I get it to work somehow. If you having anything else in mind to get it to work let me know. Hiding the flags register would mean it is not represented in the rtl at all. You can have combined compare-branch instructions. Of course, going that route would mean that the model you present to GCC is even further from the hardware than one that uses cc0. What I currently have in mind is to have a backend macro listing all the move for which a move clobber CC_REG, then whenever GCC generates a move, it queries the macro to know if the move requires clobbering and emits the clobber if required. However, I am unsure how deep the rabbit hole goes. Oh, so you do have variants that can do without the clobber. If you can make all the reloads without introducing explicit flag clobbers, that it should work. But you can't just pull a flag clobber out of thin air. You should have some way to generate valid code when the flags register is unavailable / must be saved. Then you can use peephole2 to add flag clobbers where the flags register is available. Or you can use machine_dependent_reorg or another machine-specific pass inserted with the pass manager to rewrite clobber-free instructions into ones that have a hardware equivalent; but you must make sure that your data flow remains sound in the process.
Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)
On Fri, 23 Sep 2011 02:21:44 +0200, Cary Coutant wrote: * .debug_pubtypes - Public types for use in building the .gdb_index section at link time. This section will have an extended format to allow it to represent both types in the .debug_dwo_info section and type units in .debug_types. ^^^ = .dwo_info , maybe both .debug_info and .dwo_info * .dwo_abbrev - Defines the abbreviation codes used by the .debug_dwo_info section. ^^^ = .dwo_info I find this .dwo_* setup is great for rapid development rebuilds but it should remain optional as the currently used DWARF final separate .debug info file is smaller than all the .dwo files together. In the case of the final linked .debug builds (rpm/deb/...) one does not consider the build speed as important. It probably does not make sense to merge + convert .dwo files back to a single .debug file for the rpm/deb/... build performance reasons. Thanks, Jan
Re: Use of FLAGS_REGNUM clashes with generates insn
On Fri, 23 Sep 2011 09:30:48 -0400, amylaar wrote: Hiding the flags register would mean it is not represented in the rtl at all. You can have combined compare-branch instructions. Of course, going that route would mean that the model you present to GCC is even further from the hardware than one that uses cc0. Got it! That seems that it would go against the whole point of replacing cc0 for CC_REGNUM in my specific case. Oh well... What I currently have in mind is to have a backend macro listing all the move for which a move clobber CC_REG, then whenever GCC generates a move, it queries the macro to know if the move requires clobbering and emits the clobber if required. However, I am unsure how deep the rabbit hole goes. Oh, so you do have variants that can do without the clobber. Actually I don't... My explanation was supposed to be referring to a general solution. In my case, the macro would list all moves since all moves clobber CC. If you can make all the reloads without introducing explicit flag clobbers, that it should work. Unfortunately I can't. But you can't just pull a flag clobber out of thin air. Understood. You should have some way to generate valid code when the flags register is unavailable / must be saved. Then you can use peephole2 to add flag clobbers where the flags register is available. Or you can use machine_dependent_reorg or another machine-specific pass inserted with the pass manager to rewrite clobber-free instructions into ones that have a hardware equivalent; but you must make sure that your data flow remains sound in the process. I think your last suggestion of having a pass to rewrite the clobber free instructions into one with a hardware equivalent seems the one to go for me. Thanks for the suggestions, -- PMatos
misbehaviour with md5_process_bytes and maybe in optimization
Hello, I recently asked for some help as I got a problem when using md5_process_bytes (in libiberty/md5.c): http://gcc.gnu.org/ml/gcc-help/2011-09/msg00126.html, http://gcc.gnu.org/ml/gcc-help/2011-09/msg00127.html and it appears that there is a bug in md5_process_bytes. The bug can conduct to a miscomputed md5 result. It tooks time to me to make the bug reproducible but I was finally able to do so. The fact is that it only appears in very particular situation. I have written a small gcc plugin, allowing to reproduce it (see attachment). The bad news is that the bug only appears when use libiberty compiled in -g -O0 (it works well with -O2). It is quite sad, because It could means another bug in an optimization function. I have attached a README which detail how to use the plugin and how to explain the bug. I have tried to explain as good as possible (and I apologize for my very bad english). The bug appears when: 1) We use libiberty compiled with -O0 2) We first call md5_process_bytes with a less than 64 bits buffer (we call his size len1). 3) We make a new call of md5_process_bytes with a buffer which has a size len2 such as: len2 127 + 65 (so test in line 228 of md5.C will be true) 128 -len1 != Mulint with Mulint % __alignof__ (md5_uint32) != 0 (so condition on line 238 is true) len2 - (128 - len1) = Mul64 and Mul64 such as Mul %64=0 (so the loop of line 239 is broken with len = 64, this leads to the bug as, line 249, (len ~63) = 64 and we shift the buffer without processing the data). Please, can you reproduce the bug? Is there any useful informations I can add? Must I contact somebody from libiberty (I don't know the status of this library (is this part of gcc or from another project?)). I already sent a patch correcting this issue (it does not correct the fact that we don't get the bug with an optimised libiberty): http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01098.html. It has not been reviewed, could someone reviews this? Thanks! Pierre Vittet md5sum_plugin.tar.gz Description: application/gzip
Re: misbehaviour with md5_process_bytes and maybe in optimization
Pierre Vittet pier...@pvittet.com writes: The bug appears when: 1) We use libiberty compiled with -O0 2) We first call md5_process_bytes with a less than 64 bits buffer (we call his size len1). 3) We make a new call of md5_process_bytes with a buffer which has a size len2 such as: len2 127 + 65 (so test in line 228 of md5.C will be true) 128 -len1 != Mulint with Mulint % __alignof__ (md5_uint32) != 0 (so condition on line 238 is true) len2 - (128 - len1) = Mul64 and Mul64 such as Mul %64=0 (so the loop of line 239 is broken with len = 64, this leads to the bug as, line 249, (len ~63) = 64 and we shift the buffer without processing the data). The line numbers you mention do not correspond to any version of libiberty/md5.c that I can see. Can you list the exact line for each line number you mention, so that your explanation is easier to follow? Thanks. Ian
Re: passing arguments to gcc build in eclipse
ok sorrythanks for replying..!! Andrew Haley wrote: On 09/16/2011 11:30 AM, pankajsejwal wrote: I have build gcc and imported it on eclipse and started to debug it from main but after a few steps it stops and sends malloc.c not found error and asks to give a source path to it. I believe the problem is because of the arguments that it requires to proceed for example filename.c as gcc takes some arguments to work on in terminal. Can someone please tell me the error I am facing and it i am correct can u tell me how to pass arguments to the built code that it can recognize it as a .C file. This is not an appropriate message for gcc@gcc.gnu.org, which is only about the development of gcc itself. Most of us don't use Eclipse. I think you'd be much better advised to direct this to an Eclipse-specific list, where the experts will be. Andrew. -- View this message in context: http://old.nabble.com/passing-arguments-to-gcc-build-in-eclipse-tp32477948p32503880.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Wrong documentation of TARGET_ADDR_SPACE_SUBSET_P
Hi, I notice the following description is different from how spu m32c use it. In internal manual: bool TARGET_ADDR_SPACE_SUBSET_P (addr space t superset, [Target Hook] addr space t subset) Define this to return whether the subset named address space is contained within the superset named address space. Pointers to a named address space that is a subset of another named address space will be converted automatically without a cast if used together in arithmetic operations. Pointers to a superset address space can be converted to pointers to a subset address space via explicit casts. In spu m32c ports: m32c_addr_space_subset_p (addr_space_t subset, addr_space_t superset) spu_addr_space_subset_p (addr_space_t subset, addr_space_t superset) I believe the document is wrong. The first argument is subset and the second one is superset. Should I submit a patch? Cheers, Bingfeng Mei
Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)
* .debug_pubtypes - Public types for use in building the .gdb_index section at link time. This section will have an extended format to allow it to represent both types in the .debug_dwo_info section and type units in .debug_types. ^^^ = .dwo_info , maybe both .debug_info and .dwo_info * .dwo_abbrev - Defines the abbreviation codes used by the .debug_dwo_info section. ^^^ = .dwo_info Thanks, I've fixed the wiki page. I find this .dwo_* setup is great for rapid development rebuilds but it should remain optional as the currently used DWARF final separate .debug info file is smaller than all the .dwo files together. In the case of the final linked .debug builds (rpm/deb/...) one does not consider the build speed as important. It probably does not make sense to merge + convert .dwo files back to a single .debug file for the rpm/deb/... build performance reasons. Yes, we'll definitely make this a compile-time option. While I haven't finished designing the package format for collecting all the .dwo files, I do plan on having the packaging tool do at least duplicate type elimination to reduce the size of the package file. -cary
Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)
The Apple approach has both the features of the Sun/HP implementation as well as the ability to create a standalone debug info file. Thanks for the clarifications. I based my comments on a description you sent me a couple of years ago, and I apologize for any oversimplifications I introduced. The compiler puts DWARF in the .o file, the linker adds some records in the executable which help us to understand where files/function/symbols landed in the final executable[1]. Did you intend to add a footnote? If the user runs our gdb or lldb on one of these binaries, the debugger will read the DWARF directly out of the .o files on the fly. Because the linker doesn't need to copy around/update/modify the DWARF, link times are very fast. If the developer decides to debug the program, no extra steps are required - the debugger can be started up used with the debug info still in the .o files. We're trying to achieve something very similar, but we have the additional goal of separating the info from the .o files because of our distributed build environment. I also wanted to attempt to standardize the approach, instead of having each vendor go in separate directions. Thanks, -cary
Re: misbehaviour with md5_process_bytes and maybe in optimization
Thanks for your interest, I just checked revision 179127 of GCC. Last revision is 177700, it has not been change for 6 weeks. My file is the same as this one: http://gcc.gnu.org/viewcvs/trunk/libiberty/md5.c?revision=177700view=markup in libiberty/md5.c, function md5_process_bytes start line 203. On 23/09/2011 17:13, Ian Lance Taylor wrote: Pierre Vittet pier...@pvittet.com writes: The bug appears when: 1) We use libiberty compiled with -O0 2) We first call md5_process_bytes with a less than 64 bits buffer (we call his size len1). 3) We make a new call of md5_process_bytes with a buffer which has a size len2 such as: len2 127 + 65 (so test in line 228 of md5.C will be true) line 228 is the following:if (len 64) 128 -len1 != Mulint with Mulint % __alignof__ (md5_uint32) != 0 (so condition on line 238 is true) line 238 is the following: if (UNALIGNED_P (buffer)) len2 - (128 - len1) = Mul64 and Mul64 such as Mul %64=0 (so the loop of line 239 is broken with len = 64, this leads to the bug as, line 249, (len ~63) = 64 and we shift the buffer without processing the data). line 239 is the following: while (len 64) line 249: buffer = (const void *) ((const char *) buffer + (len ~63)); The line numbers you mention do not correspond to any version of libiberty/md5.c that I can see. Can you list the exact line for each line number you mention, so that your explanation is easier to follow? Thanks. I give about the same explanation in the README (which is in the attached archive of my previous mail) but I does not use line number but direct quote of the code. It mights be more easy to try the plugin with gdb but it needs to compile libiberty.a with -O0. Ian
Re: misbehaviour with md5_process_bytes and maybe in optimization
Pierre Vittet pier...@pvittet.com writes:
Thanks for your interest,
I just checked revision 179127 of GCC. Last revision is 177700, it has
not been change for 6 weeks.
My file is the same as this one:
http://gcc.gnu.org/viewcvs/trunk/libiberty/md5.c?revision=177700view=markup
in libiberty/md5.c, function md5_process_bytes start line 203.
On 23/09/2011 17:13, Ian Lance Taylor wrote:
Pierre Vittet pier...@pvittet.com writes:
The bug appears when:
1) We use libiberty compiled with -O0
2) We first call md5_process_bytes with a less than 64 bits buffer (we
call his size len1).
3) We make a new call of md5_process_bytes with a buffer which has a
size len2 such as:
len2 127 + 65 (so test in line 228 of md5.C will be true)
line 228 is the following:if (len 64)
128 -len1 != Mulint with Mulint % __alignof__ (md5_uint32) != 0 (so
condition on line 238 is true)
line 238 is the following: if (UNALIGNED_P (buffer))
len2 - (128 - len1) = Mul64 and Mul64 such as Mul %64=0 (so the loop of
line 239 is broken with len = 64, this leads to the bug as, line 249,
(len ~63) = 64 and we shift the buffer without processing the data).
line 239 is the following: while (len 64)
line 249: buffer = (const void *) ((const char *) buffer + (len ~63));
The line numbers you mention do not correspond to any version of
libiberty/md5.c that I can see. Can you list the exact line for each
line number you mention, so that your explanation is easier to follow?
Thanks.
I give about the same explanation in the README (which is in the
attached archive of my previous mail) but I does not use line number but
direct quote of the code. It mights be more easy to try the plugin with
gdb but it needs to compile libiberty.a with -O0.
Thanks, I think I have it sorted out now.
It does not happen on x86 glibc-based systems at -O2 because at -O2
string.h #defines STRING_ARCH_unaligned, so the problematic code is
not compiled or executed.
The error was introduced by this change:
2005-07-03 Steve Ellcey s...@cup.hp.com
PR other/13906
* md5.c (md5_process_bytes): Check alignment.
Thanks for noticing this problem, analyzing it, and reporting it.
I committed this patch to mainline to fix the problem. Bootstrapped on
x86_64-unknown-linux-gnu.
Ian
2011-09-23 Ian Lance Taylor i...@google.com
* md5.c (md5_process_bytes): Correct handling of unaligned
buffer.
Index: md5.c
===
--- md5.c (revision 179127)
+++ md5.c (working copy)
@@ -1,6 +1,6 @@
/* md5.c - Functions to compute MD5 message digest of files or memory blocks
according to the definition of MD5 in RFC 1321 from April 1992.
- Copyright (C) 1995, 1996 Free Software Foundation, Inc.
+ Copyright (C) 1995, 1996, 2011 Free Software Foundation, Inc.
NOTE: This source is derived from an old version taken from the GNU C
Library (glibc).
@@ -245,9 +245,11 @@ md5_process_bytes (const void *buffer, s
}
else
#endif
- md5_process_block (buffer, len ~63, ctx);
- buffer = (const void *) ((const char *) buffer + (len ~63));
- len = 63;
+ {
+ md5_process_block (buffer, len ~63, ctx);
+ buffer = (const void *) ((const char *) buffer + (len ~63));
+ len = 63;
+ }
}
/* Move remaining bytes in internal buffer. */
Re: Incorrect optimized (-O2) linked list code with 4.3.2
On Mon, Sep 12, 2011 at 10:10 AM, pavan tc pavan...@gmail.com wrote:
Hi,
I would like to know if there have been issues with optimized linked
list code with GCC 4.3.2. [optiimization flag : -O2]
The following is the inlined code that has the problem:
static inline void
list_add_tail (struct list_head *new, struct list_head *head)
{
new-next = head;
new-prev = head-prev;
new-prev-next = new;
new-next-prev = new;
}
The above code has been used in the loop as below:
pool = GF_CALLOC (count, padded_sizeof_type, gf_common_mt_long);
if (!pool) {
GF_FREE (mem_pool);
return NULL;
}
for (i = 0; i count; i++) {
list = pool + (i * (padded_sizeof_type));
INIT_LIST_HEAD (list);
list_add_tail (list, mem_pool-list);
}
'mem_pool- list' is used as the list head. mem_pool is a pointer to type :
struct mem_pool {
struct list_head list;
int hot_count;
int cold_count;
gf_lock_t lock;
unsigned long padded_sizeof_type;
void *pool;
void *pool_end;
int real_sizeof_type;
};
'list' is the new member being added to the tail of the list pointed to by
head.
It is a pointer to type:
struct list_head {
struct list_head *next;
struct list_head *prev;
};
The generated assembly for the loop (with the linined list_add_tail())
is as below:
40a1c: e8 0f 03 fd ff callq 10d30 __gf_calloc@plt
40a21: 48 85 c0 test %rax,%rax
40a24: 48 89 c7 mov %rax,%rdi
40a27: 0f 84 bf 00 00 00 je 40aec mem_pool_new_fn+0x14c
40a2d: 48 8b 73 08 mov 0x8(%rbx),%rsi
40a31: 4d 8d 44 24 01 lea 0x1(%r12),%r8
40a36: 31 c0 xor %eax,%eax
40a38: b9 01 00 00 00 mov $0x1,%ecx
40a3d: 0f 1f 00 nopl (%rax)
40a40: 49 0f af c5 imul %r13,%rax
=== loop start
40a44: 48 8d 04 07 lea (%rdi,%rax,1),%rax
40a48: 48 89 18 mov %rbx,(%rax)
# list-next = head
40a4b: 48 89 06 mov %rax,(%rsi)
# !! head-prev-next = list
40a4e: 48 8b 10 mov (%rax),%rdx
# rdx holds list-next
40a51: 48 89 70 08 mov %rsi,0x8(%rax) #
list-prev = head-prev;
40a55: 48 89 42 08 mov %rax,0x8(%rdx) #
list-next-prev = list
40a59: 48 89 c8 mov %rcx,%rax
40a5c: 48 83 c1 01 add $0x1,%rcx
40a60: 4c 39 c1 cmp %r8,%rcx
40a63: 75 db jne 40a40 mem_pool_new_fn+0xa0
In the assembly above, %rbx holds the address of 'head'.
%rsi holds the value of head-prev. This is assigned outside the loop and the
compiler classifies it as a loop invariant, which is where, I think,
the problem is.
This line of code should have been inside the loop.
!! - %rsi still holds the value of head-prev that was assigned
outside the loop.
The following experiments eliminate the problem:
1. Using 'volatile' on the address that 'head' points to.
2. Using a function call (logging calls, for example) inside the loop.
3. Using the direct libc calloc instead of the GF_CALLOC.
[GF_CALLOC does some accounting when accounting is enabled. Calls vanilla
libc calloc() otherwise].
So, anything that necessitates a different usage of %rsi seems to be
correcting
the behaviour.
4. Using gcc 4.4.3 [ The obvious solution would then be to use 4.4.3,
but I would
like to understand if this is a known problem with 4.3.2. Small
programs written to
emulate this problem do not exhibit the erroneous behaviour.]
Please let me know if any more details about this behaviour are required.
I'll be glad to provide them.
Use -fno-strict-aliasing. Your code invokes undefined behavior.
TIA,
Pavan
Re: A case that PRE optimization hurts performance
On Fri, Sep 16, 2011 at 4:00 AM, Jiangning Liu jiangning@arm.com wrote:
Hi Richard,
I slightly changed the case to be like below,
int f(char *t) {
int s=0;
while (*t s != 1) {
switch (s) {
case 0: /* path 1 */
s = 2;
break;
case 2: /* path 2 */
s = 3; /* changed */
break;
default: /* path 3 */
if (*t == '-')
s = 2;
break;
}
t++;
}
return s;
}
-O2 is still worse than -O2 -fno-tree-pre.
-O2 -fno-tree-pre result is
f:
pushl %ebp
xorl %eax, %eax
movl %esp, %ebp
movl 8(%ebp), %edx
movzbl (%edx), %ecx
jmp .L14
.p2align 4,,7
.p2align 3
.L5:
movl $2, %eax
.L7:
addl $1, %edx
cmpl $1, %eax
movzbl (%edx), %ecx
je .L3
.L14:
testb %cl, %cl
je .L3
testl %eax, %eax
je .L5
cmpl $2, %eax
.p2align 4,,5
je .L17
cmpb $45, %cl
.p2align 4,,5
je .L5
addl $1, %edx
cmpl $1, %eax
movzbl (%edx), %ecx
jne .L14
.p2align 4,,7
.p2align 3
.L3:
popl %ebp
.p2align 4,,2
ret
.p2align 4,,7
.p2align 3
.L17:
movb $3, %al
.p2align 4,,3
jmp .L7
While -O2 result is
f:
pushl %ebp
xorl %eax, %eax
movl %esp, %ebp
movl 8(%ebp), %edx
pushl %ebx
movzbl (%edx), %ecx
jmp .L14
.p2align 4,,7
.p2align 3
.L5:
movl $1, %ebx
movl $2, %eax
.L7:
addl $1, %edx
testb %bl, %bl
movzbl (%edx), %ecx
je .L3
.L14:
testb %cl, %cl
je .L3
testl %eax, %eax
je .L5
cmpl $2, %eax
.p2align 4,,5
je .L16
cmpb $45, %cl
.p2align 4,,5
je .L5
cmpl $1, %eax
setne %bl
addl $1, %edx
testb %bl, %bl
movzbl (%edx), %ecx
jne .L14
.p2align 4,,7
.p2align 3
.L3:
popl %ebx
popl %ebp
ret
.p2align 4,,7
.p2align 3
.L16:
movl $1, %ebx
movb $3, %al
jmp .L7
You may notice that register ebx is introduced, and some more instructions
around ebx are generated as well. i.e.
setne %bl
testb %bl, %bl
I agree with you that in theory PRE does the right thing to minimize the
computation cost on gimple level. However, the problem is the cost of
converting comparison result to a bool value is not considered, so it
actually makes binary code worse. For this case, as I summarized below, to
complete the same functionality With PRE is worse than Without PRE for
all three paths,
* Without PRE,
Path1:
movl $2, %eax
cmpl $1, %eax
je .L3
Path2:
movb $3, %al
cmpl $1, %eax
je .L3
Path3:
cmpl $1, %eax
jne .L14
* With PRE,
Path1:
movl $1, %ebx
movl $2, %eax
testb %bl, %bl
je .L3
Path2:
movl $1, %ebx
movb $3, %al
testb %bl, %bl
je .L3
Path3:
cmpl $1, %eax
setne %bl
testb %bl, %bl
jne .L14
Do you have any more thoughts?
It seems to me that with PRE all the testb %bl, %bl
should be evaluated at compile-time considering the
preceeding movl $1, %ebx. Am I missing something?
Richard.
Thanks,
-Jiangning
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: Tuesday, August 02, 2011 5:23 PM
To: Jiangning Liu
Cc: gcc@gcc.gnu.org
Subject: Re: A case that PRE optimization hurts performance
On Tue, Aug 2, 2011 at 4:37 AM, Jiangning Liu jiangning@arm.com
wrote:
Hi,
For the following simple test case, PRE optimization hoists
computation
(s!=1) into the default branch of the switch statement, and finally
causes
very poor code generation. This problem occurs in both X86 and ARM,
and I
believe it is also a problem for other targets.
int f(char *t) {
int s=0;
while (*t s != 1) {
switch (s) {
case 0:
s = 2;
break;
case 2:
s = 1;
break;
default:
if (*t == '-')
s = 1;
break;
}
t++;
}
return s;
}
Taking X86 as an example, with option -O2 you may find 52
instructions
generated like below,
f:
0: 55 push %ebp
1: 31 c0 xor %eax,%eax
3: 89 e5 mov %esp,%ebp
Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)
On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote: The compiler puts DWARF in the .o file, the linker adds some records in the executable which help us to understand where files/function/symbols landed in the final executable[1]. Did you intend to add a footnote? Yeah, I realized after I sent the email - it didn't seem interesting enough to warrant a separate followup. The records that our linker puts in the executable are in the form of stabs entries. There are a handful of stabs records created - file start, file end, function start, function end, symbol, pointer to a .o file, maybe one or two others. We chose that format because it was trivial to support and we already had tools for stripping these records out of the executable once the dSYM had been created. Once a dSYM has been created with all of the DWARF collected in a single file, our DWARF is parseable by any debug info consumer with minimal changes -- they need to know to look in a separate file for the DWARF from the main executable, but the format itself is unchanged. Supporting the debug-information-in-.o-files is more involved, I don't know if any of the third-party debuggers on our platform work with it. We're trying to achieve something very similar, but we have the additional goal of separating the info from the .o files because of our distributed build environment. I also wanted to attempt to standardize the approach, instead of having each vendor go in separate directions. Yeah, if your regular build environment involves distributed compilation, and the .o files need to be copied to a central system for the linker, then I can see why you're pursuing this approach. For us, the most common usage is single-computer compilation linking -- where the linker never pages in the debug info sections from the .o files so their size is not particular important. J
Re: [Dwarf-Discuss] RFC: DWARF Extensions for Separate Debug Info Files (Fission)
Hi Jason, Jason Molenda wrote: On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote: The compiler puts DWARF in the .o file, the linker adds some records in the executable which help us to understand where files/function/symbols landed in the final executable[1]. Did you intend to add a footnote? Yeah, I realized after I sent the email - it didn't seem interesting enough to warrant a separate followup. The records that our linker puts in the executable are in the form of stabs entries. There are a handful of stabs records created - file start, file end, function start, function end, symbol, pointer to a .o file, maybe one or two others. We chose that format because it was trivial to support and we already had tools for stripping these records out of the executable once the dSYM had been created. I don't remember the exact details, but the problem I recall with the Darwin scheme is that it builds an incomplete index in the Mach-O symbol table. IIRC, it was missing things that a user might want to lookup by-name in the debugger, like static functions or variables, and type names with external linkage. Without a reasonably complete index, the debugger can't know where to find the definitions of certain things, and that forces the user to navigate using other information, like source file name or global function definitions to force the debug information in the object to be read. Of course, the current DWARF indexes (like pubnames/pubtypes) have the same problem, and some compilers do a really bad job at generating those sections. But at least when there's a single .debug_info section, the debugger can decide to ignore the indexes and skim the full debug information. The compilers on IRIX did a better job at generating indexes, so the debugger could find by-name static functions/objects. Once a dSYM has been created with all of the DWARF collected in a single file, our DWARF is parseable by any debug info consumer with minimal changes -- they need to know to look in a separate file for the DWARF from the main executable, but the format itself is unchanged. Supporting the debug-information-in-.o-files is more involved, I don't know if any of the third-party debuggers on our platform work with it. TotalView supports debug information in .o files on Darwin, and has since day one. Perhaps you recall all those email exchanges you and I had several years back. It was a modest amount of work, given that we already supported debug information in .o files on the Sun and HP platforms. I seem to recall one of the sore spots for us on Dawrin was getting good address information for certain DWARF location operations, like DW_OP_addr. Fortran was a particularly messy because some compilers didn't supply a linkage name attribute, so the debugger had to make several guesses at the name, and look things up by trial and error. Cheers, John D. We're trying to achieve something very similar, but we have the additional goal of separating the info from the .o files because of our distributed build environment. I also wanted to attempt to standardize the approach, instead of having each vendor go in separate directions. Yeah, if your regular build environment involves distributed compilation, and the .o files need to be copied to a central system for the linker, then I can see why you're pursuing this approach. For us, the most common usage is single-computer compilation linking -- where the linker never pages in the debug info sections from the .o files so their size is not particular important. J ___ Dwarf-Discuss mailing list dwarf-disc...@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
AIX libstdc++ missing symbols
My latest bootstrap of GCC on AIX failed due to missing symbols in libstdc++ expected by libgmpxx: exec(): 0509-036 Cannot load program exec(): 0509-036 Cannot load program /tmp/20110922/./gcc/cc1plus/tmp/20110922/./g cc/cc1plus because of the following errors: because of the following errors: 0509-130 Symbol resolution failed for 0509-130 Symbol resolution failed for /usr/gnu/lib/libgmpxx.a(libgmpxx .so.4)/usr/gnu/lib/libgmpxx.a(libgmpxx.so.4) because: because: 0509-136 Symbol 0509-136 Symbol _ZNSt6localeD1Ev_ZNSt6localeD1Ev (number (number 44) is not exporte d from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). . 0509-136 Symbol 0509-136 Symbol _ZNSt6localeC1ERKS__ZNSt6localeC1ERKS_ (number (number 66) is not e xported from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). . 0509-136 Symbol 0509-136 Symbol _ZNSt8ios_base4InitD1Ev_ZNSt8ios_base4InitD1Ev (number (number 1010 ) is not exported from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). . 0509-136 Symbol 0509-136 Symbol _ZNSt8ios_base4InitC1Ev_ZNSt8ios_base4InitC1Ev (number (number ) is not exported from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). Any idea what has changed and why those symbols no longer are exported by libstdc++? This seems like a libstdc++ ABI change if they really disappeared. Thanks, David
Re: AIX libstdc++ missing symbols
On 09/24/2011 12:23 AM, David Edelsohn wrote: My latest bootstrap of GCC on AIX failed due to missing symbols in libstdc++ expected by libgmpxx: On x86_64-linux are both still exported. And for sure nobody worked on the code itself. I would say, it's a compiler issue.. Paolo.
gcc-4.6-20110923 is now available
Snapshot gcc-4.6-20110923 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110923/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 179133 You'll find: gcc-4.6-20110923.tar.bz2 Complete GCC MD5=85f2513ed81259e02029c7b20e0a53bb SHA1=bdef841f21d3e2753bc7f5fad8505eef500456b3 Diffs from 4.6-20110916 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
[Bug c++/49433] internal compiler error: in write_builtin_type, at cp/mangle.c:2167
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49433 Vasiliy vash at vasiliyshlykov dot org changed: What|Removed |Added CC||vash at vasiliyshlykov dot ||org --- Comment #1 from Vasiliy vash at vasiliyshlykov dot org 2011-09-23 06:11:44 UTC --- Same result on PowerPC with gcc 4.6.1: /usr/lib/gcc/powerpc-lynx-lynxos/4.6.1/../../../../powerpc-lynx-lynxos/include/boost/lexical_cast.hpp: In instantiation of 'bool boost::detail::lexical_stream_limited_srcCharT, Base, Traits::operator(long double) [with CharT = char, Base = std::basic_streambufchar, Traits = std::char_traitschar]': conversion.cpp:45:1: instantiated from here /usr/lib/gcc/powerpc-lynx-lynxos/4.6.1/../../../../powerpc-lynx-lynxos/include/boost/lexical_cast.hpp:971:21: internal compiler error: in write_builtin_type, at cp/mangle.c:2167 This only appears with -O2 -flto and passes -Os -flto. gcc -v: Using built-in specs. COLLECT_GCC=powerpc-lynx-lynxos-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-lynx-lynxos/4.6.1/lto-wrapper Target: powerpc-lynx-lynxos Configured with: ../src/configure --prefix=/usr --target=powerpc-lynx-lynxos --disable-nls --enable-multilib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-libstdcxx-pch --enable-plugin --disable-softfloat --with-tune=750 --with-system-zlib --enable-threads=posix Thread model: lynx gcc version 4.6.1 (GCC)
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-23
07:26:10 UTC ---
Looking at:
const char *str1 = JIHGFEDCBA;
#define strcpy(x,y) __builtin___strcpy_chk (x, y, __builtin_object_size (x, 1))
int
f1 (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
strcpy (a.buf1 + (0 + 4), str1 + 5);
return 0;
}
int
f2 (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
strcpy ((char *) a + (0 + 4), str1 + 5);
return 0;
}
int
f3 (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
char *p = (char *) a;
strcpy (p + (0 + 4), str1 + 5);
return 0;
}
int
f4 (void)
{
struct A { char buf0; char buf1[9]; char buf2[1]; } a;
char *p = (char *) a;
strcpy (p + (0 + 5), str1 + 5);
return 0;
}
int
f5 (void)
{
struct A { char buf0; char buf1[9]; char buf2[1]; } a;
strcpy ((char *) a + (0 + 5), str1 + 5);
return 0;
}
with GCC 4.4, seems we have always reconstructed it into a.buf1[4].
So likely we want to reconstruct it from the MEM_REF in the *.objsz pass then.
If there is union involved, we probably want to reconstruct it to the
alternative with the largest possible __builtin_object_size (X, 1) resp.
smallest possible __builtin_object_size (X, 3).
[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477 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-09-23 08:27:09 UTC --- So just use -Wno-unused-parameter if you want to give the arguments names, don't use them and don't like unused attribute. I don't see why inline methods, virtual or non-virtual, should be any different in this regard from any other functions.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #24 from Michael Meeks michael.meeks at suse dot com 2011-09-23 08:33:17 UTC --- I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Great - so, we wouldn't loose much by having the bridge compiled without optimisation - it is ultimately used to map C++ - Java or python so all performance is already shot by that stage ;-) bridges/source/cpp_uno/gcc3_linux_intel/call.s bridges/source/cpp_uno/gcc3_linux_x86-64/call.s are the places to dig - unfortunately there is -far- too much cut/paste going on in here, though we've done some work to try to share more IIRC. These snippets are used by cpp2uno.cxx - to build trampolines cf. 'codeSnippet' - which (I hope) should work fine, and by uno2cpp.cxx to invoke things eg. 'uno2cpp.cxx's callVirtualMethod - which has some fun assembler in each case. Does that help ?
[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477 --- Comment #4 from miles at gnu dot org 2011-09-23 08:59:47 UTC --- It's different because unlike most function/method definitions, this is _two_ things together -- a virtual method declaration, which pertains to this class and all subclasses, and a method definition, which only instead only really pertains to this class. Note that if you separate the definition and the declaration, there's no issue -- the definition can have the parameter name omitted, or use the unused attribute, and it makes perfect sense, both to the compiler, and to readers. But if one uses the inline definition, there's no way to separate these two uses; the compiler still understands of course; it's readers who are inconvenienced, because they see code obfuscation intended for the _definition_ when they read the code to see the _declaration_. If it were a simple function (or an out-of-line method definition, or a non-virtual method), I'd happily use attribute unused (or whatever), because it clearly does apply to the definition, and indeed makes the code more readable by documenting something. It's only in this case where two different things are mixed together that I'm uncomfortable doing so. I'm not denying that there are many ways to make the compiler happy; my complaint is that they all make the code less readable, and I think readability is important.
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov amonakov at gcc dot gnu.org 2011-09-23 09:30:01 UTC --- Does the problem vanish if you add -fno-strict-aliasing? One more thing, you mention -O2 in the flags, but then refer to selective scheduler, which is only enabled at -O3. Perhaps you meant Haifa scheduler.
[Bug c++/49433] internal compiler error: in write_builtin_type, at cp/mangle.c:2167
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49433 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 10:00:10 UTC --- I would say put a breakpoint on write_builtin_type and see what a heck is that type!
[Bug bootstrap/38607] AIX error messages about TOC during build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38607
Lukasz Filipkowski lukasz.filipkowski at gmail dot com changed:
What|Removed |Added
CC||lukasz.filipkowski at gmail
||dot com
--- Comment #15 from Lukasz Filipkowski lukasz.filipkowski at gmail dot com
2011-09-23 10:10:58 UTC ---
Hello,
regarding ld: 0711-768 WARNING when compiling:
#include string
#include map
void foo()
{
std::mapstd::string, std::string bar;
}
into rtl-enabled shared library. Warning is caused by code construction similar
to the one presented in the following example:
//g++ -save-temps -shared -Wl,-G -o libshare.so share.cc
#include iostream
#include string
using namespace std;
templatetypename Key class MyClass
{
public:
typedef Key KeyType;
MyClass(KeyType aNumber)
{
cout aNumber ! = factorial(aNumber) endl;
}
~MyClass(){}
private:
long factorial(KeyType __x);
long factorialHelper(KeyType __x);
};
templatetypename Key long MyClassKey::factorial(KeyType __x)
{
if (__x = 0) return 1;
else return __x * factorial(__x-1);
//else return __x * factorialHelper(__x-1);
}
templatetypename Key long MyClassKey::factorialHelper(KeyType __x)
{
return factorial(__x);
}
void foo()
{
MyClassint myClass(5);
}
$ g++ -save-temps -shared -Wl,-G -o libshare.so share.cc
ld: 0711-768 WARNING: Object share.o, section 1, function
.MyClassint::factorial(int):
The branch at address 0x36c is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7C691B78.
Example code is based on contents of stl_tree.h file in which class _Rb_tree is
defined.
Warning is generated in case creation of shared libraries using TEMPLATE
CLASSES with RECURSIVE METHODS.
In the presented example factorial method is a recursive one.
When modifying:
templatetypename Key long MyClassKey::factorial(KeyType __x)
{
if (__x = 0) return 1;
else return __x * factorial(__x-1);
//else return __x * factorialHelper(__x-1);
}
into:
templatetypename Key long MyClassKey::factorial(KeyType __x)
{
if (__x = 0) return 1;
//else return __x * factorial(__x-1);
else return __x * factorialHelper(__x-1);
}
there is no linker warning.
The _Rb_tree class, defined in stl_tree.h, contains _M_erase and _M_copy
methods, both recursive.
Warning is present when using both GCC4.4.5 and GCC4.6.1 on AIX 5300-11-03-1013
(AIX5.3 TL11 SP03)
When using assembler program (as) from AIX 5300-08-02-0822 (AIX5.3 TL08 SP02)
there is no warning generated.
I'm not sure but problematic warning might be a result of fixes similar to
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ24688
[Bug bootstrap/50492] New: Bootstrap failure on x86_64-apple-darwin10 when using --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 Bug #: 50492 Summary: Bootstrap failure on x86_64-apple-darwin10 when using --with-build-config=bootstrap-lto Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ebotca...@gcc.gnu.org, ia...@gcc.gnu.org, j...@suse.cz, t...@moene.org On x86_64-apple-darwin10 bootstrap fails when building gnat* at stage 2 if --with-build-config=bootstrap-lto is used in configure: /opt/gcc/build_l/./prev-gcc/g++ -B/opt/gcc/build_l/./prev-gcc/ -B/opt/gcc/gcc4.7l/x86_64-apple-darwin10.8.0/bin/ -nostdinc++ -B/opt/gcc/build_l/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/build_l/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -I/opt/gcc/build_l/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/opt/gcc/build_l/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/include -I/opt/gcc/_clean/libstdc++-v3/libsupc++ -L/opt/gcc/build_l/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/opt/gcc/build_l/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -g -O2 -mdynamic-no-pic -flto=jobserver -frandom-seed=1 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libgcc -static-libstdc++ -static-libgcc -o gnatbind ada/b_gnatb.o ada/adaint.o ada/argv.o ada/cio.o ada/cstreams.o ada/env.o ada/exit.o ada/final.o ada/init.o ada/initialize.o ada/link.o ada/raise.o ada/seh_init.o ada/targext.o ada/tracebak.o ada/ada.o ada/a-clrefi.o ada/a-comlin.o ada/a-elchha.o ada/a-except.o ada/ali-util.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/bcheck.o ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/butil.o ada/casing.o ada/csets.o ada/debug.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/fmap.o ada/fname.o ada/fname-uf.o ada/g-hesora.o ada/g-htable.o ada/s-os_lib.o ada/s-string.o ada/gnat.o ada/gnatbind.o ada/gnatvsn.o ada/hostparm.o ada/interfac.o ada/krunch.o ada/lib.o ada/namet.o ada/nlists.o ada/opt.o ada/osint-b.o ada/osint.o ada/output.o ada/restrict.o ada/rident.o ada/s-addope.o ada/s-assert.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-excdeb.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-parame.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strhas.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scng.o ada/scans.o ada/scil_ll.o ada/sdefault.o ada/sem_aux.o ada/sinfo.o ada/sinput.o ada/sinput-c.o ada/snames.o ada/stand.o ada/stringt.o ada/switch-b.o ada/switch.o ada/style.o ada/styleg.o ada/stylesw.o ada/system.o ada/table.o ada/targparm.o ada/tree_io.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/widechar.o ggc-none.o libcommon-target.a libcommon.a ../libcpp/libcpp.a -lintl -L/opt/sw64/lib -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -g -O2 -mdynamic-no-pic -flto=jobserver -frandom-seed=1 ada/b_gnatb.ads:8:4: warning: type of 'ada_main__gnat_envp' does not match original declaration [enabled by default] ../../_clean/gcc/ada/argv.c:65:14: note: previously declared here ../../_clean/gcc/ada/gnatbind.adb:480:7: warning: type of 'shared_libgnat_default' does not match original declaration [enabled by default] ../../_clean/gcc/ada/link.c:182:6: note: previously declared here ../../_clean/gcc/version.h:3:19: warning: type of 'version_string' does not match original declaration [enabled by default] ../../_clean/gcc/ada/gnatvsn.adb:57:4: note: previously declared here ../../_clean/gcc/ada/s-os_lib.adb:1092:7: warning: type of 'target_object_ext_ptr' does not match original declaration [enabled by default] ../../_clean/gcc/ada/targext.c:60:13: note: previously declared here ada/b_gnatb.adb:96:7: warning: type of 'task_dispatching_policy' does not match original declaration [enabled by default] ../../_clean/gcc/ada/init.c:98:7: note: previously declared here ada/b_gnatb.adb:104:7: warning: type of 'interrupt_states' does not match original declaration [enabled by default] ../../_clean/gcc/ada/init.c:101:7: note: previously declared here ../../_clean/gcc/ada/s-os_lib.adb:1062:7: warning: type of 'target_exec_ext_ptr' does not match original declaration [enabled by default] ../../_clean/gcc/ada/targext.c:61:13: note: previously declared here
[Bug target/50446] [avr] Implement rotate patterns with offset 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50446 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-23 10:14:26 UTC --- Author: gjl Date: Fri Sep 23 10:14:23 2011 New Revision: 179116 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179116 Log: PR target/50446 * config/avr/avr.md (rotlqi3): Support all offsets 0..7. (rotlqi3_4): Turn insn into expander. (*rotlqi3): New insn. (rotlhi3, rotlsi3): Support rotate left/right by 1. (*rotlhi2.1, *rotlhi2.15): New insns. (*rotlsi2.1, *rotlsi2.31): New insns. * config/avr/constraints.md (C03, C05, C06, C07): New constraints. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/constraints.md
[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #57 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-23 10:16:28 UTC --- I would appreciate some help with testing on Darwin 11 and with lto-bootstraps on Darwin 10 (since my resources are stretched to the limit right now). See pr50492 for bootstrap with --with-build-config=bootstrap-lto which blocks any testing of the patch with it. Without this option, the results are the same as those without the patch.
[Bug target/50446] [avr] Implement rotate patterns with offset 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50446 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-23 10:17:11 UTC --- Closed for 4.7 milestone.
[Bug c++/50108] [C++0x] Variadic templates with both type and non-type parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50108 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 11:03:05 UTC --- Invalid then.
[Bug c++/50400] compiler accepts invalid X::Impl::Impl::Impl::.....::foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50400 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 11:05:09 UTC --- Closing.
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23
11:27:49 UTC ---
Jason, what are we going to do about this? For the record, something like the
below would pass the testsuite...
///
Index: cp/decl.c
===
--- cp/decl.c (revision 179115)
+++ cp/decl.c (working copy)
@@ -7716,8 +7716,9 @@ check_static_variable_definition (tree decl, tree
else if (cxx_dialect = cxx0x !INTEGRAL_OR_ENUMERATION_TYPE_P (type))
{
if (literal_type_p (type))
- error (%constexpr% needed for in-class initialization of static
- data member %q#D of non-integral type, decl);
+ pedwarn (input_location, OPT_pedantic,
+%constexpr% needed for in-class initialization of static
+data member %q#D of non-integral type %qT, decl, type);
else
error (in-class initialization of static data member %q#D of
non-literal type, decl);
[Bug c++/50117] [C++0x] Segmentation fault when using std::make_pair with std::ofstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50117 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 11:47:00 UTC --- Worksforme with r179116. It you see it again, please re-open, thanks.
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.6.1 Keywords||ice-on-valid-code Last reconfirmed||2011-09-23 Component|bootstrap |lto Host||x86_64-*-* Ever Confirmed|0 |1 Summary|Bootstrap failure on|[4.7 regression] Ada |x86_64-apple-darwin10 when |bootstrap failure |using |--with-build-config=bootstr |--with-build-config=bootstr |ap-lto |ap-lto | Target Milestone|--- |4.7.0 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-23 11:59:06 UTC --- I can reproduce on Linux.
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-23 11:59:56 UTC --- Investigating.
[Bug c++/45993] ICE in uses_template_parms, at cp/pt.c:7064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45993 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.2, 4.7.0 Resolution||WORKSFORME --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:15:54 UTC --- Worksforme in current mainline and 4_6-branch.
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-23 12:18:03 UTC --- How about using a permerror instead? Since it's deprecated, requiring users to give -fpermissive if they want to use it in C++11 seems reasonable to me.
[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:26:37 UTC --- Let's close this.
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 --- Comment #3 from Iain Sandoe iains at gcc dot gnu.org 2011-09-23 12:28:21 UTC --- also on i686-darwin9.
[Bug c++/45855] switched ; and : causes compile crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45855 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:31:26 UTC --- Let's close this too, then.
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-23 12:39:03 UTC --- This is a duplicate of PR50279.
[Bug c++/45755] [C++0x] Member function template is instantiated to perform the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45755 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|Member function template is |[C++0x] Member function |instantiated to perform the |template is instantiated to |copy|perform the copy --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:41:24 UTC --- This is still behaving the same, and I can't believe GCC is still wrong vs the current C++0x, aka C++11. Can you double check?
[Bug c++/45382] internal compiler error: tree code ‘call_expr’ is not supported in gimple streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45382 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:42:38 UTC --- Let's close this.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #25 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-23 12:42:26 UTC --- New ICE with today's gcc and today's libreoffice: [ build PAG ] writer [ build LNK ] Executable/oosplash [ build LNK ] Library/libspl_unxlo.so [ build CMP ] desktop/unx/splash/splash [ build CMP ] desktop/unx/splash/splash [ build LNK ] Library/libevtattlo.so [ build CMP ] eventattacher/source/evtatt [ build CMP ] eventattacher/source/evtatt [ build LNK ] Library/libfileacc.so [ build CMP ] fileaccess/source/fileacc [ build CMP ] fileaccess/source/fileacc [ build LNK ] Library/libfrmlo.so [ build CMP ] forms/util/frm [ build CMP ] forms/util/frm [ build LNK ] Library/libforlo.so [ build CMP ] formula/util/for [ build CMP ] formula/util/for [ build LNK ] Library/libhwplo.so [ build CMP ] hwpfilter/source/hwp In file included from /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/solver/unxlngx6.pro/inc/cppu/unotype.hxx:3740:0, from :3330: /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx: In member function 'columnDropped': /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx:158:1: internal compiler error: in redirect_jump, at jump.c:1497 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [/var/tmp/portage/app-office/libreoffice--r1/temp/ccoLHzyy.ltrans2.ltrans.o] Error 1 make[2]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[1]: *** [/var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/workdir/unxlngx6.pro/LinkTarget/Library/libdbalo.so] Error 1 make[1]: *** Waiting for unfinished jobs...
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:43:53 UTC --- Closing as invalid.
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 12:45:43 UTC --- Of course would work for me.
[Bug c++/45755] [C++0x] Member function template is instantiated to perform the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45755 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-23 12:55:23 UTC --- That wording was changed to clarify that it means a template will never be instantiated to produce S::S(S), it does not mean a template cannot be used to perform copies, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1080 I beleive G++ is correct here, the constructor is instantied with T = S, to produce S::S(S) which is a valid constructor for copy-initialization
[Bug c++/45755] [C++0x] Member function template is instantiated to perform the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45755 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-23 12:56:54 UTC --- ... so I think this is a dup of PR 46004
[Bug c++/46004] [C++0x] template constructor used to copy object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46004 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||boostcpp at gmail dot com --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-23 12:58:17 UTC --- *** Bug 45755 has been marked as a duplicate of this bug. ***
[Bug c++/45755] [C++0x] Member function template is instantiated to perform the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45755 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-23 12:58:16 UTC --- . *** This bug has been marked as a duplicate of bug 46004 ***
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-09-23 13:07:33 UTC --- permerror sounds good to me.
[Bug c++/45755] [C++0x] Member function template is instantiated to perform the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45755 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 13:09:22 UTC --- Ah, great, quite misleading indeed.
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-23 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 13:13:28 UTC --- Ok, let me test that + testcase.
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 --- Comment #2 from Paulo J. Matos Paulo.Matos at csr dot com 2011-09-23 13:18:10 UTC --- (In reply to comment #1) Duplicate of PR50078? Might be but I can't confirm. Surely we will know once Mat fixes PR50078.
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 Paulo J. Matos Paulo.Matos at csr dot com changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #3 from Paulo J. Matos Paulo.Matos at csr dot com 2011-09-23 13:19:33 UTC --- Richard raised concerns about this PR being an old bug and already fixed. Initially I only confirmed it in 4.6.1 but I can reproduce it in git head 36181f98f (that's from 30mins ago).
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 Paulo J. Matos Paulo.Matos at csr dot com changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #3 from Paulo J. Matos Paulo.Matos at csr dot com 2011-09-23 13:20:57 UTC --- Richard raised concerns about this PR being an old bug and already fixed. Initially I only confirmed it in 4.6.1 but I can reproduce it in git head 36181f98f (that's from 30mins ago).
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 --- Comment #4 from Paulo J. Matos Paulo.Matos at csr dot com 2011-09-23 13:22:15 UTC --- (In reply to comment #3) Richard raised concerns about this PR being an old bug and already fixed. Initially I only confirmed it in 4.6.1 but I can reproduce it in git head 36181f98f (that's from 30mins ago). Ignore previous comment. Wrong bug.
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-23 13:29:23 UTC --- I believe I fixed this one, will double check.
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-23 13:33:00 UTC --- Seems it is indeed fixed.
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #7 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-09-23 13:34:52 UTC --- This problem popped up when compiling LLVM's libc++: M:\Development\Source\libc++\src\locale.cpp:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default] M:\Development\Source\libc++\include/locale: In function 'int std::__1::__asprintf_l(char**, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:372:5: sorry, unimplemented: function 'int std::__1::__asprintf_l(char**, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__sprintf_l(char*, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:344:5: sorry, unimplemented: function 'int std::__1::__sprintf_l(char*, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__snprintf_l(char*, size_t, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:358:5: sorry, unimplemented: function 'int std::__1::__snprintf_l(char*, size_t, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__sscanf_l(const char*, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:386:5: sorry, unimplemented: function 'int std::__1::__sscanf_l(const char*, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists The code can be found here: http://llvm.org/svn/llvm-project/libcxx/trunk/include/locale
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2011-09-23 13:40:55 UTC --- This problem popped up when compiling LLVM's libc++: M:\Development\Source\libc++\src\locale.cpp:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default] M:\Development\Source\libc++\include/locale: In function 'int std::__1::__asprintf_l(char**, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:372:5: sorry, unimplemented: function 'int std::__1::__asprintf_l(char**, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__sprintf_l(char*, _locale_t, const char*, ...)': It seems wrong to add always_inline attribute on something like this. I am not aware that LLVM would be inlining variadic function either (even though it is doable in some trivial cases) Honza
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 --- Comment #9 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-09-23 13:46:27 UTC --- Current Clang compiled everything without a hitch. It might ignore the attribute, I haven't checked. Perhaps this error should be made a warning?
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-23
13:59:07 UTC ---
(In reply to comment #6)
Honestly, nothing similar will happen any time soon, it means changing
completely the semantics of templates. Maybe we can produce a better
diagnostics, let's add Manuel in CC to hear his opinion...
The code is invalid but the diagnostic could be much better (I only have GCC
4.5.2, so perhaps it is better in trunk).
Smaller testcase:
templatetypename T
class MISC{
public:
T vec1;
templateT* vc void addVecVals(){};
void add(void) { addVecValsvec1(); };
};
void foo(void) {
MISCint m;
m.add();
}
Clang++ gives a somewhat better message:
/tmp/webcompile/_14512_0.cc:6:22: error: no matching member function for call
to 'addVecVals'
void add(void) { addVecValsvec1(); };
^
/tmp/webcompile/_14512_0.cc:11:7: note: in instantiation of member function
'MISCint::add' requested here
m.add();
^
/tmp/webcompile/_14512_0.cc:5:26: note: candidate template ignored: invalid
explicitly-specified argument for template parameter 'vc'
templateT* vc void addVecVals(){};
^
1 error generated.
I would argue for reopening it...
Re: [Bug tree-optimization/10980] vararg functions are not inlined
I bet it just ignores the attribute that is not how the attribute is supposed to work. We output error in this case intentionally (and warning in at the same spot if function is declared inline and -Winline is given). Functions marked always_inlined really ought to be always inlined and attribute is supposed to be useable in the cases where compilation would fail otherwise (such as SSE buitins). Our documentation is however not particularly clear here, perhaps it should be updated... Honza
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 --- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2011-09-23 14:10:53 UTC --- I bet it just ignores the attribute that is not how the attribute is supposed to work. We output error in this case intentionally (and warning in at the same spot if function is declared inline and -Winline is given). Functions marked always_inlined really ought to be always inlined and attribute is supposed to be useable in the cases where compilation would fail otherwise (such as SSE buitins). Our documentation is however not particularly clear here, perhaps it should be updated... Honza
[Bug target/50493] New: ICE in neon_disambiguate_copy, at config/arm/arm.c:20388
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50493 Bug #: 50493 Summary: ICE in neon_disambiguate_copy, at config/arm/arm.c:20388 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: x86_64-linux-gnu Target: arm-unknown-linux-gnueabi Build: x86_64-linux-gnu Created attachment 25347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25347 preprocessed source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnueabi Configured with: ../configure --target=arm-unknown-linux-gnueabi --prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --disable-multilib --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared --disable-libmudflap --disable-libssp Thread model: posix gcc version 4.7.0 20110923 (experimental) [trunk revision 179117] (GCC) $ ./xgcc -B. -O3 -mfpu=neon -mfloat-abi=softfp ~/ice.i -fpic /home/ryan/ice.i: In function 'SetupUSEVertexShader': /home/ryan/ice.i:342:38: warning: incompatible implicit declaration of built-in function 'calloc' [enabled by default] /home/ryan/ice.i:353:1: internal compiler error: in neon_disambiguate_copy, at config/arm/arm.c:20388 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/50494] New: gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Bug #: 50494
Summary: gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc
with -flto
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
The testcase contains 2 char array initializers:
...
__attribute__ ((noinline))
void main1 (signed char x, signed char max_result, signed char min_result)
{
int i;
signed char b[N] = {1,2,3,6,8,10,12,14,16,18,20,22,24,26,28,30};
signed char c[N] = {1,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
...
The initializer data is put into .rodata, and copied to stack at the start of
the function by 2 blockmoves.
When we do expand_block_move during cc1, the blockmove source looks like this
as a tree:
...
var_decl 0xf7e37180 *.LC0
type array_type 0xf7e317e0
type integer_type 0xf7d53180 signed char sizes-gimplified public
string-flag QI
size integer_cst 0xf7d406c8 constant 8
unit size integer_cst 0xf7d406e4 constant 1
align 8 symtab 0 alias set 0 canonical type 0xf7d53180 precision 8
min integer_cst 0xf7d40674 -128 max integer_cst 0xf7d406ac 127
pointer_to_this pointer_type 0xf7e31840
sizes-gimplified BLK
size integer_cst 0xf7d409f4 constant 128
unit size integer_cst 0xf7d40a10 constant 16
align 8 symtab 0 alias set 0 canonical type 0xf7e317e0
domain integer_type 0xf7e1ff00 type integer_type 0xf7d53000 sizetype
sizes-gimplified SI
size integer_cst 0xf7d40508 constant 32
unit size integer_cst 0xf7d40524 constant 4
align 32 symtab 0 alias set -1 canonical type 0xf7e1ff00 precision
32 min integer_cst 0xf7d40540 0 max integer_cst 0xf7e1c524 15
pointer_to_this pointer_type 0xf7e37780
readonly used static ignored in-constant-pool BLK file (null) line 0 col 0
size integer_cst 0xf7d409f4 128 unit size integer_cst 0xf7d40a10 16
user align 128 initial constructor 0xf7db5860
(mem/s/c:BLK (symbol_ref/f:SI (*.LC0) [flags 0x82] var_decl 0xf7e37180
*.LC0) [1 S16 A8])
...
and like this as rtl:
...
(mem/s/c:BLK (reg/f:SI 180) [1 S16 A8])
...
This case is chosen in expand_block_move, and the blockmoves are expanded as
4-byte wordmoves.
...
else if (bytes = 4 (align = 32 || !STRICT_ALIGNMENT))
{/* move 4 bytes */
move_bytes = 4;
mode = SImode;
gen_func.mov = gen_movsi;
}
...
The .rodata section written by cc1 has align 2^4 == 16 bytes.
...
.section.rodata
.align 4
.set.LANCHOR0,. + 0
.LC0:
.byte1
.byte2
...
However, when we do expand_block_move during lto1, the blockmove source looks
like this as a tree:
...
mem_ref 0xf7dc76c8
type array_type 0xf7dc67e0
type integer_type 0xf7d51180 signed char public string-flag QI
size integer_cst 0xf7d4071c constant 8
unit size integer_cst 0xf7d40738 constant 1
align 8 symtab 0 alias set -1 canonical type 0xf7d51180 precision 8
min integer_cst 0xf7d406ac -128 max integer_cst 0xf7d40700 127
pointer_to_this pointer_type 0xf7dce8a0
BLK
size integer_cst 0xf7d40a48 constant 128
unit size integer_cst 0xf7d40a64 constant 16
align 8 symtab 0 alias set 0 canonical type 0xf7dc67e0
domain integer_type 0xf7dc6840 type integer_type 0xf7d51000 sizetype
SI
size integer_cst 0xf7d40524 constant 32
unit size integer_cst 0xf7d40540 constant 4
align 32 symtab 0 alias set -1 canonical type 0xf7d51360 precision
32 min integer_cst 0xf7d4055c 0 max integer_cst 0xf7dc7118 15
pointer_to_this pointer_type 0xf7dc6a20
readonly
arg 0 addr_expr 0xf7dc0a38
type pointer_type 0xf7dc6a20 type array_type 0xf7dc67e0
public unsigned SI size integer_cst 0xf7d40524 32 unit size
integer_cst 0xf7d40540 4
align 32 symtab 0 alias set -1 canonical type 0xf7dc6a20
readonly constant
arg 0 var_decl 0xf7dc6780 *.LC0 type array_type 0xf7dc67e0
readonly used static ignored in-constant-pool BLK file (null) line
0 col 0 size integer_cst 0xf7d40a48 128 unit size integer_cst 0xf7d40a64 16
user align 128 initial constructor 0xf7dc51f0
(mem/s/c:BLK (symbol_ref/f:SI (*.LC0) [flags 0x82] var_decl
0xf7dd9060 *.LC0) [1 S16 A8])
arg 1 integer_cst 0xf7dc76e4 type pointer_type 0xf7dc6a20 constant 0
/scratch/vries/b6/pr43864.42.all-fsf-mainline-powerpc-linux-gnu.cfg/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-2char.c:11:15
...
and like this as rtx:
...
(mem/s/u/c:BLK (reg/f:SI 180) [0 *.LC0+0 S16 A128])
...
This case is now chosen in expand_block_move, and the blockmoves are expanded
as 16-byte
[Bug c++/44906] g++ is giving error: parse error in template argument list while using a c++ code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2011-09-23 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 14:43:26 UTC --- Hey, you woke up! ;) Sure, let's re-open is a diagnostic issue, your call.
[Bug c++/50495] New: Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495
Bug #: 50495
Summary: Optimize exact matches in overload resolution
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@gaunard.com
Overload resolution in GCC (and in C++ in general) is quite slow, and I would
like to suggest the following enhancement: look-up (in constant or logarithmic
time) for exact matches first, then perform regular overload resolution if
necessary.
The idea is that
struct id_0 {};
void f(id_0);
struct id_1;
void f(id_1) {};
...
and then calling
f(id_x());
should be as fast as
void f_0();
void f_1();
...
and then calling
f_x();
Now if this could be made to work for things like
struct h0 {};
struct h1 : h0 {};
struct id_0 {};
templateclass T void f(id_0, h0T);
templateclass T void f(id_0, h1T);
to reduce the set of possible overloads to 2 early (templates inserted to make
it non-absolutely orderable), that would be perfect.
According to my benchmarks, resolving a function with an exact match on the
first argument among 1,000 tags with 10 overloads each takes 30s, while with
1,000 differently named functions of 10 overloads each it takes 100ms.
[Bug target/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #1 from vries at gcc dot gnu.org 2011-09-23 14:52:55 UTC --- Created attachment 25348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25348 test.c minimized from gcc.dg/vect/vect-reduc-2char.c To reproduce: $ powerpc-linux-gnu-gcc -O2 -ftree-vectorize test.c -flto -maltivec -static $ ./a.out ; echo $? 218 The problematic code is still generated without -static, but for me this minimal testcase does not fail runtime without the -static.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 14:54:15 UTC --- At some point Jason mentioned that other improvements were in principle possible beyond those already implemented relatively recently. No idea if this has been considered already...
[Bug target/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #2 from vries at gcc dot gnu.org 2011-09-23 15:05:19 UTC --- Same issue occurs for gcc.dg/vect/pr44507.c with -m64.
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2011-09-23 15:06:41 UTC --- two more data points: 1/ powerpc-darwin9 also fails, so this is not x86-centric. 2/ the following succeeded. Target: i686-apple-darwin9 Configured with: /GCC/gcc-4-6-branch/configure --prefix=/GCC/gcc-4-6-install --target=i686-apple-darwin9 --host=i686-apple-darwin9 --build=i686-apple-darwin9 --enable-version-specific-runtime-libs --enable-checking=release --with-gmp=/GCC/multiprec-math/x86 --with-mpfr=/GCC/multiprec-math/x86 --with-mpc=/GCC/multiprec-math/x86 --with-libiconv-prefix=/usr --enable-languages=all,ada,java,obj-c++ --with-build-config='bootstrap-lto bootstrap-debug' Thread model: posix gcc version 4.6.2 20110923 (prerelease) [gcc-4_6-branch revision 179117] (GCC)
[Bug middle-end/50481] builtin to reverse the bit order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Jonathan Schmidt-Dominé de...@the-user.org changed: What|Removed |Added CC||de...@the-user.org --- Comment #1 from Jonathan Schmidt-Dominé de...@the-user.org 2011-09-23 15:30:33 UTC --- Informative web-page listing some methods: http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64BitsDiv
[Bug lto/50496] New: [4.7 regression] ICE in redirect_jump, at jump.c:1497
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50496 Bug #: 50496 Summary: [4.7 regression] ICE in redirect_jump, at jump.c:1497 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de This ICE happened while compiling LibreOffice with --enable-lto. # g++ -r -nostdlib CRowSetColumn.ii CRowSetDataColumn.ii datacolumn.ii definitioncolumn.ii table.ii -flto -std=c++0x -O2 In file included from /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/solver/unxlngx6.pro/inc/comphelper/IdPropArrayHelper.hxx:231:0, from :631: /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx: In member function ‘columnDropped’: /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx:158:1: internal compiler error: in redirect_jump, at jump.c:1497 Please submit a full bug report I will try to reduce the .ii files further.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #2 from Mathias Gaunard mathias at gaunard dot com 2011-09-23 15:46:50 UTC --- Would you happen to have a reference to those changes or discussed improvements? I'm not testing with a very recent GCC.
[Bug lto/50496] [4.7 regression] ICE in redirect_jump, at jump.c:1497
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50496 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-23 15:50:00 UTC --- Testcase is too big ATM: 1193 kilobytes. Will post reduced testcase later.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #26 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-23 15:52:02 UTC --- (In reply to comment #25) New ICE with today's gcc and today's libreoffice: /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx:158:1: internal compiler error: in redirect_jump, at jump.c:1497 This is now PR50496. I'm still reducing with delta.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-23 Ever Confirmed|0 |1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-09-23 15:58:12 UTC --- I recently made a number of improvements that will be in 4.7.0; see PR 48481. It certainly would be possible to do more optimization: 1) Once we have seen a valid exact match, quickly disqualify any later candidates that are not. 2) Try to find that exact match faster with a hash or splay tree lookup. #2 would only be useful for large overload sets, but #1 could be a minor optimization for all code.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-09-23 16:00:37 UTC --- (In reply to comment #3) I recently made a number of improvements that will be in 4.7.0; see PR 48481. The fn_set change in particular should cut your overload resolution time by 50%. The other changes are to avoid memory bloat, which may or may not affect you.
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386
--- Comment #5 from dave.anglin at bell dot net 2011-09-23 16:04:18 UTC ---
On 9/20/2011 6:32 PM, ramana at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386
--- Comment #4 from Ramana Radhakrishnanramana at gcc dot gnu.org
2011-09-20 22:32:49 UTC ---
I think this is a bootstrap issue rather than a problem with libgomp . A
reduced testcase of this form fails with the stage2 compiler but is ok with
the
stage1 compiler.
struct gomp_work_share
{
/* This member records the SCHEDULE clause to be used for this construct.
The user specification of runtime will already have been resolved.
If this is a SECTIONS construct, this value will always be DYNAMIC. */
union {
struct {
/* This is the chunk_size argument to the SCHEDULE clause. */
long chunk_size;
/* This is the iteration end point. If this is a SECTIONS construct,
this is the number of contained sections. */
long end;
/* This is the iteration step. If this is a SECTIONS construct, this
is always 1. */
long incr;
}u;
};
}a;
Where the stage2 compiler goes :
/home/4/t1.i:21:3: warning: unnamed struct/union that defines no instances
[enabled by default]
and the stage1 compiler goes quietly.
Could you check if you see similar behaviour ?
Yes, exactly. I noted in my original report that the error occurred in
stage2.
While not fully confirmed, it looks like this was introduced by r178692.
Dave
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-23 16:20:00 UTC --- Author: paolo Date: Fri Sep 23 16:19:52 2011 New Revision: 179121 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179121 Log: /cp 2011-09-23 Paolo Carlini paolo.carl...@oracle.com PR c++/50258 * decl.c (check_static_variable_definition): Allow in-class initialization of static data member of non-integral type in permissive mode. /testsuite 2011-09-23 Paolo Carlini paolo.carl...@oracle.com PR c++/50258 * g++.dg/cpp0x/constexpr-static8.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 16:22:32 UTC --- Done.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #5 from Mathias Gaunard mathias at gaunard dot com 2011-09-23 16:38:11 UTC --- clang was already 50% faster in my tests, so I guess that will put gcc 4.7 on par with it.
[Bug target/50447] [avr] Better support of AND, OR, XOR and PLUS with constant integers for 16- and 32-bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-23 17:02:20 UTC --- Author: gjl Date: Fri Sep 23 17:02:10 2011 New Revision: 179123 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179123 Log: PR target/50447 * config/avr/avr.md: (adjust_len): Add alternative out_plus. (addsi3): Rewrite using QI scratch register. Adjust text peepholes using plus:SI. (*addsi3_zero_extend.hi): New insn. (*subsi3_zero_extend.hi): New insn. (*subhi3_zero_extend1): Set attribute cc to set_czn. (*subsi3_zero_extend): Ditto. (subsi3): Change predicate #2 to register_operand. * config/avr/avr-protos.h (avr_out_plus): New prototype. (avr_out_plus_1): New static function. (avr_out_plus): New function. (adjust_insn_length): Handle ADJUST_LEN_OUT_PLUS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug target/50447] [avr] Better support of AND, OR, XOR and PLUS with constant integers for 16- and 32-bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-23 17:06:49 UTC --- Author: gjl Date: Fri Sep 23 17:06:44 2011 New Revision: 179124 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179124 Log: * config/avr/avr.md (adjust_len): Add alternatives tsthi, tstsi, compare. (*cmpqi_sign_extend): Use s8_operand. (*cmphi, *cmpsi): Rewrite using avr_out_compare. * config/avr/avr-protos.h (compare_diff_p, compare_eq_p): Remove prototypes. (out_tsthi, out_tstsi): Remove prototypes. (avr_out_tsthi, avr_out_tstsi): New prototypes. * config/avr/avr.c (out_tsthi, out_tstsi): Remove functions. (avr_asm_len): Negative length now sets *plen to -length. (compare_sign_p): Return bool instead of int. (compare_diff_p, compare_eq_p): Ditto and make static. (avr_out_tsthi): New function. (avr_out_tstsi): New function. (avr_out_compare): New function. (adjust_insn_length): Handle ADJUST_LEN_TSTHI, ADJUST_LEN_TSTSI, ADJUST_LEN_COMPARE. PR target/50447 Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-23 17:08:57 UTC --- By the way, since apparently you ran actual benchmarks, some testcases (and relative numbers?) would not hurt here...
[Bug target/50447] [avr] Better support of AND, OR, XOR and PLUS with constant integers for 16- and 32-bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-23 17:11:06 UTC --- Closed this one as fixed for 4.7 trunk.
[Bug debug/50497] New: gcc 4.6.x '-g' option no longer emits the .debug_pubnames section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50497
Bug #: 50497
Summary: gcc 4.6.x '-g' option no longer emits the
.debug_pubnames section
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com
Our performance tool collection relies on the DWARF .debug_pubnames
section to quickly find global symbols. As of GCC 4.6.0 this section is no
longer emitted when -g is specified, imposing an unnecessary hardship upon the
performance tools. Signification problems it causes includes:
1. preventing users of the tool to instrument entry points in user-defined
source code (although -finstrument-functions can circumvent this it requires a
re-compilation of source not previously required)
2. imposing a severe processing overhead penalty if using other means to gather
subprogram details for all globally defined entry points
This bug requests that the .debug_pubnames section again be emitted when -g is
specified. Otherwise, an option should be provided that will allow this as I am
sure other tools have experienced this imposition of a seemingly short-sided
decision (and least I can not find any logical reason why this section was
removed)
Test case:
$ cat abc.c
void a () { }
void b () { }
void c () { }
$
** Here is GCC 4.5.3 working: **
$ gcc --version
gcc (GCC) 4.5.3 20110428 (Cray Inc.)
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.
$ dwarfdump abc.o
snip
.debug_pubnames
global a die-in-sect 45, cu-in-sect 11, die-in-cu 45,
cu-header-in
-sect 0
global b die-in-sect 71, cu-in-sect 11, die-in-cu 71,
cu-header-in
-sect 0
global c die-in-sect 97, cu-in-sect 11, die-in-cu 97,
cu-header-in
-sect 0
.debug_macinfo
snip
** Here is GCC 4.6.1 not working: **
$ gcc --version
gcc (GCC) 4.6.1 20110627 (Cray Inc.)
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.
$ gcc -c -g abc.c
$ dwarfdump abc.o
snip
.debug_pubnames
.debug_macinfo
snip
[Bug debug/50497] gcc 4.6.x '-g' option no longer emits the .debug_pubnames section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50497 --- Comment #1 from Geir Johansen geir at cray dot com 2011-09-23 17:20:49 UTC --- If there is some workaround that will enable previous behavior please add that to this bug.
