On 18-01-2018 20:49, Marina Polyakova wrote:
On 18-01-2018 20:34, Tom Lane wrote:
...
What you could do in the meantime is work on finding a variation of
Victor's test that will detect the bug regardless of -O level.
If we do have hope that future gcc versions will handle this
correctly,
we'll
Robert Haas writes:
> Anyway, that's really an academic debate. My real point is: I do not
> think we should reject out of hand the idea that a patch introducing
> some new notation to deal with this might be acceptable. I am not
> volunteering to write such a patch, and anyone who tries should
On Thu, Jan 18, 2018 at 1:03 PM, Tom Lane wrote:
> Sure. Part of the equation here is that (IMO anyway) int128 isn't
> sufficiently performance-critical to us to justify putting enormous
> amounts of work into trying to make it go on non-mainstream platforms.
> It's possible that that could chang
Robert Haas writes:
> On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane wrote:
>> Really, this is something that the compiler ought to do for us, IMO.
>> If the gcc guys don't want to be bothered, OK, but that tells you more
>> about the priority they place on SPARC support than anything else.
> Of cou
On 18-01-2018 20:34, Tom Lane wrote:
I wrote:
...
But ... let's not panic, but wait and see the final result of the
discussion on the gcc PR. Jakub at least seems to think it ought
to be a supportable case.
What you could do in the meantime is work on finding a variation of
Victor's test that w
On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane wrote:
> Marina Polyakova writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means
On 18-01-2018 20:24, Tom Lane wrote:
Marina Polyakova writes:
On 18-01-2018 19:53, Tom Lane wrote:
So basically, we're outta luck and we have to consider __int128 as
unsupportable on SPARC. I'm inclined to mechanize that as a test on
$host_cpu. At least that means we don't need an AC_RUN tes
I wrote:
> Marina Polyakova writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
>> %-))
Marina Polyakova writes:
> On 18-01-2018 19:53, Tom Lane wrote:
>> So basically, we're outta luck and we have to consider __int128 as
>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
> %-)) :-)
> Can I do s
On 18-01-2018 19:53, Tom Lane wrote:
Marina Polyakova writes:
On 18-01-2018 17:56, Tom Lane wrote:
Weird. Maybe the gcc bug only manifests with certain optimization
flags? That's not what I'd have expected from Victor's theory about
why the code is wrong, but if it only shows up some of the
Marina Polyakova writes:
> On 18-01-2018 17:56, Tom Lane wrote:
>> Weird. Maybe the gcc bug only manifests with certain optimization
>> flags? That's not what I'd have expected from Victor's theory about
>> why the code is wrong, but if it only shows up some of the time,
>> it's hard to think of
On 18-01-2018 17:56, Tom Lane wrote:
Marina Polyakova writes:
Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
and using the configuration command from [1], I got:
checking for __int128... yes
checking for __int128 alignment bug... broken
...
And make check-world passes. V
Victor Wagner writes:
> It seems that I've made some unreproducible mistake last night
> applying your patch. Marina repeapplied it later and everything works.
Ah, thanks for following up. I'll adjust the comment to include the
gcc PR and push it shortly.
regards, tom
On Thu, 18 Jan 2018 09:56:48 -0500
Tom Lane wrote:
> Marina Polyakova writes:
> > Applying your patch on commit
> > f033462d8f77c40b7d6b33c5116e50118fb4699d and using the
> > configuration command from [1], I got: checking for __int128... yes
> > checking for __int128 alignment bug... broken
> >
Marina Polyakova writes:
> Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
> and using the configuration command from [1], I got:
> checking for __int128... yes
> checking for __int128 alignment bug... broken
> ...
> And make check-world passes. Victor said that he used a m
On Thu, 18 Jan 2018 01:47:46 -0500
Tom Lane wrote:
> Victor Wagner writes:
> > Tom Lane wrote:
> > checking for __int128 alignment bug... ok
> > As far as I understand your patch, there should be:
> > checking for __int128 alignment bug... broken
>
> Yes, that's what I expected to happen.
On 17-01-2018 18:50, Marina Polyakova wrote:
On 17-01-2018 18:28, Tom Lane wrote:
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Thank you!
On 17-01-2018 19:33, Tom Lane wrote:
Attached is a draft patch to incorporate Victor's slimmed-down test
into configure. If you have a chance, could you confirm it does
the right thing on your Sparc machine?
Victor Wagner writes:
It seems that what it does is not exactly a right
Victor Wagner writes:
> Tom Lane wrote:
>> Attached is a draft patch to incorporate Victor's slimmed-down test
>> into configure. If you have a chance, could you confirm it does
>> the right thing on your Sparc machine?
> It seems that what it does is not exactly a right thing.
> I've applied i
On Wed, 17 Jan 2018 11:33:09 -0500
Tom Lane wrote:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?
It seems that what it does is not exactly a right thing.
I've appli
В Wed, 17 Jan 2018 11:33:09 -0500
Tom Lane пишет:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?
>
Definitely. As soon as next work day begins in Moscow.
> BTW, it
Attached is a draft patch to incorporate Victor's slimmed-down test
into configure. If you have a chance, could you confirm it does
the right thing on your Sparc machine?
BTW, it would be a good idea to set up a buildfarm member on that
machine, if you care about whether that configuration contin
On 17-01-2018 18:28, Tom Lane wrote:
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Please do that and let me know the PR number -
Marina Polyakova writes:
> On 17-01-2018 18:07, Tom Lane wrote:
>> Yeah, I can work with this. What I propose to do is use a somewhat
>> stripped-down version of this test as an AC_RUN_IFELSE test normally,
>> but if cross-compiling, fall back to just seeing if we can link.
> Thanks, I'll try to
On 17-01-2018 18:07, Tom Lane wrote:
Marina Polyakova writes:
investigating the regression diffs, we found out that the error occurs
when we pass int128 as not the first argument to the function (perhaps
its value is replaced by the value of some address):
...
Based on this, we modified the tes
Victor Wagner writes:
> I'm attaching stripped-down version of test program, which demonstrate
> the problem and two assembler listings produced with this C source using
> alignment 8 and 16. May be this stripped-down version can be used as
> base for configure test.
Ah, thanks, this will be eas
Victor Wagner writes:
> On Wed, 17 Jan 2018 10:07:37 -0500
> Tom Lane wrote:
>> Yeah, I can work with this. What I propose to do is use a somewhat
>> stripped-down version of this test as an AC_RUN_IFELSE test normally,
>> but if cross-compiling, fall back to just seeing if we can link.
> I'd s
On Wed, 17 Jan 2018 10:07:37 -0500
Tom Lane wrote:
> Marina Polyakova writes:
> Yeah, I can work with this. What I propose to do is use a somewhat
> stripped-down version of this test as an AC_RUN_IFELSE test normally,
> but if cross-compiling, fall back to just seeing if we can link.
I'd sug
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Please do that and let me know the PR number --- I think it would be
good to cite the
On Wed, 17 Jan 2018 18:02:26 +0300
Marina Polyakova wrote:
> > Attached is a possible test program. I can confirm it passes on a
> > machine with working __int128, but I have no idea whether it will
> > detect the problem on yours. If not, maybe you can tweak it?
>
> Thank you! Using gcc 5.5.
Sorry, diff.patch is attached now.
On 17-01-2018 18:02, Marina Polyakova wrote:
[I added Victor Wagner as co-researcher of this problem]
On 13-01-2018 21:10, Tom Lane wrote:
In the end this might just be an instance of the old saw about
avoiding dot-zero releases. Have you tried a newer gcc?
Marina Polyakova writes:
> investigating the regression diffs, we found out that the error occurs
> when we pass int128 as not the first argument to the function (perhaps
> its value is replaced by the value of some address):
> ...
> Based on this, we modified the test program (see attached). He
[I added Victor Wagner as co-researcher of this problem]
On 13-01-2018 21:10, Tom Lane wrote:
In the end this might just be an instance of the old saw about
avoiding dot-zero releases. Have you tried a newer gcc?
(Digging in their bugzilla finds quite a number of __int128 bugs
fixed in 5.4.x, t
Marina Polyakova writes:
> On 13-01-2018 21:10, Tom Lane wrote:
>> I'm not sure there's much we can do about this. Dropping the use
>> of the alignment spec isn't a workable option. If there were a
>> simple way for configure to detect that the compiler generates bad
>> code for that, we could h
Thank you very much!
On 13-01-2018 21:10, Tom Lane wrote:
Marina Polyakova writes:
On 12-01-2018 21:00, Tom Lane wrote:
Hm ... so apparently, that compiler has bugs in handling nondefault
alignment specs. You said upthread it was gcc, but what version
exactly?
This is 5.2.0:
Ugh ... pro
Marina Polyakova writes:
> On 12-01-2018 21:00, Tom Lane wrote:
>> Hm ... so apparently, that compiler has bugs in handling nondefault
>> alignment specs. You said upthread it was gcc, but what version
>> exactly?
> This is 5.2.0:
Ugh ... protosciurus has 3.4.3, but I see that configure detects
On 12-01-2018 21:00, Tom Lane wrote:
Marina Polyakova writes:
...
Binary search has shown that all these failures begin with commit
7518049980be1d90264addab003476ae105f70d4 (Prevent int128 from
requiring
more than MAXALIGN alignment.).
Hm ... so apparently, that compiler has bugs in handlin
Marina Polyakova writes:
> On 12-01-2018 14:05, Marina Polyakova wrote:
>> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
>> the same failures occur (see the attached regression diffs and
>> output);
>> - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
>>
On 12-01-2018 14:05, Marina Polyakova wrote:
- on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
the same failures occur (see the attached regression diffs and
output);
- on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
passes.
I'll try to find out from what c
On 12-01-2018 18:12, Alvaro Herrera wrote:
Marina Polyakova wrote:
- on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
the same
failures occur (see the attached regression diffs and output);
- on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
passes.
I'll try
Marina Polyakova wrote:
> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) the same
> failures occur (see the attached regression diffs and output);
> - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
> passes.
> I'll try to find out from what commit it start
On 11-01-2018 20:39, Andres Freund wrote:
Hi,
On 2018-01-11 20:21:11 +0300, Marina Polyakova wrote:
Hello, hackers! I got a permanent failure of master (commit
ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Did this use to work?
It always fails if you have asked about t
On 11-01-2018 20:34, Tom Lane wrote:
Marina Polyakova writes:
Hello, hackers! I got a permanent failure of master (commit
ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Regression output and diffs are attached.
Hm, buildfarm member protosciurus is running a similar config
Hi,
On 2018-01-11 20:21:11 +0300, Marina Polyakova wrote:
> Hello, hackers! I got a permanent failure of master (commit
> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Did this use to work? If so, could you check whether it worked before
69c3936a1499b772a749ae629fc59b2d72722
Marina Polyakova writes:
> Hello, hackers! I got a permanent failure of master (commit
> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
> Regression output and diffs are attached.
Hm, buildfarm member protosciurus is running a similar configuration
without problems. Lookin
Hello, hackers! I got a permanent failure of master (commit
ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Regression output and diffs are attached.
I used the following commands:
./configure CC="ccache gcc" CFLAGS="-m64 -I/opt/csw/include"
LDFLAGS="-L/opt/csw/lib/sparcv9
46 matches
Mail list logo
