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] |
On 07/24/2015 04:41 PM, Manuel LÃpez-IbÃÃez wrote:
You don't have to move the warning to the FE to fix this bug. Go back to my proposal from several years ago which has a warning analysis phase at the start and the end of the optimization pipeline. It can catch this because it gets a chance to analyze the code prior to the generate PHI elimination.On 25 July 2015 at 00:17, Patrick Palka <patrick@parcs.ath.cx> wrote:On Fri, Jul 24, 2015 at 5:55 PM, Manuel LÃpez-IbÃÃez <lopezibanez@gmail.com> wrote: Is there a PR for this particular test case? I am interested in improving the uninit analysis for gcc 6 so this potentially seems up my alley.We do not warn because of the infamous PR18501 (probably the -Wuninitialized bug with the highest number of duplicates), where CPP removes the default SSA definition of n and simply returns 1 unconditionally. But fixing PR18501 may not be necessary to detect this case (Clang does it before doing any optimization).
I haven't looked at any of these recently. But fundamentally you don't have to move the warning into the front-end, you just have to move it to the start of the optimization pipeline.There are other cases that would be better warned from the FE: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |