On 5/21/14, 12:29 PM, Tom Lane wrote:
Vik Fearing vik.fear...@dalibo.com writes:
I'm getting some more of these, including some I thought you had fixed.
Bison 3.0.2 on current head.
I didn't do anything to suppress those warnings:
gram.y:172.1-13: warning: deprecated directive, use
Peter Eisentraut pete...@gmx.net writes:
What they want is that you use
%name-prefix base_yy
instead of
%name-prefix=base_yy
That makes the warning go away.
Oh really!?
The %something=something syntax is not documented anywhere, so it looks
like it worked more or less by accident.
On 5/28/14, 2:43 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
What they want is that you use
%name-prefix base_yy
instead of
%name-prefix=base_yy
That makes the warning go away.
Oh really!?
The %something=something syntax is not documented anywhere, so it looks
I'm getting some more of these, including some I thought you had fixed.
Bison 3.0.2 on current head.
Writing postgres.bki
Writing schemapg.h
Writing postgres.description
Writing postgres.shdescription
gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
[-Wdeprecated]
Vik Fearing vik.fear...@dalibo.com writes:
I'm getting some more of these, including some I thought you had fixed.
Bison 3.0.2 on current head.
I didn't do anything to suppress those warnings:
gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ
[-Wdeprecated]
On 05/21/2014 12:29 PM, Tom Lane wrote:
Vik Fearing vik.fear...@dalibo.com writes:
I'm getting some more of these, including some I thought you had fixed.
Bison 3.0.2 on current head.
I didn't do anything to suppress those warnings:
gram.y:172.1-13: warning: deprecated directive, use
Vik Fearing vik.fear...@dalibo.com writes:
On 05/21/2014 12:29 PM, Tom Lane wrote:
I didn't do anything to suppress those warnings:
gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ
[-Wdeprecated]
%name-prefix=base_yy
^
because it's hard to see how that's
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The bottom line was:
It looks like our choices are (1) teach configure to enable
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
It looks like our choices are (1) teach configure to enable
-fno-aggressive-loop-optimizations if the compiler recognizes it,
or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9.
I am in
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
However, I comment on this mainly because anchovy has had issues with
9.1 and older for some time, which looks like an issue with GCC 4.8.0.
Did you happen to resolve or identify what is happening there..?
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
However, I comment on this mainly because anchovy has had issues with
9.1 and older for some time, which looks like an issue with GCC 4.8.0.
Did you happen
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The bottom line was:
It looks like our choices are (1) teach configure to enable
-fno-aggressive-loop-optimizations if the compiler recognizes it,
or (2)
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The bottom line was:
It looks like our choices are (1) teach configure to enable
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
If we turn off the optimization, that will fix any other cases as well,
no? So why would we risk breaking third-party code by back-porting the
struct declaration changes?
The -fno-agressive-loop
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
If we turn off the optimization, that will fix any other cases as well,
no? So why would we risk breaking third-party code by back-porting the
struct
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
I'm not excited about breaking code in order to fix optimization bugs
that are purely hypothetical (and for which there's no particular reason
to believe that the proposed change would fix them anyway).
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
Reminder to buildfarm animal owners: if you upgrade software
On 2013-07-29 08:44:56 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
I'm not excited about breaking code in order to fix optimization bugs
that are purely hypothetical (and for which there's no particular reason
to
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old.
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old.
Hmm? Anchovy is upgrading
Andres Freund and...@2ndquadrant.com writes:
FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
(After fixing trivial conflicts in the latter).
I've already spent more time on this than I wanted to, but just for
the
On 2013-07-29 10:46:41 -0400, Andrew Dunstan wrote:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is
On 2013-07-29 10:52:10 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
(After fixing trivial conflicts in the latter).
I've already spent
Andrew Dunstan and...@dunslane.net writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in various different real-life environments?
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund and...@2ndquadrant.com wrote:
Both the
gcc 4.8 and the bison 3.0 problems are things the project needs to know
about
Perl 5.18 too:
http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us
Marti
--
Sent via pgsql-hackers mailing
On 07/29/2013 11:05 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan and...@dunslane.net wrote:
There has to be something between set in stone and never changes and
auto-updates everything every 24 hours that would suit us.
Well sure I could change the update frequency. But again, it seems
like delaying the
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm client
where it wouldn't do a git pull, but would report changes if the build
result was different from the previous result. You'd run this immediately
after pulling new changes into
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I can see both sides of this. It's definitely nice to get early warning
when toolchain changes create new problems for Postgres, but it's not
clear that the buildfarm is the best way to get such notifications.
Perhaps
On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan and...@dunslane.net wrote:
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm client
where it wouldn't do a git pull, but would report changes if the build
result was different from
* Andrew Dunstan wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm
client where it wouldn't do a git pull, but would report changes if the
build result was different from the previous result. You'd run this
immediately after pulling new changes into your OS. Other,
On Mon, Jul 29, 2013 at 11:05:52AM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages
daily.
I assumed that's a good thing -- the purpose of build farm is to
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch n...@leadboat.com wrote:
Agreed. Let's stick an Updates OS packages daily, regularly acquiring
bleeding-edge upstream releases note on the buildfarm status page
FWIW, I added [updated daily] to the OS version field.
I haven't changed other
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
cubeparse.y:42.1-13: warning: deprecated directive, use '%name-prefix'
[-Wdeprecated]
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Buildfarm member anchovy has been failing for the last couple of days,
[...]
I'm thinking we should apply this to all supported branches, in case
somebody gets the idea to build an older branch with bleeding-edge
tools. Any objections?
Certainly
Stephen Frost sfr...@snowman.net writes:
However, I comment on this mainly because anchovy has had issues with
9.1 and older for some time, which looks like an issue with GCC 4.8.0.
Did you happen to resolve or identify what is happening there..?
Yeah, we know about that:
36 matches
Mail list logo
