On 2014-01-06 23:51:52 +1300, David Rowley wrote: > I looked at this a while back here: > http://www.postgresql.org/message-id/CAApHDvqOsb4nc3OG0xoBoJ2fmA-6AkihuWsAd43RLekqk6SmCQ@mail.gmail.com > > And found that because elevel was being assigned to a variable that the > compiler could not determine that the if (elevel_ >= ERROR) was constant > therefore couldn't assume that __assume(0) would be reached with the > microsoft compiler
But afair the declaration for elog() works in several other places, so that doesn't sufficiently explain this. I'd very much expect that that variable is complitely elided by any halfway competent compiler - it's just there to prevent multiple evaluation should elevel not be a constant.
Just to add more proof to my theory;
If I do this:
//#define pg_unreachable() __assume(0)
#define pg_unreachable() (void)0
I get no extra warnings.
If change the elog macro to get rid of the variable so that the if condition uses the constant then the postgres.exe goes from 4,545,024 bytes to 4,526,592 bytes.
So I guess the __assume(0) does not do much due to elevel being assigned to the variable in the elog macro.
Regards
David Rowley
Do you see the warning both with asserts enabled and non-assert builds?
Greetings,
Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services