LAST_UPDATED:
Native configuration is m68k-linux (crest)
=== gpc tests ===
Running target any
FAIL: assumptions.pas
FAIL: capexp.pas
FAIL: cfor.pas
FAIL: emil11a.pas
FAIL: emil11b.pas
FAIL: emil11c.pas
FAIL: emil11d.pas
FAIL: expotst.pas
FAIL: fjf129.pas
FAIL: fjf170.pas
FAIL: f
LAST_UPDATED:
Native configuration is ia64-linux (caballero)
=== gpc tests ===
Running target any
FAIL: arctan.pas
FAIL: fjf512.pas
FAIL: fjf762a.pas
FAIL: math.pas
=== gpc Summary ===
# of tests3910
# of expected passes 3903
# of unexpecte
LAST_UPDATED:
Native configuration is i486-linux (cachaca)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3909
# of unsupported tests1
/home/packages/gcc/3.3/gcc-3.3-3.3.5/build/gcc/xgpc ver
LAST_UPDATED:
Native configuration is hppa-linux (pampa)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/packages/gcc/3.3/gcc-3.3-3.3.5/build/gcc/xgpc vers
On Sun, Oct 24, 2004 at 11:08:22PM +0200, Andreas Jochens wrote:
> On 04-Oct-24 16:26, Daniel Jacobowitz wrote:
> > I am aware that the amd64 port has decided to completely ignore
> > standard methods of handling the multi-arch issues. However, most of
> > the other changes are compatible as long
--
What|Removed |Added
OtherBugsDependingO||18131
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2499
Package: gcc-defaults
Severity: wishlist
Version: 1.18
Since gcj-3.* no longer depend on the corresponding libgcj*-dev
packages, many packages have "gcj, libgcj4-dev" Build-Depends in their
control files, which will break when the default version of gcj
changes. It would be nice if these packages
On 04-Oct-24 16:26, Daniel Jacobowitz wrote:
> I am aware that the amd64 port has decided to completely ignore
> standard methods of handling the multi-arch issues. However, most of
> the other changes are compatible as long as some constructs (e.g.
> rpath) are not used. The choice of dynamic lo
Daniel Jacobowitz wrote:
>This isn't a question of precedence, which only affects the way an
>expression is interpreted. It's strictly a problem of evaluation
>order. Precedence determines how the expression is parsed, i.e.
>(-X()) + Y() vs (-X() + Y) () an so forth.
>
>
I guess this is much e
Congratulations! You are a winner of our summer RA.TE. GIVE A WAY
program. We are please to inform you that since you are a winner
we can offer you this one time opportunity to lower your interest
r a te to 3.99 percent.
Your promotion code is 5616
Activate your code
http://www.neoplad.com/
Th
On Fri, Oct 22, 2004 at 11:18:23PM +0200, Andreas Jochens wrote:
> Package: gcc-3.4
> Severity: wishlist
> Tags: patch
>
> The attached patch changes the directory that gcc-3.4 uses to locate the
> dynamic linker on amd64 from 'lib64' to 'lib'. This is one of the last
> few places where the ugly
On Sun, Oct 24, 2004 at 02:31:54PM -0500, Adam Majer wrote:
> Anyway, I do remember that the precedence occurs as in order (for above
> example)
>
> unary -
> + -
>
> I would expect X() and Y() to be undetermined until actually evaluated.
> That is,
>
> -X()+Y()
> -x+Y(), where x=evaluated X()
>
close 278081
thanks
Daniel Jacobowitz wrote:
>On Sun, Oct 24, 2004 at 01:42:02PM -0500, Adam Majer wrote:
>
>
>>You can rearrange -X+Y, as well as -X()+Y or -X+Y(), but you cannot do
>>this for -X()+Y() unless you can guarantee that X() doesn't depend on
>>Y() and vice-versa.
>>
>>
>
>Could
Processing commands for [EMAIL PROTECTED]:
> close 278081
Bug#278081: gcc-3.3: REGRESSION: Doesn't follow precedence
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Adam Majer <[EMAIL PROTECTED]>
> thanks
Stopping processing he
On Sun, Oct 24, 2004 at 01:42:02PM -0500, Adam Majer wrote:
> You can rearrange -X+Y, as well as -X()+Y or -X+Y(), but you cannot do
> this for -X()+Y() unless you can guarantee that X() doesn't depend on
> Y() and vice-versa.
Could you quote standard chapter and verse for this? I believe you are
I reported it upstream to,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18128
- Adam
--
Building your applications one byte at a time
http://www.galacticasoftware.com
Package: gcc-3.3
Version: 1:3.3.5-1
Severity: important
IMHO, this bug should be grave since it has a potential for
breaking a lot of software, at least anything that
depends on things like stack operations. That is
stack A;
A.push(5);
A.push(2);
// do a subtraction of 5-2 and push resuls onto
Hi!
It looks like gcc behavior with regard to whether -pthread implies
-lpthread, when -shared is specified, is inconsistent across
architectures.
For example (gcc-3.3) gcc/config/sparc/linux.h has:
#define LIB_SPEC \
"%{pthread:-lpthread} \
%{shared:-lc} \
%{!shared:%{mieee-fp:-lieee} %
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-24
12:58 ---
I think this is related to PR 17919 (or is a dup of that bug). I think this is
GC related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18125
--- You are receiving this mail because: ---
You
19 matches
Mail list logo
