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
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: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
> Because it takes a LONG time.
Figures? Tree checking is not cheap with GCC 4.x either.
--
Eric Botcazou
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
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:
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++;})
"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
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
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
[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
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
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
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
> 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 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
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 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 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 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, 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
"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, 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
> 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, 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
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
>
> 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
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
> 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 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
[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
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
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
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
> 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
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
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
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:
> > >
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.
> 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,
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
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 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;
> >
> >
> 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
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
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
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
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
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
> 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.
>>
>>
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
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
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]
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
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
> 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.
> 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
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.
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
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 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.
> 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
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
64 matches
Mail list logo
