This is the mail archive of the gcc-bugs@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]

[Bug sanitizer/83356] [7 Regression] excessive stack usage compiling with -O2 -fsanitize=bounds -fsanitize=object-size


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, there's nothing we can do here if PRE decides to do more now (the
possible effect of the fix).  We are simply finding a _lot_ more opportunities
to hoist/PRE stuff (all sanitizer stuff...).  And PRE has no throttling on
whatsoever doing that.  It PREs/hoists the arguments to
UBSAN_{BOUNDS,OBJECT_SIZE} but not
the IFNs themselves (those are neither pure nor const and I'm not sure PRE
would handle them at all).

In the process of doing this it moves address calculation to common place
and thus enlarging the lifetime of the addressed objects.

There are a lot of redundant sanitization checks but the IFNs have
side-effects (I believe they eventually abort (), right?) so we can't
make them pure or const.  I believe we don't have any category of
calls that may abort but can be commoned.  PRE just does the job for
the arguments...

I believe the way the function is written is just asking for troubles...

Maybe sanitize instrumentation can also be more clever avoiding all the
redundancies...  (seems to happen on GENERIC already for BOUNDS).

That said, can't see an easy workaround but to change the source and/or
not use -fsanitize= and expect decent code quality.

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