"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> I am upgrading my cross-compiler from 3.4.6 to 4.1.1. It has built
> successfully. But while running the test suites, i am getting lots of
> run time errors during optimization tests (Mostly size optimization -
> Os). But the same code with same level
Hi all,
I am upgrading my cross-compiler from 3.4.6 to 4.1.1. It has built
successfully. But while running the test suites, i am getting lots of
run time errors during optimization tests (Mostly size optimization -
Os). But the same code with same level of optimization works fine with
3.4.6.
1.
What is the situation with multilib builds
of libffi and libjava in gcc 4.2 on architectures
like x86_64 and ppc64 linux? I ask because I noticed
that Fedora's gcc 4.1.1 specfile explicitly disables
the multilib builds in libjava and doesn't seem to
package libffi. Thanks in advance for any cla
Survey Introduction
www.MusiCoop.com is conducting a survey regarding musician support services and
would appreciate your response. MusiCoop.com is a *free* registry for bands,
musicians, fans and promoters.
The survey will take less than five minutes and you will not be asked to
purchase any
Survey Introduction
www.MusiCoop.com is conducting a survey regarding musician support services and
would appreciate your response. MusiCoop.com is a *free* registry for bands,
musicians, fans and promoters.
The survey will take less than five minutes and you will not be asked to
purchase any
Survey Introduction
www.MusiCoop.com is conducting a survey regarding musician support services and
would appreciate your response. MusiCoop.com is a *free* registry for bands,
musicians, fans and promoters.
The survey will take less than five minutes and you will not be asked to
purchase any
On Oct 10, 2006, at 6:25 AM, Jochen Haerdtlein wrote:
I am a PhD student working on the extended use of expression
templates for solving partial differential equations.
Since compile time of huge expression template programs is a severe
problem
I fear that trying to solve that problem
October 2006
This is the thirteenth code drop of the GCC front-end for
the PL/I programming language.
PL/I for GCC is released under the terms of the
GNU Public License; version 2.
Main new feature in pl1gcc-0.0.13 is the preprocessor %GOTO statement.
There is still no code generation taking pl
Hi,
I currently have a problem of how to best preserve a register note across
an instruction split, e.g. I had to change a define_split like this (from
m68k.md):
(define_split
[(set (match_operand 0 "register_operand" "")
(zero_extend (match_operand 1 "nonimmediate_src_operand" ""))
On Tue, Oct 10, 2006 at 09:20:26AM -0700, Brooks Moses wrote:
> ---gcc/fortran
>
> 2006-10-10 Brooks Moses <[EMAIL PROTECTED]>
>
> * Make-lang.in: Added "fortran.pdf", "gfortran.pdf" target
> support.
>
This part is OK. Of course, I can
> "Brooks" == Brooks Moses <[EMAIL PROTECTED]> writes:
Brooks> The attached patch adds all of the relevant targets to enable
Brooks> "make pdf" to work; it produces the same files (modulo
Brooks> extension, of course) in the same locations as "make dvi".
The gcc/java bits are ok assuming that
On Tue, 10 Oct 2006, Paolo Bonzini wrote:
> One point in favor of distributing gmp is that (according to its maintainers)
> it's an incredible stress test for GCC, and a lot of .0 GCC versions are known
> to miscompile it.
That's a case for adding application testing back to the release criteria,
> "Steve" == Steve Kargl <[EMAIL PROTECTED]> writes:
Steve> Should we consider removing zlib and intl?
Note that zlib is built both as a host library and a target library.
So, if it is removed, cross builds of libgcj will no longer work.
Steve> In particular, zlib 1.2.3
Steve> was released o
[EMAIL PROTECTED] writes:
> - the default versions of operator new and the aligned version of
> operator new should be defined in the same section. That way,
> when a user overrides the default operator new, they will get
> a link error (duplicate definitions of new) unless they als
The attached patch adds all of the relevant targets to enable "make pdf"
to work; it produces the same files (modulo extension, of course) in the
same locations as "make dvi". The changes are, I believe, relatively
straightforward and simple.
I have attached two separate .diff files; the firs
On Tue, Oct 10, 2006 at 08:30:46AM -0400, Richard Kenner wrote:
> > Regardless of what happens with 4.3, I think the reality is that s/390
> > has been one of the better supported platforms for gcc since at least
> > 3.2.x. The maintainers are very responsive and gcc-testresults is
> > updated on a
Richard Earnshaw wrote:
I think there's a very important distinction that needs to be drawn
between a tool that needs to be installed to *build* gcc and a tool that
needs to be installed in order to *run* gcc. GMP/MPFR is needed for the
latter; and to date we have never relied on such an extern
Kai Tietz writes:
> I am currently on to build the gcc target support for x86_64-pc-mingw64.
> While this porting I found a strange register truncation, I do not believe
> it is valid. For the c code:
>
> int foo(char *,...);
> int doo(char *h) { return foo("abc ",h); }
>
Daniel Jacobowitz wrote:
On Tue, Oct 10, 2006 at 04:28:34PM +0200, Paolo Bonzini wrote:
Interestingly, other GNU projects (including bison) are no longer
distributing intl. So, I think I agree that zlib and libintl should not
be distributed.
While zlib would probably be only moderate
Interestingly, other GNU projects (including bison) are no longer
distributing intl. So, I think I agree that zlib and libintl should not
be distributed.
While zlib would probably be only moderately painful to remove, I
recommend anyone who wants to attempt intl be very very careful. Ou
On Tue, Oct 10, 2006 at 04:28:34PM +0200, Paolo Bonzini wrote:
> Interestingly, other GNU projects (including bison) are no longer
> distributing intl. So, I think I agree that zlib and libintl should not
> be distributed.
While zlib would probably be only moderately painful to remove, I
recomm
Hello,
I am currently on to build the gcc target support for x86_64-pc-mingw64.
While this porting I found a strange register truncation, I do not believe
it is valid. For the c code:
int foo(char *,...);
int doo(char *h) { return foo("abc ",h); }
compiled result ->
.f
No. I am not volunteering to maintain zlib. If you reread the
first 7 words, you'll note that I'm suggesting that zlib and
intl should be removed. Why shouldn't these libraries be treated
the same as gmp and mpfr?
... and infoZIP, which is now required to build libjava.
Interestingly, other G
No. I am not volunteering to maintain zlib. If you reread the
first 7 words, you'll note that I'm suggesting that zlib and
intl should be removed. Why shouldn't these libraries be treated
the same as gmp and mpfr?
... and infoZIP, which is now required to build libjava.
Interestingly, other G
On Tue, Oct 10, 2006 at 08:51:55AM -0400, David Edelsohn wrote:
> > Steve Kargl writes:
>
> Steve> Should we consider removing zlib and intl? In particular, zlib 1.2.3
> Steve> was released on 19 Jul 05 and included 2 fixes for security issues.
> Steve> GCC did not update zlib until 12 Sep 05
Hello,
I am a PhD student working on the extended use of
expression templates for solving partial differential equations.
Thus, I did a lot of studying of expression templates papers,
articles and expression templates implementations. Actually,
I had some ideas for improving them for high perf
> Steve Kargl writes:
Steve> Should we consider removing zlib and intl? In particular, zlib 1.2.3
Steve> was released on 19 Jul 05 and included 2 fixes for security issues.
Steve> GCC did not update zlib until 12 Sep 05. Whether the security issues
Steve> in GCC's version of zlib could be ex
> Regardless of what happens with 4.3, I think the reality is that s/390
> has been one of the better supported platforms for gcc since at least
> 3.2.x. The maintainers are very responsive and gcc-testresults is
> updated on a daily basis for multiple machine configs (390, 390x).
I agree. And wo
> Another, technical, reason to consider the s390x to be a primary
> platform is that it is a different 64-bit big-endian target.
>
> I always watch the test-result outcomes for gfortran of s390x closely -
> it's too easy to mess things up using little-endian.
Same here. In C++ land it also has m
On Tue, 2006-10-10 at 04:22, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> > Has there been any thought to including GMP/MPFR in the GCC repository
> > like we do for zlib and intl?
>
> I do not think we should be including more such packages in the GCC
> repository. It's complicated from an FS
30 matches
Mail list logo
