[Bug treelang/28980] New: internal compiler error: in tree_low_cst, at tree.c:4423
internal compiler error: in tree_low_cst, at tree.c:4423
First, If I run this with -E, I get the preprocessed source that I will attach.
vmfreebsd# gcc42 -E -g -I/usr/local/include
-I/root/devel/dynamos/src/shared/include
-I/root/devel/dynamos/src/framework/include
-I/root/devel/dynamos/src/disassembler/slicer/include
-I/root/devel/dynamos/src/os/include -I/root/devel/dynamos/config
-I/root/devel/dynamos/src/libslicer/include -I/root/devel/dynamos/devel/include
-c dynreplace.c > preprocessed_source.c
And now, the bug:
vmfreebsd# gcc42 -g -I/usr/local/include
-I/root/devel/dynamos/src/shared/include
-I/root/devel/dynamos/src/framework/include
-I/root/devel/dynamos/src/disassembler/slicer/include
-I/root/devel/dynamos/src/os/include -I/root/devel/dynamos/config
-I/root/devel/dynamos/src/libslicer/include -I/root/devel/dynamos/devel/include
-c dynreplace.c
dynreplace.c: In function 'dynreplace_add_trampoline':
dynreplace.c:71: warning: incompatible implicit declaration of built-in
function 'memcpy'
dynreplace.c:48: internal compiler error: in tree_low_cst, at tree.c:4423
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
vmfreebsd# gcc42 --version
gcc42 (GCC) 4.2.0 20060218 (experimental)
Copyright (C) 2006 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.
vmfreebsd# uname -a
FreeBSD vmfreebsd.mkgnu.net 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7
04:32:43 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
This is running inside a VMWare virtual machine loaded with FreeBSD 6.1.
No bug occurs when compiling with gcc-2.95 or gcc-3.3.4.
--
Summary: internal compiler error: in tree_low_cst, at tree.c:4423
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: treelang
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkgnu at mkgnu dot net
GCC build triplet: i386-unknown-freebsd6.1
GCC host triplet: i386-unknown-freebsd6.1
GCC target triplet: i386-unknown-freebsd6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28980
[Bug treelang/28980] internal compiler error: in tree_low_cst, at tree.c:4423
--- Comment #1 from mkgnu at mkgnu dot net 2006-09-08 04:11 --- Created an attachment (id=12210) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12210&action=view) The preprocessed source that causes this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28980
[Bug treelang/28980] internal compiler error: in tree_low_cst, at tree.c:4423
--- Comment #2 from mkgnu at mkgnu dot net 2006-09-08 04:14 --- gcc42 originated from running a: # pkg_add -r gcc42 in FreeBSD 6.1. This command installed the package gcc-4.2.0_20060218 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28980
[Bug c/31689] New: Support defining attributes at a scope level
Support defining attributes at a scope level.
I'd like to request implementing the feature of defining attributes at a scope
level. For example, allow a syntax such as the following, possibly as a GNU
extension:
if (something)
__attribute__ ((section("bar"))) {
/* body of if-statement */
}
...which will place the body of the if-statement in a separate memory region.
The motivation behind this request is the need to place uncommonly used code in
a separate memory region for better cache locality. For example, given a piece
of C code such as the following:
if (something) {
/* body */
}
... we need to place the entire body in a separate memory region.
1 -- Attempting to use extended inline assembly to implement this is
problematic since the general assumption is that outbound/inbound branches are
not allowed in inline assembly. As Jim Wilson also notes, using Labels as
values (e.g. &&label) confuses the CFG, effectively disabling some
optimizations, which means that performance may be lost when doing this
(http://lists.gnu.org/archive/html/bug-binutils/2007-04/msg00120.html).
Additionally, trying to do things behind the compilers back (in inline
assembly) will not work in the long-term.
2 -- Using the section attribute to place an entire function in a separate
region is also unsuitable. For example a definition such as:
extern void foobar (void) __attribute__ ((section ("bar")));
puts the entire function `foobar' in the `bar' section, not just the body of an
if statement inside the function. Additionally, putting the body of the
if-statement in a separate function and defining that function to be in a
separate section is not adequate. If the body of the if-statement contains
return instructions or gotos to other parts of the function, won't permit
returning to the function caller or other parts of the original function
(http://gcc.gnu.org/ml/gcc-help/2007-04/msg00282.html).
Discussions about this topic are listed in:
http://gcc.gnu.org/ml/gcc-help/2007-04/msg00250.html
http://lists.gnu.org/archive/html/bug-binutils/2007-04/msg00107.html
--
Summary: Support defining attributes at a scope level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkgnu at mkgnu dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31689
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
--- Comment #5 from mkgnu at mkgnu dot net 2007-04-25 02:12 --- (In reply to comment #3) > I've tried a couple of different ways to use branch predictions for > partitioning, but it never leads to meaningful results. Either everything is > hot or everything is cold. I don't know what else to do about this. Steven, perhaps you could elaborate what you mean by saying "it never leads to meaningful results" ? > I'm actually tempted to claim this is a WONTFIX because "hot" and "cold" are > not meaningful without profile information. Thoughts, anyone? I'm working on a research prototype in which I produce code that should be cold for a considerable amount of time when a program runs. After some time (or perhaps never), when a flag is raised, we'd like to use the cold code just once, and then revert the program back to it's original behavior of running only hot code. Apparently, as bug 31689 shows, I need this feature. In this research prototype I am 100% certain that a piece of code will be cold -- there's no need to gather profiling information, and I absolutely need this code to be out of the .text section. Using this research prototype, I ran experiments that demonstrate a slowdown in computation-bound applications in the range of 4%-300% on the i386 and PowerPC architectures depending on the size of the processor i-cache. I believe that moving the cold code sections out of .text will bring the overhead down to less than 4%, constantly. I absolutely, positively, definitely find value in this feature. In fact, my research progress depends on it and I am actively looking for a way to have this implemented. Can you help ? I've tried using __builtin_expect() and -freorder-blocks-and-partition with gcc 4.1.2 and it doesn't seem to work. If there's a patch laying around that implements this feature without gathering profiling information I would love to try it out immediately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #9 from Kristis Makris --- I won't see, open or read your email. I won't even know you emailed me. If there's something you want me to do you have to use this: https://aimelia.com/res?id=CZPr9mKgQTQfD3dYqy00b5qg This is an automated response.
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #10 from Kristis Makris --- I won't see, open or read your email. I won't even know you emailed me. If there's something you want me to do you have to use this: https://aimelia.com/res?id=BJ6WQBHg1LEYvkwLH6Hn02hK This is an automated response.
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #11 from Kristis Makris --- I won't see, open or read your email. I won't even know you emailed me. If there's something you want me to do you have to use this: https://aimelia.com/res?id=wnVviP0qSkNXW1mtSIOKtdq5 This is an automated response.
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #12 from Kristis Makris --- Please revise and resubmit. I can't tell clearly why whatever it is you are asking is important.
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
--- Comment #6 from mkgnu at mkgnu dot net 2007-04-30 23:42 --- It seems that when I use -freorder-blocks-and-partition along with -fprofile-use (after I have already run once an executable compiled with -freorder-blocks-and-partition -fprofile-generate) I can produce an object file that contains a .text.unlikely section, as expected. But when I try to further link this object file with other object files to produce an executable, the .text.unlikely section is missing from the final executable. I've tried this with gcc4.1.2/ld2.15 and then again with gcc4.1.1/ld2.17 with the same results. Is this another bug related to -freorder-blocks-and-partition ? Should I file a separate bug report for it ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493
[Bug tree-optimization/31925] New: Internal compiler error in `store_bit_field', at expmed.c:277
Internal compiler error in `store_bit_field', at expmed.c:277. It seems that I've come across a case where compiling with gcc 2.95.4 (from the Debian package 2.95.4-22) using -O3 crashes, while compiling with no optimization does not crash. I will attach the .i file produced with -save-temps. I'm experiencing: $ gcc -O3 -c bm_kiss_double.cil.i ... ./bm_kiss_double.cil.c: In function `hcu_restore_frame_of___sgnl_v1': ./bm_kiss_double.cil.c:4273: Internal compiler error: ./bm_kiss_double.cil.c:4273: Internal compiler error in `store_bit_field', at expmed.c:277 Please submit a full bug report. See http://www.gnu.org/software/gcc/bugs.html> for instructions. I'm using the gcc 2.95.x series in a performance evaluation of various compilers. I did not try to reproduce with gcc 2.96 or gcc 2.97 (I don't see them being available for Debian). I confirmed that gcc 3.3.5 does not have this problem. -- Summary: Internal compiler error in `store_bit_field', at expmed.c:277 Product: gcc Version: 2.95.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkgnu at mkgnu dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
[Bug tree-optimization/31925] Internal compiler error in `store_bit_field', at expmed.c:277
--- Comment #1 from mkgnu at mkgnu dot net 2007-05-14 22:03 --- Created an attachment (id=13554) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13554&action=view) Source code that causes an internal compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
[Bug tree-optimization/31925] Internal compiler error in `store_bit_field', at expmed.c:277
--- Comment #2 from mkgnu at mkgnu dot net 2007-05-14 22:05 --- Output of gcc -v $ gcc -v -O3 -c bm_kiss_double.cil.i Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) /usr/lib/gcc-lib/i386-linux/2.95.4/cc1 bm_kiss_double.cil.i -quiet -O3 -version -o /tmp/ccvYzdxK.s GNU C version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011002 (Debian prerelease). ... ./bm_kiss_double.cil.c: In function `hcu_restore_frame_of___sgnl_v1': ./bm_kiss_double.cil.c:4273: Internal compiler error: ./bm_kiss_double.cil.c:4273: Internal compiler error in `store_bit_field', at expmed.c:277 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
