On Fri, Dec 4, 2015 at 1:27 AM, Andres Freund wrote:
> On 2015-12-03 12:10:27 +, Greg Stark wrote:
>> I'm leaning towards using the builtin functions described here
>
> For performance reasons? Michael's version of the patch had the
> necessary 'raw' macros, and they don't
On Tue, Dec 1, 2015 at 5:17 PM, Greg Stark wrote:
> Sorry, I didn't look at it since. At the time I was using Xi Wang's software
> to find the overflow checks that need to be redone. He published a paper on
> it and it's actually pretty impressive. It constructs a constraint
Greg Stark writes:
> What version of GCC and other compilers did we decide we're targeting now?
I can't see us moving the compiler goalposts one inch for this.
"I'm going to break building on your compiler in order to work around
bugs in somebody else's compiler" isn't gonna fly.
On Thu, Dec 3, 2015 at 2:51 PM, Tom Lane wrote:
> I can't see us moving the compiler goalposts one inch for this.
> "I'm going to break building on your compiler in order to work around
> bugs in somebody else's compiler" isn't gonna fly.
Fwiw the builtins offer a carrot as
Greg Stark writes:
> On Thu, Dec 3, 2015 at 2:51 PM, Tom Lane wrote:
>> I can't see us moving the compiler goalposts one inch for this.
>> "I'm going to break building on your compiler in order to work around
>> bugs in somebody else's compiler" isn't gonna
On 2015-12-03 12:10:27 +, Greg Stark wrote:
> I'm leaning towards using the builtin functions described here
For performance reasons? Michael's version of the patch had the
necessary 'raw' macros, and they don't look *that* bad. Using the
__builtin variants when available, would be nice - and
On Thu, Dec 3, 2015 at 2:51 PM, Tom Lane wrote:
> Greg Stark writes:
>> What version of GCC and other compilers did we decide we're targeting now?
>
> I can't see us moving the compiler goalposts one inch for this.
That's not the question I asked :/
--
greg
On Fri, Oct 9, 2015 at 2:52 PM, Bruce Momjian wrote:
> Any news on this item from 2013, worked on again 2014?
>
Sorry, I didn't look at it since. At the time I was using Xi Wang's
software to find the overflow checks that need to be redone. He published a
paper on it and it's
On Tue, Oct 20, 2015 at 4:25 PM, Michael Paquier wrote:
> I'll add that to the next CF, perhaps this will interest somebody.
And nobody got interested into that, marking as returned with feedback.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Fri, Oct 16, 2015 at 11:29 PM, Michael Paquier wrote:
> Well, I have played a bit with this patch and rebased it as attached.
> One major change is the use of the variables PG_INT* that have been
> added in 62e2a8d. Some places were not updated with those new checks,
> in majority a couple of
On Fri, Oct 9, 2015 at 10:52 PM, Bruce Momjian wrote:
>
> Any news on this item from 2013, worked on again 2014?
>
> ---
>
> On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
>> On Fri, Nov 29,
Any news on this item from 2013, worked on again 2014?
---
On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 02:04:10AM +, Greg Stark wrote:
> > Attached is what I have so far. I
On Fri, Nov 29, 2013 at 02:04:10AM +, Greg Stark wrote:
Attached is what I have so far. I have to say I'm starting to come
around to Tom's point of view. This is a lot of hassle for not much
gain. i've noticed a number of other overflow checks that the llvm
optimizer is not picking up on
On 11/29/2013 04:04 AM, Greg Stark wrote:
Attached is what I have so far. I have to say I'm starting to come
around to Tom's point of view. This is a lot of hassle for not much
gain. i've noticed a number of other overflow checks that the llvm
optimizer is not picking up on so even after this
Greg Stark st...@mit.edu writes:
b) I'm concerned these checks depend on INT_MIN/MAX and SHRT_MIN/MAX
which may not be exactly the right length. I'm kind of confused why
c.h assumes long is 32 bits and short is 16 bits though so I don't
think I'm making it any worse.
I think it's something we
On Fri, Nov 29, 2013 at 5:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
c) I want to add regression tests that will ensure that the overflow
checks are all working. So far I haven't been able to catch any being
optimized away even with -fno-wrapv and -fstrict-overflow.
This does not leave me
On Fri, Nov 29, 2013 at 7:39 PM, Greg Stark st...@mit.edu wrote:
Just as an update I did get gcc to do the wrong thing on purpose. The
only overflow check that the regression tests find missing is the one
for int8abs() ie:
Also, one of the places GCC warns about optimizing away an overflow
On 11/29/2013 10:06 PM, Greg Stark wrote:
On Fri, Nov 29, 2013 at 7:39 PM, Greg Stark st...@mit.edu wrote:
Just as an update I did get gcc to do the wrong thing on purpose. The
only overflow check that the regression tests find missing is the one
for int8abs() ie:
Also, one of the places
Greg Stark st...@mit.edu writes:
Also, one of the places GCC warns about optimizing away an overflow
check (with -fno-wrapv) is inside the localtime.c file from the tz
library. I fixed it in my patch but in fact I checked and it's already
fixed upstream so I'm wondering whether you expect to
On Mon, Sep 9, 2013 at 12:21:56PM -0400, Robert Haas wrote:
On Sat, Sep 7, 2013 at 6:55 PM, Greg Stark st...@mit.edu wrote:
Should these patches be applied?
I have a copy of the program and was going to take care of this.
When?
2.5 months later, status report?
--
Bruce Momjian
On Sat, Sep 7, 2013 at 6:55 PM, Greg Stark st...@mit.edu wrote:
Should these patches be applied?
I have a copy of the program and was going to take care of this.
When?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
On Mon, Jul 15, 2013 at 06:19:27PM -0400, Alvaro Herrera wrote:
Robert Haas escribió:
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they
Should these patches be applied?
I have a copy of the program and was going to take care of this.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
This thread died without reaching a conclusion. Noah Misch, Robert Haas
and Greg Stark
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
This
Robert Haas escribió:
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
Currently we use -fwrapv to disable such (mis)optimizations in gcc,
but not in other compilers.
Examples
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
Currently we use -fwrapv to disable such (mis)optimizations in gcc,
but not in other compilers.
Examples
28 matches
Mail list logo