https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
PaX Team changed:
What|Removed |Added
CC||pageexec at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #14 from PaX Team ---
(In reply to Jakub Jelinek from comment #13)
> As has been said, we can't retroactively change released compilers from the
> last 2 decades. And going forward, I think walking the save_decoded_options
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #12 from PaX Team ---
(In reply to Jakub Jelinek from comment #11)
> I think kernel requires gcc >= 5.1 anyway.
there's more than one kernel version in active use and under
development/support, even by upstream, not to mention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #9 from PaX Team ---
(In reply to Andrew Pinski from comment #7)
> I think there might be a way to check if the option -frandom-seed was passed
> and that might be a better option for your usage anyways. You should check
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #6 from PaX Team ---
(In reply to Andrew Pinski from comment #5)
> > So that I can decide whether I am allowed to do things totally randomly
> > or if I must follow some sort of seeded determinism.
>
> That is almost always the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973
--- Comment #3 from PaX Team ---
(In reply to Andrew Pinski from comment #1)
> Can you attach what is inside cpugen.go?
i'm one of the original bug reproducers, this is what i get here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92817
--- Comment #5 from PaX Team ---
(In reply to Martin Liška from comment #2)
> You are right, it's wrong. Can you please explain to me what control-flow
> integrity check do you use?
it's my own called RAP (Reuse Attack Protector, see
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
git commit db46bcd377f4b4a26b9807a7cb3565a161178660 (since gcc 7) introduced
the callout
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
Target Milestone: ---
When trying to use get_named_event_id/etc for sending events from a plugin,
invoke_plugin_callbacks_full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256
--- Comment #7 from PaX Team ---
(In reply to Jan Hubicka from comment #5)
> I am going to test the patch against mainline and commit it. However about
> backporting, can you produce some issue with this bug?
well, the thing is that i ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
--- Comment #5 from PaX Team ---
(In reply to Andrew Pinski from comment #4)
> Because debug information happens early on and has many interactions with
> the front end.
FINISH_TYPE happens early on too and the API promise gcc makes is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
--- Comment #3 from PaX Team ---
(In reply to Andrew Pinski from comment #1)
> Plugins issues like this should reported to the plugin author and not to gcc.
what makes you think it's a plugin issue? i reported several gcc bugs myself
over the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256
--- Comment #4 from PaX Team ---
any update on this? it seems that the window for fixing 5.x was missed but
perhaps it's still not too late for the others, especially if they get updated
for spectre anyway...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256
--- Comment #2 from PaX Team ---
(In reply to Martin Liška from comment #1)
> Hi. Sorry for the breakage. Are you planning to post patch for that?
i wasn't going to, but here it is:
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
the following
commit
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
Target Milestone: ---
i encountered a crash while building recent linux kernels (v4.5+) in LTO mode.
when i tracked down the root cause it turned out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69758
PaX Team changed:
What|Removed |Added
CC||pageexec at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #21 from PaX Team ---
(In reply to PaX Team from comment #20)
> update for gcc-6: /gcc/params.list is also needed now as it gets
> included by params.h.
PR69758 fixes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #20 from PaX Team ---
(In reply to Josh Triplett from comment #13)
> Note that in addition to complaining if *any* exit to the function doesn't
> have the correct "out" value, you also need to complain if calls to
> functions with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #19 from PaX Team ---
(In reply to Josh Triplett from comment #18)
> (In reply to PaX Team from comment #17)
> > (In reply to Josh Triplett from comment #16)
> > speaking of generalization, the encoding of the lock expression (e.g.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #17 from PaX Team ---
(In reply to Josh Triplett from comment #16)
> (In reply to PaX Team from comment #14)
> > can you give me an example of this?
>
> Sparse warns if you can reach the same basic block with different context
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #14 from PaX Team ---
(In reply to Josh Triplett from comment #13)
> That sounds really plausible to me. GCC's constant propagation seems likely
> to do *at least* as well as Sparse does, if not better. (As long as you
> have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #20 from PaX Team ---
update for gcc-6: /gcc/params.list is also needed now as it gets
included by params.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #12 from PaX Team ---
1. there's a (linux) kernel-hardening effort of late that among others will try
to upstream the PaX gcc plugin infrastructure along with some plugins, so the
checker one could be added to that list (but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #5 from PaX Team ---
(In reply to Josh Triplett from comment #4)
> (In reply to Tom Tromey from comment #3)
> (As a vaguely related aside, how does GCC disambiguate whether an attribute
> preceding the function declaration or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313
--- Comment #2 from PaX Team ---
do you have a few examples of expected input/output path pairs perhaps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #18 from PaX Team pageexec at gmail dot com ---
(In reply to Jakub Jelinek from comment #17)
Created attachment 35144 [details]
gcc5-pr61176.patch
Patch to install all gcc/*.h and gcc/*.def headers, even when they aren't
listed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #14 from PaX Team pageexec at gmail dot com ---
it seems that gcc/builtins.h doesn't get installed for plugins.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
svn commit 201994 (git commit fc3dabd5) changed
DECL_CONSTRUCTOR_P/DECL_DESTRUCTOR_P to use middle-end flags instead of
frontend flags however it didn't remove the now obsolete (unused) c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #23 from PaX Team pageexec at gmail dot com ---
some data points based on my experience with the 'checker' gcc plugin in PaX:
1. the C address space infrastructure available since gcc 4.6 can be sort of
coerced into implementing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
PaX Team pageexec at gmail dot com changed:
What|Removed |Added
CC||pageexec at gmail
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
I recently faced the problem of implementing the four summary read/write
callbacks for an IPA pass in a plugin. It turned out
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
When gcc is configured using
--with-plugin-ld=/some/path/x86_64-pc-linux-gnu-hjl-master/bin/ld the resulting
ld path will be reduced to the incorrect /some
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
Unlike other debug_* functions, debug_bitmap doesn't write to stderr making it
not too useful (and writing to stdout also clobbers the primary output of the
compiler).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #22 from PaX Team pageexec at gmail dot com ---
some notes:
1. there're *.def files as well needed for certain headers
2. there're target specific headers and .def files installed/needed from
gcc/config/*/ as well
3. it's hard to tell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #18 from PaX Team pageexec at gmail dot com ---
found another missing header not installed for plugins: stmt.h (seemingly it
was split off from tree.h which has always been exported, so this probably
counts as a regression).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #17 from PaX Team pageexec at gmail dot com ---
sure, thanks for fixing the already mentioned ones, i verified that all works
fine for my plugins at least. as a related question, isn't there a better way
than playing this whack-a-mole
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #13 from PaX Team pageexec at gmail dot com ---
another missing include in trunk: tree-cfgcleanup.h (it seems that it was split
from tree-flow.h which used to be installed for plugins for gcc 4.5-4.8).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #12 from PaX Team pageexec at gmail dot com ---
two more headers not installed (even by older gcc versions so a backport to at
least 4.8/4.7 would be nice) but they're needed for an rtl pass to be able to
make use of the df info:
df.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #10 from PaX Team pageexec at gmail dot com ---
please reopen, this bug is not fixed yet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #8 from PaX Team pageexec at gmail dot com ---
Uroš, i tried your patch and it didn't install those two files. on the other
hand i found more missing headers:
gcc/tree-phinodes.h
gcc/stor-layout.h
gcc/ssa-iterators.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #6 from PaX Team pageexec at gmail dot com ---
i can confirm that only gcc/config/i386/stringop.def and
gcc/config/i386/x86-tune.def seem to be missing on x86 targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
PaX Team pageexec at gmail dot com changed:
What|Removed |Added
CC||pageexec at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335
--- Comment #3 from PaX Team pageexec at gmail dot com ---
small correction: tree-flow.h and tree-flow-inline.h seem to be removed however
here's an additional list of headers that i needed to copy over manually to get
some plugins to compile
44 matches
Mail list logo
