This is the mail archive of the
mailing list for the GCC project.
RE: GCC Front-End Questions
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: "Jodi A. Miller" <jas31 at arl dot psu dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 8 Dec 2015 20:57:44 +0100 (CET)
- Subject: RE: GCC Front-End Questions
- Authentication-results: sourceware.org; auth=none
- References: <330CAF8A870FFB478CF058205D2A809136E92F64 at exchange7 dot arl dot psu dot edu>
- Reply-to: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
On Tue, 8 Dec 2015, Jodi A. Miller wrote:
One algebraic simplification we are seeing is particularly interesting.
Given the following code snippet intended to check for buffer overflow,
which is actually undefined behavior in C++, we expected to maybe see
the if check optimized away entirely.
int length; //value received through argument or command line
If (buffer + length < buffer)
cout << "Overflow" << endl;
Instead, our assembly code showed that the conditional was changed to
length < 0, which is not what was intended at all. Again, this showed
up in the first IR file generated with g++ so we are thinking it
happened in the compiler front-end, which is surprising. Any thoughts
on this? In addition, when the above conditional expression is not used
as part of an if check (e.g., assigned to a Boolean), it is not
Those optimizations during parsing exist mostly for historical reasons,
and we are slowly moving away from them. You can look for any function
call including "fold" in its name in the front-end. They work on
expressions and mostly consist of matching patterns (described in
fold-const.c and match.pd), like p + n < p in this case.