--- 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
--- 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
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
--- 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,
--- 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 placi
--- 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 b
--- 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
--- 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
som
--- 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 re
--- 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
--- 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
11 matches
Mail list logo
