Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

configure

Blame
    • Tom Lane's avatar
      b853eb97
      Improve handling of ereport(ERROR) and elog(ERROR). · b853eb97
      Tom Lane authored
      In commit 71450d7f, we added code to inform
      suitably-intelligent compilers that ereport() doesn't return if the elevel
      is ERROR or higher.  This patch extends that to elog(), and also fixes a
      double-evaluation hazard that the previous commit created in ereport(),
      as well as reducing the emitted code size.
      
      The elog() improvement requires the compiler to support __VA_ARGS__, which
      should be available in just about anything nowadays since it's required by
      C99.  But our minimum language baseline is still C89, so add a configure
      test for that.
      
      The previous commit assumed that ereport's elevel could be evaluated twice,
      which isn't terribly safe --- there are already counterexamples in xlog.c.
      On compilers that have __builtin_constant_p, we can use that to protect the
      second test, since there's no possible optimization gain if the compiler
      doesn't know the value of elevel.  Otherwise, use a local variable inside
      the macros to prevent double evaluation.  The local-variable solution is
      inferior because (a) it leads to useless code being emitted when elevel
      isn't constant, and (b) it increases the optimization level needed for the
      compiler to recognize that subsequent code is unreachable.  But it seems
      better than not teaching non-gcc compilers about unreachability at all.
      
      Lastly, if the compiler has __builtin_unreachable(), we can use that
      instead of abort(), resulting in a noticeable code savings since no
      function call is actually emitted.  However, it seems wise to do this only
      in non-assert builds.  In an assert build, continue to use abort(), so that
      the behavior will be predictable and debuggable if the "impossible"
      happens.
      
      These changes involve making the ereport and elog macros emit do-while
      statement blocks not just expressions, which forces small changes in
      a few call sites.
      
      Andres Freund, Tom Lane, Heikki Linnakangas
      b853eb97
      History
      Improve handling of ereport(ERROR) and elog(ERROR).
      Tom Lane authored
      In commit 71450d7f, we added code to inform
      suitably-intelligent compilers that ereport() doesn't return if the elevel
      is ERROR or higher.  This patch extends that to elog(), and also fixes a
      double-evaluation hazard that the previous commit created in ereport(),
      as well as reducing the emitted code size.
      
      The elog() improvement requires the compiler to support __VA_ARGS__, which
      should be available in just about anything nowadays since it's required by
      C99.  But our minimum language baseline is still C89, so add a configure
      test for that.
      
      The previous commit assumed that ereport's elevel could be evaluated twice,
      which isn't terribly safe --- there are already counterexamples in xlog.c.
      On compilers that have __builtin_constant_p, we can use that to protect the
      second test, since there's no possible optimization gain if the compiler
      doesn't know the value of elevel.  Otherwise, use a local variable inside
      the macros to prevent double evaluation.  The local-variable solution is
      inferior because (a) it leads to useless code being emitted when elevel
      isn't constant, and (b) it increases the optimization level needed for the
      compiler to recognize that subsequent code is unreachable.  But it seems
      better than not teaching non-gcc compilers about unreachability at all.
      
      Lastly, if the compiler has __builtin_unreachable(), we can use that
      instead of abort(), resulting in a noticeable code savings since no
      function call is actually emitted.  However, it seems wise to do this only
      in non-assert builds.  In an assert build, continue to use abort(), so that
      the behavior will be predictable and debuggable if the "impossible"
      happens.
      
      These changes involve making the ereport and elog macros emit do-while
      statement blocks not just expressions, which forces small changes in
      a few call sites.
      
      Andres Freund, Tom Lane, Heikki Linnakangas