--- Comment #3 from rask at sygehus dot dk 2007-08-04 15:37 ---
This appears to intentional. On systems without a prefix on labels, registers
are always prefixed with %. This is so that you can have global variables named
.e.g. edx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from rask at sygehus dot dk 2007-08-02 09:42 ---
It's still broken as of "4.3.0 20070729 (experimental)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29493
--- Comment #4 from rask at sygehus dot dk 2007-07-28 09:00 ---
This is not a GCC bug. The part that fails is broken, inline asm:
#APP
# 173 "include/asm/string.h" 1
movb %al,%ah
1: lodsb
cmpb %ah,%al
jne 2f
leal -1(%esi),20(%esp)
2:
--- Comment #3 from rask at sygehus dot dk 2007-07-27 23:05 ---
Fixed as of revision 127005.
--
rask at sygehus dot dk changed:
What|Removed |Added
Status
ble insn configuring libgcc
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target t
--- Comment #10 from rask at sygehus dot dk 2007-07-24 15:00 ---
Created an attachment (id=13959)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13959&action=view)
Patch to fix testcase when int isn't exactly 32 bits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
--- Comment #9 from rask at sygehus dot dk 2007-07-24 14:56 ---
This is not fully fixed yet. Compile these two functions with -O2
-fdump-tree-original:
void test5_1(int e)
{
if ((e >> 31) & 64)
foo();
}
typedef int myint;
void test5_2(myint e)
{
if ((e >> 3
--- Comment #5 from rask at sygehus dot dk 2007-07-22 22:56 ---
The point is exactly to align the stack. The call instruction decrements %esp
by 4 bytes, so GCC has to decrement %esp by another 12 bytes to keep the stack
aligned. See also bug target/13685.
--
http://gcc.gnu.org
--- Comment #3 from rask at sygehus dot dk 2007-07-22 16:47 ---
That is a known bug in GCC 3.4.3, causing the SSE code in f() to segfault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32849
--- Comment #2 from rask at sygehus dot dk 2007-07-22 08:25 ---
This bug had already been opened as 32746 and 32848. Please search for existing
bugs before opening new ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32850
--- Comment #1 from rask at sygehus dot dk 2007-07-21 23:03 ---
The testcase also fails on:
i686-pc-linux-gnu
x86_64-unknown-linux-gnu
v850-unknown-elf
sh-unknown-elf
frv-unknown-elf
cris-axis-elf
arm-unknown-elf
m32c-unknown-elf
Looking at gcc-testresults for i686-pc-linux-gnu
--- Comment #4 from rask at sygehus dot dk 2007-07-21 09:07 ---
Fixed as of revision 126318.
--
rask at sygehus dot dk changed:
What|Removed |Added
Status
--- Comment #4 from rask at sygehus dot dk 2007-07-19 13:31 ---
Created an attachment (id=13939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13939&action=view)
Test case for frv-unknown-elf with -O2 -g -mcpu=fr400
It breaks on frv-unknown-elf as well:
Program received
--- Comment #4 from rask at sygehus dot dk 2007-07-18 13:48 ---
Fixed as of revision 126720.
--
rask at sygehus dot dk changed:
What|Removed |Added
Status
--- Comment #3 from rask at sygehus dot dk 2007-07-18 11:27 ---
It happens on sh-unknown-elf too compiling newlib:
make[8]: Entering directory
`/home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2a/newlib/libc/stdlib'
Makefile:1333: warning: overriding commands for target `
27; (rtx const_int) in cris_print_index, at
config/cris/cris.c:499
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot o
--- Comment #13 from rask at sygehus dot dk 2007-07-17 09:53 ---
Read config.log. Look for messages about collect2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32785
--- Comment #2 from rask at sygehus dot dk 2007-07-16 11:34 ---
The test case was derived from newlib, btw.
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #1 from rask at sygehus dot dk 2007-07-16 11:25 ---
Created an attachment (id=13920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13920&action=view)
Slightly reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32776
'reg', have 'concatn' in
rhs_regno, at rtl.h:972
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #3 from rask at sygehus dot dk 2007-07-15 23:39 ---
There are test results for GCC 4.2.1 20070706 on arm-elf here:
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00334.html>.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32753
--- Comment #1 from rask at sygehus dot dk 2007-07-15 14:29 ---
I get something similiar with my 16-bit x86 port compiling libgcc:
/home/rask/cvsbuild/gcc/./gcc/xgcc -B/home/rask/cvsbuild/gcc/./gcc/ -nostdinc
-B/home/rask/cvsbuild/gcc/ia16-elf/newlib/ -isystem
/home/rask/cvsbuild/gcc
--- Comment #3 from rask at sygehus dot dk 2007-07-13 15:40 ---
Well, if you declare R as unsigned, GCC will still optimize away "if (R<0)".
;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
--- Comment #1 from rask at sygehus dot dk 2007-07-13 15:34 ---
I don't see how R can become negative:
R=0;
while (...)
{
...
R=R*5+[unsigned value here];
...
}
What am I missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
--- Comment #4 from rask at sygehus dot dk 2007-07-11 20:45 ---
In reply to comment #2:
Reload is unable to use a register with a REG_DEAD note for an output reload.
Look at the functions find_reload_regs(), order_regs_for_reload() and
find_reg() and pay attention to how they use chain
--- Comment #1 from rask at sygehus dot dk 2007-07-11 08:53 ---
I think (1) and (2) is just the register allocator being stupid. This sort of
thing can happen when the %rax at (1) was a different pseudo register than the
%rax at (2). The register allocator is supposed to be able to tie
--- Comment #5 from rask at sygehus dot dk 2007-07-07 17:26 ---
s/multiword subreg/multiword hard reg/g and s/comment #2/comment #3/g in
comment #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
--- Comment #4 from rask at sygehus dot dk 2007-07-07 16:08 ---
In reply to comment #1:
If you're splitting a multiword subreg (such as %rbx:%rcx) after reload, then
the prologue/epilogue code has no way of knowing that all use of %rbx is later
optimized away. I don't know
--- Comment #1 from rask at sygehus dot dk 2007-07-06 20:50 ---
Created an attachment (id=13856)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13856&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
tor-layout.c:220
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: x86_64-unknown
--- Comment #13 from rask at sygehus dot dk 2007-07-01 19:52 ---
This has regressed quite badly. Here's what we get with
-O2 -fomit-frame-pointer -m32 -march=pentium4:
fl:
movzbl %al, %eax # 21*zero_extendqisi2_movzbw[length
= 3]
movlx,
--- Comment #2 from rask at sygehus dot dk 2007-07-01 10:01 ---
Created an attachment (id=13810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13810&action=view)
First attempt at a patch
The attached patch makes the v850 build on x86_64. There are a few regressions
(when
--- Comment #1 from rask at sygehus dot dk 2007-07-01 09:37 ---
Additionally, the asm output has problems around the edges (seen in _pack_df):
mov 9218868437227405312,r14 # 395 *movdi_internal/1 [length
= 4]
mov 0,r15
--
rask at sygehus dot dk changed
dTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: v850-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32558
--- Comment #17 from rask at sygehus dot dk 2007-06-29 21:10 ---
Fixed for both m32c and avr, so closing.
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #18 from rask at sygehus dot dk 2007-06-27 19:48 ---
It has not been committed yet because I feared that it was causing the reload
failure. I have now verified that the reload failure still happens with a
pre-dataflow checkout, so I'll submit the patch. I think
--- Comment #16 from rask at sygehus dot dk 2007-06-27 19:15 ---
What's wrong with the patch at the top of comment 9? FWIW, I can now build the
m32c after this configure command:
$ /n/12/rask/src/all/configure --target=m32c-unknown-elf
--enable-languages=c,c++ --enable-cxx-flag
--- Comment #14 from rask at sygehus dot dk 2007-06-27 00:35 ---
Notice in comment 10 that there is no optimization flag. Just -O1 is enough to
make the reload failure go away. I'll see what the libstdc++ people have to say
about that.
--
http://gcc.gnu.org/bugzilla/show_bug.c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: powerpc-unknown-eabisim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32498
: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: mipsisa64-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32495
--- Comment #13 from rask at sygehus dot dk 2007-06-24 17:38 ---
I updated to revision 125983, which hasn't changed anything as far as I can
tell.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
--- Comment #24 from rask at sygehus dot dk 2007-06-24 13:04 ---
Subject: Re: [4.3 Regression] Segmentation
fault in build_classic_dist_vector_1()@tree-data-ref.c:2700
On Sun, Jun 24, 2007 at 02:50:37PM +0200, Sebastian Pop wrote:
> 2007-06-24 Sebastian Pop <
dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: m32c-unknown-elf avr-unknown-none h8300-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32471
--- Comment #11 from rask at sygehus dot dk 2007-06-21 18:19 ---
Disregard the comment about the code label use count. They have
LABEL_PRESERVE_P (/s) set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
--- Comment #10 from rask at sygehus dot dk 2007-06-21 16:15 ---
Created an attachment (id=13758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13758&action=view)
Preprocessed source code for the problem in comment 9.
$ ./xgcc -B./ -S -dp -o /dev/null ~/complex_io.cc
/ho
--- Comment #9 from rask at sygehus dot dk 2007-06-21 15:59 ---
I tried this on top of the patch in comment 3 of bug 32441:
Index: gcc/config/m32c/m32c.c
===
--- gcc/config/m32c/m32c.c (revision 125892)
+++ gcc/config
--- Comment #1 from rask at sygehus dot dk 2007-06-20 21:36 ---
Created an attachment (id=13750)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13750&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m
--- Comment #7 from rask at sygehus dot dk 2007-06-20 20:08 ---
This is something I have no clue about.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
--- Comment #5 from rask at sygehus dot dk 2007-06-20 17:24 ---
I'll CC DJ Delorie since he'll know why EH_RETURN_STACKADJ_RTX has been defined
that way.
--
rask at sygehus dot dk changed:
What|Removed
--- Comment #1 from rask at sygehus dot dk 2007-06-20 16:58 ---
Created an attachment (id=13747)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13747&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32431
iority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68hc11-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32431
--- Comment #11 from rask at sygehus dot dk 2007-06-20 13:52 ---
Ah, notice the mismatch in register sizes between prologue and epilogue:
(insn/f 59 5 60 2 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:5 (parallel
[
(set/f (mem:HI (plus:HI (reg/f:HI 8 sp
--- Comment #10 from rask at sygehus dot dk 2007-06-20 13:41 ---
I'm adding the m32c back because the testcase for bug 32069 fails with
optimization turned on:
$ ./xgcc -B./ /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c -S -dp -o
/dev/null -O1
/n/08/rask/src/gcc/gcc/test
--- Comment #3 from rask at sygehus dot dk 2007-06-20 13:25 ---
*** Bug 32419 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:25 ---
*** This bug has been marked as a duplicate of 32418 ***
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:24 ---
*** This bug has been marked as a duplicate of 32418 ***
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #2 from rask at sygehus dot dk 2007-06-20 13:24 ---
*** Bug 32420 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
ty: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.or
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:21 ---
Created an attachment (id=13742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13742&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
ty: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.or
ty: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.or
--- Comment #2 from rask at sygehus dot dk 2007-06-20 11:00 ---
Does it work for you if you apply patch 3 from bug other/32154?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12019
--- Comment #3 from rask at sygehus dot dk 2007-06-19 11:27 ---
You can use memcpy (&int, &float, min (sizeof (int), sizeof (float))) and vice
versa. I suppose you can also memcpy() into or out of a char array of the right
size.
If you were to use the GCC extension of using a u
--- Comment #5 from rask at sygehus dot dk 2007-06-17 08:43 ---
I agree that the insn is invalid. It probably should be something like this:
(parallel [
(set (reg:PSI 7 fb)
(mem:PSI (reg:PSI 7 fb) [0 S4 A8]))
(set (reg:PSI 8 sp
--- Comment #9 from rask at sygehus dot dk 2007-06-15 14:24 ---
Bug bootstrap/28949 is also similiar to this one.
Btw, this bug is the root cause of the error message 'Link tests are not
allowed after GCC_NO_EXECUTABLES' for newlib targets, so it should show up in
searche
--- Comment #3 from rask at sygehus dot dk 2007-06-14 15:43 ---
Finally, I can close a bug as fixed. :-)
--
rask at sygehus dot dk changed:
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target tr
o missing thread
synchronization primitives
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sy
--- Comment #7 from rask at sygehus dot dk 2007-06-14 10:36 ---
I've thought about adding ENOSYS stubs for the missing functions to libgloss.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
1508
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GC
--- Comment #7 from rask at sygehus dot dk 2007-06-13 13:36 ---
Looking at this again, I don't think the transformation I'm making with the
splitter is valid, because I'm making up a zero extension which wasn't there to
begin with. The upper part could have been
--- Comment #8 from rask at sygehus dot dk 2007-06-11 22:05 ---
Bug bootstrap/12019 looks similiar to this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
--- Comment #2 from rask at sygehus dot dk 2007-06-09 11:02 ---
It is still broken as of revision 125570.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68hc11-un
--- Comment #7 from rask at sygehus dot dk 2007-06-08 17:35 ---
Created an attachment (id=13669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669&action=view)
Patch v3 to add -L and -B as necessary
This patch should fix the mep* case that I accidentally deleted.
--
--- Comment #4 from rask at sygehus dot dk 2007-06-06 10:33 ---
I see no reason to mark this enhancement request as invalid.
As to generating reasonable x86 code for overflow checks written in C, it
isn't completely hopeless. I did an experiment with my 16-bit x86 port. Fir
--- Comment #6 from rask at sygehus dot dk 2007-06-01 19:56 ---
According to the documentation, -B passes -L to the linker, so there is no need
to pass both. It seems to work as documented.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
--- Comment #4 from rask at sygehus dot dk 2007-05-31 22:37 ---
Created an attachment (id=13642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13642&action=view)
Patch v2 to add -L and -B as necessary
I believe I have covered boths cases of linker script placement.
The c
--- Comment #2 from rask at sygehus dot dk 2007-05-31 21:01 ---
Created an attachment (id=13641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13641&action=view)
Patch to add -L and -B as necessary
This happens on all targets except m32c-*-*. I'm testing the at
--- Comment #1 from rask at sygehus dot dk 2007-05-31 10:02 ---
The same thing happens when configuring with --target==mcore-unknown-elf, only
the startup file is crt0.c instead of sim-crt0.o.
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #12 from rask at sygehus dot dk 2007-05-30 21:29 ---
The AVR is unusual in having
#define STACK_PUSH_CODE POST_DEC
#define STACK_GROWS_DOWNWARD
where most targets would have PRE_DEC when the stack grows downward. The
middle-end tries to synthesize the missing pushdi
org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-eabisim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
d at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-eabisim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
--- Comment #1 from rask at sygehus dot dk 2007-05-26 15:50 ---
Created an attachment (id=13615)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13615&action=view)
sendmsg.c preprocessed
I have attached the preprocessed sendmsg.c in case you need it.
--
http://gcc.
d at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i386-unknown-netbsdelf2.0.2
GCC host triplet: i386-unknown-netbsdelf2.0.2
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32097
--- Comment #1 from rask at sygehus dot dk 2007-05-24 13:28 ---
Created an attachment (id=13608)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13608&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32069
it-wide-types
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i686-pc-li
MED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i386-unknown-netbsdelf2.0.2
GCC host triplet: i386-unknown-netbsdelf2.0.2
GCC target tr
--- Comment #8 from rask at sygehus dot dk 2007-01-07 14:16 ---
Created an attachment (id=12869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12869&action=view)
updated patch in testing
Here's a new patch as discussed. The GCC 4.2 branch now manages to build
libgcc
--- Comment #7 from rask at sygehus dot dk 2007-01-07 14:07 ---
I tried to build several versions to find out which ones work:
GCC 4.0.3 works (dies later compiling newlib/libc/math/e_j0.c).
GCC 4.1.0 unknown (fails to compile rs6000.c).
GCC 4.1.1 works (dies later with bug 27075).
GCC
--- Comment #5 from rask at sygehus dot dk 2007-01-06 14:28 ---
The condition in t-ppccomm is written just like the example in the GNU Make
documentation ("Conditionals that Test Flags"), except for the missing
parentheses.
Indeed toplevel libgcc fixes this, revision 1205
--- Comment #3 from rask at sygehus dot dk 2007-01-05 17:29 ---
Created an attachment (id=12861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12861&action=view)
patch in testing to fix typo
The option -specs=ldblspecs is added by gcc/config/rs6000/t-ppccomm when
co
bgcc2 powitf2 with ICE
in gen_reg_rtx
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at s
--- Comment #9 from rask at sygehus dot dk 2006-12-11 20:24 ---
Created an attachment (id=12785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12785&action=view)
Partial patch
Please try this patch. It removes the ICE, but the code may not run on 68000
and 68010 CPUs
--- Comment #1 from rask at sygehus dot dk 2006-04-23 14:46 ---
Created an attachment (id=11317)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11317&action=view)
Preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27266
cc dot gnu dot org
ReportedBy: rask at sygehus dot dk
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=27266
98 matches
Mail list logo
