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 binutil
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 d
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 re
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
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 misal
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.
I
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 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
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 fi
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, a
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 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: tha
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 f
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 i
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 fenv_t
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
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 wit
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 happenin
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
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
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
[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 G
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 Goto-san,
There is a bug in libm that results in unaligned access on hppa when calling
feholdexcept() or fegetenv(
24 matches
Mail list logo
