[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #21 from guenter at roeck-us dot net 2006-08-29 19:12 --- This bug fix causes severe problems with all e500 double precision floating point code. It generates code such as : ... evldd 9,104(31) stw 9,112(31) stw 10,116(31) ... i.e., the compiler believes that a floating point value is in (r9,r10), while it is in LO(r9),HI(r9). Evidence is that any glibc compiled with a gcc including the fix fails all over the place. printf() of any float does not work. The fractional result of modf() is bad, for example. Just a heads up, I will try to submit a bug report after I find a simple test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #23 from guenter at roeck-us dot net 2006-08-29 20:23 ---
Here is a test case:
double calc(double val, double *result)
{
double f = val - (double)((int)val);
*result = val - f;
if (!val)
return val - *result;
else
return val;
}
Compile with:
gcc testc2.c -S -mcpu=8548 -mfloat-gprs=double -o testc2.S
Generates the following (bad) code:
.L2:
evldd 0,24(31)
evstdd 0,40(31)
.L4:
evldd 9,40(31)
stw 9,48(31)
stw 10,52(31)
lwz 9,48(31)
"evldd 9,40(31)" is generated from "evldd%X1 %0,%y1".
Unfortunately, I don't know enough to have a clue
what needs to be changed to fix this, though I did find
out that simply replacing "evldd%X1 %0,%y1" with
"evldd%X1 %0,%y1\;evmergelo %L0,%0,%0" is insufficient
and causes problems elsewhere.
Should I file a new bug or reopen this one ?
--
guenter at roeck-us dot net changed:
What|Removed |Added
CC| |guenter at roeck-us dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #27 from guenter at roeck-us dot net 2006-08-30 15:16 --- Created an attachment (id=12154) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12154&action=view) possible patch This might be a possible patch. It reverts to the original insn declaration, except for replacing the original "register_operand" with "input_operand". Generated code is less than optimal for the m->r case, but at least it appears to be correct. I tested this patch with the test cases provided. Also compiled a complete linux environment including perl which seems to work fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #28 from guenter at roeck-us dot net 2006-08-30 18:00 --- Created an attachment (id=12158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12158&action=view) Another possible patch Another possible patch. This one retains m->r handling, and thus produces somewhat more efficient code. Tested with existing test cases, and with linux / perl distribution compiled with both -O1 and -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #31 from guenter at roeck-us dot net 2006-08-30 20:40 --- > > By the way, the use of "%H" in the frob patterns is completely > wrong and should be removed. %H does not mean high register. > I did wonder about that, since it does not seem to be used elsewhere, but I did not really know or understand enough to comment on it. Regarding evlwwsplat - after looking into its definition, I don't think it should be used, but I may be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #33 from guenter at roeck-us dot net 2006-08-31 05:15 --- (In reply to comment #32) > I do not mean one evlwwsplat. I mean two in place of the two lwz, to > correspond to the evmergelo/evmergehi pair. > Hmm ... what would be the point ? evlwwsplat copies 32 bit memory content into the upper and lower 32 bits of the target register. The upper part is not needed in the given case, so moving data into it would not provide any benefit. Am I missing something ? Would using evlwwsplat make subsequent optimizations more difficult ? That might be an argument against it. Other than that, I don't really care which opcodes to use, as long as the resulting code works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #38 from guenter at roeck-us dot net 2006-09-02 13:23 --- (In reply to comment #36) > Subject: Re: [4.1/4.2 Regression] returning constant double > > What is confusing to me is that the r->r case is using evmergehi > and evmergelo. This is placing the value in both halves of the SIMD > register. It seems like this could have been done with two "mr". > > It is ambiguous whether the pattern is trying to load the full 64 > bit register or not. > I think it is supposed to move the upper part of %1 to %0, and the lower part of %1 to %L0. So it might be possible to replace it with evmergehi %0,%1,%1\;mr %L0,%1 (In reply to comment #36) > Subject: Re: [4.1/4.2 Regression] returning constant double > > What is confusing to me is that the r->r case is using evmergehi > and evmergelo. This is placing the value in both halves of the SIMD > register. It seems like this could have been done with two "mr". > > It is ambiguous whether the pattern is trying to load the full 64 > bit register or not. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/30259] ICE on valid code
--- Comment #5 from guenter at roeck-us dot net 2007-02-04 16:40 --- Problem is seen with 4.1.2 release candidate. Build is successful with proposed patch for bug 30270 applied. Not really my call to make, but it appears that this is neither P3 nor severity "normal". Also, the status of "unconfirmed" appears to be inappropriate, as the problem is easy to reproduce. -- guenter at roeck-us dot net changed: What|Removed |Added CC| |guenter at roeck-us dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
[Bug c/30717] New: Compile error with e500 target on gcc 4.1/4.2
glibc 2.3.6 fails to compile with gcc 4.1.2 dated 11/24/06 or later, or
matching gcc version 4.2.x, if gcc is compiled for e500 or e500v2 CPUs.
The following code is a shortened test case.
#define testmacro(mem) \
({ \
__typeof (*(mem)) __val; \
__asm __volatile (" addi%0,%2,1\n"\
: "=&b" (__val), "=m" (*mem)\
: "b" (mem), "m" (*mem) \
: "cr0", "memory"); \
__val;\
})
struct teststruct1
{
int count;
} __attribute__ ((packed));
struct teststruct2
{
int count;
};
void testfunc (struct teststruct1 *s1, struct teststruct2 *s2)
{
int v;
testmacro(&v);// ok
testmacro(&s1->count);// fails
testmacro(&s2->count);// ok
}
Compilation output:
$ ppc-teak-linuxspe1-gcc -c testcc.c
testcc.c: In function 'testfunc':
testcc.c:26: error: output number 1 not directly addressable
testcc.c:26: warning: use of memory input without lvalue in asm operand 3 is
deprecated
$
The problem is caused by the addition of MASK_STRICT_ALIGN into the processor
mask for 8540 and 8548 CPUs in various locations; if the MASK_STRICT_ALIGN
definitions added between gcc-4.1-20061117 and gcc-4.1-20061124 are removed,
everything compiles fine.
Problem is not seen if gcc is compiled for ppc or powerpc targets.
--
Summary: Compile error with e500 target on gcc 4.1/4.2
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guenter at roeck-us dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
[Bug c/30717] Compile error with e500 target on gcc 4.1/4.2
--- Comment #1 from guenter at roeck-us dot net 2007-02-06 19:28 --- Turns out that compilation is fine if I compile with -mno-strict-align. Maybe this is not a bug after all but simply changed semantics ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
[Bug c/30717] Compile error with e500 target on gcc 4.1/4.2
--- Comment #3 from guenter at roeck-us dot net 2007-02-06 19:41 --- Does that mean this is really a glibc problem ? In glibc, the problem occurs with an atomic_increment() on an element of a packet structure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
