Re: Usage of -ftrapv
On Jun 16, 2006, at 5:43 PM, Paulo J. Matos wrote: I'd like to catch automatically over/underflows on floating point Wrong list. You want gcc-help... Does it mean that if I use this, exceptions are thrown when I have an over/underflow? No, it it meant that, the documentation would say that the flag causes exceptions to be thrown. There is no such option. You can write your own code to throw exceptions, but I think you'd want to study FP on modern processors and just when exactly it is known that something is exceptional. Hint, it happens really late, and you have to add machine instructions to get them to be not deferred, but, if you do that, you throw performance out the window. You'll have to refer to your OS documentation on just how exactly to do this, it you can at all. man signal is the usual entry into this world.
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Fri, Jun 02, 2006 at 09:24:17AM +0200, Rask Ingemann Lambertsen wrote:
The rest of the ARM backend presently assumes that the pattern has the form
(set (operand:QI 0) (operand:QI 1))
but now we've changed it to
(parallel [(set (operand:QI 0) (operand:QI 1))
(clobber (operand:QI 2))
])
so that's why you get unrecognizable insn errors now. Any place which
intended to generate an *arm_movqi_insn has to add a clobber also. For a
start, this means the movqi pattern.
I've now implemented it. This brings a small improvement to the code
generated for bytewritetest:
bytewritetest:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr3, [r0, #5]@ zero_extendqisi2
ldrbip, [r0, #4]@ zero_extendqisi2
ldr r2, [r0, #0]
add r1, r3, ip
str r2, [r0, #8]
str r1, [r0], #5--
eor r3, r3, ip
swpbr2, r3, [r0]
@ lr needed for prologue
bx lr
Exactly the same number of instructions as without -mswp-byte-writes because
of postincrement. Basicly, it pays off to get the insn expanded correctly to
begin with, rather than leaving it to reload to fix it up later. This should
work fine with volatile variables because there is no need to read back from
memory. The peephole optimizations are gone for the same reason. I do wonder
if the ability to reuse the input register as a scratch register has been
preserved, though.
Compiling unwind-dw2-fde.c, I noticed that the code produced for
__register_frame_info_table_bases() differs more than expected:
__register_frame_info_table_bases:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
1 stmfd sp!, {r4, lr}
2 mov lr, #0
3 str lr, [r1, #16]
4 ldrbip, [r1, #16] @ zero_extendqisi2
5 orr ip, ip, #2
6 strbip, [r1, #16]
7 ldr r4, .L28
8 ldrhip, [r1, #16]
9 ldr lr, [r4, #0]
10 orr ip, ip, #2032
11 str r0, [r1, #12]
12 orr ip, ip, #8
13 mvn r0, #0
14 strhip, [r1, #16] @ movhi
15 str lr, [r1, #20]
16 str r0, [r1, #0]
17 str r1, [r4, #0]
18 stmib r1, {r2, r3}@ phole stm
19 ldmfd sp!, {r4, pc}
vs.
__register_frame_info_table_bases:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
2 mov ip, #0
3 str ip, [r1, #16]
1 str lr, [sp, #-4]!
4 ldrblr, [r1, #16] @ zero_extendqisi2
11 str r0, [r1, #12]
5 orr lr, lr, #2
13 mvn r0, #0
6a add ip, r1, #16
16+18? stmia r1, {r0, r2, r3}@ phole stm
6b swpbr3, lr, [ip]
7 ldr r0, .L28
8 ldrhr3, [r1, #16]
9 ldr r2, [r0, #0]
10 orr r3, r3, #2032
12 orr r3, r3, #8
14 strhr3, [r1, #16] @ movhi
15 str r2, [r1, #20]
17 str r1, [r0, #0]
19 ldr pc, [sp], #4
But the swp version seems to be equivalent, doesn't it?
I'm not sure that the reload_outqi expander will correctly handle
cases where reload spills a register to memory. If the memory address
doesn't have the right form, it becomes more complicated.
Index: gcc/config/arm/arm.h
===
--- gcc/config/arm/arm.h(revision 114119)
+++ gcc/config/arm/arm.h(working copy)
@@ -1094,6 +1094,8 @@
? vfp_secondary_reload_class (MODE, X) \
: TARGET_ARM\
? (((MODE) == HImode ! arm_arch4 true_regnum (X) == -1) \
+ || ((MODE) == QImode TARGET_ARM TARGET_SWP_BYTE_WRITES\
+true_regnum (X) == -1) \
? GENERAL_REGS : NO_REGS) \
: THUMB_SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X))
Index: gcc/config/arm/arm.opt
===
--- gcc/config/arm/arm.opt (revision 114119)
+++ gcc/config/arm/arm.opt (working copy)
@@ -153,3 +153,7 @@
mwords-little-endian
Target Report RejectNegative Mask(LITTLE_WORDS)
Assume big endian bytes, little endian words
+
+mswp-byte-writes
+Target Report Mask(SWP_BYTE_WRITES)
+Use the swp instruction for byte writes. The default is to use str
Index: gcc/config/arm/predicates.md
===
--- gcc/config/arm/predicates.md(revision 114119)
+++ gcc/config/arm/predicates.md(working copy)
@@ -125,6 +125,14 @@
|| (GET_CODE (op) == REG
REGNO (op) = FIRST_PSEUDO_REGISTER))
+;; Match register operands or memory operands of the form (mem (reg ...)),
+;; as permitted by the Q memory
Re: Coroutines
Dustin Laurence writes: On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote: If every language were going to have the feature, then, moving it down into the mid-end or back-end might make sense, but I don't think it does in this case. Personally, I'd like, and use, decent coroutines in C. But perhaps I am the only one. I wouldn't start with pthreads I don't think. That was my thought--I played with it some but I intended it as a bit of threads practice. Using threads to emulate a synchronous construct just seems *wrong.* You need a way to switch from one stack to another, but why not leave open the possibility of implementing this in a number of different ways? You need detach() and resume() [in Simula notation] and these can be provided either by low-level stack-switching or by invoking a pthreads library. As long as you don't change the API, that'll get you portability to systems you haven't even heard of, let alone seen. You can prototype the runtime library with pthreads in the knowledge that you can do something else later. Andrew.
Re: Coroutines
Andrew Haley [EMAIL PROTECTED] writes: | Dustin Laurence writes: | On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote: | |If every language were going to have the feature, then, moving it |down into the mid-end or back-end might make sense, but I don't think |it does in this case. | | Personally, I'd like, and use, decent coroutines in C. But perhaps I am | the only one. | |I wouldn't start with pthreads I don't think. | | That was my thought--I played with it some but I intended it as a bit of | threads practice. Using threads to emulate a synchronous construct just | seems *wrong.* | | You need a way to switch from one stack to another, but why not leave | open the possibility of implementing this in a number of different | ways? Yup. | You need detach() and resume() [in Simula notation] and these | can be provided either by low-level stack-switching or by invoking a | pthreads library. I wouldn't use a thread library because many uses of coroutine are to implement low-cost, efficient, alternatives to thread where, for example, the full power of threads are not essential. -- Gaby
Boehm's GC crashed by adjustment of GC root set
Hi, So far I've been debugging GCC bootstrap failures with Boehm's GC, and now I'm stuck. I used to register all GC roots at the startup of GCC, including stringpool roots. That worked fine until first ht_expand() call, which moves identifier hash table around in the memory and Boehm's GC still uses its old location as a root segment. Oops. But if I try to remove the old root segment and register the current one with GC_remove_roots() and GC_add_roots(), first GC_collect() crashes with Program received signal SIGSEGV, Segmentation fault. 0x01046191 in GC_mark_from (mark_stack_top=0x22e7b4, mark_stack=0x0, mark_stack_limit=0x0) at ../../../gcc-boehm-test/boehm-gc/mark.c:759 759 deferred = *limit; (gdb) bt #0 0x01046191 in GC_mark_from (mark_stack_top=0x22e7b4, mark_stack=0x0, mark_stack_limit=0x0) at ../../../gcc-boehm-test/boehm-gc/mark.c:759 #1 0x in ?? () from I've verified by GC_dump() call right before collection, that the root set is correctly adjusted (i.e. pointing to the current hash table location). I The collector is compiled with all debugging options I could find: --enable-gc-debug --enable-full-debug CFLAGS=-DKEEP_BACK_PTRS -DGC_ASSERTIONS -g -O2 At this point I've run out of ideas, how to proceed. Any clues would much appreciated. -- TIA, Laurynas
Re: Coroutines
I'm looking at the very same problem, hoping to get very lightweight user-level threads for use in discrete event simulation. It would be very nice if it was possible to write an inlined piece of assembler that saved the program counter and the stack pointer and then be able to say to GCC that everything is clobbered by those few lines of assembler. Ideally this clobber should include all registers, including callee- saved registers, otherwise you need to explicitly save at least those. With that über-clobber I think it would be possible to implement very cheap context switches, where only the registers that GCC knows are required when resuming the context are actually saved. All attempts to say clobber-all that I've made result in problems, typically failure to reload. Is there a safe way to say to GCC that everything is clobbered in a way that is safe across all possible optimization settings? I'm particularly interested in the x86_64 target. On a side note, when writing this type of context-switching code one would often need to insert (local) labels in the assembler to serve as target for thread resumption. GCC is very aggressive in removing labels which according to C/C++ semantics he can prove are never reached. It would be nice to have an attribute to say please, GCC, for reasons I cannot explain to you, this label will actually be reached eventually. This is particularly useful combined with the über-clobber of above, otherwise GCC could easily convince himself that not too much needs to be saved. -- Maurizio On Jun 17, 2006, at 5:28 AM, Gabriel Dos Reis wrote: Andrew Haley [EMAIL PROTECTED] writes: | Dustin Laurence writes: | On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote: | |If every language were going to have the feature, then, moving it |down into the mid-end or back-end might make sense, but I don't think |it does in this case. | | Personally, I'd like, and use, decent coroutines in C. But perhaps I am | the only one. | |I wouldn't start with pthreads I don't think. | | That was my thought--I played with it some but I intended it as a bit of | threads practice. Using threads to emulate a synchronous construct just | seems *wrong.* | | You need a way to switch from one stack to another, but why not leave | open the possibility of implementing this in a number of different | ways? Yup. | You need detach() and resume() [in Simula notation] and these | can be provided either by low-level stack-switching or by invoking a | pthreads library. I wouldn't use a thread library because many uses of coroutine are to implement low-cost, efficient, alternatives to thread where, for example, the full power of threads are not essential. -- Gaby
c++ - inquiry
Hello,
first of all, my best regards for the developers of gcc, it is a very
big and great piece of work, I appreciate it much and use it
frequently.
I am very curios over a piece of code I wrote recently.
In a slight variation it produces a compile error from g++ and I
have no idea if
i) I do not understand c++ enough
ii) it is a bug in g++
iii) it is a design flaw in c++
so I decided to share this one with you (you can freely ignore it
without offending me).
Topic: overloading the == and != operators:
this code
#include iostream
// comment in to get compile error
#define BUG
struct t_settings {
bool operator==(t_settings const a){
if (a.x != this-x) { return (false); }
if (a.y != this-y) { return (false); }
if (a.z != this-z) { return (false); }
return (true);
}
#ifndef BUG
bool operator!=(t_settings const a){
return ( ! ( *this == a ) );
}
#else
bool operator!=(t_settings const a){
return ( ! ( a == *this ) );
}
#endif
int x;
int y;
int z;
};
int main (int argc, char **argv){
t_settings mySettings;
mySettings.x=1;
mySettings.y=2;
mySettings.z=3;
t_settings hisSettings;
hisSettings.x=1;
hisSettings.y=2;
hisSettings.z=4;
if (mySettings != hisSettings){
std::cout Settings not equal std::endl;
} else {
std::cout Settings equal std::endl;
}
return (0);
}
g++ (version 3 and 4 equally) produces:
In member function `bool t_settings::operator!=(const t_settings)':
error: passing `const t_settings' as `this' argument of `bool
t_settings::operator==(const t_settings)' discards qualifiers
comment out #define BUG and it compiles.
So the order of a and *this are all that matters.
Sorry, but I have no idea why this is so.
Greetings
Bernhard Günther,
Bonn, Germany
--
--
Bernhard Guenther
[EMAIL PROTECTED]
[EMAIL PROTECTED]
ICQ: 1632197, Jabber: [EMAIL PROTECTED]
Tel: +4922896779696, Cell: +491704931668
--
pgpWgssbsthSC.pgp
Description: PGP signature
Re: c++ - inquiry
On 6/17/06, Bernhard Guenther [EMAIL PROTECTED] wrote:
Hello,
first of all, my best regards for the developers of gcc, it is a very
big and great piece of work, I appreciate it much and use it
frequently.
First of all, this is off-topic on this list. Use gcc-help or better
comp.lang.c++ for this kind of questions.
I am very curios over a piece of code I wrote recently.
In a slight variation it produces a compile error from g++ and I
have no idea if
i) I do not understand c++ enough
Yep.
struct t_settings {
bool operator==(t_settings const a){
Try
bool operator==(t_settings const a) const {
Richard.
Re: Where is the egg?
On Mon, 12 Jun 2006, Thomas Neumann wrote: how about using a svg image as a master instead of a png? It could be scaled without loss. I attached a svg produced from the original png. Thanks, Thomas! I've now put this into our CVS (as wwwdocs:htdocs/img/gccegg.svg) so that we can use this in the future. Gerald
Re: MIPS RDHWR instruction reordering
On 16 Jun 2006 14:12:29 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote: The RDHWR is executed _before_ evaluating the arg value. For arg == 0 case, the RDHWR has no point but just a overhead. Without -O2, the RDHWR is executed _after_ the evaluation, so gcc's optimizer reorder the RDHWR instruction. The computation of the address of x was moved outside the conditional--that is, both the rdhwr and the addu moved. You'll have to figure out why. gcc shouldn't move instructions outside of a conditional unless they are cheap and don't trap. This instruction doesn't trap, but it's not cheap. AFAIK on all MIPS CPU the rdhwr generates an exception (trap). I tried changing unspec to unspec_volatile in this definition: (define_insn tls_get_tp_mode [(set (match_operand:P 0 register_operand =v) (unspec:P [(const_int 0)] UNSPEC_TLS_GET_TP))] HAVE_AS_TLS !TARGET_MIPS16 .set\tpush\;.set\tmips32r2\t\;rdhwr\t%0,$29\;.set\tpop [(set_attr type unknown) (set_attr mode MODE)]) With unspec_volatile, gcc do not move the rdhwr before the branch. But this change has bad side effects. For example, if I incremented a thread local variable, rdhwr is used twice (for load and store). So I suppose we should tell gcc that rdhwr is not cheap. But I do not know how to describe such information in .md file... --- Atsushi Nemoto
gcc-4.2-20060617 is now available
Snapshot gcc-4.2-20060617 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060617/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 114741 You'll find: gcc-4.2-20060617.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060617.tar.bz2 C front end and core compiler gcc-ada-4.2-20060617.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060617.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060617.tar.bz2 C++ front end and runtime gcc-java-4.2-20060617.tar.bz2 Java front end and runtime gcc-objc-4.2-20060617.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060617.tar.bz2The GCC testsuite Diffs from 4.2-20060610 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
cross compiler problem
Hello, I Am trying to compile my gcc source as cross compiler. I tryied to compile for pdp10, crx, mips and I still get the same error: Make[2]: *** No rules to make object `/usr/local/bin/crx-as', needed by `stamp-as'. Stop. Make[2]: Leaving directory `/home/piotrek/Desktop/umik/objdir/gcc' Make[1]: *** [all-gcc] Error 2 Make: *** [all] Error 2 To configure I am using such command: ./configure --enable-prefix=/usr/local/cross --without-headers --with-newlib --enable-threds=single --disable-shared --disable-multilib --disable-nls --target=crx I tryied a few of gcc releases. Does anybody know what is the problem? Do I need first to compile binutils for the same target as gcc? Thanks in advance. Best regards, Piotr Pałka
Re: cross compiler problem
On 6/17/06, Piotr Pałka [EMAIL PROTECTED] wrote: Do I need first to compile binutils for the same target as gcc? You should probably read http://gcc.gnu.org/simtest-howto.html. Gr. Steven
Re: Boehm's GC crashed by adjustment of GC root set
Laurynas Biveinis wrote: Hi, So far I've been debugging GCC bootstrap failures with Boehm's GC, and now I'm stuck. I used to register all GC roots at the startup of GCC, including stringpool roots. That worked fine until first ht_expand() call, which moves identifier hash table around in the memory and Boehm's GC still uses its old location as a root segment. Oops. But if I try to remove the old root segment and register the current one with GC_remove_roots() and GC_add_roots(), first GC_collect() crashes with Are you trying to do incremental marking? If the root set changes in the middle of an incremental mark and it's still got things from the old root set to mark, i bet it blows up, :) --Dan
Re: Boehm's GC crashed by adjustment of GC root set
2006/6/18, Daniel Berlin [EMAIL PROTECTED]: Are you trying to do incremental marking? If the root set changes in the middle of an incremental mark and it's still got things from the old root set to mark, i bet it blows up, :) I thought I was safe with disabled incremental collection. Additionally http://gcc.gnu.org/ml/java/2005-12/msg00059.html and other messages I was able to find mention incremental marking only in context of of incremental collection, leaving me to guess that it is not a part of full collection. Moreover I have GC disabled most of the time (enabling just for ggc_collect()), that might disable marking at allocation if it existed (a guess, I know...) All in all, I'm not sure incremental marking is at fault here. I think I will try to narrow a problem by non freeing, but clearing old hash table on increase. This way root set will only grow, but the set of marked objects should remain the same. If it still crashes, then somehow adding roots is at fault - but I'm not sure how to continue after that. Oh, and accidentally I have found http://gcc.gnu.org/ml/gcc/2002-08/msg00837.html - a previous Boehm's GC investigation results, which I was looking for earlier. It seems I'm taking a different approach, at least my ggc_collect() collects instead of being no-op. -- Laurynas
Questions about another usage of GCOV
Hi All. I have some questions regarding GCOV, which is part of GCC. I hope this is the right place (if not, suggestions are welcome). Please add me (marc dot alff at comcast dot net) in your replies, as I am not subscribed to this list. Let me start with some background : A project XYZ consist of : - a programming language XYZ, - a server, which interprets the XYZ code at runtime. This language is procedural, but can not be compiled into binary code in a traditional sense like C, C++, Java, Fortran etc, so it's not a language that is likely to be supported by GCC. Yet, the language defines concepts like : - procedures, functions, - flow control statements (if, while, switch/case, etc). The goal is to instrument the code in the interpretor in the XYZ server, to basically compute code coverage on paths executed at runtime, the have same functionality for XYZ that GCOV provides for GCC. Looking at how GCOV works, I found that : - GCOV only cares that code is located on a file+line, - the programming language is not important, only the graph representing the code is. So, what I have in mind is the following : When some code is loaded in the XYZ server, generate a .gcno file Loading function foo.xyz (typically done once) : foo.xyz (server) foo.gcno When code is executed, generate a .gcda file Executing function foo.xyz : request that invokes foo() (server) foo.gcda After the code has been executed, coverage can be collected : foo.xyz + foo.gcno + foo.gcda (GCOV) foo.xyz.gcov All this raises the following questions, and I appreciate your comments ... 1) File formats So far, the .gcno and .gcda file formats were private to the implementation of GCC, and subject to change at any time. Now, a third party (from the GCC point of view) is generating these files ... Do you welcome such a dependency ? The file formats themselves seem to be very stables (in my understanding), so this interface is well defined. There is no need to preserve data forever since coverage analysis is typically done in a build/test/fix bugs cycle, so there is no expectations that a given format will be supported by every future releases of GCC, so this now external dependency does not add constraints to the GCC code base (in my opinion). The question is if you feel this usage of GCOV is fair, or if it's unwelcome. The underlying question is whether using GCOV for languages not supported by GCC can be done (and how ?). 2) Licensing For technical reasons, I can not use the gcov library itself, and plan to implement code to read/write the files the GCOV program needs. Is the file format (for *.gcno and *.gcda) itself covered by the GPL ? Can a third party implement, with original code not based on GPL'ed work, a library that knows how to read/write *.gcno and *.gcda files ? How much does reading comments that specify a file format in gcov-io.h and implementing from scratch some code constitute a derived work of GNU GPL code ? The new work is based on an interface specification, not on an implementation ... ... assuming the file formats are considered an interface. Is the file format documented elsewhere ? XYZ is a well known open source project I would like to contribute to, to implement code coverage in XYZ, and I am evaluating if GCOV can be leveraged or not, or under what conditions. Early prototyping shows that from a pure technical point of view, it works :) Licensing in this case is a very tricky question, because the code base of XYZ itself happen to be covered by a dual license : either GNU GPL, or commercial. When XYZ is used under the terms of the GNU GPL license, it's simple. When XYZ is used under the terms of the commercial license : - XYZ contains in it's code base original code (not GCC's) to read/write *.gcno and *.gcda - XYZ write files during it's execution - GCOV, used as a stand alone program, later consumes these files. So, XYZ and GCOV are independent programs, and are not linked together. Is that usage of GCOV a valid one ? Thanks for your time and comments, Marc Alff.
Re: Boehm's GC crashed by adjustment of GC root set
Laurynas Biveinis wrote: 2006/6/18, Daniel Berlin [EMAIL PROTECTED]: Are you trying to do incremental marking? If the root set changes in the middle of an incremental mark and it's still got things from the old root set to mark, i bet it blows up, :) I thought I was safe with disabled incremental collection. Additionally http://gcc.gnu.org/ml/java/2005-12/msg00059.html and other messages I was able to find mention incremental marking only in context of of incremental collection, leaving me to guess that it is not a part of full collection. Moreover I have GC disabled most of the time (enabling just for ggc_collect()), that might disable marking at allocation if it existed (a guess, I know...) All in all, I'm not sure incremental marking is at fault here. Okay, i'm just saying it looks like it's trying to mark a range that has moved. You should probably copy Hans, or email the gc list, and see if they have any idea. You can probably also get it to crash much quicker if you use --param ggc-min-heapsize=0 --ggc-min-expand=0 (assuming you are still using the heuristics inside ggc_collect), which will cause it to collect at every call.
Re: Questions about another usage of GCOV
On Sat, Jun 17, 2006 at 07:39:56PM -0700, Marc Alff wrote: I have some questions regarding GCOV, which is part of GCC. I hope this is the right place (if not, suggestions are welcome). Your questions are basically legal, and we don't really have the competence on this list to address them. It is my *understanding* that the GPL does not apply to file formats, and that the FSF does not object to use of its file formats by others. No promises on that, though. If you read the gcov source code in an attempt to understand the file format, you risk inadvertantly creating a derivative work. It is copyright law, not the GPL, that defines what a derivative work is. There are standard ways of doing reverse engineering to avoid that risk, and what is required differs depending on what country you live/work in. You could contact the FSF to get more reassurance; since you plan to dual-license, I assume that they will be friendly. There's no guarantee that the gcov formats won't change.
[Bug target/28069] New: __m128 local variables don't get properly aligned.
GCC dosen't allocate __m128 locals on a 16-byte boundary, but continues to use movaps to access them, causing general protection faults at run-time. -- Summary: __m128 local variables don't get properly aligned. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zuxy dot meng at gmail dot com GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28069
[Bug target/28069] __m128 local variables don't get properly aligned.
--- Comment #1 from zuxy dot meng at gmail dot com 2006-06-17 06:25 --- Created an attachment (id=11685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11685action=view) The file that gcc fails to compile correctly. Use gcc -S -msse and look at the assembly. GCC allocates __m128 locals directly on the stack without adjusting ESP, which might not be 16-byte aligned. But GCC uses movaps, which requires its operand to be 16-byte aligned, to access those locals. ICC solves this problem by adding pushl %ebp movl %esp, %ebp andl $-16, %esp to the function prolog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28069
[Bug target/28069] __m128 local variables don't get properly aligned.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-17 06:30 --- (In reply to comment #1) Use gcc -S -msse and look at the assembly. GCC allocates __m128 locals directly on the stack without adjusting ESP, which might not be 16-byte aligned. But GCC uses movaps, which requires its operand to be 16-byte aligned, to access those locals. In a way this is a dup of bug 27537. Though there is an attribute to realign the stack in 4.2.0 so using that might just fix this issue instead. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27537 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28069
[Bug libstdc++/27984] [4.2 Regression] installed libstdc++ testing broken
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-17 09:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27984
[Bug c/28071] New: A file that can not be compiled in reasonable time/space
The following file compiles in 30s with gcc -c and never compiles with gcc -O -c -- Summary: A file that can not be compiled in reasonable time/space Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raffalli at univ-savoie dot fr GCC build triplet: all gcc version in fact GCC host triplet: Intel and Apple G4 GCC target triplet: Linux and OS X http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #1 from raffalli at univ-savoie dot fr 2006-06-17 09:27 --- Created an attachment (id=11687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11687action=view) a file that gcc can not compile with -O just try gcc -c -O on this file ! (remark no problem with icc) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug bootstrap/28072] New: [4.2 Regression] target-boehm-gc is being build for targets that do not support it
This regression was cause by the patches allowing Boehm-GC to be build with --enable-objc-gc. The problem is that instead of testing whether java is part of enabled languages (as java is a default langauge and the front end is build independent of the runtime), the new configure test should test whether the java runtime (target-libjava) is being build. This not only affects sh-elf but any target that fails to build target-boehmgc. -- Summary: [4.2 Regression] target-boehm-gc is being build for targets that do not support it Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ayers at gcc dot gnu dot org GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug bootstrap/28072] [4.2 Regression] target-boehm-gc is being build for targets that do not support it
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-17 09:52:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-17 10:18 --- It actually does finish for me at -O with gcc 4.0.2. It just takes an incredible amount of time and memory, but that doesn't surprise me so much, given the nature of this evil test case ;-) With gcc 4.2 20060617, I can't compile the test case. After a long time and after using up to 1.5 GB, the compiler dies with: cc1: out of memory allocating 399751872 bytes after a total of 79527936 bytes -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-17 10:18:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug fortran/26801] -fbounds-check generates segfault
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-17 10:57 --- The test case of comment #4 is invalid as the Fortran standard says that a pointer is undefined unless it is associated (allocated, assigned) or deassociated (nullifyed). In this case it is undefined. (What gfortran should do in this case is a matter of taste, crashing is completely acceptable.) However, the test case of comment #3 is valid Fortran 2003, nonetheless gfortran crashes here, which should be fixed (and seems to be fixed by patch in comment 6). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26801
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-17 11:05 --- Caused by excessive inlining: inline heuristics : 37.25 (25%) usr 0.04 ( 1%) sys 36.56 (15%) wall 2312 kB ( 0%) ggc integration : 19.91 (13%) usr 1.49 (36%) sys 62.70 (26%) wall 1058857 kB (76%) ggc -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-17 11:05 --- Platform independent. Honza, one for you I suppose. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org GCC build triplet|all gcc version in fact (up | |to 4.1) | GCC host triplet|Intel and Apple G4 | GCC target triplet|Linux and OS X | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)
--- Comment #23 from rleigh at debian dot org 2006-06-17 14:29 --- This will take a few more hours. I didn't have a built GCC tree to hand, so I'm still waiting on make bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
[Bug c/28073] New: Type-punned pointer passed as function parameter generates bad assembly sequence
The following test code
-- begin --
typedef struct {
int val;
} Foo;
int func(long longPtr) {
Foo *pFoo = *(Foo **)longPtr; /* BAD! */
/* Foo *pFoo = (Foo *)longPtr; If you do this instead it works */
return pFoo-val;
}
int main(int argc, const char *argv[]) {
Foo foo;
foo.val = 1;
return func((long)(foo));
}
-- end --
When compiled with -O2 (which implies -fstrict-aliasing) on the x86_64
architectures changes the generated assembly sequence
movl(%rdi), %eax
movq%rdi, -8(%rsp)
--
movq-8(%rsp), %rax
movl(%rax), %eax
Comparing to other architectures, for example, i686 - the -O2 generated code
with -fstrict-aliasing and -fno-strict-aliasing is identical. The code
generated with strict aliasing on the x86_64 is pretty much nonsense and
in the case of this test program will result in garbage from the stack being
returned from main (or, possibly, a seg fault)
Compare x86_64
$ gcc -O2 -Wall badcase.c; ./a.out; echo $?
badcase.c: In function func:
badcase.c:9: warning: dereferencing type-punned pointer will break
strict-aliasing rules
76
$ gcc -O2 -fno-strict-aliasing -Wall badcase.c; ./a.out; echo $?
1
with i686
$ gcc -O2 -Wall badcase.c; ./a.out; echo $?
badcase.c: In function `func':
badcase.c:9: warning: dereferencing type-punned pointer will break
strict-aliasing rules
1
Please note that putting in any diagnostic code into func (for example a
print statement) will fix it because it changes the determination of
aliasing.
This makes this particular interaction extra hard to spot.
After some considerable debate with my colleagues about the nature of the code
and its use of type-punning to convert a long into a pointer, I decided to
submit this as a bug because (1) google reveals that a great many distribution
builders are adding -fno-strict-aliasing to get their distributions building
and working on x86_64 and (2) this ugly construct is the exact type of code
that the current version of the (somewhat) popular swig library wrapper
generates. I intend to open a bug against SWIG as well as there is no good
reason why a code generator should generate code like this.
Some of us believe that this code violates the standard (although how
specifically they cannot say) and, thus, the compiler is under no obligation to
compile it correctly. Even so, in this particular case, it would be better not
to generate the eroneous instruction sequence. Hopefully it will be reasonably
easy to pin down under which conditions the instruction sequence is changed,
for this particular architecture, and perhaps this might point the way to a
more fundamental bug.
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
--
Summary: Type-punned pointer passed as function parameter
generates bad assembly sequence
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sorenj at us dot ibm dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28073
[Bug middle-end/28071] [4.2 regression] A file that can not be compiled in reasonable time/space
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||memory-hog Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/28062] [4.1 regression] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #6 from tbm at cyrius dot com 2006-06-17 14:56 --- (In reply to comment #3) It works in 4.2.0 for sure. I don't think that's correct. I can confirm that gcc 4.2 20060508 works, but 20060530 and 20060613 definitely fail here (both the C and Objective-C test cases). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug c/28073] Type-punned pointer passed as function parameter generates bad assembly sequence
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-17 14:56 --- Foo *pFoo = *(Foo **)longPtr; /* BAD! */ The above statement accesses a long as a Foo* which does violate aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28073
[Bug c/21920] alias violating
--- Comment #100 from pinskia at gcc dot gnu dot org 2006-06-17 14:56 --- *** Bug 28073 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sorenj at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug bootstrap/28072] [4.2 Regression] target-boehm-gc is being build for targets that do not support it
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug rtl-optimization/28062] [4.1 regression] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-17 15:00 --- (In reply to comment #6) (In reply to comment #3) It works in 4.2.0 for sure. I don't think that's correct. I can confirm that gcc 4.2 20060508 works, but 20060530 and 20060613 definitely fail here (both the C and Objective-C test cases). I works with 4.2.0 20060617. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug rtl-optimization/28062] [4.1 regression] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #8 from tbm at cyrius dot com 2006-06-17 16:26 --- This ICE got introduced with: r113775 | sayle | 2006-05-15 06:43:05 +0200 (Mon, 15 May 2006) | 13 lines PR rtl-optimization/22563 Backports from mainline * expmed.c (store_fixed_bit_field): When using AND and IOR to store a fixed width bitfield, always force the intermediates into pseudos. Also check whether the bitsize is valid for the machine's insv instruction before moving the target into a pseudo for use with the insv. -- tbm at cyrius dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-17 18:18 --- Same with 4.1. 4.0.3 needs about 500MB ram at -O, while 4.1 get's killed with cc1: out of memory allocating 1134939624 bytes after a total of 43368448 bytes (though that first number looks interesting) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to fail|4.2.0 |4.2.0 4.1.2 Summary|[4.2 regression] A file that|[4.1/4.2 regression] A file |can not be compiled in |that can not be compiled in |reasonable time/space |reasonable time/space http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug target/28074] New: -mstackrealign generates very inefficient code
[EMAIL PROTECTED] xmm]$ cat x.c
#include emmintrin.h
extern char *e1 (void);
char *e1 (void)
{
volatile __m128 dummy = _mm_set_ps1(0.f);
return OK;
}
[EMAIL PROTECTED] xmm]$ /usr/gcc-4.2/bin/gcc -m32 -O -msse2 -S -mstackrealign
x.c
[EMAIL PROTECTED] xmm]$ cat x.s
.file x.c
.section.rodata.str1.1,aMS,@progbits,1
.LC0:
.string OK
.text
.globl e1
.type e1, @function
e1:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ecx
subl$20, %esp
xorps %xmm0, %xmm0
movaps %xmm0, -24(%ebp)
movl$.LC0, %eax
addl$20, %esp
popl%ecx
popl%ebp
leal-4(%ecx), %esp
ret
.size e1, .-e1
.ident GCC: (GNU) 4.2.0 20060613 (experimental) [trunk revision
114620 clean]
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED] xmm]$
Icc 9.1 generates:
.globl e1
e1:
..B1.1: # Preds ..B1.0
pushl %ebp #4.1
movl %esp, %ebp#4.1
andl $-16, %esp#4.1
subl $16, %esp #4.1
xorps %xmm0, %xmm0 #5.27
movaps%xmm0, (%esp) #5.19
movl $__STRING.0, %eax #6.10
movl %ebp, %esp#6.10
popl %ebp #6.10
ret #6.10
It doesn't waste ecx to align the stack.
--
Summary: -mstackrealign generates very inefficient code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28074
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-17 18:44 --- Btw, we do not die during inlining, but during optimization which is confronted with one gigantic basic block, as all BBs after inlining are merged by fixupcfg ;) Oh, and we die during RTL optimizations... but I wonder why we are not able to free up some memory before (lower gc params help for this, and we enter greg with 250MB used and it still wants cc1: out of memory allocating 1134939624 bytes after a total of 43487232 bytes So, more something for Matz/Vladimir. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at suse dot de Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #9 from pluto at agmk dot net 2006-06-17 19:24 --- patch posted on gcc-patches over month ago. still no response. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug middle-end/28075] New: gimplifier introduces unnecessary type conversions
typedef struct {
double min;
double max;
} interval;
inline interval add(interval x, interval y)
{
interval r;
r.min = x.min + y.min;
r.max = x.max + y.max;
return r;
}
interval foo (interval a, interval b, interval c)
{
return add (a, add (b, c));
}
for the temporary for gimplifying the nested call to add, the gimplifier
introduces a temporary of type TYPE_MAIN_VARIANT (interval), which survives
as added casts.
This happens here:
static inline tree
create_tmp_from_val (tree val)
{
return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name (val));
}
in the optimized dump we still have
foo (a, b, c)
{
double r$min;
double r$min;
double a$max;
double a$min;
struct interval y;
struct
{
double min;
double max;
} D.1542;
bb 2:
a$max = a.max;
a$min = a.min;
r$min = b.min + c.min;
D.1542.max = b.max + c.max;
D.1542.min = r$min;
y = (struct interval) D.1542;
r$min = y.min + a$min;
retval.max = y.max + a$max;
retval.min = r$min;
return retval;
}
by simply removing this TYPE_MAIN_VARAINT there we end up with two
temporary structures less:
Analyzing Edge Insertions.
foo (a, b, c)
{
double r$min;
bb 2:
r$min = b.min + c.min + a.min;
retval.max = b.max + c.max + a.max;
retval.min = r$min;
return retval;
}
--
Summary: gimplifier introduces unnecessary type conversions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, memory-hog, compile-time-hog
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] gimplifier introduces unnecessary type conversions
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-17 19:44 --- http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01236.html does not help (we don't FRE structure assignments). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] gimplifier introduces unnecessary type conversions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-17 19:45 --- I have a patch to fix the inliner to get rid of the unnecessary type conversions. This only happens with C front-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-17 19:45:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] gimplifier introduces unnecessary type conversions
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-17 19:51 --- This sort of blocks 28071 because we cannot optimize anything with the casts there and so regalloc blows up with the large BB. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||28071 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] inliner introduces unnecessary type conversions
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-17 19:53 --- Here is the patch: Index: tree-inline.c === --- tree-inline.c (revision 114740) +++ tree-inline.c (working copy) @@ -1081,6 +1081,8 @@ setup_one_parameter (copy_body_data *id, if (rhs == error_mark_node) return; + + STRIP_USELESS_TYPE_CONVERSION (rhs); /* We want to use MODIFY_EXPR, not INIT_EXPR here so that we keep our trees in gimple form. */ @@ -1267,6 +1269,8 @@ declare_return_variable (copy_body_data use = var; if (!lang_hooks.types_compatible_p (TREE_TYPE (var), caller_type)) use = fold_convert (caller_type, var); + + STRIP_USELESS_TYPE_CONVERSION (use); done: /* Register the VAR_DECL as the equivalent for the RESULT_DECL; that -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|28071 | nThis|| Summary|gimplifier introduces |inliner introduces |unnecessary type conversions|unnecessary type conversions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] [4.1/4.2 Regression] inliner introduces unnecessary type conversions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|inliner introduces |[4.1/4.2 Regression] inliner |unnecessary type conversions|introduces unnecessary type ||conversions Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug c/28045] Bitfield, , and optimization = bad code generation
--- Comment #2 from Jerry dot James at usu dot edu 2006-06-17 21:04 --- Created an attachment (id=11688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11688action=view) Testcase showing an optimizaton bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
[Bug c/28045] Bitfield, , and optimization = bad code generation
--- Comment #3 from Jerry dot James at usu dot edu 2006-06-17 21:05 --- I can confirm that both the mainline and the current 4.1 branch compile the testcase correctly. Nevertheless, both the current 4.1 branch and the mainline (revision 114741) are still miscompiling XEmacs when any optimization at all is used, so the testcase must be too simple. I just attached a more complex testcase that includes much of the actual code from XEmacs. I trimmed this down quite a bit from the original code, but it's still over 600 lines. This code illustrates the bug on both the i386 and x86_64 platforms. You have to link with the GMP library (-lgmp) when compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
[Bug c/28045] Bitfield, , and optimization = bad code generation
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-17 22:06 ---
Reduced testcase:
struct a
{
unsigned int bits : 1;
signed long val : ((sizeof(long) * 8) - 1);
};
int Fnegate (struct a b)
{
if ((-((long)b.val)) = ((long) ((1UL (((sizeof(long) * 8) - 1) - 1))
-1UL)) (-((long)b.val)) = (-(((long) ((1UL (((sizeof(long) * 8) - 1) -
1)) -1UL))) - 1))
return 0 ;
abort ();
}
int main ()
{
struct a b = {1, 1};
Fnegate (b);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
[Bug c/21920] alias violating
--- Comment #101 from steven at gcc dot gnu dot org 2006-06-17 22:06 --- Release folks from the I-use-C-but-do-not-understand-its-semantics punishment list. Seriously, though... There is no reason to spam every one of these people every time there is another duplicate of this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC|hurbain at cri dot ensmp dot| |fr, gopalv82 at gmail dot | |com, adruab at voria dot| |com, renzo at cs dot unibo | |dot it, devin at dungeon2 | |dot cainetworks dot com, c | |dot pop at free dot fr, zybi| |at talex dot pl, sorenj at | |us dot ibm dot com, bobm75 | |at gmail dot com, puvar at | |rambler-co dot ru, steger at| |mvtec dot com, | |grigory_zagorodnev at linux | |dot intel dot com | CC|fabdouze at caramail dot| |com, lucho at haemimont dot | |bg, davmac at ozonline dot | |com dot au, hayim at dv-| |networks dot com, linuxadmin| |at yandex dot ru, ja2morri | |at uwaterloo dot ca, davids | |at webmaster dot com, | |danfuzz at milk dot com,| |thomas dot anders at blue- | |cable dot de, gino at dtecta| |dot com, duraid at octopus | |dot com dot au | CC|christophe dot guillon at st| |dot com, cdfrey at netdirect| |dot ca, evgeny at nowecom | |dot ru, ghouston at arglist | |dot com, gcc at arbruijn dot| |dds dot nl, kalas at| |unicontrols dot cz, fm at | |4js dot com, Andreas dot| |Glowatz at philips dot com, | |horst dot lehser at hightec-| |rt dot com, steffen dot | |zimmermann at philips dot | |com, jochang at gmail dot | |com | CC|jason dot elbaum at gmail | |dot com, spelis at | |federation dot 3dlabs dot | |com, noaml at mainsoft dot | |com, andreg at discreet dot | |com, dmeggy at techsol dot | |ca, zengpan at goldhuman dot| |com, pjh at cs dot unh dot | |edu, oder at eleks dot lviv | |dot ua, rarob at erols dot | |com, julien dot durand dot | |1981 at gmail dot com, | |ulrich dot lauther at | |siemens dot com | CC|larschri at pvv dot ntnu dot| |no, cxl at ntllib dot org, | |strasbur at chkw386 dot ch | |dot pwr dot wroc dot pl,| |mike at arl dot army dot| |mil, d dot bonekaemper at | |rtsgroup dot net, sumii at | |saul dot cis dot upenn dot | |edu, czang at panasas dot | |com, pgonzalez at bluel dot | |com, pierre dot chatelier at| |club-internet dot fr, boris | |at lml dot ls dot fi dot upm| |dot es | CC|jfran at clip dot dia dot fi| |dot upm dot es, rick dot ju | |at sun dot com, charles at | |provis dot com, mor_gopal at| |yahoo dot com, l_heldt at | |poczta dot onet dot pl, djk | |at super dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/21920] alias violating
--- Comment #102 from dberlin at gcc dot gnu dot org 2006-06-17 23:42 --- Subject: Re: alias violating steven at gcc dot gnu dot org wrote: --- Comment #101 from steven at gcc dot gnu dot org 2006-06-17 22:06 --- Release folks from the I-use-C-but-do-not-understand-its-semantics punishment list. Seriously, though... There is no reason to spam every one of these people every time there is another duplicate of this bug. Uh, they are free to remove themselves from the cc list if they like. I'm certainly not going to special case the bugzilla cc list merging code just for this bug :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)
--- Comment #24 from rleigh at debian dot org 2006-06-18 00:27 --- ../gcc-20060613/configure --enable-languages=c,c++ --prefix=/home/rleigh/gcc-test --enable-shared --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-libstdcxx-debug $ ./wide terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted #0 0x0fcf77c8 in kill () at ../string/bits/string2.h:998 #1 0x0fcf754c in *__GI_raise (sig=6) at ../linuxthreads/sysdeps/unix/sysv/linux/raise.c:32 #2 0x0fcf8e68 in *__GI_abort () at ../sysdeps/generic/abort.c:88 #3 0x0ffb273c in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc-20060613/libstdc++-v3/libsupc++/vterminate.cc:98 #4 0x0ffaf87c in __cxxabiv1::__terminate (handler=0) at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:43 #5 0x0ffaf8b8 in std::terminate () at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:53 #6 0x0ffafa20 in __cxa_throw (obj=value optimized out, tinfo=value optimized out, dest=value optimized out) at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_throw.cc:76 #7 0x0ff3a050 in std::__throw_runtime_error (__s=value optimized out) at ../../../../gcc-20060613/libstdc++-v3/src/functexcept.cc:84 #8 0x0ffadd64 in std::locale::facet::_S_create_c_locale (__cloc=value optimized out, __s=value optimized out) at c++locale.cc:141 #9 0x0ff40154 in _Impl (this=0x10013080, __s=0x6 Address 0x6 out of bounds, __refs=value optimized out) at ../../../../gcc-20060613/libstdc++-v3/src/localename.cc:185 #10 0x0ff41ac4 in locale (this=0x7fc83950, __s=value optimized out) at ../../../../gcc-20060613/libstdc++-v3/src/localename.cc:138 #11 0x100015e8 in main () at wide.cc:54 $ ./wide2 1 fffäß» fffäß» ./wide3 fffäß» 1 fffäß» Rebuilding libstdc++v3 with 'make CXXFLAGS=-O0 -g3': $ ./wide terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted (gdb) run Starting program: /home/rleigh/wbug/wide terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Program received signal SIGABRT, Aborted. 0x0fcc57c8 in kill () at ../string/bits/string2.h:998 998 ../string/bits/string2.h: No such file or directory. in ../string/bits/string2.h Current language: auto; currently c (gdb) bt #0 0x0fcc57c8 in kill () at ../string/bits/string2.h:998 #1 0x0fcc554c in *__GI_raise (sig=6) at ../linuxthreads/sysdeps/unix/sysv/linux/raise.c:32 #2 0x0fcc6e68 in *__GI_abort () at ../sysdeps/generic/abort.c:88 #3 0x0ffaf7d4 in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc-20060613/libstdc++-v3/libsupc++/vterminate.cc:98 #4 0x0ffaa238 in __cxxabiv1::__terminate (handler=0xffaf5ac __gnu_cxx::__verbose_terminate_handler()) at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:43 #5 0x0ffaa288 in std::terminate () at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:53 #6 0x0ffaa534 in __cxa_throw (obj=0x10013130, tinfo=0xffe2d58, dest=0xff1ea3c ~runtime_error) at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_throw.cc:76 #7 0x0ff120e4 in std::__throw_runtime_error (__s=0xffb7e04 locale::facet::_S_create_c_locale name not valid) at ../../../../gcc-20060613/libstdc++-v3/src/functexcept.cc:84 #8 0x0ffa7624 in std::locale::facet::_S_create_c_locale ([EMAIL PROTECTED], __s=0x1001306c en_GB.UTF8) at c++locale.cc:141 #9 0x0ff1bda4 in _Impl (this=0x10013080, __s=0x1001306c en_GB.UTF8, __refs=1) at ../../../../gcc-20060613/libstdc++-v3/src/localename.cc:185 #10 0x0ff1de70 in locale (this=0x7fd11950, __s=0x10002364 ) at ../../../../gcc-20060613/libstdc++-v3/src/localename.cc:138 #11 0x10001748 in main () at wide.cc:54 $ ./wide2 1 fffäß» fffäß» $ ./wide3 fffäß» 1 fffäß» Regards, Roger -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
[Bug rtl-optimization/28062] [4.1 regression] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #9 from tbm at cyrius dot com 2006-06-18 01:09 --- (In reply to comment #7) It works with 4.2.0 20060617. Hmm. (sid)46:[EMAIL PROTECTED]: ~/tmp/gcc/4.2/gcc] ./cc1 -O2 ~/m.c NSMakePoint RelativePoint g Analyzing compilation unitPerforming intraprocedural optimizations Assembling functions: g /home/tbm/m.c: In function g: /home/tbm/m.c:24: internal compiler error: in simplify_subreg, at simplify-rtx.c:4466 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. zsh: exit 4 ./cc1 -O2 ~/m.c (sid)47:[EMAIL PROTECTED]: ~/tmp/gcc/4.2/gcc] ./xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/tbm/scratch/gcc-4.2/configure --disable-bootstrap --enable-languages=c Thread model: posix gcc version 4.2.0 20060617 (experimental) (sid)48:[EMAIL PROTECTED]: ~/tmp/gcc/4.2/gcc] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug rtl-optimization/28062] [4.1/4.2 regression] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-18 02:58 --- You know what I have a fix for an inliner bug in my tree which also fixes this bug. I am going to test that patch fully and submit it for both 4.1.x and 4.2.x. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28075 Known to fail|4.1.1 |4.1.1 4.2.0 Known to work|4.0.4 4.2.0 |4.0.4 Summary|[4.1 regression] ICE in |[4.1/4.2 regression] ICE in |simplify_subreg, at |simplify_subreg, at |simplify-rtx.c:4466 |simplify-rtx.c:4466 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
