: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-09-05 12:41
---
(In reply to comment #4)
Anyways I am going to test the obvious fix unless you (Ulrich) want to do it.
Please go ahead, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-09-05 12:47
---
(In reply to comment #5)
Is this also supposed to fix the problem I posted in comment #2? I applied
that
patch to my gcc but it didn't fix the generated code for me. It's just weird
because the bug only
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-10-24 19:03
---
Sorry for missing that bug. The proposed patch is OK -- thanks for
catching this.
As to the general problem, I think you're right that we need to further
constrain the range of accepted offsets. However
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-15
12:18 ---
The smaller test case also still ICEs on s390. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19865
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18
17:42 ---
I think the middle-end *should* allow back-ends to use SUBREGs
in that way. cleanup_subreg_operands should really act only on
SUBREGs that are part of an operand, and not on SUBREGs that
are part
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18
18:45 ---
OK, now I see the problem: cleanup_subreg_operands *does* indeed
touch only operands. However, the result of the splitter matches
the *llgt_didi insn instead of *llgt_disi, because after reload
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18
19:01 ---
This test case fails on s390(x) as well; in fact it is quite annoying
because it causes the whole test suite to hang ...
The reason for this appears to be that the Ada runtime has installed
a segfault
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-18
21:15 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20054
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09
16:09 ---
I cannot reproduce the problem on today's GCC 4.0.0 version ...
What is different for you? Do you have any patches on top?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20917
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09
16:16 ---
D'oh. Ignore my previous post; I forgot that the 4.0 branch now defaults
to checking disabled. I can indeed reproduce the problem, an am looking
into it now ...
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09
18:26 ---
Here's a reduced test case:
extern void abort (void);
extern void **alloc (void);
void *test (void)
{
void **p = alloc ();
if (!p) abort ();
__builtin_set_thread_pointer (p);
return *p
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-11
19:40 ---
Reduced testcase:
struct point { double x, y; };
extern void use (struct point);
void test (struct point *pc, struct point p1)
{
struct point p0 = *pc;
if (p0.x == p1.x p0.y == p1.y)
use (p0
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-16
15:48 ---
The problem originates in find_reloads_subreg_address, which decides
to widen access to a memory reference. The instruction we have is:
(insn 129 127 130 10 (parallel [
(set (reg:SI 106
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-05-27
16:05 ---
I'm seeing the failure on s390 as well. What appears to happen is that
the main program calls the library routine
static void
eoshift0 (gfc_array_char * ret, const gfc_array_char * array,
int
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-06-06
15:57 ---
Here's another reduced test case, this time without
uninitialized variables:
// ICEs with -O2 -fPIC
struct args
{
short int matrix[8][8];
char **current;
};
int test (struct args *args, char *init
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-06-14
10:36 ---
A change like this:
static void
+eoshift0 (gfc_array_char * , const gfc_array_char *,
+ int, const char *, int);
+
+static void
eoshift0 (gfc_array_char * ret, const gfc_array_char * array
-alleve.adb
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: s390x
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-04 19:11
---
(In reply to comment #2)
Could you try the following fix?
Yes, this fixes the problem. Bootstrap and regression test passes
on s390x-ibm-linux (and s390-ibm-linux) with this fix.
The following test case
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-04 20:16
---
(In reply to comment #4)
Thanks. ce3107b is new to me but all the others are fully understood.
It looks like ce3107b is one of those spurious failures I'm getting from
time to time -- I've never quite
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-08 16:10
---
FYI -- this also breaks bootstrap on s390-ibm-linux and s390x-ibm-linux:
../../../gcc-head/libgfortran/io/unit.c: In function 'find_unit_1':
../../../gcc-head/libgfortran/io/unit.c:269: internal compiler error
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-02-08 21:44
---
The spurious failures are always in different test cases for me as well ...
In fact, I now did a re-test and only see the four well-understood failures:
FAIL: c32001e
FAIL: c64105b
FAIL: c95086b
FAIL
--- Comment #10 from uweigand at gcc dot gnu dot org 2006-02-08 22:36
---
(In reply to comment #9)
The first 3 are so well-understood as to be fixed on my machine. :-) We are
working on the 4th.
Excellent!
Will you be committing the patch, or is this not the proper fix?
It's
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-10 20:00
---
Yup. See how this is handled in config/s390/linux-unwind.c:
/* If we got a SIGSEGV or a SIGBUS, the PSW address points *to*
the faulting instruction, not after it. This causes the logic
in unwind
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-10 20:34
---
(In reply to comment #4)
Not all the targets have the luxury of spare register slots.
I guess we were lucky here ;-)
So the current proposal is to add a new CIE augmentation that will signify
a signal frame
--- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57
---
(In reply to comment #17)
(e.g. s390/linux-unwind.h was doing that, although just for 2 selected
signals, which wasn't good enough, as e.g. all async signals need to be
handled the same).
We've actually
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: powerpc-*-linux
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-04-06 14:03
---
(In reply to comment #3)
Ulrich, can you prepare a patch or should I do so?
It would be great if you could do that, I don't yet
have a proper setup for ppc testing ...
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-04-13 11:47
---
I've now tested and submitted the patch, thanks.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-04-13 20:27
---
Subject: Bug 27006
Author: uweigand
Date: Thu Apr 13 20:26:59 2006
New Revision: 112923
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112923
Log:
2006-04-13 Paolo Bonzini [EMAIL PROTECTED
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-04-13 20:33
---
Subject: Bug 27006
Author: uweigand
Date: Thu Apr 13 20:33:51 2006
New Revision: 112924
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112924
Log:
2006-04-13 Paolo Bonzini [EMAIL PROTECTED
--- Comment #10 from uweigand at gcc dot gnu dot org 2006-04-13 20:35
---
Fixed for 4.1 and mainline.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-05-22 13:27
---
Looking somewhat more into this problem, there are other places where
reload decides to reload an CONST_INT as address. Where this happens,
it usually uses Pmode as the mode to do the reload in (which makes
sense
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-26 12:58
---
This looks like a source-code problem. The assembler instruction
union {DItype __ll; struct {USItype __h, __l;} __i; } __x;
__asm__ (lr %N0,%1\n\tmr %0,%2 : =r (__x.__ll)
: r
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-05-26 20:22
---
Subject: Bug 27661
Author: uweigand
Date: Fri May 26 20:21:53 2006
New Revision: 114141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114141
Log:
PR rtl-optimization/27661
* reload.c
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-31 16:59
---
I'm not sure (subreg:SF (const_int)) is canonical RTL, I haven't seen
subregs of anything but REG or MEM.
In any case, I don't really see what this would buy us over an UNSPEC -- will
the generic simplifier
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-06-01 21:30
---
Yes, that makes sense -- in fact, it looks like altivec_vslw_v4sf can then be
removed as well. I'm currenly testing a patch to that effect ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-06-06 17:01
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:01:27 2006
New Revision: 114438
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114438
Log:
PR target/27842
* config/rs6000/altivec.md
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-06-06 17:05
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:04:56 2006
New Revision: 114439
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114439
Log:
PR target/27842
* config/rs6000/altivec.md
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-06-06 17:10
---
Fixed on 4.1 branch and mainline.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-07-14 19:27
---
Yes, looks like this is long fixed. Closing bug now.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from uweigand at gcc dot gnu dot org 2005-11-15 18:31
---
Just one additional comment: the patch from comment #10 was rejected,
maybe because it required changes to the core gimplifier.
However, I've tested just the Ada front-end pieces from that patch
--- Comment #30 from uweigand at gcc dot gnu dot org 2005-11-17 01:08
---
With that patch applied, Ada bootstraps on s390-ibm-linux and
s390x-ibm-linux. Regression test results are at:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00831.html
http://gcc.gnu.org/ml/gcc-testresults
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-17 12:45
---
It looks like the simplify-rtx patch is not really the cause of the problem,
it simply exposes a pre-existing bug in combine and/or flow.
Before combine, we have a situation that looks like (simplified):
insn
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-12-09 11:20
---
Subject: Bug 25311
Author: uweigand
Date: Fri Dec 9 11:20:40 2005
New Revision: 108278
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108278
Log:
PR target/25311
* config/s390/s390.c
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-12-09 11:26
---
Subject: Bug 25311
Author: uweigand
Date: Fri Dec 9 11:26:47 2005
New Revision: 108279
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108279
Log:
PR target/25311
* config/s390/s390.c
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot
|dot org
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-12-09 11:29
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from uweigand at gcc dot gnu dot org 2005-12-09 11:30
---
Looks like a reload problem, I'll be posting a patch ...
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-12-14 23:35
---
Subject: Bug 25310
Author: uweigand
Date: Wed Dec 14 23:34:51 2005
New Revision: 108543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108543
Log:
PR rtl-optimization/25310
* reload1.c
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-12-14 23:40
---
Subject: Bug 25310
Author: uweigand
Date: Wed Dec 14 23:40:22 2005
New Revision: 108544
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108544
Log:
PR rtl-optimization/25310
* reload1.c
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-12-14 23:40
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #11 from uweigand at gcc dot gnu dot org 2005-12-16 18:05
---
Patch posted.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from uweigand at gcc dot gnu dot org 2005-12-18 16:06
---
Subject: Bug 21041
Author: uweigand
Date: Sun Dec 18 16:06:55 2005
New Revision: 108760
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108760
Log:
PR rtl-optimization/21041
* reload.c
--- Comment #13 from uweigand at gcc dot gnu dot org 2005-12-23 18:38
---
Subject: Bug 21041
Author: uweigand
Date: Fri Dec 23 18:38:43 2005
New Revision: 109019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109019
Log:
PR rtl-optimization/21041
* reload.c
--- Comment #14 from uweigand at gcc dot gnu dot org 2005-12-23 18:44
---
Subject: Bug 21041
Author: uweigand
Date: Fri Dec 23 18:44:07 2005
New Revision: 109020
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109020
Log:
PR rtl-optimization/21041
* reload.c
--- Comment #15 from uweigand at gcc dot gnu dot org 2005-12-23 18:45
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from uweigand at gcc dot gnu dot org 2006-01-19 23:10
---
This testcase also fails on s390x-ibm-linux (crash of f951).
The patch in comment 13 fixes the crash.
Any chance of getting the fix into 4.1?
--
uweigand at gcc dot gnu dot org changed:
What
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-01-19 23:19
---
FYI, the glibc folks have made a similar request w.r.t. adding
128-bit long double (IEEE quad) support for s390(x)-ibm-linux.
We're currently preparing a patch -- if there's still a chance
of getting
--- Comment #14 from uweigand at gcc dot gnu dot org 2006-01-20 18:39
---
Some additional details about the s390x failure. This is caused by a
miscompile of the fdd2a00__write__2 support routine:
lg %r4,168(%r15) # 35*movdi_64/8 [length = 6]
lg
--- Comment #25 from uweigand at gcc dot gnu dot org 2006-01-25 18:03
---
Yes, the patch fixes the problem on s390x.
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-01-27 18:43
---
Thanks for fixing this!
Any chance of getting the fix into 4.1, or this is too risky?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-01-30 12:31
---
The reduced testcase build fine for me with current 4.1 ...
Can you send me the full test case, and the assembler file you get?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-01-30 18:32
---
This appears to be a pre-existing bug in s390_decompose_address,
that happens to be triggered by this particular glibc code.
The problem is the construct label1 - label2 used in the
source (b.t.w. is this usage
--- Comment #11 from uweigand at gcc dot gnu dot org 2006-01-31 01:06
---
Subject: Bug 26018
Author: uweigand
Date: Tue Jan 31 01:06:16 2006
New Revision: 110422
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110422
Log:
PR target/26018
* config/s390/s390.c
--- Comment #12 from uweigand at gcc dot gnu dot org 2006-01-31 01:09
---
Subject: Bug 26018
Author: uweigand
Date: Tue Jan 31 01:09:36 2006
New Revision: 110423
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110423
Log:
PR target/26018
* config/s390/s390.c
--- Comment #13 from uweigand at gcc dot gnu dot org 2006-01-31 01:11
---
Fixed in mainline and 4.1.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-01-15
00:45 ---
This is caused by instruction scheduling not noticing a dependency,
apparently because alias sets are set up incorrectly.
At the end of the tree optimizer phase we have:
L29:;
fortran_character_1[1]{lb
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-01-15
00:55 ---
This one fails on s390-ibm-linux as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-01-15
00:56 ---
And on s390x-ibm-linux too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-01-27
19:03 ---
Sorry for not looking at this problem earlier, I had completely missed
this bugzilla entry. (Andrew, if you see any new reports related to
s390 in the future, would you mind putting me on CC so I'm aware
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-01-27
23:42 ---
Fixed for 3.3.6 and 3.4.4.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-10
14:03 ---
Some more information about the problem.
The __builtin_memset call gets as V_MAY_DEF operands all global variables
(using the call_clobbered_vars mechanism). Initially, this does *not*
include global_int
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-14
18:55 ---
I guess this will fix this test case, but not the original Ada problem;
what happens there is that the constructor has an initializer of the
form ADDR_EXPR of CONSTRUCTOR. When SRA scalarizes
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-14
19:25 ---
(In reply to comment #7)
We *gimplify* in the middle of the optimization pipeline? Sigh.
See tree-sra.c:generate_one_element_init. Now, I don't see how to
cause this gimplification to create new
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-14
22:50 ---
(In reply to comment #5)
The error occurs when building this with
gnat1 -Ipath-to-srcdir/gcc/ada -O2 pr19865.adb
(I've tested a gnat1 configured for s390-ibm-linux.)
I'm sorry, I have mixed up
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-09-20 18:55
---
I don't have a i386 setup with valgrind, but I built a i386-cross from
current sources, and do not see any 'weird' notes.
Is the problem still reproducible with current sources? Maybe Jeff Law's
recent
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-15 10:46
---
As I understand it, generation of subregs the hardware does not support
should be prevented by the CANNOT_CHANGE_MODE_CLASS mechanism. Reload
would reload the full inner reg into a register that allows
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-18 12:47
---
On s390, CANNOT_CHANGE_MODE_CLASS does indeed return false for such
superclasses:
#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
(GET_MODE_SIZE (FROM) != GET_MODE_SIZE
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 15:54
---
David Edelsohn wrote:
One could view this problem as reload not obeying CANNOT_CHANGE_MODE_CLASS
because it should not try to spill just the SImode SUBREG instead of creating a
DImode temporary
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 16:20
---
Does this patch help?
Index: gcc/simplify-rtx.c
===
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.206
diff -c -p -r1.206
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 17:17
---
Well, as I understand it, SUBREG (MEM) is *supposed* to be generated
for the case of SUBREG (pseudo) where the pseudo gets a stack slot.
The scan_paradoxical_subregs mechanism was supposed to have
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 20:38
---
David Edelsohn wrote: Correction. While the reload changes fix the crash, it looks
like there still is a bug because the resulting code does not access the correct
SUBREG. It does not access the LSW
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 20:42
---
(My last message got messed up somehow, I'm trying again.)
David Edelsohn wrote:
Correction. While the reload changes fix the crash, it looks like there still
is a bug because the resulting code
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 21:04
---
well, as pointed out by David you do need in addition the change I
described in comment #20.
If you prefer a patch:
Index: gcc/recog.c
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
CC: gcc-bugs at gcc dot
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18184
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24
13:11 ---
You are apparently trying to build a bi-arch s390x-ibm-linux compiler;
this is possible only if you have *both* 64-bit and 31-bit libc developement
packages (including crt*.o) available.
You'll need
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24
13:27 ---
The inline assembly statement is impossible to reload under the
given circumstances. Note that the statement requires 12 general
purpose registers at the same time (6 inputs and 6 clobbers), but
using
--
What|Removed |Added
CC||uweigand at de dot ibm dot
||com
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24
14:50 ---
We have here the following situation before reload:
(insn 27 46 28 7 (set (reg:DI 118 [ D.1118 ])
(const_int 4294967295 [0x])) 313 {*movdi_internal32} (nil)
(nil))
where reg 118 gets
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24
14:56 ---
This new problem doesn't appear to have anything to do with GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-24
15:40 ---
It was an error message correctly explaining that (and why) a specific
inline assembly statment could not be compiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-25
18:33 ---
Now that RTH's validate_subreg patch is in, I guess the right fix for
this problem might be to always return a SUBREG in simplify_gen_subreg
unless that SUBREG is actually invalid.
What do you think
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-25
21:53 ---
This is not very feasible, since whether or not the address is required to be
offsettable depends on which alternative is selected; and the current flow of
find_reloads does all the address reloading
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-11-25
21:57 ---
(Trying again, this time hopefully with proper formatting.)
This is not very feasible, since whether or not the address
is required to be offsettable depends on which alternative is
selected
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-12-02
16:14 ---
As to 1), this can be achieved by marking the 'f' alternatives
in the *movdi_internal32 pattern as '!*f'; this will prevent
both regclass and reload from using the alternatives unless
there was a floating
1 - 100 of 196 matches
Mail list logo
