https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #17 from Jakub Jelinek ---
Does the kernel boot now with the latest trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #16 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 15 09:05:59 2018
New Revision: 256686
URL: https://gcc.gnu.org/viewcvs?rev=256686&root=gcc&view=rev
Log:
PR middle-end/82694
* common.opt (fstrict-overflow): No l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #15 from Jakub Jelinek ---
Created attachment 43116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43116&action=edit
gcc8-pr82694.patch
So like this untested patch? Certainly don't have energy to look for all other
spots that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #14 from Richard Biener ---
(In reply to Jakub Jelinek from comment #13)
> Does the kernel still need this workaround? Shall we just add the option
> and gradually add the checks?
Yes - note I got stuck in the attempt to do the -f[n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #12 from Richard Biener ---
Note though that there were _many_ foldings not properly guarded by
POINTER_TYPE_OVERFLOW_UNDEFINED. I'd rather fold that into
TYPE_OVERFLOW_UNDEFINED / TYPE_OVERFLOW_WRAPS anyway (thus also allow those on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #11 from Richard Biener ---
Rather than reverting I'd add
fwrapp
Common Report Var(flag_wrapp) Optimization
Assume pointer arithmetic overflow wraps around.
and adjust fstrict-overflow to also enable fwrapp. Maybe we need to
change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to amker from comment #9)
> (In reply to Markus Trippelsdorf from comment #8)
> > I think -fno-strict-overflow/-fwrapv should use the old behavior.
> > The kernel really needs a flag to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #8)
> I think -fno-strict-overflow/-fwrapv should use the old behavior.
> The kernel really needs a flag to control pointer wrapping.
Well, GCC doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #8 from Markus Trippelsdorf ---
I think -fno-strict-overflow/-fwrapv should use the old behavior.
The kernel really needs a flag to control pointer wrapping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #7 from amker at gcc dot gnu.org ---
I didn't go through all the differences, but below is an example of using
wrapping behavior for pointers:
int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #6 from Markus Trippelsdorf ---
Created attachment 42458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42458&action=edit
assembly good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #5 from Markus Trippelsdorf ---
Created attachment 42457
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42457&action=edit
assembly bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #4 from Markus Trippelsdorf ---
Created attachment 42456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42456&action=edit
unreduced testcase
The unreduced testcase is attached.
% /home/trippels/gcc_bad/usr/local/bin/gcc -fno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #2)
> I would not revert without a testcase. Give me a few hours...
Thanks very much for helping!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #2 from Markus Trippelsdorf ---
I would not revert without a testcase. Give me a few hours...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #1 from amker at gcc dot gnu.org ---
Sorry for the breakage.
As I mentioned when committing the patch, it's kind of an experiment and we can
always revert it. I can revert it now, but a test case for further
investigation would be hig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|---
21 matches
Mail list logo
