Hi Marek,
On Do, 2014-10-23 at 10:23 +0200, Marek Polacek wrote:
> On Tue, Apr 22, 2014 at 01:58:00PM +0200, Hannes Frederic Sowa wrote:
> > I'll play around and will post a new patch in the not too distant
> > future. ;)
>
> Are you still planning on posting the revised patch? Perhaps I could
>
Hi,
On Tue, Apr 22, 2014 at 01:58:00PM +0200, Hannes Frederic Sowa wrote:
> I'll play around and will post a new patch in the not too distant
> future. ;)
Are you still planning on posting the revised patch? Perhaps I could
take and finish the patch, but I don't think I can do that because you
d
On Thu, Apr 17, 2014 at 04:20:06PM +0200, Ondřej Bílka wrote:
> On Sat, Apr 12, 2014 at 12:53:45AM +0200, Hannes Frederic Sowa wrote:
> > Hi!
> >
> > On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> > > For a "quick" GCC implementation of the builtins you could expand
> > > them t
On Tue, Apr 15, 2014 at 03:41:53PM +0200, Richard Biener wrote:
> On Sat, Apr 12, 2014 at 12:53 AM, Hannes Frederic Sowa
> wrote:
> > Hi!
> >
> > On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> >> For a "quick" GCC implementation of the builtins you could expand
> >> them to a op
On Sat, Apr 12, 2014 at 12:53:45AM +0200, Hannes Frederic Sowa wrote:
> Hi!
>
> On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> > For a "quick" GCC implementation of the builtins you could expand
> > them to a open-coded sequence during gimplification. But due to
> > the issues
On Sat, Apr 12, 2014 at 12:53 AM, Hannes Frederic Sowa
wrote:
> Hi!
>
> On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
>> For a "quick" GCC implementation of the builtins you could expand
>> them to a open-coded sequence during gimplification. But due to
>> the issues pointed out
Hi!
On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> For a "quick" GCC implementation of the builtins you could expand
> them to a open-coded sequence during gimplification. But due to
> the issues pointed out above I'm not sure it is the best interface
> to support (though now t
On Tue, Nov 26, 2013 at 12:31:00PM -0500, Geert Bosch wrote:
> >> [...]
> >> A few things helped to make the cost small: the biggest one is that
> >> typically on of the operands is known to be negative or positive.
> >> Gigi will use Ada type information, and Natural or Positive integer
> >> var
On Nov 9, 2013, at 02:48, Ondřej Bílka wrote:
>> I've done the overflow checking in Gigi (Ada front end). Benchmarking
>> real world large Ada programs (where every integer operation is checked,
>> including array index computations etc.), I found the performance cost
>> *very* small (less than
On Fri, Nov 08, 2013 at 08:31:38PM -0500, Geert Bosch wrote:
>
> On Oct 29, 2013, at 05:41, Richard Biener wrote:
>
> > For reference those
> > (http://clang.llvm.org/docs/LanguageExtensions.html) look like
> >
> > if (__builtin_umul_overflow(x, y, &result))
> >return kErrorCodeHackers;
>
On Oct 29, 2013, at 05:41, Richard Biener wrote:
> For reference those
> (http://clang.llvm.org/docs/LanguageExtensions.html) look like
>
> if (__builtin_umul_overflow(x, y, &result))
>return kErrorCodeHackers;
>
> which should be reasonably easy to support in GCC (if you factor out
> gen
On 31/10/13 17:51, Andrew Haley wrote:
On 10/31/2013 08:02 AM, David Brown wrote:
On 30/10/13 16:56, Andrew Haley wrote:
On 10/30/2013 03:23 PM, David Brown wrote:
I believe that's only a minor reason for making signed overflows
undefined behaviour. If it were a matter of implementation, I th
On 10/31/2013 08:02 AM, David Brown wrote:
> On 30/10/13 16:56, Andrew Haley wrote:
>> On 10/30/2013 03:23 PM, David Brown wrote:
>>> I believe that's only a minor reason for making signed overflows
>>> undefined behaviour. If it were a matter of implementation, I think it
>>> would have been made
On 30/10/13 16:56, Andrew Haley wrote:
> On 10/30/2013 03:23 PM, David Brown wrote:
>> I believe that's only a minor reason for making signed overflows
>> undefined behaviour. If it were a matter of implementation, I think it
>> would have been made "implementation defined" rather than "undefined"
On 10/30/2013 03:23 PM, David Brown wrote:
> I believe that's only a minor reason for making signed overflows
> undefined behaviour. If it were a matter of implementation, I think it
> would have been made "implementation defined" rather than "undefined",
> so that two's complement machines could
On 30/10/13 15:59, Ondřej Bílka wrote:
> On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
>> On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
>>> 2013/10/30 Andrew Haley :
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
> The reasons of adding builtins is
On Wed, Oct 30, 2013 at 03:59:59PM +0100, Ondřej Bílka wrote:
> On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
> > On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
> > > 2013/10/30 Andrew Haley :
> > > > On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
> > > >
> > > >>>
> > >
On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
> On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
> > 2013/10/30 Andrew Haley :
> > > On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
> > >
> > >>>
> > >> The reasons of adding builtins is performance. Without that one can
> >
On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
> 2013/10/30 Andrew Haley :
> > On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
> >
> >>>
> >> The reasons of adding builtins is performance. Without that one can
> >> write a simple template to generically check overflows like
> >>
> >> templa
On 10/30/2013 03:03 PM, David Brown wrote:
Technically speaking, casting your signed values to unsigned and using
that to detect overflow will not necessarily work - I think it would be
"implementation defined". But almost all architectures use two's
compliment arithmetic, and it will work ther
On 30/10/13 10:00, Kai Tietz wrote:
> 2013/10/30 Andrew Haley :
>> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
>>> The reasons of adding builtins is performance. Without that one can
>>> write a simple template to generically check overflows like
>>>
>>> template class overflow {
>>> pub
On Wed, Oct 30, 2013 at 12:54:12PM +0100, Florian Weimer wrote:
> On 10/26/2013 09:29 PM, Ondřej Bílka wrote:
> >Hi, as I brainstormed how prevent possible overflows in memory allocation I
> >came with heretic idea:
> >
> >For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> >type
On 10/26/2013 09:29 PM, Ondřej Bílka wrote:
Hi, as I brainstormed how prevent possible overflows in memory allocation I
came with heretic idea:
For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
type by one that checks for integer overflow and aborts on it. This
would prevent m
On Wed, Oct 30, 2013 at 08:41:32AM +, Andrew Haley wrote:
> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>
> >>
> > The reasons of adding builtins is performance. Without that one can
> > write a simple template to generically check overflows like
> >
> > template class overflow {
> > publi
2013/10/30 Andrew Haley :
> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>
>>>
>> The reasons of adding builtins is performance. Without that one can
>> write a simple template to generically check overflows like
>>
>> template class overflow {
>> public:
>> C val;
>> overflow operator + (ov
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
> The reasons of adding builtins is performance. Without that one can
> write a simple template to generically check overflows like
>
> template class overflow {
> public:
> C val;
> overflow operator + (overflow &y) {
> overflow ret;
>
On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> On Sun, Oct 27, 2013 at 1:50 AM, Hannes Frederic Sowa
> wrote:
> > On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
> >> Hi, as I brainstormed how prevent possible overflows in memory allocation I
> >> came with heretic
On Tue, 29 Oct 2013, Richard Biener wrote:
> LLVM covers addition, subtraction and multiply on signed and unsigned
> int, long and long long types. Not sure why they offer anything for
> unsigned - possibly for size_t arithmetic and security concerns with
> malloc? For practicability and to be l
On Sun, Oct 27, 2013 at 1:50 AM, Hannes Frederic Sowa
wrote:
> On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
>> Hi, as I brainstormed how prevent possible overflows in memory allocation I
>> came with heretic idea:
>>
>> For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with
On Sun, Oct 27, 2013 at 02:15:57PM +0100, Jakub Jelinek wrote:
> On Sun, Oct 27, 2013 at 12:35:24PM +0100, Ondřej Bílka wrote:
> > On Sun, Oct 27, 2013 at 11:51:00AM +0100, Marek Polacek wrote:
> > > Or just wait till the integer overflow detection in ubsan is completed.
> > >
> > As these computat
On Sun, Oct 27, 2013 at 12:35:24PM +0100, Ondřej Bílka wrote:
> On Sun, Oct 27, 2013 at 11:51:00AM +0100, Marek Polacek wrote:
> > Or just wait till the integer overflow detection in ubsan is completed.
> >
> As these computations now are done on unsigned type which has behaviour
> defined as modul
On Sun, Oct 27, 2013 at 11:51:00AM +0100, Marek Polacek wrote:
> Or just wait till the integer overflow detection in ubsan is completed.
>
As these computations now are done on unsigned type which has behaviour
defined as modular arithmetic this would not help.
Or just wait till the integer overflow detection in ubsan is completed.
Marek
On Sun, 2013-10-27 at 07:48 +0100, Ondřej Bílka wrote:
> On Sun, Oct 27, 2013 at 01:50:14AM +0200, Hannes Frederic Sowa wrote:
> > On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
> > > Hi, as I brainstormed how prevent possible overflows in memory allocation
> > > I
> > > came with h
On Sun, Oct 27, 2013 at 01:50:14AM +0200, Hannes Frederic Sowa wrote:
> On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
> > Hi, as I brainstormed how prevent possible overflows in memory allocation I
> > came with heretic idea:
> >
> > For gcc -D_FORTIFY_SOURCE=2 we expand all multip
>>>
>>>
>>>
>> Or alternatively you could use the Ada language where integer overflow
>> and buffer overflows are built into the language are fully handled by
>> the compiler.
>>
> Yeah, I will suggest my boss in our project that cost $1 000 000 to
> fire all C programmers, hire ada programmer
On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
> Hi, as I brainstormed how prevent possible overflows in memory allocation I
> came with heretic idea:
>
> For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> type by one that checks for integer overflow and aborts o
On Sat, Oct 26, 2013 at 09:41:36PM +0200, Arnaud Charlet wrote:
> > Hi, as I brainstormed how prevent possible overflows in memory allocation I
> > came with heretic idea:
> >
> > For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> > type by one that checks for integer overflow
> Hi, as I brainstormed how prevent possible overflows in memory allocation I
> came with heretic idea:
>
> For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> type by one that checks for integer overflow and aborts on it. This
> would prevent most overflow at cost of breaking s
Hi, as I brainstormed how prevent possible overflows in memory allocation I
came with heretic idea:
For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
type by one that checks for integer overflow and aborts on it. This
would prevent most overflow at cost of breaking some legitima
40 matches
Mail list logo
