> Generic but you might want to start by trying to define a type
> system first.
>
Actually, we shouldn't be writing out any of them, at least in their
current form.
(IE it shouldn't be pickled trees)
> -- Pinski
>
> I have been given some time by my management to work on creating a
> framework for IPO optimizations in GCC by creating an intermediate file
> reader and writer for GCC.
>
> I would like to start by getting any input and advice the members of the
> GCC community might have for me. I would al
I have been given some time by my management to work on creating a
framework for IPO optimizations in GCC by creating an intermediate file
reader and writer for GCC.
I would like to start by getting any input and advice the members of the
GCC community might have for me. I would also like to see
On Fri, Oct 07, 2005 at 12:06:32PM -0700, Kean Johnston wrote:
> >You're in luck! dg-warning and similar directives can be skipped or
> >xfailed for particular targets, but those don't take options into
> >account. There is, however, an effective-target keyword for fpic.
> Ok I'll give that a whi
You're in luck! dg-warning and similar directives can be skipped or
xfailed for particular targets, but those don't take options into
account. There is, however, an effective-target keyword for fpic.
Ok I'll give that a whirl. But what if I needed to skip the test
based on some other command li
On Fri, Oct 07, 2005 at 07:06:21PM +0100, Felix Oxley wrote:
> > For variables marked __initdata, the "*foo" form causes only the
> > pointer, not the string itself, to be dropped from the kernel image,
> > which is a bug.
Not a bug. A missing feature, perhaps, but not a bug.
> > http://lists.os
On Fri, Oct 07, 2005 at 07:06:21PM +0100, Felix Oxley wrote:
>
> I was looking on the kernel-janitors site at the To Do list and found this
> task below, which I decided to try my hand at.
> (http://www.kerneljanitors.org/TODO)
>
> > 1) The string form
> >
> > [const] char *foo = "blah
I was looking on the kernel-janitors site at the To Do list and found this
task below, which I decided to try my hand at.
(http://www.kerneljanitors.org/TODO)
> 1) The string form
>
> [const] char *foo = "blah";
>
> creates two variables in the final assembly output, a static string,
On Fri, Oct 07, 2005 at 01:32:29AM -0700, Kean Johnston wrote:
> Is there a way to exclude specific line tests based on
> target switches? Something like dg-skip-if? Or perhaps
> thats the right think to use (but all the examples I
> have seen seem to skip the entire test case).
You're in luck! d
On Fri, 2005-10-07 at 08:26 -0400, Richard Kenner wrote:
> Personally, I would have not had a DECL_SIZE, i would have made
> TYPE_SIZE express the type size properly (IE not always a multiple).
>
> What is the incredibly good reason we have them both, other than to save
> memory in
Daniel Berlin wrote:
> Thinking harder about it, you might be better off then making
> everything based on TYPE_SIZE then, since we don't always have the
> FIELD_DECL's handy.
[...]
> i meant in tree-ssa-structalias.c. The results you get by doing this
> should be fine.
Oh, OK. Will look into
Personally, I would have not had a DECL_SIZE, i would have made
TYPE_SIZE express the type size properly (IE not always a multiple).
What is the incredibly good reason we have them both, other than to save
memory in the number of bitfield types we create?
Because we need to have a
4.1.4
Thread model: posix
gcc version 4.1.0 20051007 (experimental)
Brad
> > precision 3 min max >
>
> You'll note we actually created a new type for this :)
Indeed, and I think we also have that in Ada, my confusion.
Actually, I don't think we do and I recall a discussion a few weeks
ago that it would be incorrect Ada semantics to do it. But
On Fri, 2005-10-07 at 07:35 -0400, Richard Kenner wrote:
> This is the correct fix, however, if you are going to lie to the
> middle end about TYPE_SIZE so that the TYPE_SIZE and DECL_SIZE do not
> match.
>
> If we always require that DECL_SIZE be identical to TYPE_SIZE, why
> have
This is the correct fix, however, if you are going to lie to the
middle end about TYPE_SIZE so that the TYPE_SIZE and DECL_SIZE do not
match.
If we always require that DECL_SIZE be identical to TYPE_SIZE, why
have a DECL_SIZE in the first place? But how else would you support
bitf
> > Thinking harder about it, you might be better off then making
> > everything based on TYPE_SIZE then, since we don't always have the
> > FIELD_DECL's handy.
>
> I'm not sure we can.
>
> I think we must have an integral mode (and size) for the type to be
> able to place the field on a
Richard Henderson wrote:
> > precision 3 min max >
> ^^^
>
> Actually, we did create a different type just for this bitsize.
Indeed, my comment was confused on that account.
> Not that that detracts from the fact that TYPE_SIZE is always a
> multiple of BITS_PER_UNIT.
Agr
Daniel Berlin wrote:
> >
> > size
> > > size
> > precision 3 min max >
>
> You'll note we actually created a new type for this :)
Indeed, and I think we also have that in Ada, my confusion. The
TYPE_SIZE is still larger than the DECL_SIZE above, and the field
rea
Hi,
Is there a way to exclude specific line tests based on
target switches? Something like dg-skip-if? Or perhaps
thats the right think to use (but all the examples I
have seen seem to skip the entire test case).
For example, in gcc.dg/assign-warn-3.c, how would I
ignore the check for a warning
20 matches
Mail list logo
