On 2015-01-15 17:59:40 +0100, Andres Freund wrote:
> On 2015-01-15 11:56:24 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
> > >> While I'll not cry too hard when we decide to break C89 compatibility,
> > >> I don't want it to happen accidental
On 2015-01-15 11:56:24 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
> >> While I'll not cry too hard when we decide to break C89 compatibility,
> >> I don't want it to happen accidentally; so having a pretty old-school
> >> compiler in the farm s
Andres Freund writes:
> On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
>> While I'll not cry too hard when we decide to break C89 compatibility,
>> I don't want it to happen accidentally; so having a pretty old-school
>> compiler in the farm seems important to me.
> I'd worked on setting up a mode
On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
> * I've got gaur configured so it will throw "array subscript of type char"
> complaints whenever somebody forgets to cast a function argument
> to unsigned char.
But, but. That would never happen to anyone (hides).
> While I'll not cry too hard whe
I wrote:
> I've launched a run now, expect results from gcc HEAD in an hour and
> a half or so.
... and it's happy. Thanks!
BTW, the reason I went to the trouble of cranking up the buildfarm scripts
on that machine (and it was painful :-() is that I don't believe any other
buildfarm members are
and...@anarazel.de (Andres Freund) writes:
> On 2015-01-14 19:31:18 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> Right now I think a #ifdef/undef S_UNLOCK in the relevant gcc section
>>> sufficient and acceptable. It's after all the HPPA section that doesn't
>>> really play by the rules.
>
On 2015-01-14 19:31:18 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Right now I think a #ifdef/undef S_UNLOCK in the relevant gcc section
> > sufficient and acceptable. It's after all the HPPA section that doesn't
> > really play by the rules.
>
> Works for me.
Pushed something like that.
Andres Freund writes:
> Right now I think a #ifdef/undef S_UNLOCK in the relevant gcc section
> sufficient and acceptable. It's after all the HPPA section that doesn't
> really play by the rules.
Works for me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
On 2015-01-14 12:27:42 -0500, Robert Haas wrote:
> On Mon, Jan 12, 2015 at 12:57 PM, Andres Freund
> wrote:
> > On 2015-01-10 23:03:36 +0100, Andres Freund wrote:
> >> On 2015-01-10 16:09:42 -0500, Tom Lane wrote:
> >> > I've not tried to build HEAD on my HPPA dinosaur for awhile, but I did
> >>
On Mon, Jan 12, 2015 at 12:57 PM, Andres Freund wrote:
> On 2015-01-10 23:03:36 +0100, Andres Freund wrote:
>> On 2015-01-10 16:09:42 -0500, Tom Lane wrote:
>> > I've not tried to build HEAD on my HPPA dinosaur for awhile, but I did
>> > just now, and I am presented with boatloads of this:
>> >
>>
On 2015-01-10 23:03:36 +0100, Andres Freund wrote:
> On 2015-01-10 16:09:42 -0500, Tom Lane wrote:
> > I've not tried to build HEAD on my HPPA dinosaur for awhile, but I did
> > just now, and I am presented with boatloads of this:
> >
> > ../../../src/include/storage/s_lock.h:759: warning: `S_UNLO
Andres Freund writes:
> On 2015-01-10 18:40:58 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> Actually. It looks like I only translated the logic from barrier.h 1:1
>>> and it already was broken there. Hm, it looks like the current code
>>> essentially is from 89779bf2c8f9aa480e0ceb8883f93e9
On 2015-01-10 18:40:58 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-11 00:06:41 +0100, Andres Freund wrote:
> >> Ick, that one is my failure.
>
> > Actually. It looks like I only translated the logic from barrier.h 1:1
> > and it already was broken there. Hm, it looks like the cu
Andres Freund writes:
> On 2015-01-11 00:06:41 +0100, Andres Freund wrote:
>> Ick, that one is my failure.
> Actually. It looks like I only translated the logic from barrier.h 1:1
> and it already was broken there. Hm, it looks like the current code
> essentially is from 89779bf2c8f9aa480e0ceb888
On 2015-01-11 00:06:41 +0100, Andres Freund wrote:
> On 2015-01-10 17:58:10 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > Given you got the error above, you used gcc. Have you used non-gcc
> > > compiler on hppa recently? I seem to recall you mentioning that that
> > > doesn't work sanely
On 2015-01-10 17:58:10 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Given you got the error above, you used gcc. Have you used non-gcc
> > compiler on hppa recently? I seem to recall you mentioning that that
> > doesn't work sanely anymore? If so, perhaps we can just remove the !gcc
> > vari
Andres Freund writes:
> Given you got the error above, you used gcc. Have you used non-gcc
> compiler on hppa recently? I seem to recall you mentioning that that
> doesn't work sanely anymore? If so, perhaps we can just remove the !gcc
> variant?
It still compiles, modulo some old and uninteresti
Andres Freund writes:
> Given you got the error above, you used gcc.
Right.
> Have you used non-gcc
> compiler on hppa recently? I seem to recall you mentioning that that
> doesn't work sanely anymore? If so, perhaps we can just remove the !gcc
> variant?
I'll try that shortly ...
On 2015-01-10 16:09:42 -0500, Tom Lane wrote:
> I've not tried to build HEAD on my HPPA dinosaur for awhile, but I did
> just now, and I am presented with boatloads of this:
>
> ../../../src/include/storage/s_lock.h:759: warning: `S_UNLOCK' redefined
> ../../../src/include/storage/s_lock.h:679: wa
I've not tried to build HEAD on my HPPA dinosaur for awhile, but I did
just now, and I am presented with boatloads of this:
../../../src/include/storage/s_lock.h:759: warning: `S_UNLOCK' redefined
../../../src/include/storage/s_lock.h:679: warning: this is the location of the
previous definition
20 matches
Mail list logo
