On Fri, Oct 14, 2005 at 12:02:04AM -0400, Daniel Jacobowitz wrote:
...
Just to clarify: if you fix the inline asm in glibc, then you don't
need to recompile any of the currently broken libraries or
applications.
We don't need to fix the inline asm - the kernel is required to
handle the
On Thu, Oct 13, 2005 at 11:58:10PM -0600, Grant Grundler wrote:
On Fri, Oct 14, 2005 at 12:02:04AM -0400, Daniel Jacobowitz wrote:
...
Just to clarify: if you fix the inline asm in glibc, then you don't
need to recompile any of the currently broken libraries or
applications.
We don't
On Fri, Oct 14, 2005 at 10:50:38AM +0200, Aurelien Jarno wrote:
On Thu, Oct 13, 2005 at 11:58:10PM -0600, Grant Grundler wrote:
On Fri, Oct 14, 2005 at 12:02:04AM -0400, Daniel Jacobowitz wrote:
...
Just to clarify: if you fix the inline asm in glibc, then you don't
need to recompile
Aurelien Jarno wrote:
[...]
Oh yes, BTW, I have seen that glibc does not built anymore on hppa. It
seems the new binutils does not accept some assembly instructions.
Currently I am doing my tests with binutils 2.16.1. It has to be fixed
before uploading a new glibc, but unfortunately I
On Fri, Oct 14, 2005 at 10:28:27PM +, Joel Soete wrote:
Aurelien Jarno wrote:
[...]
Oh yes, BTW, I have seen that glibc does not built anymore on hppa. It
seems the new binutils does not accept some assembly instructions.
Currently I am doing my tests with binutils 2.16.1. It
[Ccing [EMAIL PROTECTED], because there is people who know hppa assembly
there]
Hi!
Steve Langasek a écrit :
Package: libc6
Version: 2.3.5-6.0.1
Severity: serious
Justification: this is the bug that broke the toolkit that held up the \
C++ transition that ruined the port that HP built
Hey
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote:
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
source code:
__asm__ (
fstd,ma %%fr0,8(%1)\n
fstd,ma %%fr1,8(%1)\n
fstd,ma
This one time, at band camp, Steve Langasek said:
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote:
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
I also don't speak hppa assembly, but it is obvious that the code
Hi,
Stephen Gran a écrit :
This one time, at band camp, Steve Langasek said:
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote:
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
I also don't speak hppa assembly, but it
On Fri, Oct 14, 2005 at 12:20:50AM +0200, Aurelien Jarno wrote:
- gcc-4.0 generates wrong code
For that see my attached file. It's the file from the glibc, with the
code from Steve pasted at the end. It works with gcc-3.4, but fails
with gcc-4.0.
I don't think that's what is happening
On Thu, Oct 13, 2005 at 11:05:01PM +0100, Stephen Gran wrote:
I think you are misunderstanding him, Steve, or I am misunderstanding
the whole thing (which is not unlikely). I think Aurelian is saying
that the same source code that you supplied builds and runs fine with
gcc-3.4, but not with
On Thu, Oct 13, 2005 at 05:04:55PM -0700, Steve Langasek wrote:
To say that this is a compiler bug, you would have to show that gcc-4.0 is
*wrong* to 32-bit align the fenv_t struct instead of 64-bit aligning it.
You'd have to check with the compiler folks to be sure, but I don't think
this is
I don't think that's what is happening at all: I think that in one of
these cases, your test file's on-stack fenv_t is aligned, and on the
other it isn't. The code you posted for gcc 4.0 looks fine. I think
the assembly is broken or the definition of fenv_t.
drow is right, as usual. our
On Fri, Oct 14, 2005 at 08:40:20AM +0800, Randolph Chung wrote:
I don't think that's what is happening at all: I think that in one of
these cases, your test file's on-stack fenv_t is aligned, and on the
other it isn't. The code you posted for gcc 4.0 looks fine. I think
the assembly is
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote:
drow is right, as usual. our fenv_t needs to be defined with
__attribute__((aligned(8))) or similar.
I'd recommend fixing the asm instead: that's an ABI change and would
require heinous rebuilds.
Sorry - I'm not
On Thu, Oct 13, 2005 at 09:17:21PM -0600, Grant Grundler wrote:
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote:
drow is right, as usual. our fenv_t needs to be defined with
__attribute__((aligned(8))) or similar.
I'd recommend fixing the asm instead: that's an ABI
Daniel Jacobowitz a écrit :
On Thu, Oct 13, 2005 at 09:17:21PM -0600, Grant Grundler wrote:
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote:
drow is right, as usual. our fenv_t needs to be defined with
__attribute__((aligned(8))) or similar.
I'd recommend fixing the asm
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote:
Ok, that's mean that theoretically it would break the ABI, but
practically, it does not break the ABI as the alignment is the same
(otherwise we would also have noticed SIGBUS in other applications).
Said in other words,
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote:
Ok, that's mean that theoretically it would break the ABI, but
practically, it does not break the ABI as the alignment is the same
(otherwise we would also have noticed SIGBUS in other applications).
Just to clarify: if you fix
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote:
On Fri, Oct 14, 2005 at 08:40:20AM +0800, Randolph Chung wrote:
I don't think that's what is happening at all: I think that in one of
these cases, your test file's on-stack fenv_t is aligned, and on the
other it isn't. The
Daniel Jacobowitz a écrit :
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote:
Ok, that's mean that theoretically it would break the ABI, but
practically, it does not break the ABI as the alignment is the same
(otherwise we would also have noticed SIGBUS in other applications).
Daniel Jacobowitz a écrit :
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote:
Ok, that's mean that theoretically it would break the ABI, but
practically, it does not break the ABI as the alignment is the same
(otherwise we would also have noticed SIGBUS in other applications).
On Fri, Oct 14, 2005 at 06:17:46AM +0200, Aurelien Jarno wrote:
I have attached a patch that changes the alignment of the f_env type. I
have tested it separately from the glibc, it works.
Yes, your patch looks right.
Please also add the following comment in front of the fenv_t declaration.
It
23 matches
Mail list logo
