On Thu, 5 Mar 2009, Geert Bosch wrote:
> Hi Richard,
>
> Great to see that you're addressing this issue. If I understand correctly,
> for RTL all operations are always wrapping, right?
That's true (we don't have signedness information there) and I don't
plan to change that.
> I have been consid
Hi,
I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
no extern linker lib when i understand right.
But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0
I also link with libgcc.but does not help
also my includes-fixed/math.h
contain a declaration
On Fri, Mar 6, 2009 at 12:27 PM, Bernd Roesch wrote:
> Hi,
>
> I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
> no extern linker lib when i understand right.
>
> But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0
>
> I also link with libgcc.but do
This build problem has been occuring for at least a month,
both on the most recent snapshots and on trunk.
The compiler is configured as follows:
../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared
--enable-sha
On Fri, Mar 6, 2009 at 1:48 PM, Piotr Wyderski wrote:
> This build problem has been occuring for at least a month,
> both on the most recent snapshots and on trunk.
>
> The compiler is configured as follows:
>
> ../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
> --enable-version
Richard Guenther wrote:
> Where is windows.h included?
I am not 100% sure yet -- the build process is in progress right
now, so I don't want to interfere. I suspect it is the one included
by gthr-win32.h. It contains the following lines:
#include
/* Now undef the windows BOOL. */
#undef BOOL
On Fri, Mar 6, 2009 at 2:05 PM, Piotr Wyderski wrote:
> Richard Guenther wrote:
>
>> Where is windows.h included?
>
> I am not 100% sure yet -- the build process is in progress right
> now, so I don't want to interfere. I suspect it is the one included
> by gthr-win32.h. It contains the following
On Fri, 6 Mar 2009, Richard Guenther wrote:
> There is of course the problem that we have to be careful not to
> introduce new traps via folding, a problem that doesn't exist with
> the no-overflow variants (I can simply drop to the wrapping variants).
> With for example (a -/v 10) +/v 10 would y
Piotr Wyderski wrote:
> Richard Guenther wrote:
>
>> Where is windows.h included?
>
> I am not 100% sure yet -- the build process is in progress right
> now, so I don't want to interfere. I suspect it is the one included
> by gthr-win32.h. It contains the following lines:
WAG: Do not pass --e
On Fri, 6 Mar 2009, Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Richard Guenther wrote:
>
> > There is of course the problem that we have to be careful not to
> > introduce new traps via folding, a problem that doesn't exist with
> > the no-overflow variants (I can simply drop to the wrapping va
Dave Korn wrote:
> Piotr Wyderski wrote:
>> Richard Guenther wrote:
>>
>>> Where is windows.h included?
>> I am not 100% sure yet -- the build process is in progress right
>> now, so I don't want to interfere. I suspect it is the one included
>> by gthr-win32.h. It contains the following lines:
>
On Fri, 6 Mar 2009, Richard Guenther wrote:
> Ok, I didn't think of generating optimal code for the overflow checks,
> but it should be reasonably possible to if-convert the explicit
> overflow checks back to builtins that can be specially expanded
> (that would also help explicit overflow checks
> So while trapping variants can certainly be introduced it looks like
> this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x +nv y
(((s ^ x) & (s ^ y)) < 0) ? trap () : s
d = x -nv y
(((
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
>
>> So while trapping variants can certainly be introduced it looks like
>> this task may be more difficult.
>
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
>
> s = x +nv y
Richard Guenther wrote:
> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
>>> So while trapping variants can certainly be introduced it looks like
>>> this task may be more difficult.
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front-
Richard Guenther writes:
> I agree. Btw, for the addition case we generate
>
> leal(%rsi,%rdi), %eax
> xorl%eax, %esi
> xorl%eax, %edi
> testl %edi, %esi
> jns .L2
> .value 0x0b0f
> .L2:
> rep
> ret
>
> wh
On Fri, Mar 6, 2009 at 4:09 PM, Paolo Bonzini wrote:
> Richard Guenther wrote:
>> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
>>> I don't think you need to introduce trapping t
On Mar 6, 2009, at 09:15, Joseph S. Myers wrote:
It looks like only alpha and pa presently have insn patterns such as
addvsi3 that would be used by the present -ftrapv code, but I expect
several other processors also have instructions that would help in
overflow-checking code. (For example, Pow
On Mar 6, 2009, at 04:11, Richard Guenther wrote:
I didn't spend too much time thinking about the trapping variants
(well, I believe it isn't that important ;)). But in general we would
have to expand the non-NV variants via the trapping expanders
if flag_trapv was true (so yeah, combining TUs
On Fri, 6 Mar 2009, Richard Guenther wrote:
> Well, I was thinking about detecting the pattern on the tree level instead.
>
> s_6 = x.0_2 + y.1_4;
> D.1597_7 = s_6 ^ x_1(D);
> D.1598_8 = s_6 ^ y_3(D);
> D.1599_9 = D.1597_7 & D.1598_8;
> if (D.1599_9 < 0)
> goto ;
> else
> goto
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
Multiple front ends want the same thing. This is why it would be better
to introduce the codes in GENERIC and have the language-independent
On Fri, 6 Mar 2009, Geert Bosch wrote:
> > this task may be more difficult. So lowering them early during
> > gimplification looks like a more reasonable plan IMHO.
>
> Right, that was my intention. Still, I'll need to add code to
> handle the new tree codes in fold(), right?
If you add new tra
On Fri, 6 Mar 2009, Geert Bosch wrote:
> In any case, while I'd really like to move the checked signed
> integer overflow from Gigi (GNAT-to-GNU tree translator) to
> the language independent part of GCC, I want to have the absolute
> minimum amount of changes that is necessary to achieve this goa
Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Paolo Bonzini wrote:
>
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front-end as
>
> Multiple front ends want the same thing. This is why it would be better
> to introduce the codes in GENERIC
Dear GCC developers,
I tried to use plugin frameworks
svn://gcc.gnu.org/svn/gcc/branches/plugin (old?) and
svn://gcc.gnu.org/svn/gcc/branches/plugins (current).
'plugin' has transform_ctrees() API. - callback on every fndecl
'plugins' has PLUGIN_CXX_CP_PRE_GENERICIZE. - only supported in C++
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> >
> >> I don't think you need to introduce trapping tree codes. You can
> >> introduce them directly in the front-end as
> >
> > Multiple front ends want the same thing. This is why
Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Geert Bosch wrote:
>
>>> this task may be more difficult. So lowering them early during
>>> gimplification looks like a more reasonable plan IMHO.
>> Right, that was my intention. Still, I'll need to add code to
>> handle the new tree codes in fold(),
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
> If this does not work, on ARM you can also hope for something like this:
>
> ADDR0, R1, R2
> XORS R0, R2, R3
> XORSMI R1, R2, R3
> SWIMI #trap
On ARM you can just check for overflow directly...
ADDSR
On Thu, 2009-03-05 at 18:24 +0100, Laurent GUERBY wrote:
> On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote:
> > On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote:
> > > Laurent GUERBY wrote:
> > > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote:
> > > >> Laurent GUERBY wrote:
> > > >>
On Mar 5, 2009, Jan Hubicka wrote:
> The patch adds mechanizm for tracking inline substitutions, so we
> actually note that on whole scope of its existence ARGUMENT is having
> same value as OTHERARGUMENT.
Beautiful!
> So if we want to have DEBUG_INSN approach, those aproaches should
> combine
>> If this does not work, on ARM you can also hope for something like this:
>>
>> ADDR0, R1, R2
>> XORS R0, R2, R3
>> XORSMI R1, R2, R3
>> SWIMI #trap
>
> On ARM you can just check for overflow directly...
>
> ADDSR0, R1, R2
> SWIVS #trap
Of course,
Richard Earnshaw writes:
> On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
>> If this does not work, on ARM you can also hope for something like this:
>>
>> ADDR0, R1, R2
>> XORS R0, R2, R3
>> XORSMI R1, R2, R3
>> SWIMI #trap
>
> On ARM you can just check for o
Ian Lance Taylor wrote:
Richard Earnshaw writes:
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check
Laurent GUERBY wrote:
>
> On i686-linux for c,ada:
>
> 3.4.4 bootstraped 4.3.2 fine (your configuration)
> 3.4.0 bootstraped 4.3.1 fine
> 3.4.0 bootstraped trunk 143919 fine
>
> I'm not going to test more, a priori what the documentation
> currently says for Ada is correct at least for i686-lin
On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
If you add new trapping codes to GENERIC I'd recommend *not* making
fold()
handle them. I don't think much folding is safe for the trapping
codes
when you want to avoid either removing or introducing traps. Either
lower
the codes in gimpli
On Fri, 6 Mar 2009, Geert Bosch wrote:
>
> On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
> > If you add new trapping codes to GENERIC I'd recommend *not* making fold()
> > handle them. I don't think much folding is safe for the trapping codes
> > when you want to avoid either removing or intr
Snapshot gcc-4.4-20090306 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090306/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > On Fri, 6 Mar 2009, Geert Bosch wrote:
> >
> >>> this task may be more difficult. So lowering them early during
> >>> gimplification looks like a more reasonable plan IMHO.
> >> Right, that was my intention. Still, I'll need t
I'm happy to report that the gcc-in-cxx branch can now bootstrap. That
is, the code in gcc proper can now be compiled with a C++ compiler.
My plan going forward is as follows (when we are back in stage 1):
* For each difference between trunk and gcc-in-cxx:
+ Try to implement a -Wc++-compat wa
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if interested.
Thank you,
Silvius
Motivation
==
int foo(int x)
{
int i = 100;
do
{
if (x > 0)
x = x & 1; /* After this insn, all bits
I'm thinking about adding bitwise dataflow analysis support to RTL.
Before embarking on this, I'd suggest playing with the bitwise domain
analysis that one of my students did as part of his cXprop tool:
http://www.cs.utah.edu/~coop/research/cxprop/#DOWNLOADS
This is a source-level analysis
Sent from my iPhone
On Mar 6, 2009, at 7:00 PM, Silvius Rus wrote:
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if
interested.
There is already some bitwise dataflow implemented in combine. And I
think
42 matches
Mail list logo
