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 look *that* bad. Usi
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 fly.
> I was proposing to implement wr
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 well. They promise to
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
--
Sent via pgsql-hackers mailing
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.
The original po
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 problem
> and then thr
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 actually pretty imp
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 ro
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, 2013 at 02:04:10AM
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 ha
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 o
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 pat
Greg Stark 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 merge in an
On 11/29/2013 10:06 PM, Greg Stark wrote:
On Fri, Nov 29, 2013 at 7:39 PM, Greg Stark 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
On Fri, Nov 29, 2013 at 7:39 PM, Greg Stark 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
check (with
On Fri, Nov 29, 2013 at 5:21 PM, Tom Lane 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 with a warm f
Greg Stark 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 figured w
On Mon, Sep 9, 2013 at 12:21:56PM -0400, Robert Haas wrote:
> On Sat, Sep 7, 2013 at 6:55 PM, Greg Stark 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 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 mailing list (
> 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
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
> > wrote:
> > > Xi Wang escribió:
> > >> Intel's icc and PathScale's pathcc compilers optimize away several
> > >> overflow checks, since they consider signe
Robert Haas escribió:
> On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
> 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 b
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
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 thread died withou
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
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
