Eric Botcazou wrote:
For Ada, I propose we make the following changes:
- by default, enable overflow checks using -ftrapv
-ftrapv is not practically usable because (1) it generates awful code and (2)
it badly interacts with the RTL optimizers.
please before you say this compare it with
Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes:
> >>I couldn't understand why the insns 620 and 621 are
> >>being generated here as DI moves.
> > I'm not sure specifically why it got a DI move here, but it doesn't
> > look wrong. It's treating the struct named parts as DImode.
> >
> >>This is crea
I've just done an x86_64 build of HEAD and didn't see this error.
Bryce
Richard Guenther wrote:
On x86_64 I see
/net/pherkad/scratch/rguenth/gcc-obj/./gcc/gcj
-B/net/pherkad/scratch/rguenth/gcc-obj/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -
> For Ada, I propose we make the following changes:
>- by default, enable overflow checks using -ftrapv
-ftrapv is not practically usable because (1) it generates awful code and (2)
it badly interacts with the RTL optimizers.
--
Eric Botcazou
On x86_64 I see
/net/pherkad/scratch/rguenth/gcc-obj/./gcc/gcj
-B/net/pherkad/scratch/rguenth/gcc-obj/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-i
Geert Bosch wrote:
For Ada, I propose we make the following changes:
- by default, enable overflow checks using -ftrapv
This won't work, we generate plenty of cases of operations
where we definitely don't want a check, and we don't set the
flag, but currently the flag is ignored by gcc/gigi,
On Fri, Jun 03, 2005 at 03:26:19PM -0400, Bradley Lucier wrote:
> Assuming that overflow of signed integer arithmetic wraps (and what gcc
> flag do I have to set to assume this?) then here is the algorithm to
> multiply x and y with overflow detection.
Cast to unsigned; we are guaranteed that
I definitely think that -fwrapv should be the default for
Ada.
On Jun 3, 2005, at 09:02, Florian Weimer wrote:
It probably makes sense to turn on -fwrapv for Ada because even
without -gnato, the behavior is not really undefined:
| The reason that we distinguish overflow checking from other kinds of
| range constraint checking is that a failure of an overfl
On May 30, 2005, at 02:57, Victor STINNER wrote:
I'm using gcc "long long" type for my calculator. I have to check
integer overflow. I'm using sign compare to check overflow, but it
doesn't work for 10^16 * 10^4 :
1 * 1
I see your question went unanswered, however I do th
This is the wrong list to ask such a question, but I'll answer it
anyway since the answer might be of general interest.
There is a wonderful book "Hacker's Delight" by Henry S. Warren Jr.,
http://www.awprofessional.com/bookstore/product.asp?
isbn=0201914654&redir=1&rl=1
In some ways it can
> Jan Hubicka wrote:
>
> > I didn't have any cleanup_cfg in between earliest place putting
> > predictions and the profiling pass consuming them, so this scenario
> > didn't happen. This has however changed a long time ago. I guess just
> > teaching remove_edge to walk prediction list if it is p
> struct-layout-1_generate.c is run on the host, not on the target.
> And for hosts AFAIK GCC requires 32-bit int.
But the structures it generates assume 32-bit ints:
T(0,enum E2 a:31;,B(0,a,e2_m1,e2_0))
You can't have a 31 bit enum on a 16 bit target. You get messages
like this:
On Fri, 2005-06-03 at 13:03 -0400, Paul Schlie wrote:
> > From: Joe Buck <[EMAIL PROTECTED]>
> >> On Fri, Jun 03, 2005 at 11:43:32AM -0400, Andrew Pinski wrote:
> >> Everyone's who writes C/C++ should know that overflow of signed is
> >> undefined.
> >
> > In practice, however, this issue is comm
> From: Joe Buck <[EMAIL PROTECTED]>
>> On Fri, Jun 03, 2005 at 11:43:32AM -0400, Andrew Pinski wrote:
>> Everyone's who writes C/C++ should know that overflow of signed is undefined.
>
> In practice, however, this issue is commonly ignored, because people code
> in a hurry, then test the behavior
> Everyone's who writes C/C++ should know that overflow of signed is undefined.
>
> Now in Java it is defined, which is the reason why -fwrapv exists in the
> place since GCC has a "Java" compiler.
Right. I also believe that it is conceptually wrong to enable this for
Ada, so until this issue is
On Fri, Jun 03, 2005 at 06:25:27PM +0200, Florian Weimer wrote:
> There's also a fair amount of code whih relies on -1 ==
> (int)0x.
While that is not portable, -(1U) is portably all-ones, even on 36 bit
one's complement machines or other oddball architectures, since unsigned
types are req
* Joe Buck:
> I'm sure there are plenty of production codes that assume signed integer
> overflow wraps, or at least make the weaker assumption that in
>
>a = b + c + d;
>
> where all variables are integers, if one of the intermediate terms
> can't be represented in an integer, we still ge
On Fri, Jun 03, 2005 at 11:14:15AM +0200, Jakub Jelinek wrote:
> On Fri, Jun 03, 2005 at 02:07:57AM -0700, Mark Mitchell wrote:
> > >Doesn't "is-effective-target ilp32" test for 32 bits int?
> >
> > Good point! I forgot about that. My brain is stuck in some other year.
> >
> > That doesn't let
On Fri, Jun 03, 2005 at 11:43:32AM -0400, Andrew Pinski wrote:
> Everyone's who writes C/C++ should know that overflow of signed is undefined.
In practice, however, this issue is commonly ignored, because people code
in a hurry, then test the behavior of the executable code, and if on all
platform
* Paul Schlie:
>> No they should be using -ftrapv instead which traps on overflow and then
>> make sure they are not trapping when testing.
>
> - why? what language or who's code/target ever expects such a behavior?
I think Andrew wants programmers to fix their code, instead of
papering over prob
>
> > No they should be using -ftrapv instead which traps on overflow and then
> > make sure they are not trapping when testing.
>
> - why? what language or who's code/target ever expects such a behavior?
Everyone's who writes C/C++ should know that overflow of signed is undefined.
Now in Java i
Greetings!
Raymond Toy <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Raymond Toy writes:
> >
> >>On the sparc port, this area can be zeroed out with appropriate
> >>optimization settings. I ran some tests using Eric Marsden's
> >>cl-bench. If the stack is always cleared, the cost of so
> From: Andrew Pinski <[EMAIL PROTECTED]>
(Without -fwrapv, integer overflow is undefined, and subsequent range
checks can be optimized away, so that it might cause erroneous
behavior.)
>>>
>>> - Since for all practical purposes most (if not all) target's use
>>> 2's complement in
>
> * Paul Schlie:
>
> >> (Without -fwrapv, integer overflow is undefined, and subsequent range
> >> checks can be optimized away, so that it might cause erroneous
> >> behavior.)
> >
> > - Since for all practical purposes most (if not all) target's use
> > 2's complement integer representation
* Paul Schlie:
>> (Without -fwrapv, integer overflow is undefined, and subsequent range
>> checks can be optimized away, so that it might cause erroneous
>> behavior.)
>
> - Since for all practical purposes most (if not all) target's use
> 2's complement integer representations which naturally "
I have a 2 bedroom suite at Les Suites for June 21 through 25. I'm
looking to split costs with someone for the other bedroom and / or
someone for the living room + sofa bed. Preferably for all 4 nights.
If interested please send me mail off-list.
Also, I'll be driving from North-of-Toronto area
> (Without -fwrapv, integer overflow is undefined, and subsequent range
> checks can be optimized away, so that it might cause erroneous
> behavior.)
- Since for all practical purposes most (if not all) target's use
2's complement integer representations which naturally "wrap", might
it be sim
* Andrew Pinski:
> The Ada front-end is still being missed compiled by VRP but VRP is doing
> the correct thing as the type is signed and overflow on signed is
> undefined
> (-fwrapv is not turned on by default for Ada).
It probably makes sense to turn on -fwrapv for Ada because even
without -gn
On 6/2/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 6/2/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > LAST_UPDATED: Thu Jun 2 08:44:04 UTC 2005
> >
> > Works on Solaris as of Wed Jun 1 04:42:14 UTC 2005
> >
> > > Any ideas of what goes on?
> >
> > Top of ChangeLog here is:
> >
> >
On Fri, Jun 03, 2005 at 10:56:37AM +0100, Nix wrote:
> The point of that trickery is to avoid introducing a dependency on the
> shared libgcc for programs that don't use exception handling. If they
> do, it'll come from the shared libgcc: otherwise, the shared libgcc gets
> entirely dropped thanks
On 2 Jun 2005, Peter S. Mazinger murmured:
> On Thu, 2 Jun 2005, Jakub Jelinek wrote:
>
>> On Thu, Jun 02, 2005 at 01:59:46PM +0200, Peter S. Mazinger wrote:
>> > Hello!
>> >
>> > the sequence used for linking on x86 (but most archs will have it too)
>> > -lgcc --as-needed -lgcc_s --no-as-needed
On Thu, Jun 02, 2005 at 09:49:03PM -0400, DJ Delorie wrote:
>
> gcc.dg/compat/struct-layout-1_generate.c assumes sizeof(int) is 4.
> This of course fails on any target where sizeof(int) is 2. They may
> fail when sizeof(int) is 8 too, or at least they won't be testing the
> full range of possibil
On Fri, Jun 03, 2005 at 02:07:57AM -0700, Mark Mitchell wrote:
> >Doesn't "is-effective-target ilp32" test for 32 bits int?
>
> Good point! I forgot about that. My brain is stuck in some other year.
>
> That doesn't let you adjust the test based on the compiler, but it does
> let you skip test
Steven Bosscher wrote:
On Friday 03 June 2005 10:48, Mark Mitchell wrote:
DJ Delorie wrote:
Do we have a standard way of telling the testsuite how big target
types are, or some standard "this test assumes 32 bit int" dejagnu
flag?
I don't think we have any way of doing this at present. I c
On Friday 03 June 2005 10:48, Mark Mitchell wrote:
> DJ Delorie wrote:
> > Do we have a standard way of telling the testsuite how big target
> > types are, or some standard "this test assumes 32 bit int" dejagnu
> > flag?
>
> I don't think we have any way of doing this at present. I could be
> wro
DJ Delorie wrote:
Do we have a standard way of telling the testsuite how big target
types are, or some standard "this test assumes 32 bit int" dejagnu
flag?
I don't think we have any way of doing this at present. I could be
wrong, though. We could certainly add logic to compute this, using
The Ada front-end is still being missed compiled by VRP but VRP is doing
the correct thing as the type is signed and overflow on signed is
undefined
(-fwrapv is not turned on by default for Ada).
The following code shows the problem (reduced from csets.ad?):
package body Asets is
X_80 : cons
Thanks for an extremely quick reply.
We could get this on one of the OS CDs. No hassles at all.
Regards,
Prafulla Shukla,
ISV,
Patni, Pune,
(W): +91 20 3984 4206
(W): +91 20 3984 4000 (X 4206)
-Original Message-
From: Karel Gardas [mailto:[EMAIL PROTECTED]
Sent: Friday, June 03, 2005 12:1
39 matches
Mail list logo
