From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: gcc versus division-by-zero traps |
Date: | 2009-09-03 17:26:52 |
Message-ID: | 19979.1251998812@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> On Thu, Sep 03, 2009 at 10:24:17AM -0400, Tom Lane wrote:
>> While s390x is still not quite mainstream, at least I can get
>> access to one ;-).
> Do you also have access to z/OS with Unix System Services?
No, Red Hat's machines run RHEL ;-)
>> What I am thinking is that in the three
>> functions known to exhibit the bug (int24div, int28div, int48div)
>> we should do something like this:
> How big would this change be? How would people know to use that
> construct everywhere it's appropriate?
I'm talking about patching exactly those three functions. We don't
have any reports of trouble elsewhere. The long-term fix is in the
compiler anyway, this is just a workaround for currently-known issues.
Part of my motivation for this is to get rid of an existing hack in
the Red Hat RPMs:
# use -O1 on sparc64 and alpha
%ifarch sparc64 alpha
CFLAGS=`echo $CFLAGS| sed -e "s|-O2|-O1|g" `
%endif
I believe that that is only there to prevent exactly this problem.
Anyway I'd like to try removing it after patching as proposed, and
then we'll find out if there are other trouble spots ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Selena Deckelmann | 2009-09-03 17:34:06 | Re: community decision-making & 8.5 |
Previous Message | Robert Haas | 2009-09-03 17:26:01 | Re: community decision-making & 8.5 |