This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Maxim Ostapenko <m dot ostapenko at partner dot samsung dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Kostya Serebryany <kcc at google dot com>, Dmitry Vyukov <dvyukov at google dot com>, Marek Polacek <polacek at redhat dot com>, Yury Gribov <y dot gribov at samsung dot com>, Slava Garbuzov <v dot garbuzov at samsung dot com>, Vyacheslav Barinov <v dot barinov at samsung dot com>
- Date: Mon, 19 Oct 2015 09:20:38 +0200
- Subject: Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.
- Authentication-results: sourceware.org; auth=none
- References: <561CE769 dot 6050800 at partner dot samsung dot com> <561CE97C dot 50002 at partner dot samsung dot com> <20151014074825 dot GT478 at tucnak dot redhat dot com> <561E33C0 dot 7030109 at partner dot samsung dot com> <20151014110648 dot GX478 at tucnak dot redhat dot com> <561E444E dot 2080101 at partner dot samsung dot com> <20151014121214 dot GZ478 at tucnak dot redhat dot com> <5620DF84 dot 5050202 at partner dot samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Oct 16, 2015 at 02:29:08PM +0300, Maxim Ostapenko wrote:
> On 14/10/15 15:12, Jakub Jelinek wrote:
> >On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote:
> >>On 14/10/15 14:06, Jakub Jelinek wrote:
> >>>On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
> >>>>Ok, got it. The first solution would require changes in libsanitizer because
> >>>>heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
> >>>>upstream, right? Or this may be implemented as local patch for GCC?
> >>>No. The heuristics relies on:
> >>>1) either it is old style float cast overflow without location
> >>>2) or it is new style float cast with location, but the location must:
> >>> a) not have NULL filename
> >>> b) the filename must not be ""
> >>> c) the filename must not be "\1"
> >>>So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
> >>>c) is true, otherwise the new style. I have no idea what you mean by
> >>>heuristic doesn't work for GCC after that.
> >>I mean that there are some cases where (FilenameOrTypeDescriptor[0] +
> >>FilenameOrTypeDescriptor[1] < 2) is not sufficient to determine if we should
> >>use old style. I actually caught this on float-cast-overflow-10.c testcase.
> >Ah, ok, in that case the heuristics is flawed. If they want to keep it,
> >they should check if MaybeFromTypeKind is either < 2 or equal to 0x1fe.
> >Can you report it upstream? If that is changed, we'd need to change the
> >above and also add
> > d) the filename must not start with "\xff\xff"
> >to the rules.
> >
> >I think it would be better to just add a whole new entrypoint, but if they
> >think the heuristics is good enough, they should at least fix it up.
> >
> > Jakub
> >
>
> Done. I've realized that we could just set loc to input_location if loc ==
> UNKNOWN_LOCATION. In this case, we always would have new style. This would
While using input_location in this case (as it is invoked from the FEs)
might help sometimes, it still doesn't guarantee input_location will not
be UNKNOWN_LOCATION afterwards, or builtin location, or b), c) or d) above.
Plus there is no fix on the library side to the heuristics, which we need
anyway.
Jakub