- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
>
> I have to agree now with Andrew's last mail that -fno-strict-aliasing is
> the only safe solution. Since gcc isn't even pretending that it can
> warn in all cases where the optimization might break things, I'm not
> sure we co
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Of course, the linux kernel is aimed at a limited set of compilers - as I
> understand it basically gcc although it has been made to build with Intel
> compilers - which makes things somewhat easier for them. What is our target
> set of compilers? What
Tom Lane wrote:
BTW, I haven't looked at the problem spots in detail. How many of them
are due to the use of MemSet in conjunction with other access to a chunk
of memory? ISTM that we need not worry about code motion around a
MemSet call, since that would require the compiler to prove that the
m
Andrew Dunstan wrote:
there were 3 calls to MemSet it complained about - all in
src/backend/storage/lmgr/proc.c, and all zeroing out the timeval
structure. (is MemSet actually a gain in this instance?)
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be unnecessary
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Resubmission of patch (for 7.4).
While I agree with the objection that we shouldn't break the strings
freeze for this, I do think it might be a good idea to apply the change
that prints CHECK constraints using pg_get_constraintdef() rather than
Andrew Dunstan writes:
> And looking at it even closer, 2 of the 3 cases of calling MemSet appear
> to be unnecessary, as the zeroed out values are immediately overwritten.
We need to zero out the holes in the structures so that hash functions
work correctly.
--
Peter Eisentraut [EMAIL PROTEC
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers
icc once compiled the kernel. But they had to teach it quite a lots of
gcci
Please commit the changes, file reviewed by Gaetano Mendola. Corrected a couple of
messages.
Regards,
Fabrizio Mazzoni
libpq-it.po
Description: Binary data
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane writes:
> Doing that would require making this one string change:
>
> ! printfPQExpBuffer(&buf, _("\"%s\" CHECK %s"),
> becomes
> ! printfPQExpBuffer(&buf, _("\"%s\" %s"),
>
> but ISTM the latter string doesn't really need any translation and so
> i
Peter Eisentraut wrote:
Andrew Dunstan writes:
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be unnecessary, as the zeroed out values are immediately overwritten.
We need to zero out the holes in the structures so that hash functions
work correctly.
I susp
I've asked the question on the gcc devel list. The first reply was that
MemSet violates strict aliasing rules:
http://gcc.gnu.org/ml/gcc/2003-10/msg00524.html
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
--
Manfred
--
Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > Of course, the linux kernel is aimed at a limited set of compilers - as I
> > understand it basically gcc although it has been made to build with Intel
> > compilers - which makes things somewhat easier for them. What is our target
Manfred Spraul wrote:
I've asked the question on the gcc devel list. The first reply was
that MemSet violates strict aliasing rules:
http://gcc.gnu.org/ml/gcc/2003-10/msg00524.html
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
The conce
On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
> I think we must either add -fno-strict-aliasing, or switch to the c
> compiler memset functions for gcc.
The last time we did some benchmarking, using the builtin memset()
imposes a significant performance penalty on plenty of different
platfor
Manfred Spraul <[EMAIL PROTECTED]> writes:
> I've asked the question on the gcc devel list. The first reply was that
> MemSet violates strict aliasing rules:
No doubt it does, but that is not really the issue here; the issue IMHO
is whether there is any real risk involved. Remember that the macr
Tom Lane wrote:
> > I think we must either add -fno-strict-aliasing, or switch to the c
> > compiler memset functions for gcc.
>
> We will not be doing the latter, for certain.
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it? Would someone profile Postgre
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, what gcc versions support -fno-strict-aliasing? Do we need a
> configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is not the existence
of
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, what gcc versions support -fno-strict-aliasing? Do we need a
> > configure test for it?
>
> Perhaps ... although it is recognized in 2.95.3 and probably for a good
> ways before that.
>
> It looks to me like what has changed in
Tom Lane writes:
> Given that gcc is smart enough not to move any code across the memset()
> call,
Is it? If you violate the aliasing rules, all bets are off.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Given that gcc is smart enough not to move any code across the memset()
>> call,
> Is it?
It had better be.
regards, tom lane
---(end of broadcast)---
TIP 8
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is no
Neil Conway writes:
> On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
> > I think we must either add -fno-strict-aliasing, or switch to the c
> > compiler memset functions for gcc.
>
> The last time we did some benchmarking, using the builtin memset()
> imposes a significant performance penalty
Tom Lane wrote:
Given that gcc is smart enough not to move any code across the memset()
call, I doubt that it would be moving anything across the whole if()
construct. Now if the if-condition were such that the memset code path
could be optimized away, then we'd have a problem, but in practice I
On Tue, 2003-10-14 at 16:29, Peter Eisentraut wrote:
> The last time I did some testing, the builtin memset() was significantly
> faster on plenty of different platforms.
Oh? Which platforms are you referring to, and what tests were performed?
You can find the benchmark results I'm referring to i
Manfred Spraul <[EMAIL PROTECTED]> writes:
> After some massaging, I've succeeded in generating bad code using a
> slightly modified MemSetAligned macro (parameters -O2
> -fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about the MemSetAligned c
Neil Conway writes:
> Oh? Which platforms are you referring to, and what tests were performed?
http://archives.postgresql.org/pgsql-patches/2002-10/msg00085.php
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/r
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about t
Recently I've been seeing regular but very occasional errors like the
following while using psql:
test=> BEGIN ;
BEGIN
test=> UPDATE language SET name_native = 'Français' WHERE lang_id='fr';
ERROR: current transaction is aborted, commands ignored until end of
transaction block
where the UPDAT
Manfred Spraul wrote:
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained,
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Is gcc 3.3 smart enough to optimize away the pointer alignment test
>> in the full macro?
>>
> 3.2 optimizes away the pointer alignment test, but then doesn't pipeline
> the "x*x" calculation.
Hm, confirmed here. So indeed it seems
Ian Barwick <[EMAIL PROTECTED]> writes:
> A patch for this using PQescapeString (is there another preferred method?) is
> attached as a possible solution.
Surely all those replacements of \\ with are wrong. I agree that
it's insane not to be escaping the user input, though ...
new files
pg_resetxlog.po : src/bin/pg_resetxlog/po/sl.po
pg_controldata.po : src/bin/pg_controldata/po/sl.po
updated files
psql.po : src/bin/psql/po/sl.po
regards,
Aleksander
sl_tanslations.tar.gz
Description: GNU Zip compressed data
---(end of broadcast)---
32 matches
Mail list logo