This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING] Re: [PATCH] c/66516 - missing diagnostic on taking the address of a builtin function


On 08/03/2015 07:02 PM, Martin Sebor wrote:
I've prototyped this approach in a couple places in the middle
end. Both implementations are very simple and work great when
the code isn't optimized away. The problem is that the
optimizations done at various points between the front end and
the final gimplification make the diagnostics inconsistent.

For instance, with F being the type of the builtin, this is
diagnosed in the first prototype:

   F* foo () { if (0) return __builtin_trap; return 0; }

but this isn't:

   F* bar () { return 0 ? __builtin_trap : 0; }

because the ternary ?: expression is folded into a constant by
the front end even before it reaches the gimplifier, while the
if-else statement isn't folded until the control flow graph is
built. (As an aside: I'm wondering why that is. Why have the
front end do any optimization at all if the middle can and
does them too, and better?)

This is largely historical baggage, I think, from days where computers had less memory and we were trying to do as much processing as possible immediately.

The c++-delayed-folding branch delays folding the ?: expression until the end of the function, at which point we can see better what context the function is being used in, which could simplify your patch.

But your question leads me to wonder if we need to do front end folding there, either...

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]