Hi Carlos and Mark,
Your "Relocated compiler should not look in $prefix" patch here:
http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
appears to have caused a regression in my GCC 4.3 testing.
In summary, there is a small window *during the GCC build itself* where GCC
does not pick up the correc
FX Coudert wrote:
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use (or would use) checking on signe
Sorry terminology is fighting language!
by parameter - I mean argument registers - also a stray "use" may have
crept in.
Original problem : prolog is saving "live" registers that are not "call
used" following normal gcc methods.
But in AVR target this will include some argument registers - a
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use (or would use) checking on signed
overflow.
FX
2008/3/1 Andrew Hutchinson <[EMAIL PROTECTED]>:
> I'm am still struggling with a good solution that avoids unneeded saves
> of parameter registers.
>
> To solve problem all I need to know are the registers actually used for
> parameters. Since the caller assumes all of these are clobbered by
>
Robert Dewar wrote:
The reason that we distinguish overflow checking from other kinds of
constraint checking is that a failure of an overflow check, unlike
for example the failure of a range check, can result in an incorrect
value, but cannot cause random memory destruction (like an out of range
Florian Weimer wrote:
* Robert Dewar:
Standard ML. I don't think there is a GCC front end (and it's not
likely that one will be feasible, at least until GCC supports a fitting
garbage collector).
Why is it a GCC issue to support a GC for ML, I don't get it ...
ML programs are mostly functio
Florian Weimer wrote:
Are we talking about the Ada semantics or GNAT without -gnato? In the
latter case, the documentation disagrees with you:
The reason that we distinguish overflow checking from other kinds
of range constraint checking is that a failure of an overflow
check ca
* Robert Dewar:
>> Standard ML. I don't think there is a GCC front end (and it's not
>> likely that one will be feasible, at least until GCC supports a fitting
>> garbage collector).
>
> Why is it a GCC issue to support a GC for ML, I don't get it ...
ML programs are mostly functional and alloca
* Robert Dewar:
> Florian Weimer wrote:
>> * Robert Dewar:
>>
>>> So here's exactly what happens now in Ada
>>>
>>> 1. If -gnato is not set (no overflow checking)
>>>
>>> In this case, the situation is exactly the same as C, and the front end
>>> ignores the possibility of overflow.
>>
>> It's C i
Mark,
While I don't see any particular differences in how
gcc 4.3 branch links its shared libraries with or without
r131198 applied, I do notice that it causes the xgcc created
to be linked against the system libgcc. Without r131198,
only the xgcc in stage1-gcc is linked to the system libgcc.
Wi
Florian Weimer wrote:
* Richard Kenner:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that re
Florian Weimer wrote:
* Robert Dewar:
So here's exactly what happens now in Ada
1. If -gnato is not set (no overflow checking)
In this case, the situation is exactly the same as C, and the front end
ignores the possibility of overflow.
It's C in -fwrapv mode, isn't it? (Otherwise, you can'
* Florian Weimer:
> * Richard Kenner:
>
>>> int f(int a, int b) { return 0 * (a + b); }
>>>
>>> get the potentially trapping arithmetic folded away. If -ftrapv is to
>>> have properly defined semantics, those must include trapping if (a + b)
>>> overflows in the above code.
>>
>> Why? Is ther
* Richard Kenner:
>> int f(int a, int b) { return 0 * (a + b); }
>>
>> get the potentially trapping arithmetic folded away. If -ftrapv is to
>> have properly defined semantics, those must include trapping if (a + b)
>> overflows in the above code.
>
> Why? Is there any language that requires
* Robert Dewar:
> So here's exactly what happens now in Ada
>
> 1. If -gnato is not set (no overflow checking)
>
> In this case, the situation is exactly the same as C, and the front end
> ignores the possibility of overflow.
It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the
On Sat, 1 Mar 2008, Richard Kenner wrote:
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Why? Is the
On Sat, 1 Mar 2008, Richard Guenther wrote:
> > But arbitrary arithmetic expressions aren't marked as potentially trapping
> > / having side-effects with -ftrapv, so cases such as
> >
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. I
hello
sorry after 2 more success with gcc build this night ,i have not
succeeded to reproduce
the error "Ada.Calendar is not a predefined library unit"
the difficult with mingw, there are no dependance packages, only
overwrite binaries manualy
and flex,bison and deps libs are not natively presen
Hello all,
apologies for causing a bootstrap failure when building libobjc due to
my patch for PR 35063 (r132800). As of r132802, I believe this issue
is now fixed. Big thanks to Jerry DeLisle for helping out with the
fix.
--
Janne Blomqvist
I'm am still struggling with a good solution that avoids unneeded saves
of parameter registers.
To solve problem all I need to know are the registers actually used for
parameters. Since the caller assumes all of these are clobbered by
callee - they should never need to be saved.
DF_REG_DEF_COUNT
> Can you pin-point the patch that caused this and investigate what is
> going wrong?
Sure. It was some time yesterday at least (that script runs every
night), but I'll try to narrow it down further.
On Sat, Mar 1, 2008 at 4:48 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Not a primary target, but still...
>
> Results for 4.3.0 20080301 (prerelease) [gcc-4_3-branch revision 132798]
> (GCC) testsuite on m32c-unknown-elf
>
> --- Start of forwarded message --
Not a primary target, but still...
Results for 4.3.0 20080301 (prerelease) [gcc-4_3-branch revision 132798] (GCC)
testsuite on m32c-unknown-elf
--- Start of forwarded message ---
gcc result changes...
Multilib: m32c-sim/-mcpu=m32c
PASS-FAIL: gcc.c-torture/execute/980707-1.c execution
On Sat, 2008-03-01 at 09:05 -0500, Robert Dewar wrote:
> Note that in Ada, you can often avoid one or both ends of
> the range check, e.g.
>
> type R is integer range 1 .. 10;
>
> RV : R;
>
> R := R + 1;
>
> no need for double length arithmetic here, you just check that the
> re
Joern Rennecke wrote:
Considering the trouble that you get when you try to generate branches in
a non-branch expander, we should probably have alternate named patterns
to be used in ports to processors that have no conditional trap facility,
or where a conditional trap is more expensive than a w
I missed once point noticed by Joseph also, that the libgcc implementation
uses signed types in the implementation of the trapping arithmetics.
Where we of course optimize away the overflow check, so the libgcc
routines will never trap. (if it does work in some cases then this
would be a missed o
On Fri, 29 Feb 2008, Robert Dewar wrote:
Well presumably one would want to use target dependent stuff for
detecting overflow where it exists (sticky overflow bits on
power, O flag on PC, trapping add on MIPS etc).
In fact, when I wrote the original -ftrapv code, it was for the sole purpose
of u
Well presumably one would want to use target dependent stuff for
detecting overflow where it exists (sticky overflow bits on
power, O flag on PC, trapping add on MIPS etc).
On the whole I think you'd want to benefit from tree-ssa optimizing
overflow checks where possible (including optimizing
Richard Kenner wrote:
No one needs a broken anything,
Not necessarily and perhaps not in this case. Let's suppose there was
an implementation of -ftrapv that did trap, but only about 80% of the
time. Such an implementation would nevertheless be useful in C since
there overflow is not a requir
And there's another special-case treatment for libcalls. On top of
REG_LIBCALL/REG_RETVAL/REG_LIBCALL_ID. This is bug prone. For GCC 4.3
alone, I've fixed half a dozen libcall blocks related bugs, and others
have fixed at least as many. Not to mention all the extra work they
caused for the peop
Richard Guenther wrote:
On Sat, 1 Mar 2008, Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is
> IMHO this semantics asks for the frontend to implement the overflow
> check. Does the above mean that Ada does intermediate arithmetics
> in wider types?
No, it means that it must *either* do the arithmetic in wider types *or*
use arithmetic in the narrower types that checks for overflow.
Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semanti
> No one needs a broken anything,
Not necessarily and perhaps not in this case. Let's suppose there was
an implementation of -ftrapv that did trap, but only about 80% of the
time. Such an implementation would nevertheless be useful in C since
there overflow is not a required feature of the lang
On Sat, Mar 1, 2008 at 3:01 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
>
> > it is more productive to spend the cycles getting rid of the libcalls
> > rather than figuring out the edge cases. as steven implied, we have
> > been on the verge of get
Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semanti
On Sat, 1 Mar 2008, Richard Kenner wrote:
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Why? Is the
> int f(int a, int b) { return 0 * (a + b); }
>
> get the potentially trapping arithmetic folded away. If -ftrapv is to
> have properly defined semantics, those must include trapping if (a + b)
> overflows in the above code.
Why? Is there any language that requires such semantics?
Richard Guenther wrote:
IMHO this semantics asks for the frontend to implement the overflow
check. Does the above mean that Ada does intermediate arithmetics
in wider types? I don't see how you could catch the B + C case
otherwise (assuming the range check for the assignment to A covers
all of
On 3/1/08 5:13 AM, Jan Hubicka wrote:
while I am with Diego that would preffer PHI nodes on side especially in
FUD chain where rest of your SSA is on side too. But if we go with the
extra instruction scheme, I think you are much better to use RTL USE
instruction. The moves are generated by tar
On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
it is more productive to spend the cycles getting rid of the libcalls
rather than figuring out the edge cases. as steven implied, we have
been on the verge of getting rid of them for years and just have just
not fixed the last reason. The amount of
On Sat, Mar 1, 2008 at 2:57 PM, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Paolo Bonzini wrote:
> >> Seems a pity, this feature is really needed for Ada, which requires
> >> efficient overflow checking for signed arithmetic, and it seems
> >> useful for C, where signed overflow is undefined, and
Paolo Bonzini wrote:
Seems a pity, this feature is really needed for Ada, which requires
efficient overflow checking for signed arithmetic, and it seems
useful for C, where signed overflow is undefined, and it would be
nice to enable trapping.
Right now, Ada uses really horrible double length ar
On Sat, 1 Mar 2008, Robert Dewar wrote:
> Joseph S. Myers wrote:
>
> > But arbitrary arithmetic expressions aren't marked as potentially trapping /
> > having side-effects with -ftrapv, so cases such as
> >
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping ari
Richard Kenner wrote:
Clearly. My point was that Ada doesn't need a *broken* -ftrapv. So if
there's no hope of fixing it, we might as well deprecate it.
Sure, but right now we have the start of a constructive discussion of
how to fix it, so the best thing would be to contribute positively to
Seems a pity, this feature is really needed for Ada, which requires
efficient overflow checking for signed arithmetic, and it seems
useful for C, where signed overflow is undefined, and it would be
nice to enable trapping.
Right now, Ada uses really horrible double length arithmetic to
do trapp
On 3/1/08 8:50 AM, Paolo Bonzini wrote:
Yes, that's what I meant by "no subscripts" (see also my other message
re. birthpoints). Instead of subscripting variables you have multiple
defs for each variable. End each def is obviously assigned only once,
and each use in the IL stream except for
Diego Novillo wrote:
On 2/29/08 7:04 PM, Steven Bosscher wrote:
I am not sure what would happen if GCC would start using FUD chains.
Is it like in SSA that every register is assigned only once?
But this would only affect the UD chains built by the DF code.
Yes, that's what I meant by "no su
On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > > You also need to deal with fold, which will optimize away potentially
> > > trapping computations with -ftrapv and runs before gimplification
> > > (possibly in association with making fold run at g
By the way, I still don't understand how birth points would work. Can
someone give an example of what the insn stream would look like with
birth points, and what the DU/UD chains would look like?
With a big IIUC, and using a high-level IR for simplicity
if (a < 5) goto BB1; else goto BB2;
Joseph S. Myers wrote:
But arbitrary arithmetic expressions aren't marked as potentially trapping
/ having side-effects with -ftrapv, so cases such as
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined sema
On Fri, 29 Feb 2008, Robert Dewar wrote:
> > If it were done at gimplification time I imagine something like the libgcc
> > code would be used, but with conversions to/from unsigned inserted as
> > needed. It would be possible to do optimizations at gimplification time if
> > one argument is cons
On Sat, 1 Mar 2008, Richard Guenther wrote:
> > You also need to deal with fold, which will optimize away potentially
> > trapping computations with -ftrapv and runs before gimplification
> > (possibly in association with making fold run at gimplification time and
> > not before).
>
> It shoul
Richard Guenther wrote:
So I would hestitate to deprecate it so quickly
Maybe you should organize some resources to fix its implementation
then?
Richard.
It's been on the list for over a decade, it's always harder to find
resources to fix performance problems that don't specifically show
up
On Fri, 29 Feb 2008, Robert Dewar wrote:
> Richard Guenther wrote:
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time. As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3
On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> On Fri, 29 Feb 2008, Mark Mitchell wrote:
>
> > Thanks for the explanations. It seems like tree-ssa should in theory make
> > it
> > easier to implement this; for example, at the point of gimplification one
> > could insert checks, and then just let
On Fri, 29 Feb 2008, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> > The tree optimizers do not recognize +-* of singed integers as
> > possibly trapping which causes functions to become const/pure that
> > should not and causes 'dead' code to be removed that should not.
>
> Thanks for the
GCC 4.3.0 release candidate 2 is now available at:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.0-RC-20080301/
Please test the tarballs there and report any problems to Bugzilla. CC me
on the bugs if you believe they are regressions from previous releases
severe enough that they should block the
>
> Not libcalls, but libcall *notes*.
>
> > This exist so we can effectivly remove
> > blocks of code in dead code removal and do some other changes, but I
> > don't see how they can be less friendly to FUD than they are to DU/UD.
> > Sure the optimization has to care to not break the extra
> > Ada currently has to do this itself, precisely because -ftrapv doesn't
> > work, so it's not the case that Ada "needs" it.
>
> Well no one "needs" anything in this sense, any interfaced is Turing
> complete so there is *always* a work around deficiencies in the back
> end. But right now, the
On Sat, Mar 1, 2008 at 11:03 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > The two complications are:
> > 1) libcalls
>
> I am probably dense here, but why we can't just ignore existence of
> libcalls for dataflow framework?
Not libcalls, but libcall *notes*.
> This exist so we can effectiv
> Diego,
>
> I am leaning to just adding noop moves at the birthpoints (dominance
> frontiers) as real noop move insns in the streams in the passes that use
> ud or du chains. The back end is tolerant of noop moves and without
Hi,
while I am with Diego that would preffer PHI nodes on side espec
> The two complications are:
> 1) libcalls
I am probably dense here, but why we can't just ignore existence of
libcalls for dataflow framework? This exist so we can effectivly remove
blocks of code in dead code removal and do some other changes, but I
don't see how they can be less friendly to F
64 matches
Mail list logo
