--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-02-24 21:46
---
Edmar --
Great, yes, that looks like the right information. However, it's unlikely that
I'll be able to personally look at this before 4.1.0.
Thanks,
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #11 from bugzilla-gcc at thewrittenword dot com 2006-02-24
22:03 ---
(In reply to comment #9)
> Can you try 3.4.5?
Same problem as 3.4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #2 from yichen dot xie at gmail dot com 2006-02-24 22:12
---
(In reply to comment #1)
> It seems like you are trying to
> deal with your own threading system instead of allowing the OS do its work.
>
This is indeed what I am trying to do, and C seems to be the perfect lang
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 22:38 ---
(In reply to comment #2)
> (In reply to comment #1)
> > It seems like you are trying to
> > deal with your own threading system instead of allowing the OS do its work.
> >
>
> This is indeed what I am trying to do,
--- Comment #4 from yichen dot xie at gmail dot com 2006-02-24 23:06
---
> Why not let the OS do its job? I still don't understand that idea.
It's a thread library that builds on top of pthreads, so yes, OS is doing its
job, and we're doing more on top of that. C is a natural choice f
--- Comment #2 from quanah at stanford dot edu 2006-02-24 23:09 ---
This seems to be because libsax_gcj_la-sax.o is not being built with -fPIC,
like it apparently needs to be:
[EMAIL
PROTECTED]:/afs/ir/src/pubsw/languages/gcc-build/amd64_linux26/x86_64-unknown-linux-gnu/libjava/extern
--- Comment #3 from quanah at stanford dot edu 2006-02-24 23:24 ---
This may be in part because two variables are not being set correctly:
"PICFLAG=" "PICFLAG_FOR_TARGET="
when building in libjava/
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-25 00:02 ---
ISO C is not your normal low level language any more. It actually tries to be
a high level language.
So this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Optimization on sample below creates a temporary
pointer &buf[i] where data is written. However
this pointer is not restored to &buf[0] when i
is set to 0.
Occurs on 3.3.3 but not 2.95. I realize that 3.3
is really old, but it would be useful to know if this
has already been fixed and if possibl
--- Comment #4 from quanah at stanford dot edu 2006-02-25 00:59 ---
Setting the PIC flags did not fix this issue. It appears impossible at this
time to build gcj on AMD64 with 4.0.x.
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
--- Comment #26 from rth at gcc dot gnu dot org 2006-02-25 01:00 ---
I agree we shouldn't mess with _Unwind_GetIP. While I kinda like the idea
behind _Unwind_SignalFrameContext, I'm not sure I like the idea of the
effectively mandatory back-to-back PLT calls. If you think that _U_SFC
With the following test case: Either an invalid argument or abort triggered on
READ depending on datasize. Initial test case from Dale Ranta Comment #15 of
pr26423. Seems to trigger for datasize less then 1022.
program test
integer,parameter :: datasize = 1020
dimension idata(d
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-02-25 01:24
---
I have reverted back several patches and the problem in Comment #15 is not a
recent regression. I have opened a new PR for this since it manifests
completely differently. See PR26464.
This PR26423 is fixed in
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #6 from yichen dot xie at gmail dot com 2006-02-25 01:55
---
(In reply to comment #5)
> ISO C is not your normal low level language any more. It actually tries to be
> a high level language.
>
> So this is not a bug.
>
I still don't think it's a good idea to treat thread
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-02-25 03:03
---
This does not fail with 4.0.2 , so it is a regression after all, but farther
back.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26464
On Fri, 2006-02-24 at 13:06 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 13:06
> ---
> Confirmed. Though VRP2 is just doing constant propagation at this point.
>
>
Last time i looked at a bug like this, it was actually
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-02-25 03:09 ---
Subject: Re: [4.2 regression] ICE in
add_virtual_operand, at tree-ssa-operands.c:1867
On Fri, 2006-02-24 at 13:06 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #2 from pinskia at gcc dot
--- Comment #13 from aoliva at gcc dot gnu dot org 2006-02-25 03:53 ---
It was GNU/Linux, for sure. Earlier gthr-posix.h used #pragma weak, which did
not require declarations for referenced symbols, whereas the new weakref
machinery requires earlier declarations to obtain the type for t
--- Comment #14 from shanwill44 at yahoo dot com 2006-02-25 07:18 ---
> I changed the libgcj.spec file manually to the second. That seems to work.
> So, my conclusion is to change the libgcj.spec.in.
> The following line:
> *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@
101 - 120 of 120 matches
Mail list logo
