Re: Usage of C11 Annex K Bounds-checking interfaces on GCC
On Tue, 10 Dec 2019 at 06:22, Andrew Pinski wrote: > > On Mon, Dec 9, 2019 at 10:14 PM li zi wrote: > > > > Hi All, > > We are using gcc in our projects and we found some of the C standard > > functions (like memcpy, strcpy) used in gcc may induce security > > vulnerablities like buffer overflow. Currently we have not found any > > instances which causes such issues. > > Are you using GCC as a compiler or the sources of GCC to do something > else? If you are using it as a compiler, GCC does NOT provide the > libc functions, another project (e.g. glibc) provides those. And glibc considers them not useful and so doesn't provide them, see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm Your question would have been more appropriate on the gcc-help mailing list, as you're not discussing development of GCC itself.
GCC static analysis branch now available on Compiler Explorer
For the adventurous/curious, my static analyzer branch of GCC [1] is now available on Compiler Explorer (aka godbolt.org) so you can try it out without building it yourself. [Thanks to Matt Godbolt, Patrick Quist and others at the Compiler Explorer project] On https://godbolt.org/ within the C and C++ languages, select "x86-64 gcc (static analysis)" as the compiler (though strictly speaking only C is in-scope right now). It's configured to automatically inject -fanalyzer (just on this site; it isn't the default in the branch). Some precanned examples: * various malloc issues: https://godbolt.org/z/tnx65n * stdio issues: https://godbolt.org/z/4BP-Tj * fprintf in signal handler: https://godbolt.org/z/ew7mW6 * tainted data affecting control flow: https://godbolt.org/z/3v8vSj * password-leakage: https://godbolt.org/z/pRPYiv (the non-malloc examples are much more in "proof-of-concept" territory) Would it make sense to add an "analyzer" component to our bugzilla, even though this is still on a branch? (with me as default assignee) Dave [1] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
Re: GCC static analysis branch now available on Compiler Explorer
On Tue, Dec 10, 2019 at 10:46:59AM -0500, David Malcolm wrote: > For the adventurous/curious, my static analyzer branch of GCC [1] is > now available on Compiler Explorer (aka godbolt.org) so you can try it > out without building it yourself. [Thanks to Matt Godbolt, Patrick > Quist and others at the Compiler Explorer project] Congrats! > On https://godbolt.org/ within the C and C++ languages, select > "x86-64 gcc (static analysis)" > as the compiler (though strictly speaking only C is in-scope right > now). It's configured to automatically inject -fanalyzer (just on this > site; it isn't the default in the branch). > > Some precanned examples: > * various malloc issues: https://godbolt.org/z/tnx65n > * stdio issues: https://godbolt.org/z/4BP-Tj > * fprintf in signal handler: https://godbolt.org/z/ew7mW6 > * tainted data affecting control flow: https://godbolt.org/z/3v8vSj > * password-leakage: https://godbolt.org/z/pRPYiv > (the non-malloc examples are much more in "proof-of-concept" territory) > > Would it make sense to add an "analyzer" component to our bugzilla, > even though this is still on a branch? (with me as default assignee) I think so, we have it for e.g. JIT already, and it's probably just a matter of time before the analyzer is merged. -- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: GCC static analysis branch now available on Compiler Explorer
On 12/10/19 8:46 AM, David Malcolm wrote: For the adventurous/curious, my static analyzer branch of GCC [1] is now available on Compiler Explorer (aka godbolt.org) so you can try it out without building it yourself. [Thanks to Matt Godbolt, Patrick Quist and others at the Compiler Explorer project] On https://godbolt.org/ within the C and C++ languages, select "x86-64 gcc (static analysis)" as the compiler (though strictly speaking only C is in-scope right now). It's configured to automatically inject -fanalyzer (just on this site; it isn't the default in the branch). Some precanned examples: * various malloc issues: https://godbolt.org/z/tnx65n * stdio issues: https://godbolt.org/z/4BP-Tj * fprintf in signal handler: https://godbolt.org/z/ew7mW6 * tainted data affecting control flow: https://godbolt.org/z/3v8vSj * password-leakage: https://godbolt.org/z/pRPYiv (the non-malloc examples are much more in "proof-of-concept" territory) Would it make sense to add an "analyzer" component to our bugzilla, even though this is still on a branch? (with me as default assignee) Yes, that would make sense to me for bugs/enhancements specific to just the analyzer. I think it's important to have a shared understanding how requests for new warnings (either completely new features or enhancements to existing ones) should be triaged in Bugzilla. For instance, pr82520 is a request to enhance -Wreturn-local-addr to detect other forms of escaping dangling pointers besides by returning them from functions. I think the request (and a number of others) would be a good fit for the analyzer as well, but assigning it to the analyzer component would suggest that it's suitable only for it. How do we track requests that we'd like handled in both? Martin Dave [1] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
Re: GCC static analysis branch now available on Compiler Explorer
On Tue, 2019-12-10 at 11:04 -0500, Marek Polacek wrote: > On Tue, Dec 10, 2019 at 10:46:59AM -0500, David Malcolm wrote: [...] > > Would it make sense to add an "analyzer" component to our bugzilla, > > even though this is still on a branch? (with me as default > > assignee) > > I think so, we have it for e.g. JIT already, and it's probably just a > matter > of time before the analyzer is merged. It turns out I had admin rights to do this, so I've gone ahead and created an "analyzer" component for the "gcc" product within our bugzilla; I'm the default assignee. Dave
Re: GCC static analysis branch now available on Compiler Explorer
On Tue, 2019-12-10 at 12:11 -0500, David Malcolm wrote: > On Tue, 2019-12-10 at 11:04 -0500, Marek Polacek wrote: > > On Tue, Dec 10, 2019 at 10:46:59AM -0500, David Malcolm wrote: > [...] > > > Would it make sense to add an "analyzer" component to our > > > bugzilla, > > > even though this is still on a branch? (with me as default > > > assignee) > > > > I think so, we have it for e.g. JIT already, and it's probably just > > a > > matter > > of time before the analyzer is merged. > > It turns out I had admin rights to do this, so I've gone ahead and > created an "analyzer" component for the "gcc" product within our > bugzilla; I'm the default assignee. I've also created an "analyzer branch" version within BZ for such bugs, given that they'd be being filed against my branch, rather than trunk. Dave
Re: GCC static analysis branch now available on Compiler Explorer
On Tue, 2019-12-10 at 09:36 -0700, Martin Sebor wrote: > On 12/10/19 8:46 AM, David Malcolm wrote: > > For the adventurous/curious, my static analyzer branch of GCC [1] > > is > > now available on Compiler Explorer (aka godbolt.org) so you can try > > it > > out without building it yourself. [Thanks to Matt Godbolt, Patrick > > Quist and others at the Compiler Explorer project] > > > > On https://godbolt.org/ within the C and C++ languages, select > >"x86-64 gcc (static analysis)" > > as the compiler (though strictly speaking only C is in-scope right > > now). It's configured to automatically inject -fanalyzer (just on > > this > > site; it isn't the default in the branch). > > > > Some precanned examples: > >* various malloc issues: https://godbolt.org/z/tnx65n > >* stdio issues: https://godbolt.org/z/4BP-Tj > >* fprintf in signal handler: https://godbolt.org/z/ew7mW6 > >* tainted data affecting control flow: > > https://godbolt.org/z/3v8vSj > >* password-leakage: https://godbolt.org/z/pRPYiv > > (the non-malloc examples are much more in "proof-of-concept" > > territory) > > > > Would it make sense to add an "analyzer" component to our bugzilla, > > even though this is still on a branch? (with me as default > > assignee) > > Yes, that would make sense to me for bugs/enhancements specific to > just the analyzer. > > I think it's important to have a shared understanding how requests > for new warnings (either completely new features or enhancements to > existing ones) should be triaged in Bugzilla. For instance, pr82520 > is a request to enhance -Wreturn-local-addr to detect other forms of > escaping dangling pointers besides by returning them from functions. > I think the request (and a number of others) would be a good fit for > the analyzer as well, but assigning it to the analyzer component > would suggest that it's suitable only for it. How do we track > requests that we'd like handled in both? It feels to me that the question of BZ component is a proxy for a deeper scope question about what we want to handle in each warning. If it's clear that we want an issue handled by both the core code *and* by the analyzer, then we should have two PRs. Perhaps discuss in the PRs which things we expect to be handled by which warning (e.g. some cases might be capable of being caught by -Wreturn-local-addr, others might require the deeper analysis of -fanalyzer). Otherwise, have a single PR and assign it accordingly. I'm not sure if that answers your question. Dave > Martin > > > Dave > > > > [1] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > > >
Re: GCC static analysis branch now available on Compiler Explorer
On 12/10/19 10:56 AM, David Malcolm wrote: On Tue, 2019-12-10 at 09:36 -0700, Martin Sebor wrote: On 12/10/19 8:46 AM, David Malcolm wrote: For the adventurous/curious, my static analyzer branch of GCC [1] is now available on Compiler Explorer (aka godbolt.org) so you can try it out without building it yourself. [Thanks to Matt Godbolt, Patrick Quist and others at the Compiler Explorer project] On https://godbolt.org/ within the C and C++ languages, select "x86-64 gcc (static analysis)" as the compiler (though strictly speaking only C is in-scope right now). It's configured to automatically inject -fanalyzer (just on this site; it isn't the default in the branch). Some precanned examples: * various malloc issues: https://godbolt.org/z/tnx65n * stdio issues: https://godbolt.org/z/4BP-Tj * fprintf in signal handler: https://godbolt.org/z/ew7mW6 * tainted data affecting control flow: https://godbolt.org/z/3v8vSj * password-leakage: https://godbolt.org/z/pRPYiv (the non-malloc examples are much more in "proof-of-concept" territory) Would it make sense to add an "analyzer" component to our bugzilla, even though this is still on a branch? (with me as default assignee) Yes, that would make sense to me for bugs/enhancements specific to just the analyzer. I think it's important to have a shared understanding how requests for new warnings (either completely new features or enhancements to existing ones) should be triaged in Bugzilla. For instance, pr82520 is a request to enhance -Wreturn-local-addr to detect other forms of escaping dangling pointers besides by returning them from functions. I think the request (and a number of others) would be a good fit for the analyzer as well, but assigning it to the analyzer component would suggest that it's suitable only for it. How do we track requests that we'd like handled in both? It feels to me that the question of BZ component is a proxy for a deeper scope question about what we want to handle in each warning. If it's clear that we want an issue handled by both the core code *and* by the analyzer, then we should have two PRs. Perhaps discuss in the PRs which things we expect to be handled by which warning (e.g. some cases might be capable of being caught by -Wreturn-local-addr, others might require the deeper analysis of -fanalyzer). You're quite right that the two questions are related, and it is the latter that prompted my comment above. My concern is that I'm not sure we have a good rule of thumb to decide whether a given warning is better suited to just the analyzer or just the middle-end, or that it should be implemented in both. Or even a good basis for making such decisions. We have not discussed yet if we should even worry about overlap (duplicate warnings issued by both the analyzer and the middle-end). I asked a few questions to help get more clarity here in my comments on the initial patch but only heard from Jeff. So here are some of my thoughts. I'd be very interested in yours (or anyone else's who cares about this subject). I can think of no warning that's currently implemented in the middle- end (or that could be implemented there) that would not also be appropriate for the analyzer. IIUC, it has the potential for finding more problems but may be more noisy than a middle-end implementation, and take longer to analyze code. Are there any kinds of problems that you think are not appropriate for it? Any inherent limitations? At the same time I also think there's room for and value in providing at least some support in the middle-end for pretty much every warning that the analyzer already exposes options for. They may not find as many problems as the analyzer eventually will but they don't have as much overhead (either to implement, or in terms of compile time -- the analysis often benefits optimizations as well). In addition, by being tied to the optimizers the detection provides an opportunity to also prevent the bugs (by folding invalid code away, or inserting traps or branches around it, perhaps under the control of users as we have discussed). In my mind the only reason to have to choose between one and other is the duplication of effort and resource constraints: we don't have enough contributors into either area. There isn't a lot we can about the latter but we should make an effort to minimize the duplication (starting with bug triage). But maybe I'm overanalyzing it and playing it by ear will work just fine. Martin Otherwise, have a single PR and assign it accordingly. I'm not sure if that answers your question. Dave Martin Dave [1] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
Re: Code bloat due to silly IRA cost model?
Hi, doesn't actually anybody know know to make memory more expensive
than registers when it comes to allocating registers?
Whatever I am trying for TARGET_MEMORY_MOVE_COST and
TARGET_REGISTER_MOVE_COST, ira-costs.c always makes registers more
expensive than mem and therefore allocates values to stack slots instead
of keeping them in registers.
Test case (for avr) is as simple as it gets:
float func (float);
float call (float f)
{
return func (f);
}
What am I missing?
Johann
Georg-Johann Lay schrieb:
Hi,
I am trying to track down a code bloat issue and am stuck because I do
not understand IRA's cost model.
The test case is as simple as it gets:
float func (float);
float call (float f)
{
return func (f);
}
IRA dump shows the following insns:
(insn 14 4 2 2 (set (reg:SF 44)
(reg:SF 22 r22 [ f ])) "bloat.c":4:1 85 {*movsf}
(expr_list:REG_DEAD (reg:SF 22 r22 [ f ])
(nil)))
(insn 2 14 3 2 (set (reg/v:SF 43 [ f ])
(reg:SF 44)) "bloat.c":4:1 85 {*movsf}
(expr_list:REG_DEAD (reg:SF 44)
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SF 22 r22)
(reg/v:SF 43 [ f ])) "bloat.c":5:12 85 {*movsf}
(expr_list:REG_DEAD (reg/v:SF 43 [ f ])
(nil)))
(call_insn/j 7 6 8 2 (parallel [
#14 sets pseudo 44 from arg register R22.
#2 moves it to pseudo 43
#6 moves it to R22 as it prepares for call_insn #7.
There are 2 allocnos and cost:
Pass 0 for finding pseudo/allocno costs
a1 (r44,l0) best NO_REGS, allocno NO_REGS
a0 (r43,l0) best NO_REGS, allocno NO_REGS
a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
which is quite odd because MEM is way more expensive here than any REG.
Okay, so let's boost the MEM cost (TARGET_MEMORY_MOVE_COST) by a factor
of 100:
a1 (r44,l0) best NO_REGS, allocno NO_REGS
a0 (r43,l0) best NO_REGS, allocno NO_REGS
a0(r43,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000
a1(r44,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000
What??? The REG costs are 100 times higher, and stille higher that the
MEM costs. What the heck is going on?
Setting TARGET_REGISTER_MOVE_COST and also TARGET_MEMORY_MOVE_COST to 0
yiels:
a0(r43,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
GENERAL_REGS:0 MEM:0
a1(r44,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
GENERAL_REGS:0 MEM:0
as expected, i.e. there is no other hidden source of costs considered by
IRA. And even TARGET_REGISTER_MOVE_COST = 0 and
TARGET_MEMORY_MOVE_COST = original gives:
a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
How the heck do I tell ira-costs that registers are way cheaper than MEM?
Johann
p.s.
test case compiled with
$ avr-gcc bloat.c -S -Os -dp -da -fsplit-wide-types-early -v
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-10 --disable-shared --disable-nls
--with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld
--enable-checking=release --enable-languages=c,c++ --disable-gcov
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191021 (experimental) (GCC)
Re: GCC static analysis branch now available on Compiler Explorer
On Tue, 2019-12-10 at 12:51 -0700, Martin Sebor wrote: > On 12/10/19 10:56 AM, David Malcolm wrote: > > On Tue, 2019-12-10 at 09:36 -0700, Martin Sebor wrote: > > > On 12/10/19 8:46 AM, David Malcolm wrote: > > > > For the adventurous/curious, my static analyzer branch of GCC > > > > [1] > > > > is > > > > now available on Compiler Explorer (aka godbolt.org) so you can > > > > try > > > > it > > > > out without building it yourself. [Thanks to Matt Godbolt, > > > > Patrick > > > > Quist and others at the Compiler Explorer project] > > > > > > > > On https://godbolt.org/ within the C and C++ languages, select > > > > "x86-64 gcc (static analysis)" > > > > as the compiler (though strictly speaking only C is in-scope > > > > right > > > > now). It's configured to automatically inject -fanalyzer (just > > > > on > > > > this > > > > site; it isn't the default in the branch). > > > > > > > > Some precanned examples: > > > > * various malloc issues: https://godbolt.org/z/tnx65n > > > > * stdio issues: https://godbolt.org/z/4BP-Tj > > > > * fprintf in signal handler: https://godbolt.org/z/ew7mW6 > > > > * tainted data affecting control flow: > > > > https://godbolt.org/z/3v8vSj > > > > * password-leakage: https://godbolt.org/z/pRPYiv > > > > (the non-malloc examples are much more in "proof-of-concept" > > > > territory) > > > > > > > > Would it make sense to add an "analyzer" component to our > > > > bugzilla, > > > > even though this is still on a branch? (with me as default > > > > assignee) > > > > > > Yes, that would make sense to me for bugs/enhancements specific > > > to > > > just the analyzer. > > > > > > I think it's important to have a shared understanding how > > > requests > > > for new warnings (either completely new features or enhancements > > > to > > > existing ones) should be triaged in Bugzilla. For instance, > > > pr82520 > > > is a request to enhance -Wreturn-local-addr to detect other forms > > > of > > > escaping dangling pointers besides by returning them from > > > functions. > > > I think the request (and a number of others) would be a good fit > > > for > > > the analyzer as well, but assigning it to the analyzer component > > > would suggest that it's suitable only for it. How do we track > > > requests that we'd like handled in both? > > > > It feels to me that the question of BZ component is a proxy for a > > deeper scope question about what we want to handle in each > > warning. If > > it's clear that we want an issue handled by both the core code > > *and* by > > the analyzer, then we should have two PRs. Perhaps discuss in the > > PRs > > which things we expect to be handled by which warning (e.g. some > > cases > > might be capable of being caught by -Wreturn-local-addr, others > > might > > require the deeper analysis of -fanalyzer). > > You're quite right that the two questions are related, and it is > the latter that prompted my comment above. > > My concern is that I'm not sure we have a good rule of thumb to > decide whether a given warning is better suited to just the analyzer > or just the middle-end, or that it should be implemented in both. > Or even a good basis for making such decisions. We have not > discussed > yet if we should even worry about overlap (duplicate warnings issued > by both the analyzer and the middle-end). I asked a few questions to > help get more clarity here in my comments on the initial patch but > only > heard from Jeff. > > So here are some of my thoughts. I'd be very interested in yours (or > anyone else's who cares about this subject). > > I can think of no warning that's currently implemented in the middle- > end (or that could be implemented there) that would not also be > appropriate for the analyzer. IIUC, it has the potential for finding > more problems but may be more noisy than a middle-end implementation, > and take longer to analyze code. Are there any kinds of problems > that > you think are not appropriate for it? Any inherent limitations? > > At the same time I also think there's room for and value in providing > at least some support in the middle-end for pretty much every warning > that the analyzer already exposes options for. They may not find as > many problems as the analyzer eventually will but they don't have as > much overhead (either to implement, or in terms of compile time -- > the analysis often benefits optimizations as well). In addition, by > being tied to the optimizers the detection provides an opportunity > to also prevent the bugs (by folding invalid code away, or inserting > traps or branches around it, perhaps under the control of users as we > have discussed). > > In my mind the only reason to have to choose between one and other > is the duplication of effort and resource constraints: we don't have > enough contributors into either area. There isn't a lot we can about > the latter but we should make an effort to minimize the duplication > (starting with bug
Re: Questions about IPA/clones and new LTO pass
On Mon, 2019-12-09 at 17:59 -0500, Erick Ochoa wrote: > Hello, > > this is an update on the LTO pass we've been working on. The > optimization is called ipa-initcall-cp because it propagates constant > values written to variables with static lifetimes (such as ones > initialized in initialization functions). [ ... ] Just a note, I suspect most of the development community is currently focused on stage3 bugfixing rather than new code development. So replies may be limited. Jan Hubicka is probably the best person to answer your questions, but others may be able to do so as well. jeff
Re: Questions about IPA/clones and new LTO pass
> On Mon, 2019-12-09 at 17:59 -0500, Erick Ochoa wrote: > > Hello, > > > > this is an update on the LTO pass we've been working on. The > > optimization is called ipa-initcall-cp because it propagates constant > > values written to variables with static lifetimes (such as ones > > initialized in initialization functions). > [ ... ] > Just a note, I suspect most of the development community is currently > focused on stage3 bugfixing rather than new code development. So > replies may be limited. > > Jan Hubicka is probably the best person to answer your questions, but > others may be able to do so as well. Indeed, I am bit swamped at the moment, but I will try to look at this at thursday. Sorry for being slow - feel free to ping me about any IPA/LTO related issues if I respond slowly or not at all. Honza > > jeff >
Question about storing summaries during LTO
Hello,
I am trying to understand how to store information in object files
during LTO.
Is it possible to write arbitrary data in these sections?
There's not a lot of documentation about the specifics I need in the GCC
Internals.
I have made a simple LTO pass that writes
* "Hello world\n" into an LTO section during the write_summary stage, and
* during the read_summary stage it attempts to read the "Hello world\n",
string from the LTO section.
I don't really understand the interfaces yet, but I have "pattern
matched" code from ipa-cp.c to attempt to produce my desired result.
Can anyone point me in the right direction? Any help is greatly
appreciated. I include the small pass that I am using as a playground to
understand how to these interfaces work. I'll still continue working
on understanding the interfaces better.
By compiling and linking two simple files, the dump file for this pass
will contain the strings:
```
HELLO FROM READ SUMMARY
COULDN'T FIND IT
COULDN'T FIND IT
```
GCC will segfault, in a different pass. Probably due to these changes.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6b857bd..f4f1376 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1368,6 +1368,7 @@ OBJS = \
incpath.o \
init-regs.o \
internal-fn.o \
+ ipa-hello-world.o \
ipa-cp.o \
ipa-sra.o \
ipa-devirt.o \
diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
new file mode 100644
index 000..76a5126
--- /dev/null
+++ b/gcc/ipa-hello-world.c
@@ -0,0 +1,106 @@
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "gimple-expr.h"
+#include "predict.h"
+#include "alloc-pool.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "diagnostic.h"
+#include "fold-const.h"
+#include "gimple-fold.h"
+#include "symbol-summary.h"
+#include "tree-vrp.h"
+#include "ipa-prop.h"
+#include "tree-pretty-print.h"
+#include "tree-inline.h"
+#include "ipa-fnsummary.h"
+#include "ipa-utils.h"
+#include "tree-ssa-ccp.h"
+#include "stringpool.h"
+#include "attribs.h"
+#include "gimple.h"
+#include "lto-streamer.h"
+#include "data-streamer.h"
+
+static void
+iphw_generate_summary (void)
+{
+}
+
+static void
+iphw_write_summary (void)
+{
+ struct output_block *ob;
+ ob = create_output_block (LTO_section_hello_world);
+ streamer_write_string (ob, ob->string_stream, "hello world\n", true);
+ lto_write_stream(ob->string_stream);
+ //produce_asm (ob, NULL);
+ destroy_output_block (ob);
+}
+
+static void
+iphw_read_summary (void)
+{
+ if (dump_file) fprintf(dump_file, "HELLO FROM READ SUMMARY\n");
+ struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
+ struct lto_file_decl_data *file_data;
+ unsigned int j = 0;
+
+ while ((file_data = file_data_vec[j++]))
+ {
+ size_t len;
+ const char* data = lto_get_summary_section_data (file_data,
LTO_section_hello_world, &len);
+ if (data && dump_file) fprintf(dump_file, "FROM READ SUMMARY %s\n", data);
+ else fprintf(dump_file, "COULDN'T FIND IT\n");
+ }
+}
+
+static unsigned int
+iphw_execute()
+{
+ return 0;
+}
+
+namespace {
+const pass_data pass_data_ipa_hello_world =
+{
+ IPA_PASS,
+ "hello_world",
+ OPTGROUP_NONE,
+ TV_NONE,
+ (PROP_cfg | PROP_ssa),
+ 0,
+ 0,
+ 0,
+ 0,
+};
+
+class pass_ipa_hello_world : public ipa_opt_pass_d
+{
+public:
+ pass_ipa_hello_world (gcc::context *ctx)
+: ipa_opt_pass_d (pass_data_ipa_hello_world, ctx,
+ iphw_generate_summary,
+ iphw_write_summary,
+ iphw_read_summary,
+ NULL,
+ NULL,
+ NULL,
+ 0,
+ NULL,
+ NULL)
+ {}
+
+ virtual bool gate(function*) { return true; }
+ virtual unsigned execute (function*) { return iphw_execute(); }
+};
+} // anon namespace
+
+ipa_opt_pass_d*
+make_pass_ipa_hello_world (gcc::context *ctx)
+{
+ return new pass_ipa_hello_world (ctx);
+}
diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
index dba195d..c26b334 100644
--- a/gcc/lto-streamer.h
+++ b/gcc/lto-streamer.h
@@ -236,6 +236,7 @@ enum lto_section_type
LTO_section_ipa_hsa,
LTO_section_lto,
LTO_section_ipa_sra,
+ LTO_section_hello_world,
LTO_N_SECTION_TYPES /* Must be last. */
};
diff --git a/gcc/passes.def b/gcc/passes.def
index 798a391..52cd14b 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -146,6 +146,7 @@ along with GCC; see the file COPYING3. If not see
NEXT_PASS (pass_ipa_profile);
NEXT_PASS (pass_ipa_icf);
NEXT_PASS (pass_ipa_devirt);
+ NEXT_PASS (pass_ipa_hello_world);
NEXT_PASS (pass_ipa_cp);
NEXT_PASS (pass_ipa_sra);
NEXT_PASS (pass_ipa_cdtor_merge);
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index a987661..820daaa 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -498,6 +498,7 @@ extern ipa_opt_pass_d *make_pass_ipa_fn_summary
(gcc::context *ctxt);
extern ipa_opt_pass_d *make_pass_ipa_inline (gcc::context *ctxt);
extern simple_ipa_o
How to modify Bugzilla tracker
Hi, I want to alter some information of an existing Bugzilla tracker, such as assignee, but found there is no entrance in page of the Bugzilla tracker to do this. How can I get it? Thanks, Feng
