"Tom Turelinckx" writes:
> Tom Lane wrote:
>> Thanks! But it doesn't seem to have taken: snapper just did a new run
>> that still failed, and it still seems to be using -O2.
> Snapper did build using -O1 a few hours ago, but it failed the check stage
> very early with a different error:
> FATAL:
Andres Freund writes:
> On 2020-03-30 12:24:06 -0400, Tom Lane wrote:
>> (As of this weekend, it seemed to be impossible to find the wheezy sparc
>> distribution images on-line anymore.
> The installer downloads are still available at:
> https://www.debian.org/releases/wheezy/debian-installer/
A
Hi,
Tom Lane wrote:
> Thanks! But it doesn't seem to have taken: snapper just did a new run
> that still failed, and it still seems to be using -O2.
Snapper did build using -O1 a few hours ago, but it failed the check stage very
early with a different error:
FATAL: null value in column "classi
Hi,
On 2020-03-30 12:24:06 -0400, Tom Lane wrote:
> "Tom Turelinckx" writes:
> Yeah, I've got a couple of those myself. But perhaps it'd be sensible
> to move to a newer Debian LTS release? Or have they dropped Sparc
> support altogether?
I think the 32bit sparc support has been phased out. Sp
"Tom Turelinckx" writes:
> In the past, I've already switched from gcc 4.6 to gcc 4.7 as a workaround
> for a similar compiler bug, but I can't upgrade to a newer gcc without
> backporting it myself, so for the moment I've switched snapper to use -O1
> instead of -O2, for HEAD only.
Thanks! B
Hi,
Tom Lane wrote:
> Confirmed: building gistget with --enable-cassert, and all of snapper's
> compile/link options, produces something that passes regression.
Skate uses buildfarm default configuration, whereas snapper uses settings which
are used when building postgresql debian packages. Debi
I wrote:
> I'm forced to the conclusion that the important difference between
> snapper and skate is that the latter uses --enable-cassert and the
> former doesn't, because that's the only remaining difference between
> how I built a working version before and the not-working version
> I have right
Andres Freund writes:
> On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
>> I could, but it's mighty slow, so I don't especially want to try all 2^N
>> combinations. Do you have any specific cases in mind?
> I'd be most suspicious of -fstack-protector --param=ssp-buffer-size=4
> and -D_FORTIFY_SOUR
Andres Freund writes:
> Is it visibly bad when looking at the .s of gistget.c "directly", or
> when disassembling the fiinal binary? Because I've seen linkers screw up
> on a larger scale than I'd have expected in the past.
Yes, the bogus asm that I showed was from gistget.s, not from
disassembli
Hi,
On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > If you still have the environment it might make sense to check wether
> > it's related to one of the other options. But otherwise I wouldn't be
> > against the proposal.
>
> I could, but it's mighty slow, so I don't es
Andres Freund writes:
> On 2020-03-28 23:50:32 -0400, Tom Lane wrote:
>> ... Curiously, its sibling
>> skate is *not* failing, despite being on the same machine and compiler.
> Hm. There's some difference in code-gen specific options.
Yeah, I confirmed that on my VM install too: using our typica
Hi,
On 2020-03-28 23:50:32 -0400, Tom Lane wrote:
> Buildfarm member snapper has been crashing in the core regression tests
> since commit 17a28b0364 (well, there's a bit of a range of uncertainty
> there, but 17a28b0364 looks to be the only such commit that could have
> affected code in gistget.c
Buildfarm member snapper has been crashing in the core regression tests
since commit 17a28b0364 (well, there's a bit of a range of uncertainty
there, but 17a28b0364 looks to be the only such commit that could have
affected code in gistget.c where the crash is). Curiously, its sibling
skate is *not
13 matches
Mail list logo
