Hi all,
[Cc general gcc list for people with ABI-compatibility experience,
and Jakub because he's the one who introduced the scheme currently
used by the library]
The plans for the libgfortran library is to stabilize things from now
on, and keep ABI compatibility. But I have to admit that
> Brooks Moses wrote on 11/06/06 17:41:
>
> >Is there a need for any fine-grained control on this knob, though, or
> >would it be sufficient to add an -O4 option that's equivalent to -O3 but
> >with no optimization throttling?
> >
> We need to distinguish two orthogonal issues here: effort and e
On Nov 7, 2006, at 1:59 AM, FX Coudert wrote:
The idea is that common.flags has a bit for every possible member
such as rec, to indicated whether it's present or not. The question
is that we sometimes need to add another struct member (like rec)
in this structure, to implement new features.
On Tue, Nov 07, 2006 at 10:59:05AM +0100, FX Coudert wrote:
> {
> st_parameter_common common;
> GFC_IO_INT rec;
> [...lots of other struct members...]
> /* Private part of the structure. The compiler just needs
> to reserve enough space. */
> union
> {
> struct
>
On Tue, Nov 07, 2006 at 02:38:39AM -0800, Mike Stump wrote:
> >Now, we also sometimes want to increase the size of the private
> >stuff, and I don't see how we can do that in a way that keeps ABI
> >compatibility, because the bits in the private stuff are always
> >used by the library. So, I
Jan Hubicka wrote on 11/07/06 05:07:
-O3 enables inlining, unswitching and GCSE after reload. How those
change semantics of the program?
Bah, I was convinced we were switching on -ffast-math at -O3. Never mind.
> Eric Christopher writes:
Eric> We're in stage1, breakages happen - see the current fun with gmp/mpfr as
Eric> well as c99 inlining. File a bug or bring a problem up for discussion.
Yes, breakage happens in Stage 1, but the goal should be no
breakage. Breakage is by no means inevita
> Okay for mainline?
Ok. src too, please.
> 2006-11-06 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * configure.in: Robustify error message for missing GMP/MPFR.
>
> * configure: Regenerate.
Andrew Haley wrote:
Ricardo FERNANDEZ PASCUAL writes:
> So, I think the real question is: are COMPONENT_REF nodes allowed
> to be marked as volatile by themselves? I think they should, and
> actually it seems to work (the generated code looks correct).
volatile is a type qualifier. The type of
Ricardo FERNANDEZ PASCUAL writes:
> Andrew Haley wrote:
>
> >Ricardo FERNANDEZ PASCUAL writes:
> > > So, I think the real question is: are COMPONENT_REF nodes allowed
> > > to be marked as volatile by themselves? I think they should, and
> > > actually it seems to work (the generated code lo
At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.
Almost there. It looks like strip_useless_type_conversions is not used,
and then something Bad happens.
The following patch fixes it, but it's completely untested.
2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]
Paolo Bonzini wrote:
At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.
Almost there. It looks like strip_useless_type_conversions is not
used, and then something Bad happens.
Thank you Andrew and Paolo for your quick answers. I have made a report
for this b
On Nov 7, 2006, at 5:24 AM, David Edelsohn wrote:
Eric Christopher writes:
Eric> We're in stage1, breakages happen - see the current fun with
gmp/mpfr as
Eric> well as c99 inlining. File a bug or bring a problem up for
discussion.
Yes, breakage happens in Stage 1, but the goal s
> Eric Christopher writes:
Eric> On Nov 7, 2006, at 5:24 AM, David Edelsohn wrote:
>>> Eric Christopher writes:
>>
Eric> We're in stage1, breakages happen - see the current fun with
>> gmp/mpfr as
Eric> well as c99 inlining. File a bug or bring a problem up for
>> discussion.
>>
>>
Eric> Well, yes, did you see anything in what I wrote that argued
differently?
Yes, what I quoted, the comparison with gmp/mpfr and c99 inlining.
Those other problems are irrelevant.
I disagree, they were other examples of breakages.
-eric
Snapshot gcc-4.2-20061107 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061107/
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/branches
Mike Stump wrote:
On Nov 6, 2006, at 6:57 PM, Mike Stump wrote:
On Nov 6, 2006, at 5:25 PM, Philip Coltharp wrote:
I'm trying to compile gcc v3.2.3 and I'm getting through most of it
but the make file stops showing the following error:
/bin/sh: ./../../../configure: No such file or directory
On Tue, Nov 07, 2006 at 06:16:50AM -0500, Jakub Jelinek wrote:
> If you want to add over time new fields, if there is space in
> common.flags, you just define a new bit there and add the new field
> to the end of u.p structure if there is space for it. That's the
> easy part.
We're having a flag
I just read Nathan's discussion [1] on changing GCC's type system to
use canonical type nodes, where the comparison between two types
requires only a pointer comparison. Right now, we use "comptypes",
which typically needs to do deep structural checks to determine if
two types are equivalen
> typedef int foo;
> typedef foo* foo_p;
>
> In a truly canonical type-node environment, "foo" would have the same
> type node as "int" (so we couldn't produce the name "foo" in
> diagnostics), and "foo_p" would have the same type node as "int*".
But what about when you have multi
On 07 November 2006 16:33, Andrew Haley wrote:
> Ricardo FERNANDEZ PASCUAL writes:
> > I have done some experiments to try to understand what is happening, and
> > I am a bit confused by the bahavior of GCC. Consider the following C
> > function:
> >
> > static struct { int w; } s;
> >
> >
The r8c/m16c family cannot shift by more than 16 bits at a time ever,
or 8 bits at a time with constant shifts. So, to do a variable number
of shift on a 32 bit value, it needs to emit a conditional, turning
the attached example into this:
i = 0xf;
if (j >= 16)
{
i >>= 8;
i >>= 8;
On 11/7/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> typedef int foo;
> typedef foo* foo_p;
>
> In a truly canonical type-node environment, "foo" would have the same
> type node as "int" (so we couldn't produce the name "foo" in
> diagnostics), and "foo_p" would have the same type
> Combine (rightfully) knows that i becomes the constant 0xf and
> replaces the two constant shifts with it. However, it doesn't update
> the life information. So, we have a basic block (#3 below) which has
> register 28 live, but being assigned (i.e. it's really dead). GCC
> notices this later,
Doug Gregor wrote:
These are different types. For instance, "int" and "long" are distinct
types in C++, even if both map onto 32-bit integers.
And in Ada, you can have any number of distinct integer types
with identical representations.
Dave Korn writes:
> On 07 November 2006 16:33, Andrew Haley wrote:
>
> > Ricardo FERNANDEZ PASCUAL writes:
>
> > > I have done some experiments to try to understand what is happening, and
> > > I am a bit confused by the bahavior of GCC. Consider the following C
> > > function:
> > >
On Nov 7, 2006, at 11:47 AM, Douglas Gregor wrote:
I just read Nathan's discussion [1] on changing GCC's type system
to use canonical type nodes, where the comparison between two types
requires only a pointer comparison. Right now, we use "comptypes",
which typically needs to do deep struc
DJ Delorie <[EMAIL PROTECTED]> writes:
> The r8c/m16c family cannot shift by more than 16 bits at a time ever,
> or 8 bits at a time with constant shifts. So, to do a variable number
> of shift on a 32 bit value, it needs to emit a conditional, turning
> the attached example into this:
>
> i = 0
> The problem is presumably arising from the REG_EQUAL notes. Where are
> those being generated? Why does this case not arise for other targets?
If the problem stems from REG_NOTEs, then it may again be a duplicate of PR
rtl-optimization/25514.
--
Eric Botcazou
Dale Johannesen wrote:
On Nov 7, 2006, at 11:47 AM, Douglas Gregor wrote:
I just read Nathan's discussion [1] on changing GCC's type system to
use canonical type nodes, where the comparison between two types
requires only a pointer comparison. Right now, we use "comptypes",
which typically n
Bootstrap off the trunk on powerpc-linux fails currently with:
/cvs/gcc-svn/trunk/gcc/libgcov.c: In function ‘__gcov_execl’:
/cvs/gcc-svn/trunk/gcc/libgcov.c:796: internal compiler error: RTL check:
expected code 'set' or 'clobber', have 'parallel' in adjacent_mem_locations, at
config/rs6000/rs
Douglas Gregor <[EMAIL PROTECTED]> writes:
[...]
| What would it take to get canonical type nodes in GCC? Nathan has
| experimented with some pieces of it, and I have experimented with
| others. It will likely be a large effort, but the payoff will be
| worth it in the end. Is the GCC community i
[EMAIL PROTECTED] (Richard Kenner) writes:
| > typedef int foo;
| > typedef foo* foo_p;
| >
| > In a truly canonical type-node environment, "foo" would have the same
| > type node as "int" (so we couldn't produce the name "foo" in
| > diagnostics), and "foo_p" would have the same type
On 11/7/06, Dale Johannesen <[EMAIL PROTECTED]> wrote:
On Nov 7, 2006, at 11:47 AM, Douglas Gregor wrote:
> I just read Nathan's discussion [1] on changing GCC's type system
> to use canonical type nodes, where the comparison between two types
> requires only a pointer comparison. Right now, we
> Like when int and long have the same range on a platform?
> The answer is they are different, even when they imply the same object
> representation.
>
> The notion of unified type nodes is closer to syntax than semantics.
I'm more than a little confused, then, as to what we are talking about
ca
on Sat, Oct 28, 2006 at 11:53:29PM +0200, I (Basile S.) asked
> There are several topics that I wish to be covered a bit on the Wiki (or
> some other documentations), mostly related to configuration (and autoconf,
> with which I am not very familiar, especially in the context of GCC whose
> config
>
> Bootstrap off the trunk on powerpc-linux fails currently with:
>
> /cvs/gcc-svn/trunk/gcc/libgcov.c: In function =E2=80=98__gcov_execl=E2=80=
> =99:
> /cvs/gcc-svn/trunk/gcc/libgcov.c:796: internal compiler error: RTL check: e=
> xpected code 'set' or 'clobber', have 'parallel' in adjacent_me
Richard Kenner wrote:
Like when int and long have the same range on a platform?
The answer is they are different, even when they imply the same object
representation.
The notion of unified type nodes is closer to syntax than semantics.
I'm more than a little confused, then, as to what we are t
On Tue, 7 Nov 2006, Doug Gregor wrote:
> On 11/7/06, Dale Johannesen <[EMAIL PROTECTED]> wrote:
> >
> > On Nov 7, 2006, at 11:47 AM, Douglas Gregor wrote:
> >
> > > I just read Nathan's discussion [1] on changing GCC's type system
> > > to use canonical type nodes, where the comparison between t
> But note this is with RTL checking enabled (--enable-checking=rtl).
Can anyone refresh my memory: why is RTL checking disabled on the mainline?
--
Eric Botcazou
On Tue, Nov 07, 2006 at 11:40:01PM +0100, Eric Botcazou wrote:
> > But note this is with RTL checking enabled (--enable-checking=rtl).
>
> Can anyone refresh my memory: why is RTL checking disabled on the mainline?
Because it takes a LONG time.
Janis
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
[...]
| In C, there are several other sources of intransitivity, such as
| incomplete array types (int[10] and int[5] both compatible with int[] but
I'm sure we can (and probably must) specical-case that.
| not with each other), unprototyped funct
On Tue, 7 Nov 2006, Eric Botcazou wrote:
> > But note this is with RTL checking enabled (--enable-checking=rtl).
>
> Can anyone refresh my memory: why is RTL checking disabled on the mainline?
> Eric Botcazou
I tried many years ago and Mark objected:
http://gcc.gnu.org/ml/gcc-patches/2000-10/msg0
On Nov 7, 2006, at 2:13 PM, Richard Kenner wrote:
Like when int and long have the same range on a platform?
The answer is they are different, even when they imply the same
object
representation.
The notion of unified type nodes is closer to syntax than semantics.
I'm more than a little conf
On Tue, 7 Nov 2006, DJ Delorie wrote:
> > Okay for mainline?
>
> Ok. src too, please.
>
Sorry, I don't have access to that repo.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
>
> On Tue, 7 Nov 2006, Eric Botcazou wrote:
>
> > > But note this is with RTL checking enabled (--enable-checking=rtl).
> >
> > Can anyone refresh my memory: why is RTL checking disabled on the mainline?
> > Eric Botcazou
>
> I tried many years ago and Mark objected:
> http://gcc.gnu.org/ml/gcc
On Nov 7, 2006, at 3:48 PM, Kaveh R. GHAZI wrote:
Perhaps we could take a second look at this decision? The average
system
has increased in speed many times since then. (Although sometimes I
feel
like bootstrapping time has increased at an even greater pace than
chip
improvements over the
On Nov 7, 2006, at 3:53 PM, Mike Stump wrote:
Anyway, in C++, the entire template mechanism was rife with building
up duplicates.
Oh, and as for why not having a canonical type is bad, callers to
comptypes are notorious for just beating it to death:
http://gcc.gnu.org/ml/gcc-patches/2002
> Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The average system
Kaveh> has increased in speed many times since then. (Although sometimes I
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The
average system
Kaveh> has increased in s
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The
average system
Kaveh> has increased in s
David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The average system
Kaveh> has increased in speed many times since then. (Al
Hi,
My driver is crashing when I call copy_from_user()
call. Does any one have idea about this ?
Thanks much in advance...
Thanks & Regards,
Raj
Sponsored Link
Get a free Motorola Razr! Today Only!
Choose
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Like when int and long have the same range on a platform?
| > The answer is they are different, even when they imply the same object
| > representation.
| >
| > The notion of unified type nodes is closer to syntax than semantics.
|
| I'm more than a
On Nov 7, 2006, at 3:05 PM, Gabriel Dos Reis wrote:
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
[...]
| In C, there are several other sources of intransitivity, such as
| incomplete array types (int[10] and int[5] both compatible with
int[] but
I'm sure we can (and probably must) specic
On 11/7/06, Mike Stump <[EMAIL PROTECTED]> wrote:
Anyway, in C++, the entire template mechanism was rife with building
up duplicates. I'd propose that this problem can (and should be
addressed) and that we can do it incrementally. Start with a hello
world, then in comptypes, check to see when i
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 11/7/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > Anyway, in C++, the entire template mechanism was rife with building
| > up duplicates. I'd propose that this problem can (and should be
| > addressed) and that we can do it incrementally. Start wit
Hi,
I'm trying to implement proposal n1968 in g++ which basically adds
lambda functions to C++. The obvious way of implementing this is by a
simple translation which generates a function object which is created
where the lambda function is created. Something like:
for_each(b,e,<>(int & t){t++;})
On Tue, 2006-11-07 at 17:30 -0500, Andrew Pinski wrote:
> >
> > Bootstrap off the trunk on powerpc-linux fails currently with:
> >
> > /cvs/gcc-svn/trunk/gcc/libgcov.c: In function =E2=80=98__gcov_execl=E2=80=
> > =99:
> > /cvs/gcc-svn/trunk/gcc/libgcov.c:796: internal compiler error: RTL check:
On Tue, Nov 07, 2006 at 11:36:00PM -0600, Peter Bergner wrote:
> The parallel that is causing the ICE is a store with update RTL insn.
> It seems like we should detect that and reach into the parallel and
> grab the actual store insn. I'll look into adding that.
I'm testing the patch below. It f
> Because it takes a LONG time.
Figures? Tree checking is not cheap with GCC 4.x either.
--
Eric Botcazou
On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
Now, how much do we worry about the fact that we won't be printing
typedef names
The only potential language gotcha I can think of is:
5 If the typedef declaration defines an unnamed class (or enum), the
first typedef-name declared by the
Basavaraj Hiremath <[EMAIL PROTECTED]> writes:
> My driver is crashing when I call copy_from_user()
> call. Does any one have idea about this ?
Wrong mailing list. Try a kernel programming list. This list is for
compiler development.
Ian
On Nov 7, 2006, at 7:09 PM, Dale Johannesen wrote:
I do understand the advantages of sharing them more. Perhaps some
90% solution could be made to work, with most type nodes being
unified and the problem cases (there would not be any in C++,
apparently) using the existing inefficient mechan
64 matches
Mail list logo
