Am I just being dense, or is there *no* way to effectively turn off doc
builds in the GCC packages as of 3.3/3.4? This is not a concern for normal
builds, but it can be extremely useful when, say, trying to bootstrap a
compiler for a new port - since the GCC build itself (mostly) requires only
thin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
04:06 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
02:37 ---
Subject: Bug 9157
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-01 02:36:36
Modified files:
gcc/java : ChangeLog parse.y
Log message:
Which seems like an acceptable error message. Unfortunately, it is
rather likely that this gets fixed in 3.3, too.
How about this variant that defines inverse() ?
$ g++ -c bug.c
bug.c: In function `void c_area(const xform_split&, const box&, const
box&)':
bug.c:32: error: parse error before `,'
LAST_UPDATED: Tue Jan 25 23:51:29 UTC 2005
Native configuration is ia64-unknown-linux-gnu
=== g++ tests ===
Running target unix
FAIL: g++.dg/opt/longbranch1.C (test for excess errors)
WARNING: g++.old-deja/g++.mike/p10769a.C compilation failed to produce
executable
XPASS: g++.o
LAST_UPDATED: Tue Jan 25 23:51:29 UTC 2005
Native configuration is arm-unknown-linux-gnu
=== libffi tests ===
Running target unix
FAIL: libffi.call/closure_fn0.c (test for excess errors)
WARNING: libffi.call/closure_fn0.c compilation failed to produce executable
FAIL: libffi.cal
LAST_UPDATED: Sun Jan 30 17:58:51 UTC 2005
Native configuration is sparc-linux (vore)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/buildd/gcc-3.3-3.3.5/
LAST_UPDATED: Sun Jan 30 17:58:51 UTC 2005
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
LAST_UPDATED: Sun Jan 30 17:58:51 UTC 2005
Native configuration is mipsel-linux (remake)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/buildd/gcc-3.3-3.3
LAST_UPDATED: Sun Jan 30 17:58:51 UTC 2005
Native configuration is powerpc-linux (voltaire)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/buildd/gcc-3.3-
LAST_UPDATED: Sun Jan 30 17:58:51 UTC 2005
Native configuration is alpha-unknown-linux-gnu
=== libjava tests ===
Running target unix
WARNING: program timed out.
FAIL: SyncTest execution - bytecode->native test
WARNING: program timed out.
FAIL: SyncTest -O execution - bytecode->n
LAST_UPDATED: Sun Jan 30 17:58:51 UTC 2005
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 pa
LAST_UPDATED: Thu Jan 27 21:23:18 UTC 2005
Native configuration is mipsel-linux (remake)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/buildd/gcc-3.3-3.3
LAST_UPDATED: Thu Jan 27 21:23:18 UTC 2005
Native configuration is mips-linux (casals)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/buildd/gcc-3.3-3.3.5
LAST_UPDATED: Thu Jan 27 21:23:18 UTC 2005
Native configuration is hppa-linux (sarti)
=== gpc tests ===
Running target any
=== gpc Summary ===
# of tests3910
# of expected passes 3905
# of unsupported tests5
/build/buildd/gcc-3.3-3.3.5/
LAST_UPDATED: Thu Jan 27 21:23:18 UTC 2005
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
tags 293076 + upstream
tags 293076 + fixed-upstream
retitle 293076 [fixed in 3.4] g++-3.3: uninformative error when base class
missing
thanks
Greg Kochanski <[EMAIL PROTECTED]> writes:
> In the following program, the base class is missing.
> G++ gives a wimpy error message:
>
> bug.c:3: error: p
tags 292961 + upstream
tags 292961 + fixed-upstream
retitle 292961 [fixed in 3.4] g++-3.3: vastly uninformative error message
thanks
Greg Kochanski <[EMAIL PROTECTED]> writes:
> OK. Here is a condensed version.
>
> $ g++ -c bug.c
> bug.c: In function `void c_area(const xform_split&, const box&, c
Processing commands for [EMAIL PROTECTED]:
> tags 293076 + upstream
Bug#293076: [fixed in 3.4] g++-3.3 uninformative error when base class missing
Tags were: upstream fixed-upstream
Tags added: upstream
> tags 293076 + fixed-upstream
Bug#293076: [fixed in 3.4] g++-3.3 uninformative error when bas
Processing commands for [EMAIL PROTECTED]:
> tags 292961 + upstream
Bug#292961: g++-3.3: g++ -- vastly uninformative error message
There were no tags set.
Tags added: upstream
> tags 292961 + fixed-upstream
Bug#292961: g++-3.3: g++ -- vastly uninformative error message
Tags were: upstream
Tags ad
tags 293076 + fixed-upstream
tags 293076 + upstream
retitle 293076 [fixed in 3.4] g++-3.3 uninformative error when base class
missing
thanks
$ g++-3.4 -c bug-293076.cc
bug-293076.cc:1: error: expected class-name before '{' token
Greg Kochanski writes:
> Package: g++-3.3
> Version: 1:3.3.5-5
> Se
Processing commands for [EMAIL PROTECTED]:
> tags 293076 + fixed-upstream
Bug#293076: g++-3.3 uninformative error when base class missing
There were no tags set.
Tags added: fixed-upstream
> tags 293076 + upstream
Bug#293076: g++-3.3 uninformative error when base class missing
Tags were: fixed-up
Falk Hueffner wrote:
Greg Kochanski <[EMAIL PROTECTED]> writes:
Why is the test case important?
Because I cannot reproduce the problem without it.
OK. Here is a condensed version.
$ g++ -c bug.c
bug.c: In function `void c_area(const xform_split&, const box&, const
box&)':
bug.c:31: error: parse
Package: g++-3.3
Version: 1:3.3.5-5
Severity: normal
In the following program, the base class is missing.
G++ gives a wimpy error message:
bug.c:3: error: parse error before `{' token
It could do much better. Syntactically, there aren't a lot of
options for 'z'. A better error message might
OK. I'll spend an hour or so boiling down a test case.
Falk Hueffner wrote:
I can see that. However without a test case it is not clear to me
whether, or how, g++ could have done better. So I need a test case
plus an example error message that you would have liked to see.
--
To UNSUBSCRIBE, email
Greg Kochanski <[EMAIL PROTECTED]> writes:
> Why is the test case important?
Because I cannot reproduce the problem without it.
> I think (though I may be wrong) that you're missing the main point
> of the bug report.
>
> The main point is simply that the error message is uninformative.
> Nearly
Why is the test case important?
I think (though I may be wrong) that
you're missing the main point of the bug report.
The main point is simply that the error message is
uninformative. Nearly useless.
Whatever the compiler *thought* it was parsing is
hidden, and that's the problem -- it provides n
Greg Kochanski <[EMAIL PROTECTED]> writes:
> You may assume that box, xform_split, and parallelogram are classes,
> that insidebox() is a member function of class parallelogram, and
> that inverse_image() and intersect() are functions.
I'm not willing to guess the test case, since my experience h
Package: libgcj4-dev
Version: 1:3.3.5-7
Severity: important
File: /usr/lib/libgcj.la
Justification: Causes related packages to miscompile
Hi,
libgcj.la contains
libdir='/usr/lib64'
instead of
libdir='/usr/lib'
resulting in libtool using rpath and dpkg-shlibdeps to not find
required libs (and
The line you are wanting is
#define C const
You may assume that
box, xform_split, and parallelogram are classes,
that insidebox() is a member function of class parallelogram,
and that inverse_image() and intersect() are functions.
With those additions, it becomes quite reasonable C++ code.
In fact,
Greg Kochanski <[EMAIL PROTECTED]> writes:
> Here's the code:
>
> box c_area(C xform_split &xf, C box& databox0, C box& databox1)
> {
> // Next is line 84:
> C box box0inOUTin(parallelogram(inverse(xf.back), databox0).insidebox());
> C box lc(inverse_image(databox1, xf.fwd));
> return intersec
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-31
14:45 ---
Proposed patch here:
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00245.html
--
What|Removed |Added
Package: g++-3.3
Version: 1:3.3.5-5
Severity: normal
Having been away from C++ for several years, I've now tried
to compile some old (circa 1999) code.
The error message
geom.c:84: parse error before ',' token
(or a dozen variants of it) are completely useless!
I note that this problem
Package: gcc-3.3
Version: 3.3.5-6
Severity: normal
gcc 3.3 apparently does not compile correctly lib/dns/rbt.c from
BIND 9.3, which then will die on startup with an assertion failure.
Workarounds known to fix this:
- compiling rbt.c without -O2
- removing "inline" from rotate_left() and rotate_ri
34 matches
Mail list logo
