mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.

Browse Source 
It appears that commit cf63c641c, which intended to prevent
misoptimization of the result-building step in makeOrderedSetArgs,
didn't go far enough: buildfarm member hornet's version of xlc
is now optimizing back to the old, broken behavior in which
list_length(directargs) is fetched only after list_concat() has
changed that value.  I'm not entirely convinced whether that's
an undeniable compiler bug or whether it can be justified by a
sufficiently aggressive interpretation of C sequence points.
So let's just change the code to make it harder to misinterpret.

Back-patch to all supported versions, just in case.

Discussion: https://postgr.es/m/1830491.1601944935@sss.pgh.pa.us
This commit is contained in:
Tom Lane 2020-10-07 18:41:39 -04:00
parent f2c6e94f07
commit e3868c7d59
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/backend/parser/gram.y
View File

@ -15812,7 +15812,7 @@ makeOrderedSetArgs(List *directargs, List *orderedargs,
core_yyscan_t yyscanner)
{
FunctionParameter *lastd = (FunctionParameter *) llast(directargs);
int ndirectargs;
Value *ndirectargs;
/* No restriction unless last direct arg is VARIADIC */
if (lastd->mode == FUNC_PARAM_VARIADIC)
@ -15836,10 +15836,10 @@ makeOrderedSetArgs(List *directargs, List *orderedargs,
}
/* don't merge into the next line, as list_concat changes directargs */
ndirectargs = list_length(directargs);
ndirectargs = makeInteger(list_length(directargs));
return list_make2(list_concat(directargs, orderedargs),
makeInteger(ndirectargs));
ndirectargs);
}
/* insertSelectOptions()