Hi,
We are designing a 16-bit asynchronous microcontroller. Ive already ported
bfd, binutils (including sid simulator) using cgen, and part of gdb (for asm
debug only) and we are now investigating the best way to have C compiler.
So my questions are:
1- How much time do you think it will take to
I would like to commit the following testcase to ensure we do not
regress for PR 12603.
OK for trunk?
2008-10-20 Manuel López-Ibáñez <[EMAIL PROTECTED]>
PR 12603
* gcc.dg/pr12603.c: New testcase.
Index: gcc/testsuite/gcc.dg/pr12603.c
===
On Mon, 2008-10-20 at 20:07 +0200, Manuel López-Ibáñez wrote:
> I would like to commit the following testcase to ensure we do not
> regress for PR 12603.
>
> OK for trunk?
>
> 2008-10-20 Manuel López-Ibáñez <[EMAIL PROTECTED]>
>
> PR 12603
> * gcc.dg/pr12603.c: New testcase.
OK.
Jay <[EMAIL PROTECTED]> writes:
> http://gcc.gnu.org/install/specific.html#alpha-dec-osf
>
> "Note that since the Alpha is a 64-bit architecture, cross-compilers from
> 32-bit machines will not generate code as efficient as that generated when
> the compiler is running on a 64-bit machine becaus
Aurélien Buhrig <[EMAIL PROTECTED]> writes:
> We are designing a 16-bit asynchronous microcontroller. I’ve already ported
> bfd, binutils (including sid simulator) using cgen, and part of gdb (for asm
> debug only) and we are now investigating the best way to have C compiler.
> So my questions are
From: "Tobias Schlüter" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] and @option{--with-gmp-include}. Alternatively,
+if a GMP source ditribution is found in a subdirectory of you GCC
+sources named @file{gmp}, it will be built together with [EMAIL PROTECTED]
+Library is not installed in your default
Eric,
I'm not sure what you are trying to say here - that it should be fixed
locally on my side at the level of the header file? Or something else?
Fixing locally really isn't feasible as I'm working with a large
amount of code (a whole code distribution, in fact) and who knows how
many anachronis
Hi,
I tried to compile the following program, but I got the following
error. Is it a bug of GCC? Has it been fixed in a newer version GCC?
g++ -Wall -W -pedantic -g -c -o main-g.o main.cc
main.cc:57: internal compiler error: in write_type, at cp/mangle.c:1651
Please submit a full bug report,
wit
On Mon, Oct 20, 2008 at 7:04 PM, Peng Yu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I tried to compile the following program, but I got the following
> error. Is it a bug of GCC? Has it been fixed in a newer version GCC?
>
It is a bug in GCC but in later versions 4.3.0 and above, we get a
sorry message:
On Mon, Oct 20, 2008 at 9:09 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 20, 2008 at 7:04 PM, Peng Yu <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I tried to compile the following program, but I got the following
>> error. Is it a bug of GCC? Has it been fixed in a newer version GCC?
>>
>
On Mon, Oct 20, 2008 at 7:19 PM, Peng Yu <[EMAIL PROTECTED]> wrote:
> Could you please help explain what the difference between typeof and
> decltype are? What are c++0x/g++0x modes?
Well decltype is part of the C++0x standard
(http://gcc.gnu.org/projects/cxx0x.html,
http://www.open-std.org/jtc1/s
袁立威 wrote:
> Hi, I'm a guy working with gcc4.1.1 on itanium2. In my work, some
> instrumentations are added by gcc. After instrumentation, all
> specint2000 benchmarks except gzip can successfully run with
> optimization flag -O3. There are some information list below:
No answer from me but hopeful
On Mon, Oct 20, 2008 at 9:09 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 20, 2008 at 7:04 PM, Peng Yu <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I tried to compile the following program, but I got the following
>> error. Is it a bug of GCC? Has it been fixed in a newer version GCC?
>>
>
13 matches
Mail list logo