On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote:
Yes; to do this right, GCC's builtins need to know about the different
names.
If you're interested in fixing this, I can tell you what to do...
I figured out how to fix it and will be posting a patch later this week.
but a function like:
stat
On 17/12/2005, at 5:56 PM, Mike Stump wrote:
On Dec 17, 2005, at 6:08 AM, FX Coudert wrote:
I'm trying to understand the gfortran failure
large_real_kind_2.F90 on ppc-darwin7.9, which can be reduced to:
$ cat large_real_kind_2.F90
real(kind=16) :: x
real(8) :: y
x = 1
y = x
x =
On Sat, Dec 17, 2005 at 09:41:16PM -0500, Richard Kenner wrote:
> bootstrap-lean is done by doing the following (which I feel is the
> wrong way):
>
> Configure with --enable-bootstrap=lean
> and then do a "make bootstrap"
>
> I agree with you. Why not just keep this as a make ta
On Sat, 17 Dec 2005, Daniel Jacobowitz wrote:
> On Sun, Dec 18, 2005 at 02:10:36AM +0100, Gerald Pfeifer wrote:
> > I agree with that and plan to do so next week, once the server hosting
> > my GCC trees is online again.
>
> Before you go ahead with that, please check with overseers@; they
> (Frank
On 17/12/2005, at 10:08 AM, Jakub Jelinek wrote:
But there are dozens of other uses of TREE_PUBLIC in the backends, so
it wouldn't surprise me if something similar is not present on
other arches.
Normal aliases are usually declared through
extern __typeof (foo) bar __attribute__((alias ("fo
bootstrap-lean is done by doing the following (which I feel is the
wrong way):
Configure with --enable-bootstrap=lean
and then do a "make bootstrap"
I agree with you. Why not just keep this as a make target? Why go back and
have to reconfigure?
And yes this causes to use di
On Sun, Dec 18, 2005 at 02:10:36AM +0100, Gerald Pfeifer wrote:
> On Wed, 14 Dec 2005, Mike Stump wrote:
> > :-( I think we should remove all traces of any search that doesn't work.
>
> I agree with that and plan to do so next week, once the server hosting
> my GCC trees is online again.
Before
On Dec 17, 2005, at 6:08 AM, FX Coudert wrote:
I'm trying to understand the gfortran failure large_real_kind_2.F90
on ppc-darwin7.9, which can be reduced to:
$ cat large_real_kind_2.F90
real(kind=16) :: x
real(8) :: y
x = 1
y = x
x = cos (x)
y = cos (y)
print *, x, y, y-x
end
Hi people,
Consider the following C++ program, which is my test case for PR25130,
a wrong-code issue seen on x86 and powerpc (with a different test case)
but it can probably be triggered anywhere under the right, well wrong,
circumstances if I understand the bug properly (and that's a Big If).
//
On Wed, 14 Dec 2005, Mike Stump wrote:
> :-( I think we should remove all traces of any search that doesn't work.
I agree with that and plan to do so next week, once the server hosting
my GCC trees is online again.
> It has never been any good, so I don't think it is a real loss.
This is not fa
Gabriel Dos Reis wrote:
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > On Fri, 16 Dec 2005, Paolo Bonzini wrote:
| > > Yes. "make bubblestrap" is now called simply "make".
| >
| > Okay, how is "make bootstrap-lean" called these days? ;-)
| >
| > In fact, bootstrap-lean is still documente
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Thu, Dec 15, 2005 at 08:20:39PM -, Dave Korn wrote:
>> If gmane is free, please supply me a set of the source code to the gmane
>> application, so that I can modify it and use it for my own purposes.
> http://gmane.org/dist.php
> The bit
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > On Fri, 16 Dec 2005, Paolo Bonzini wrote:
| > > Yes. "make bubblestrap" is now called simply "make".
| >
| > Okay, how is "make bootstrap-lean" called these days? ;-)
| >
| > In fact, bootstrap-lean is still documented in install.texi and
| >
>
> On Fri, 16 Dec 2005, Paolo Bonzini wrote:
> > Yes. "make bubblestrap" is now called simply "make".
>
> Okay, how is "make bootstrap-lean" called these days? ;-)
>
> In fact, bootstrap-lean is still documented in install.texi and
> makefile.texi, but it no longer seems to be present in the
On Fri, 16 Dec 2005, Paolo Bonzini wrote:
> Yes. "make bubblestrap" is now called simply "make".
Okay, how is "make bootstrap-lean" called these days? ;-)
In fact, bootstrap-lean is still documented in install.texi and
makefile.texi, but it no longer seems to be present in the Makefile
machiner
On Sat, Dec 17, 2005 at 10:56:51AM -0200, Alexandre Oliva wrote:
> > I thus propose your change to be reverted, and request you to explain
> > what you were trying to fix with this patch so that I can try to do
> > something about it.
>
> Nevermind this bit :-)
>
>
> Jakub, do you have any furth
Snapshot gcc-4.2-20051217 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20051217/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Dec 17, 2005, at 9:08 AM, FX Coudert wrote:
But I can't make a C testcase for that. Is "long double" supposed to
be usable on ppc-darwin7.9 ?
That is because if you include math.h with a C testcase it gets the
"correct" function.
Basically Darwin is broken in terms of the ABI for any lang
I'm trying to understand the gfortran failure large_real_kind_2.F90 on
ppc-darwin7.9, which can be reduced to:
$ cat large_real_kind_2.F90
real(kind=16) :: x
real(8) :: y
x = 1
y = x
x = cos (x)
y = cos (y)
print *, x, y, y-x
end
$ ./usr/local/gfortran/bin/gfortran -g large_rea
On Dec 17, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> On Dec 1, 2005, [EMAIL PROTECTED] (Geoffrey Keating) wrote:
>>> The easiest solution to this is to require that weakrefs must be
>>> 'static', because the name that they d
On Dec 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 1, 2005, [EMAIL PROTECTED] (Geoffrey Keating) wrote:
>> The easiest solution to this is to require that weakrefs must be
>> 'static', because the name that they define is not visible outside
>> this translation unit.
> While t
I get this on trunk Sat Dec 17 00:14:08 UTC 2005 (revision 108698):
../../xgcc -B../../ -c -O2 -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg
-gnata -I- -I../rts -I. -I/usr/local/src/trunk/gcc/gcc/ada
/usr/local/src/trunk/gcc/gcc/ada/make.adb -o
Even better though would be some option to keep the "old style". As I
understand it, the point here is to add functionality at top level, but that
shouldn't be at the expense of functionality at the gcc/ level. Indeed I
see no reason that we can't be upwards compatible.
I can of course provi
23 matches
Mail list logo
