Hello,
I'm new to GCC and eCos and ixdp425.
As a part of my college project, I am supposed to simulate a GSM
mobile network and add extra feature of Wi-Fi also. For that, I have
decided to use IXDP425 board and port eCos on it.
As till now, I have been successful in making test programs run on t
I can't build gcc-4.1-20050709 for target arm; it fails with
gcc-4.1-20050709/libiberty/cp-demangle.c: In function 'd_print_comp':
gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in
loop_givs_rescan, at loop.c:5517
Compiling the same version of gcc for
On Sunday 10 July 2005 00:16, Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> > Here's a patch.
>
> Thanks.
>
> There are a couple of commas between items missing (usually when
> there is a line break) and some of the lines are too long (as with
> GCC sources we generally prefer
On Fri, 8 Jul 2005, Daniel Berlin wrote:
> Here's a patch.
Thanks.
There are a couple of commas between items missing (usually when
there is a line break) and some of the lines are too long (as with
GCC sources we generally prefer lines no longer than ~77 characters).
Is the new stack checking i
On Saturday, July 9, 2005, at 01:23 PM, Florian Michel wrote:
I have a question concerning successfully assembling and linking the
following assembly program on a linux AMD 64 machine:
Wrong list, this list isn't for help with how to program is assembly.
gcc-help would be more appropriate, th
Hello,
I have a question concerning successfully assembling and linking the following
assembly program on a linux AMD 64 machine:
#cpuid2.s View the CPUID Vendor ID string using C library calls
.section .datatext
output:
.asciz "The processor Vendor ID is '%s'\n"
.section .bss
.lcomm bu
Daniel Jacobowitz dixit:
>> >Geoff> Does anyone mind if I update libtool to the latest released
>> >version,
>> >Geoff> 1.5.18, and regenerate everything with automake 1.9.5?
>> >
>> >If everyone agrees to go forward with this
>>
>> Oh, I should have said: "and if you don't mind, how do yo
objdump -p says:
Dynamic Section:
NEEDED libc.so.37.0
SONAME libgcc_s.so.1.1
[...]
nm | sort says:
U _exit
U abort
U dl_iterate_phdr
U free
U malloc
U memcpy
U memset
U mprotect
U perror
U sys
Snapshot gcc-4.1-20050709 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050709/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-07-09 17:43 UTC
You'll
* Adam Nielsen:
> It still makes me wonder whether GCC is reporting the correct error for
> this mistake though, I would've expected a compiler error (something
> along the lines of 'you can't call a pure virtual function') rather than
> a linker error. Especially as GCC should be able to tell at
> Roughly speaking, when number() is invoked, the object still has type
> Base (with a corresponding vtable). One's constructor will change the
> type once the Base part has been constructed.
Aha yes, I didn't even think of that! Thanks Florian and Lion for your
helpful answers!
> The following
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I was under the
> impression that this is allowed, according to
> http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.1
See [23.3]. You aren't allowed to call the virtual function from the Base class
constructor.
- --
Lion Vollnha
* Adam Nielsen:
> class Base {
> public:
> Base()
> {
> cout << "This is class " << this->number();
> }
>
> virtual int number() = 0;
> };
Roughly speaking, when number() is invoked, the object still has type
Base (with a corresponding vtable). One's constructor will chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> It seems like GCC initially allows it as it starts to compile okay, but
> then I get an undefined reference error from the linker (because it
> seems to be actually calling Base::number(), which obviously won't work
> as it's a pure virtual function.
Hi all,
I was expecting the following code snippet to work, so am I doing
something wrong, or is there an issue with GCC? I was under the
impression that this is allowed, according to
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.1
It seems like GCC initially allows it as
Jhair Tocancipa Triana <[EMAIL PROTECTED]> writes:
| Consider the following snippet:
|
| --8<---cut here---start->8---
| namespace foo
| {
| class A
| {
| friend class B;
|
| void bar (B);
| };
|
| class B {};
| }
| --8<---cut here
Consider the following snippet:
--8<---cut here---start->8---
namespace foo
{
class A
{
friend class B;
void bar (B);
};
class B {};
}
--8<---cut here---end--->8---
This compiles fine with:
g++ (GCC) 3.3.3
17 matches
Mail list logo
