Package: g++-3.3
Version: 1:3.3.5-2
Severity: normal
Here are 3 functions and a dummy main:
--begin--
int one() { return 1; }
static int two() { return 2; }
namespace
{
int three() { return 3; }
}
int main()
{
return one() + two() + three();
}
--end--
i was expecting that g++ handled two(
LAST_UPDATED:
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/build/gcc/xgpc version 200405
LAST_UPDATED:
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-3.3.5/build/gcc/xgpc version
LAST_UPDATED:
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.5/build/gcc/xgpc version 200
LAST_UPDATED:
Native configuration is arm-unknown-linux-gnu
=== libjava tests ===
Running target unix
FAIL: calls run
FAIL: cxxtest run
FAIL: field run
FAIL: final_method run
FAIL: findclass run
FAIL: invoke run
FAIL: martin run
FAIL: noclass run
FAIL: overload run
FAIL: registe
!! http://lwuMxzN.jfhbaije.info/?ratwZXY5wvykdXXBAvYZZi !!
!! http://gwTIpTP.mjfbbimd.info/?nCVsVEnxsrugFTnoEAUklt !!
On Sun, Oct 24, 2004 at 04:26:47PM -0400, 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.
On 04-Oct-25 11:16, Daniel Jacobowitz wrote:
> On Mon, Oct 25, 2004 at 05:06:21PM +0200, Andreas Jochens wrote:
> I really don't agree that doing this based on the performance issues
> makes sense. And you're wrong about mips64; the most efficient
> libraries on mips64 targets are usually n32, whi
On Mon, Oct 25, 2004 at 05:06:21PM +0200, Andreas Jochens wrote:
> ia64 puts 64bit libraries in '/lib' and not in '/lib64'.
> The FHS Version 2.3 summarizes the reason for this:
> "IA-64 uses a different scheme, reflecting the deprecation of
> 32-bit binaries (and hence libraries) on that arc
On 04-Oct-25 09:36, Daniel Jacobowitz wrote:
> On Mon, Oct 25, 2004 at 08:02:37AM +0200, Andreas Jochens wrote:
> > The '/lib64' was created with a 32bit system in mind which had to be
> > supplemented by a few 64bit libraries, while the existing 32bit
> > libraries would stay at '/lib'. The curr
On Mon, Oct 25, 2004 at 08:02:37AM +0200, Andreas Jochens wrote:
> On 04-Oct-24 18:34, Daniel Jacobowitz wrote:
> > On Sun, Oct 24, 2004 at 11:08:22PM +0200, Andreas Jochens wrote:
> > > The '/lib64' directory is just ugly and I want to get rid of that
> > > or at least minimize its use (and I thi
Phil Edwards wrote:
>On Sun, Oct 24, 2004 at 03:49:11PM -0500, Adam Majer wrote:
>
>
>>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
On Sun, Oct 24, 2004 at 03:49:11PM -0500, Adam Majer wrote:
> 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.
>
On 04-Oct-24 18:34, Daniel Jacobowitz wrote:
> On Sun, Oct 24, 2004 at 11:08:22PM +0200, Andreas Jochens wrote:
> > The '/lib64' directory is just ugly and I want to get rid of that
> > or at least minimize its use (and I think I am not alone here).
>
> You're certainly not alone among the Debian
15 matches
Mail list logo
