On Tue, Jan 7, 2014 at 12:06 AM, Andres Freund <and...@2ndquadrant.com>wrote:

> 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-6akihuwsad43rlekqk6s...@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.


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

Reply via email to