porting gcc
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 port gcc for this platform with a quite simple instruction set, with a good porting guide? 2- What about optimizations? I suppose most of them are platform-independent and performed at RTL level, aren't they? But, generally speaking, are there many platform-dependent optimizations (I would have to do)? And is it possible or how is it complex to have a level of optimization (code compactness...) as good as commercial compiler ones (such as IAR, Keil, ACE...)? 3- Finally, some companies may port gcc for us (perhaps in this mailing list?). An idea of how much it could be? Many thanks, Aurelien
PR 12603 testcase
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
===
--- gcc/testsuite/gcc.dg/pr12603.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr12603.c (revision 0)
@@ -0,0 +1,8 @@
+/* PR 12603: No return statement warning on function that never returns with -O3. */
+/* { dg-do compile } */
+/* { dg-options "-O3 -Wall -Wextra -Wreturn-type -Wunreachable-code" } */
+int
+this_function_never_returns ()
+{
+ for (;;);
+}
Re: PR 12603 testcase
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. Janis
Re: out of date docs? (alpha/64bit vs. 32bit vs. cross)
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 because many optimizations that > depend on being able to represent a word on the target in an integral value > on the host cannot be performed. Building cross-compilers on the Alpha for > 32-bit machines has only been tested in a few cases and may not work > properly. " > > This is false lately, eh? > Can it be amended to note what versions it was possibly true for and what > versions it is definitely false for? > In particular, I /assume/ it is false for any version that uses gmp. I believe that this is false these days. I believe that it has been false since a cross-compiler to the alpha required a 64-bit HOST_WIDE_INT, which was in gcc 3.4. Ian
Re: porting gcc
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: > > 1- How much time do you think it will take to port gcc for this platform > with a quite simple instruction set, with a good porting guide? My answer the last time I answered this question: http://gcc.gnu.org/ml/gcc-help/2008-04/msg00117.html > 2- What about optimizations? I suppose most of them are platform-independent > and performed at RTL level, aren't they? But, generally speaking, are there > many platform-dependent optimizations (I would have to do)? And is it > possible or how is it complex to have a level of optimization (code > compactness...) as good as commercial compiler ones (such as IAR, Keil, > ACE...)? Most optimizations are platform independent. The hardest platform specific one to implement is scheduling; you will have to write a description of your pipeline. Some peepholes may be appropriate. Other than that, you will only need platform specific code if your processor is unusual in some respect. Unfortunately, my experience is that every processor has some unusual aspects. gcc is a commercial compiler. If you mean: how does gcc compare to a proprietary compiler, the answer is that it is very competitive for conventional processors. > 3- Finally, some companies may port gcc for us (perhaps in this mailing > list?). An idea of how much it could be? I have no idea what the rates are these days, sorry. In any case the precise details of your processor make a big difference to the price. Ian
Re: [PATCH]: GMP/MPFR in-tree build instructions [Was: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)]
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 library search path. See also
[EMAIL PROTECTED] and @option{--with-mpfr-include}.
+Alternatively, if a MPFR source ditribution is found in a subdirectory
+of you GCC sources named @file{mpfr}, it will be built together with
[EMAIL PROTECTED]
Typos:
s/ditribution/distribution/
s/you GCC sources/your GCC sources/
Both occur twice.
--Kaveh
Re: thread build on solaris
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 anachronisms are in the solaris headers. Ed On Sun, Oct 19, 2008 at 1:16 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: >> This is having the unfortunate side effect that a lot of packages that >> used to compile perfectly fine with gcc-3 are no longer doing so with >> gcc-4. > > The major Linux distributions use GCC 4.x so this should be doable. > >> Here's another example I'm finding: >> >> Constructs of the form >> >> extern enum vtype iftovt_tab[]; >> >> are now failing with forgiving >> >> error: array type has incomplete element type >> >> This would be fine if it was code that I controlled - but the matter >> of fact is that this code is in /usr/include/sys/mode.h, which comes >> bundled with solaris 10, and the upshot is that I'm going to have to >> somehow hack solaris headers in order to make gcc-4.3.2 be able to >> compile perl-5.10.0. > > This should be fix-included if it's really a bug in the Solaris headers. > > -- > Eric Botcazou >
GCC bug when using typeof
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,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccEcnj4W.out file, please attach
this to your bugreport.
Currently, I'm using g++ of the following version.
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks,
Peng
#include
namespace A {
template
class X {
public:
X() { }
X(T t) : _t(t) { }
const T &the_t() const { return _t; }
private:
T _t;
};
template
struct multiply_traits;
template
struct multiply_traits, T2> {
typedef X result_type;
};
template
typename multiply_traits, T2>::result_type operator*(const
X &x, const T2 &t) {
return X(x.the_t() * t);
}
}
namespace B {
template
class Y {
public:
Y(T t) : _t(t) { }
const T &the_t() const { return _t; }
private:
T _t;
};
template
Y
operator*(const Y &y, const T2 &t) {
return Y(y.the_t() * t);
}
}
int main () {
A::X x(2);
B::Y > y(x);
std::cout << (x * 3).the_t() << std::endl;
std::cout << (y * 5).the_t().the_t() << std::endl;
}
Re: GCC bug when using typeof
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: t.cc: In instantiation of 'B::Y<__typeof__ ((T1() * T2()))> B::operator*(const B::Y&, const T2&) [with T1 = A::X, T2 = int]': t.cc:54: instantiated from here t.cc:46: sorry, unimplemented: mangling typeof, use decltype instead Replacing typeof with __decltype (or decltype in c++0x/g++0x modes) works in 4.3.0 and above. Thanks, Andrew Pinski
Re: GCC bug when using typeof
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? >> > > It is a bug in GCC but in later versions 4.3.0 and above, we get a > sorry message: > t.cc: In instantiation of 'B::Y<__typeof__ ((T1() * T2()))> > B::operator*(const B::Y&, const T2&) [with T1 = A::X, T2 = > int]': > t.cc:54: instantiated from here > t.cc:46: sorry, unimplemented: mangling typeof, use decltype instead > > Replacing typeof with __decltype (or decltype in c++0x/g++0x modes) > works in 4.3.0 and above. Hi, Could you please help explain what the difference between typeof and decltype are? What are c++0x/g++0x modes? Thanks, Peng
Re: GCC bug when using typeof
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/sc22/wg21/docs/papers/2007/n2343.pdf ). typedef is a GCC extension. Thanks, Andrew Pinski
RE: How to debug if scheduling in gcc is wrong?
袁立威 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 hopefully following suggestion useful. Your information posted here may not be sufficient for root cause analysis. Posting the full patch will be more helpful. As to the failure itself. Suggest you reduce the it a small case, or at least find out exactly with function in gzip is miscompiled and split that function. It might not the scheduling problem. Finding exactly which instruction in .s is wrong will help tracing back to problem in your patch. Thanks - Joey
Re: GCC bug when using typeof
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? >> > > It is a bug in GCC but in later versions 4.3.0 and above, we get a > sorry message: > t.cc: In instantiation of 'B::Y<__typeof__ ((T1() * T2()))> > B::operator*(const B::Y&, const T2&) [with T1 = A::X, T2 = > int]': > t.cc:54: instantiated from here > t.cc:46: sorry, unimplemented: mangling typeof, use decltype instead > > Replacing typeof with __decltype (or decltype in c++0x/g++0x modes) > works in 4.3.0 and above. Hi, Somebody replace __decltype with typeof and try to compile, he got the following error (with 4.3.0). Do you know why? main.cc:54: sorry, unimplemented: zero-operand casts cannot be mangled due to a defect in the C++ ABI main.cc:54: sorry, unimplemented: zero-operand casts cannot be mangled due to a defect in the C++ ABI Thanks, Peng
