Re: FIXME in gcc/gimplify.c
On 3/29/19 11:29 PM, nick wrote: > Greetings all, > > Not sure why this exists still as tree-eh.h is including in tree-eh.c which > defines this header > as used for this FIXME: > #include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ > > Unless there is something in the build ordering that would cause issues it's > indirectly including > that way so this header inclusion should now be removed. Unless I'm missing > something else > which is fine. > > If not just let me known and I will just send a patch for it, > Nick > Hi. Using following patch: diff --git a/gcc/gimplify.c b/gcc/gimplify.c index e264700989f..ede679b311c 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -31,7 +31,6 @@ along with GCC; see the file COPYING3. If not see #include "tm_p.h" #include "gimple.h" #include "gimple-predict.h" -#include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ #include "ssa.h" #include "cgraph.h" #include "tree-pretty-print.h" I get: g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimplify.o -MT gimplify.o -MMD -MP -MF ./.deps/gimplify.TPo /home/marxin/Programming/gcc/gcc/gimplify.c /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gbind* gimplify_body(tree, bool)’: /home/marxin/Programming/gcc/gcc/gimplify.c:13636:17: error: ‘TV_TREE_GIMPLIFY’ was not declared in this scope timevar_push (TV_TREE_GIMPLIFY); ^~~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: error: ‘timevar_push’ was not declared in this scope timevar_push (TV_TREE_GIMPLIFY); ^~~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: note: suggested alternative: ‘timeval’ timevar_push (TV_TREE_GIMPLIFY); ^~~~ timeval /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: error: ‘timevar_pop’ was not declared in this scope timevar_pop (TV_TREE_GIMPLIFY); ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: note: suggested alternative: ‘timeval’ timevar_pop (TV_TREE_GIMPLIFY); ^~~ timeval /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘void gimplify_function_tree(tree)’: /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: error: ‘PROP_gimple_lva’ was not declared in this scope cfun->curr_properties |= PROP_gimple_lva; ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: note: suggested alternative: ‘is_gimple_val’ cfun->curr_properties |= PROP_gimple_lva; ^~~ is_gimple_val /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: error: ‘PROP_gimple_any’ was not declared in this scope cfun->curr_properties |= PROP_gimple_any; ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: note: suggested alternative: ‘walk_gimple_op’ cfun->curr_properties |= PROP_gimple_any; ^~~ walk_gimple_op /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gimplify_status gimplify_va_arg_expr(tree_node**, gimple**, gimple**)’: /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: error: ‘PROP_gimple_lva’ was not declared in this scope cfun->curr_properties &= ~PROP_gimple_lva; ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: note: suggested alternative: ‘is_gimple_val’ cfun->curr_properties &= ~PROP_gimple_lva; ^~~ is_gimple_val Martin
Re: [GSoC 2019] Proposal: Parallelize GCC With Threads
On Sun, 31 Mar 2019, Giuliano Belinassi wrote: > Hi, > > I wrote my GSoC Proposal to the "Parallelize GCC with threads" project, > and if someone is interested in it, I am linking the text here in order > to get feedback. Please let me know if something is not entirely clear, > or if there are any problems with the calendar, or if you have any > suggestions. :-) > > Link to the proposal: > https://github.com/giulianobelinassi/proposta-gsoc/blob/master/proposta.pdf > > GitHub seems mess up with the PDF hyperlinks in their viewer, therefore you > will > need to download the PDF if you want to click on them, or use this > mirror i've set: > https://www.ime.usp.br/~belinass/GSoC-Proposal.pdf Hi, I've read the proposal and it is great - the planned tasks timeline is solid and realistic. Of course what will happen between second and final evaluation depends a lot on the amount of issues unconvered. Thanks, Richard. > Thank you, > Giuliano. > -- Richard Biener SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
Re: GSOC Proposal
On Fri, 29 Mar 2019, nick wrote: > > > On 2019-03-29 10:28 a.m., nick wrote: > > > > > > On 2019-03-29 5:08 a.m., Richard Biener wrote: > >> On Thu, 28 Mar 2019, nick wrote: > >> > >>> > >>> > >>> On 2019-03-28 4:59 a.m., Richard Biener wrote: > On Wed, Mar 27, 2019 at 6:31 PM nick wrote: > > > > Greetings All, > > > > I've already done most of the work required for signing up for GSoC > > as of last year i.e. reading getting started, being signed up legally > > for contributions. > > > > My only real concern would be the proposal which I started writing here: > > https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing > > > > The biography and success section I'm fine with my bigger concern would > > be the project and roadmap > > section. The roadmap is there and I will go into more detail about it > > in the projects section as > > need be. Just wanted to known if the roadmap is detailed enough or can > > I just write out a few > > paragraphs discussing it in the Projects Section. > > I'm not sure I understand either the problem analysis nor the project > goal parts. What > shared state with respect to garbage collection are you talking about? > > Richard. > > >>> I just fixed it. Seems we were discussing RTL itself. I edited it to > >>> reflect those changes. Let me know if it's unclear or you would actually > >>> like me to discuss some changes that may occur in the RTL layer itself. > >>> > >>> > >>> I'm glad to be more exact if that's better but seems your confusion was > >>> just what layer we were touching. > >> > >> Let me just throw in some knowledge here. The issue with RTL > >> is that we currently can only have a single function in this > >> intermediate language state since a function in RTL has some > >> state in global variables that would differ if it were another > >> function. We can have multiple functions in GIMPLE intermediate > >> language state since all such state is in a function-specific > >> data structure (struct function). The hard thing about moving > >> all this "global" state of RTL into the same place is that > >> there's global state in the various backends (and there's > >> already a struct funtion 'machine' part for such state, so there's > >> hope the issue isn't as big as it could be) and that some of > >> the global state is big and only changes very rarely. > >> That said, I'm not sure if anybody knows the full details here. > >> > >> So as far as I understand you'd like to tackle this as project > >> with the goal to be able to have multiple functions in RTL > >> state. > >> > >> That's laudable but IMHO also quite ambitious for a GSoC > >> project. It's also an area I am not very familiar with so > >> I opt out of being a mentor for this project. > >> > > While I'm aware of three areas where the shared state is an issue > > currently: > > 1, Compiler's Proper > > 2. The expand_functions > > 3. RTL > > 4.Garbage Collector > > > > Or maybe a project to be more > > explicit about regions of the code that assume that the garbage- > > collector can't run within them?[3] (since the GC is state that would > > be shared by the threads). > > > > This is what we were discussing previously and I wrote my proposal for > > that. You however seem confused about what parts of the garbage collector > > would be touched. That's fine with me, however seems you want be to > > be more exact about which part is touched. > > > > My questions would be as it's changed back to the garbage collector project: > > https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit > > > > 1. Your confusion about which part of the garbage collector is touched > > doesn't > > really make sense s it's for the whole garbage collector as related to > > shared > > state? > > 2. Injection was my code here in phase 3 for the callers of the new > > functions or > > macros, perhaps this is not needed as the work with the garbage collector > > is enough? > > 3. Am I not understanding this project as I thought I was in the proposal I > > wrote? > > > > Seems your more confusing my wording probably so I'm going to suggest one > > of > > two things here: > > a) I'm going to allow you to make comments with what's confusing you and > > it needs that's the issue here more than anything else so I sent you > > a link and please comment where you are having issues with this not > > be clear for you: > > Or maybe a project to be more > > explicit about regions of the code that assume that the garbage- > > collector can't run within them?[3] (since the GC is state that would > > be shared by the threads). > > as that's the actual project > > > > b) Just comment here about the wording that's an issue for you or > > where you want more exact wording > > > > Sorry and hopefully this is helps you understand where I'm go
Re: GSOC Proposal
On 4/1/19 1:24 AM, Eric Gallager wrote: On 3/29/19, nick wrote: Seems your right touching the complete garbage collector is too much. I'm just looking at the users of the garbage collector and it seems one of the major ones is pre compiled headers. The thing about pre-compiled headers is that I seem to remember some GCC devs saying they wanted to rip out pre-compiled headers completely once the C++ modules branch is merged, so I'm not sure if it's worth putting that much work into something that might be removed soon, anyways... I'm pretty sure Nathan Sidwell is the main person working on the C++ modules branch, so I'm cc-ing him. The use of the GC machinery for PCH is needed by the front ends and is orthogonal to that for GC during code generation. nathan -- Nathan Sidwell
Re: GSOC Proposal
On 2019-04-01 5:56 a.m., Richard Biener wrote: > On Fri, 29 Mar 2019, nick wrote: > >> >> >> On 2019-03-29 10:28 a.m., nick wrote: >>> >>> >>> On 2019-03-29 5:08 a.m., Richard Biener wrote: On Thu, 28 Mar 2019, nick wrote: > > > On 2019-03-28 4:59 a.m., Richard Biener wrote: >> On Wed, Mar 27, 2019 at 6:31 PM nick wrote: >>> >>> Greetings All, >>> >>> I've already done most of the work required for signing up for GSoC >>> as of last year i.e. reading getting started, being signed up legally >>> for contributions. >>> >>> My only real concern would be the proposal which I started writing here: >>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing >>> >>> The biography and success section I'm fine with my bigger concern would >>> be the project and roadmap >>> section. The roadmap is there and I will go into more detail about it >>> in the projects section as >>> need be. Just wanted to known if the roadmap is detailed enough or can >>> I just write out a few >>> paragraphs discussing it in the Projects Section. >> >> I'm not sure I understand either the problem analysis nor the project >> goal parts. What >> shared state with respect to garbage collection are you talking about? >> >> Richard. >> > I just fixed it. Seems we were discussing RTL itself. I edited it to > reflect those changes. Let me know if it's unclear or you would actually > like me to discuss some changes that may occur in the RTL layer itself. > > > I'm glad to be more exact if that's better but seems your confusion was > just what layer we were touching. Let me just throw in some knowledge here. The issue with RTL is that we currently can only have a single function in this intermediate language state since a function in RTL has some state in global variables that would differ if it were another function. We can have multiple functions in GIMPLE intermediate language state since all such state is in a function-specific data structure (struct function). The hard thing about moving all this "global" state of RTL into the same place is that there's global state in the various backends (and there's already a struct funtion 'machine' part for such state, so there's hope the issue isn't as big as it could be) and that some of the global state is big and only changes very rarely. That said, I'm not sure if anybody knows the full details here. So as far as I understand you'd like to tackle this as project with the goal to be able to have multiple functions in RTL state. That's laudable but IMHO also quite ambitious for a GSoC project. It's also an area I am not very familiar with so I opt out of being a mentor for this project. >>> While I'm aware of three areas where the shared state is an issue >>> currently: >>> 1, Compiler's Proper >>> 2. The expand_functions >>> 3. RTL >>> 4.Garbage Collector >>> >>> Or maybe a project to be more >>> explicit about regions of the code that assume that the garbage- >>> collector can't run within them?[3] (since the GC is state that would >>> be shared by the threads). >>> >>> This is what we were discussing previously and I wrote my proposal for >>> that. You however seem confused about what parts of the garbage collector >>> would be touched. That's fine with me, however seems you want be to >>> be more exact about which part is touched. >>> >>> My questions would be as it's changed back to the garbage collector project: >>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit >>> >>> 1. Your confusion about which part of the garbage collector is touched >>> doesn't >>> really make sense s it's for the whole garbage collector as related to >>> shared >>> state? >>> 2. Injection was my code here in phase 3 for the callers of the new >>> functions or >>> macros, perhaps this is not needed as the work with the garbage collector >>> is enough? >>> 3. Am I not understanding this project as I thought I was in the proposal I >>> wrote? >>> >>> Seems your more confusing my wording probably so I'm going to suggest one >>> of >>> two things here: >>> a) I'm going to allow you to make comments with what's confusing you and >>> it needs that's the issue here more than anything else so I sent you >>> a link and please comment where you are having issues with this not >>> be clear for you: >>> Or maybe a project to be more >>> explicit about regions of the code that assume that the garbage- >>> collector can't run within them?[3] (since the GC is state that would >>> be shared by the threads). >>> as that's the actual project >>> >>> b) Just comment here about the wording that's an issue for you or >>> where you want more exact wording >>> >>> Sorry and hopef
Re: GSOC Proposal
On Mon, 1 Apr 2019, nick wrote: > > > On 2019-04-01 5:56 a.m., Richard Biener wrote: > > On Fri, 29 Mar 2019, nick wrote: > > > >> > >> > >> On 2019-03-29 10:28 a.m., nick wrote: > >>> > >>> > >>> On 2019-03-29 5:08 a.m., Richard Biener wrote: > On Thu, 28 Mar 2019, nick wrote: > > > > > > > On 2019-03-28 4:59 a.m., Richard Biener wrote: > >> On Wed, Mar 27, 2019 at 6:31 PM nick wrote: > >>> > >>> Greetings All, > >>> > >>> I've already done most of the work required for signing up for GSoC > >>> as of last year i.e. reading getting started, being signed up legally > >>> for contributions. > >>> > >>> My only real concern would be the proposal which I started writing > >>> here: > >>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing > >>> > >>> The biography and success section I'm fine with my bigger concern > >>> would be the project and roadmap > >>> section. The roadmap is there and I will go into more detail about it > >>> in the projects section as > >>> need be. Just wanted to known if the roadmap is detailed enough or > >>> can I just write out a few > >>> paragraphs discussing it in the Projects Section. > >> > >> I'm not sure I understand either the problem analysis nor the project > >> goal parts. What > >> shared state with respect to garbage collection are you talking about? > >> > >> Richard. > >> > > I just fixed it. Seems we were discussing RTL itself. I edited it to > > reflect those changes. Let me know if it's unclear or you would > > actually > > like me to discuss some changes that may occur in the RTL layer itself. > > > > > > I'm glad to be more exact if that's better but seems your confusion was > > just what layer we were touching. > > Let me just throw in some knowledge here. The issue with RTL > is that we currently can only have a single function in this > intermediate language state since a function in RTL has some > state in global variables that would differ if it were another > function. We can have multiple functions in GIMPLE intermediate > language state since all such state is in a function-specific > data structure (struct function). The hard thing about moving > all this "global" state of RTL into the same place is that > there's global state in the various backends (and there's > already a struct funtion 'machine' part for such state, so there's > hope the issue isn't as big as it could be) and that some of > the global state is big and only changes very rarely. > That said, I'm not sure if anybody knows the full details here. > > So as far as I understand you'd like to tackle this as project > with the goal to be able to have multiple functions in RTL > state. > > That's laudable but IMHO also quite ambitious for a GSoC > project. It's also an area I am not very familiar with so > I opt out of being a mentor for this project. > > >>> While I'm aware of three areas where the shared state is an issue > >>> currently: > >>> 1, Compiler's Proper > >>> 2. The expand_functions > >>> 3. RTL > >>> 4.Garbage Collector > >>> > >>> Or maybe a project to be more > >>> explicit about regions of the code that assume that the garbage- > >>> collector can't run within them?[3] (since the GC is state that would > >>> be shared by the threads). > >>> > >>> This is what we were discussing previously and I wrote my proposal for > >>> that. You however seem confused about what parts of the garbage collector > >>> would be touched. That's fine with me, however seems you want be to > >>> be more exact about which part is touched. > >>> > >>> My questions would be as it's changed back to the garbage collector > >>> project: > >>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit > >>> > >>> 1. Your confusion about which part of the garbage collector is touched > >>> doesn't > >>> really make sense s it's for the whole garbage collector as related to > >>> shared > >>> state? > >>> 2. Injection was my code here in phase 3 for the callers of the new > >>> functions or > >>> macros, perhaps this is not needed as the work with the garbage collector > >>> is enough? > >>> 3. Am I not understanding this project as I thought I was in the proposal > >>> I wrote? > >>> > >>> Seems your more confusing my wording probably so I'm going to suggest one > >>> of > >>> two things here: > >>> a) I'm going to allow you to make comments with what's confusing you and > >>> it needs that's the issue here more than anything else so I sent you > >>> a link and please comment where you are having issues with this not > >>> be clear for you: > >>> Or maybe a project to be more > >>> explicit about regions of the code that assume that the
Re: GSOC Proposal
On 2019-04-01 9:47 a.m., Richard Biener wrote: > On Mon, 1 Apr 2019, nick wrote: > >> >> >> On 2019-04-01 5:56 a.m., Richard Biener wrote: >>> On Fri, 29 Mar 2019, nick wrote: >>> On 2019-03-29 10:28 a.m., nick wrote: > > > On 2019-03-29 5:08 a.m., Richard Biener wrote: >> On Thu, 28 Mar 2019, nick wrote: >> >>> >>> >>> On 2019-03-28 4:59 a.m., Richard Biener wrote: On Wed, Mar 27, 2019 at 6:31 PM nick wrote: > > Greetings All, > > I've already done most of the work required for signing up for GSoC > as of last year i.e. reading getting started, being signed up legally > for contributions. > > My only real concern would be the proposal which I started writing > here: > https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing > > The biography and success section I'm fine with my bigger concern > would be the project and roadmap > section. The roadmap is there and I will go into more detail about it > in the projects section as > need be. Just wanted to known if the roadmap is detailed enough or > can I just write out a few > paragraphs discussing it in the Projects Section. I'm not sure I understand either the problem analysis nor the project goal parts. What shared state with respect to garbage collection are you talking about? Richard. >>> I just fixed it. Seems we were discussing RTL itself. I edited it to >>> reflect those changes. Let me know if it's unclear or you would >>> actually >>> like me to discuss some changes that may occur in the RTL layer itself. >>> >>> >>> I'm glad to be more exact if that's better but seems your confusion was >>> just what layer we were touching. >> >> Let me just throw in some knowledge here. The issue with RTL >> is that we currently can only have a single function in this >> intermediate language state since a function in RTL has some >> state in global variables that would differ if it were another >> function. We can have multiple functions in GIMPLE intermediate >> language state since all such state is in a function-specific >> data structure (struct function). The hard thing about moving >> all this "global" state of RTL into the same place is that >> there's global state in the various backends (and there's >> already a struct funtion 'machine' part for such state, so there's >> hope the issue isn't as big as it could be) and that some of >> the global state is big and only changes very rarely. >> That said, I'm not sure if anybody knows the full details here. >> >> So as far as I understand you'd like to tackle this as project >> with the goal to be able to have multiple functions in RTL >> state. >> >> That's laudable but IMHO also quite ambitious for a GSoC >> project. It's also an area I am not very familiar with so >> I opt out of being a mentor for this project. >> > While I'm aware of three areas where the shared state is an issue > currently: > 1, Compiler's Proper > 2. The expand_functions > 3. RTL > 4.Garbage Collector > > Or maybe a project to be more > explicit about regions of the code that assume that the garbage- > collector can't run within them?[3] (since the GC is state that would > be shared by the threads). > > This is what we were discussing previously and I wrote my proposal for > that. You however seem confused about what parts of the garbage collector > would be touched. That's fine with me, however seems you want be to > be more exact about which part is touched. > > My questions would be as it's changed back to the garbage collector > project: > https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit > > 1. Your confusion about which part of the garbage collector is touched > doesn't > really make sense s it's for the whole garbage collector as related to > shared > state? > 2. Injection was my code here in phase 3 for the callers of the new > functions or > macros, perhaps this is not needed as the work with the garbage collector > is enough? > 3. Am I not understanding this project as I thought I was in the proposal > I wrote? > > Seems your more confusing my wording probably so I'm going to suggest one > of > two things here: > a) I'm going to allow you to make comments with what's confusing you and > it needs that's the issue here more than anything else so I sent you > a link and please comment where you are having issues with this not > be clear for you: > Or maybe a project to be more > e
Investicní príležitost
Zdravím, Obsah této posty je velmi duverný a legální. Jmenuji se Peter Wong, pracuji s bankou tady v Hong Kongu. Rozhodl jsem se vás kontaktovat pro moznost investovat do lukrativního podnikání ve va?í zemi. Jsem ochoten Vám nabídnout 40% investicního zisku jako muj obchodní partner. Nase banka nabízí rychlý úver s nízkou úrokovou sazbou bez po?adovaného zajistení. Pokud máte zájem, odpovezte prosím na více informací na mém soukromém e-mailu: pw178...@gmail.com S pozdravem: Peter Wong This email was sent by the shareware version of Postman Professional.
Re: syncing the GCC vax port
On 3/31/19 11:25 AM, Paul Koning wrote: > > >> On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote: >> >> hi folks, >> >> i was interesting in tackling some problems gcc netbsd/vax has. >> it has some ICEs which are in reload phase. searching around, the answer >> to that is "switch to LRA first". Now, I don't quite know what that is >> yet, but I know I need to try to do it. > > That's not quite the whole story. > > The answer is (1) switch from CC0 to CCmode condition code handling, which > enables (2) switch from Reload to LRA. > > (1) requires actual work, not terribly hard but not entirely trivial. (2) > may take as little as switching the "use LRA" flag to "yes". > > I did (1) as well as a tentative (2) for pdp11 last year. It was reasonably > straightforward thanks to a pile of help from Eric Botcazou and his gcc wiki > articles on the subject. You might find the pdp11 deltas for CCmode helpful > as a source of ideas, since the two machines have a fair amount in common as > far as condition codes goes. At least for the integer ops (pdp11 has > separate floating point conditions, vax doesn't). Right. Another port one could look at which recently went through this transition is the v850. Jeff
Re: Applying patch to longlong.h
On 4/1/19 12:57 AM, claz...@gmail.com wrote: > Hi, > > I would like to apply the ARC specific fix for bugzilla 89877 to > include/longlong.h file, but I don't know for sure if I am allowed or > not. I mention that I am the ARC reviewer. If it's in ARC specific bits within longlong.h, then yes, you can just go ahead and apply your fix. Jeff
Re: FIXME in gcc/gimplify.c
On 2019-04-01 4:21 a.m., Martin Liška wrote: > On 3/29/19 11:29 PM, nick wrote: >> Greetings all, >> >> Not sure why this exists still as tree-eh.h is including in tree-eh.c which >> defines this header >> as used for this FIXME: >> #include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ >> >> Unless there is something in the build ordering that would cause issues it's >> indirectly including >> that way so this header inclusion should now be removed. Unless I'm missing >> something else >> which is fine. >> >> If not just let me known and I will just send a patch for it, >> Nick >> > > Hi. > > Using following patch: > > diff --git a/gcc/gimplify.c b/gcc/gimplify.c > index e264700989f..ede679b311c 100644 > --- a/gcc/gimplify.c > +++ b/gcc/gimplify.c > @@ -31,7 +31,6 @@ along with GCC; see the file COPYING3. If not see > #include "tm_p.h" > #include "gimple.h" > #include "gimple-predict.h" > -#include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ > #include "ssa.h" > #include "cgraph.h" > #include "tree-pretty-print.h" > > I get: > > g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common > -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc > -I/home/marxin/Programming/gcc/gcc/. > -I/home/marxin/Programming/gcc/gcc/../include > -I/home/marxin/Programming/gcc/gcc/../libcpp/include > -I/home/marxin/Programming/gcc/gcc/../libdecnumber > -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber > -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimplify.o -MT > gimplify.o -MMD -MP -MF ./.deps/gimplify.TPo > /home/marxin/Programming/gcc/gcc/gimplify.c > /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gbind* > gimplify_body(tree, bool)’: > /home/marxin/Programming/gcc/gcc/gimplify.c:13636:17: error: > ‘TV_TREE_GIMPLIFY’ was not declared in this scope >timevar_push (TV_TREE_GIMPLIFY); > ^~~~ > /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: error: ‘timevar_push’ > was not declared in this scope >timevar_push (TV_TREE_GIMPLIFY); >^~~~ > /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: note: suggested > alternative: ‘timeval’ >timevar_push (TV_TREE_GIMPLIFY); >^~~~ >timeval > /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: error: ‘timevar_pop’ was > not declared in this scope >timevar_pop (TV_TREE_GIMPLIFY); >^~~ > /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: note: suggested > alternative: ‘timeval’ >timevar_pop (TV_TREE_GIMPLIFY); >^~~ >timeval > /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘void > gimplify_function_tree(tree)’: > /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: error: > ‘PROP_gimple_lva’ was not declared in this scope >cfun->curr_properties |= PROP_gimple_lva; > ^~~ > /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: note: suggested > alternative: ‘is_gimple_val’ >cfun->curr_properties |= PROP_gimple_lva; > ^~~ > is_gimple_val > /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: error: > ‘PROP_gimple_any’ was not declared in this scope >cfun->curr_properties |= PROP_gimple_any; > ^~~ > /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: note: suggested > alternative: ‘walk_gimple_op’ >cfun->curr_properties |= PROP_gimple_any; > ^~~ > walk_gimple_op > /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gimplify_status > gimplify_va_arg_expr(tree_node**, gimple**, gimple**)’: > /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: error: > ‘PROP_gimple_lva’ was not declared in this scope >cfun->curr_properties &= ~PROP_gimple_lva; > ^~~ > /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: note: suggested > alternative: ‘is_gimple_val’ >cfun->curr_properties &= ~PROP_gimple_lva; > ^~~ > is_gimple_val > > Martin > Martin, Seems this was refactored in commit id,7c29e30e. Andrew MacLeaod seems to be the author so I'm asking him for why this fixme was added during his major reordering and refactoring of included headers in various .c or .cc files in gcc. Nick
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 3/26/19, Andi Kleen wrote: >> That is a correct diagnostics. >> >> See Canonical loop form. >> >> test-exprOne of the following: >> var relational-op b >> b relational-op var >> >> ( var relational-op b ) >> is neither of those. > > Still seems strange to fail for some meaningless brackets. > > But ok. > > -Andi >
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
HI, Discussing the project with Andi, I have drafted a proposal, please review and suggest necessary changes. If some OpenMP experts from GCC have some ideas or changes please suggest. https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing Thanks, Sameeran Joshi.
Re: FIXME in gcc/gimplify.c
On 4/1/19 12:49 PM, nick wrote: On 2019-04-01 4:21 a.m., Martin Liška wrote: On 3/29/19 11:29 PM, nick wrote: Greetings all, Not sure why this exists still as tree-eh.h is including in tree-eh.c which defines this header as used for this FIXME: #include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ Unless there is something in the build ordering that would cause issues it's indirectly including that way so this header inclusion should now be removed. Unless I'm missing something else which is fine. If not just let me known and I will just send a patch for it, Nick Hi. Using following patch: diff --git a/gcc/gimplify.c b/gcc/gimplify.c index e264700989f..ede679b311c 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -31,7 +31,6 @@ along with GCC; see the file COPYING3. If not see #include "tm_p.h" #include "gimple.h" #include "gimple-predict.h" -#include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ #include "ssa.h" #include "cgraph.h" #include "tree-pretty-print.h" I get: g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimplify.o -MT gimplify.o -MMD -MP -MF ./.deps/gimplify.TPo /home/marxin/Programming/gcc/gcc/gimplify.c /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gbind* gimplify_body(tree, bool)’: /home/marxin/Programming/gcc/gcc/gimplify.c:13636:17: error: ‘TV_TREE_GIMPLIFY’ was not declared in this scope timevar_push (TV_TREE_GIMPLIFY); ^~~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: error: ‘timevar_push’ was not declared in this scope timevar_push (TV_TREE_GIMPLIFY); ^~~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: note: suggested alternative: ‘timeval’ timevar_push (TV_TREE_GIMPLIFY); ^~~~ timeval /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: error: ‘timevar_pop’ was not declared in this scope timevar_pop (TV_TREE_GIMPLIFY); ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: note: suggested alternative: ‘timeval’ timevar_pop (TV_TREE_GIMPLIFY); ^~~ timeval /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘void gimplify_function_tree(tree)’: /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: error: ‘PROP_gimple_lva’ was not declared in this scope cfun->curr_properties |= PROP_gimple_lva; ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: note: suggested alternative: ‘is_gimple_val’ cfun->curr_properties |= PROP_gimple_lva; ^~~ is_gimple_val /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: error: ‘PROP_gimple_any’ was not declared in this scope cfun->curr_properties |= PROP_gimple_any; ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: note: suggested alternative: ‘walk_gimple_op’ cfun->curr_properties |= PROP_gimple_any; ^~~ walk_gimple_op /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gimplify_status gimplify_va_arg_expr(tree_node**, gimple**, gimple**)’: /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: error: ‘PROP_gimple_lva’ was not declared in this scope cfun->curr_properties &= ~PROP_gimple_lva; ^~~ /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: note: suggested alternative: ‘is_gimple_val’ cfun->curr_properties &= ~PROP_gimple_lva; ^~~ is_gimple_val Martin Martin, Seems this was refactored in commit id,7c29e30e. Andrew MacLeaod seems to be the author so I'm asking him for why this fixme was added during his major reordering and refactoring of included headers in various .c or .cc files in gcc. Nick Presumably because I didn't add it? I just refactored the major spaghetti-interdependencies, not all the include files. If you look back into 2012 before I did any refactoring, that file looked like: #include "config.h" #include "system.h" #include "coretypes.h" #include "tm.h" #include "tree.h" #include "gimple.h" #include "tree-iterator.h" #include "tree-inline.h" #include "tree-pretty-print.h" #include "langhooks.h" #include "tree-flow.h" #include
GSoC OMPD
Hi, My name is Bryan Carroll and I'm a M.S. student in the Applied Mathematics and Computer Science program at University of Central Oklahoma. I'm interested in the OpenMP and GDB debugger project. A little bit about myself: I've been programming for about 6 years, the majority of those years in C++ or C. Last year I started learning about parallelization. I taught myself MPI and recently started learning OpenMP. I have some experience with compiling - I'm taking a Progamming Languages class right now. The final project is an assembler. I know how to debug programs. However, I don't really know much about how debuggers work. I also don't really know about how OpenMP works underneath the directives. I very much want to learn about these topics. I'm very much willing to learn and think I could be of help to this project. What I'd like to know and discuss: What other pre-requisites are there other than those listed on the GNU GSoC page? Also what would the goals and timeline look like? Thank you for your time, Bryan Carroll M.S. at University of Central Oklahoma
Re: About GSOC.
On Sat, 30 Mar 2019, Tejas Joshi wrote:
> Hello.
> I have developed a fairly working patch for roundeven, attaching herewith.
> The testcase function as follows :
>
> double f()
> {
> double x = 4.5;
> double ret = __builtin_roundeven (x);
> return ret;
> }
Tests need to be added to the testsuite, covering a range of inputs and
automatically verifying that the test is optimized correctly.
"Round X to nearest even integer towards zero." is not correct. The
roundeven function does not round to an even integer. It rounds to the
nearest integer, whether even or odd - but, if two integers are equally
close, the result is even (and for any input that is not halfway between
two integers, it produces the same result as round (which rounds halfway
cases away from zero) - so 2.501, 3 and 3.499 round to 3, but 2.5 rounds
to 2 not 3, unlike round, and 3.5 rounds to 4, as with round).
The function can't rely on arguments being in the range of HOST_WIDE_INT,
so it needs to examine the REAL_VALUE_TYPE representation directly to
determine whether it's half way between two integers and which way to
round in that case.
--
Joseph S. Myers
jos...@codesourcery.com
Re: FIXME in gcc/gimplify.c
On 2019-04-01 1:54 p.m., Andrew MacLeod wrote: > On 4/1/19 12:49 PM, nick wrote: >> >> On 2019-04-01 4:21 a.m., Martin Liška wrote: >>> On 3/29/19 11:29 PM, nick wrote: Greetings all, Not sure why this exists still as tree-eh.h is including in tree-eh.c which defines this header as used for this FIXME: #include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ Unless there is something in the build ordering that would cause issues it's indirectly including that way so this header inclusion should now be removed. Unless I'm missing something else which is fine. If not just let me known and I will just send a patch for it, Nick >>> Hi. >>> >>> Using following patch: >>> >>> diff --git a/gcc/gimplify.c b/gcc/gimplify.c >>> index e264700989f..ede679b311c 100644 >>> --- a/gcc/gimplify.c >>> +++ b/gcc/gimplify.c >>> @@ -31,7 +31,6 @@ along with GCC; see the file COPYING3. If not see >>> #include "tm_p.h" >>> #include "gimple.h" >>> #include "gimple-predict.h" >>> -#include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ >>> #include "ssa.h" >>> #include "cgraph.h" >>> #include "tree-pretty-print.h" >>> >>> I get: >>> >>> g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti >>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings >>> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic >>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common >>> -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc >>> -I/home/marxin/Programming/gcc/gcc/. >>> -I/home/marxin/Programming/gcc/gcc/../include >>> -I/home/marxin/Programming/gcc/gcc/../libcpp/include >>> -I/home/marxin/Programming/gcc/gcc/../libdecnumber >>> -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber >>> -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimplify.o -MT >>> gimplify.o -MMD -MP -MF ./.deps/gimplify.TPo >>> /home/marxin/Programming/gcc/gcc/gimplify.c >>> /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gbind* >>> gimplify_body(tree, bool)’: >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13636:17: error: >>> ‘TV_TREE_GIMPLIFY’ was not declared in this scope >>> timevar_push (TV_TREE_GIMPLIFY); >>> ^~~~ >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: error: ‘timevar_push’ >>> was not declared in this scope >>> timevar_push (TV_TREE_GIMPLIFY); >>> ^~~~ >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13636:3: note: suggested >>> alternative: ‘timeval’ >>> timevar_push (TV_TREE_GIMPLIFY); >>> ^~~~ >>> timeval >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: error: ‘timevar_pop’ >>> was not declared in this scope >>> timevar_pop (TV_TREE_GIMPLIFY); >>> ^~~ >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13726:3: note: suggested >>> alternative: ‘timeval’ >>> timevar_pop (TV_TREE_GIMPLIFY); >>> ^~~ >>> timeval >>> /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘void >>> gimplify_function_tree(tree)’: >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: error: >>> ‘PROP_gimple_lva’ was not declared in this scope >>> cfun->curr_properties |= PROP_gimple_lva; >>> ^~~ >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13792:28: note: suggested >>> alternative: ‘is_gimple_val’ >>> cfun->curr_properties |= PROP_gimple_lva; >>> ^~~ >>> is_gimple_val >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: error: >>> ‘PROP_gimple_any’ was not declared in this scope >>> cfun->curr_properties |= PROP_gimple_any; >>> ^~~ >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13895:28: note: suggested >>> alternative: ‘walk_gimple_op’ >>> cfun->curr_properties |= PROP_gimple_any; >>> ^~~ >>> walk_gimple_op >>> /home/marxin/Programming/gcc/gcc/gimplify.c: In function ‘gimplify_status >>> gimplify_va_arg_expr(tree_node**, gimple**, gimple**)’: >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: error: >>> ‘PROP_gimple_lva’ was not declared in this scope >>> cfun->curr_properties &= ~PROP_gimple_lva; >>> ^~~ >>> /home/marxin/Programming/gcc/gcc/gimplify.c:13988:29: note: suggested >>> alternative: ‘is_gimple_val’ >>> cfun->curr_properties &= ~PROP_gimple_lva; >>> ^~~ >>> is_gimple_val >>> >>> Martin >>> >> Martin, >> >> Seems this was refactored in commit id,7c29e30e. Andrew MacLeaod seems to be >> the author so I'm asking him >> for why this fixme was added during his major reordering and refactoring of >> included headers in vari
Re: GSoC Project Ideas
Hi Richard, Jakub and Martin,
First of all I'm sorry for the very late reply, and I will be more
punctual with my replies from now on.
On Fri, Mar 8, 2019 at 4:35 AM Richard Biener
wrote:
>
> On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor wrote:
> >
> > On 3/4/19 6:17 AM, Richard Biener wrote:
> > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek wrote:
> > >>
> > >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > >* Make TREE_NO_WARNING more fine-grained
> > > (inspired by comment #7 of PR74762 [3])
> > >TREE_NO_WARNING is currently used as a catch-all marker that
> > > inhibits all
> > >warnings related to the marked expression. The problem with
> > > this is that
> > >if some warning routine sets the flag for its own purpose,
> > >then that later may inhibit another unrelated warning from
> > > firing, see for
> > >example PR74762. Implementing a more fine-grained mechanism
> > > for
> > >inhibiting particular warnings would eliminate such issues.
> > Might be interesting. You'd probably need to discuss the details
> > further.
> > >>>
> > >>> I guess an implementation could use TREE_NO_WARNING (or
> > >>> gimple_no_warning_p)
> > >>> as indicator that there's out-of-bad detail information which could be
> > >>> stored as
> > >>> a map keyed off either a location or a tree or gimple *.
> > >>
> > >> I guess on tree or gimple * is better, there would need to be some hook
> > >> for
> > >> copy_node/gimple_copy that would add the info for the new copy as well if
> > >> the TREE_NO_WARNING or gimple_no_warning_p bit was set. Plus there
> > >> could be
> > >> some purging of this on the side information, e.g. once code is handed
> > >> over
> > >> from the FE to the middle-end (maybe do that only at free_lang_data
> > >> time),
> > >> for any warnings that are FE only there is no need to keep records in
> > >> the on
> > >> the side mapping that have info about those FE warnings only, as later on
> > >> the FE warnings will not be reported anymore.
> > >> The implementation could be e.g. a hash map from tree/gimple *
> > >> (pointers) to
> > >> bitmaps of warning numbers, with some hash table to ensure that the same
> > >> bitmap is used for all the spots that need to have the same set of
> > >> warnings
> > >> disabled.
This design makes a lot of sense, thank you for this!
> > >
> > > A possibly related project is to "defer" output of diagnostics until we
> > > know
> > > the stmt/expression we emit it for survived dead code elimination. Here
> > > there's
> > > the question what to key the diagnostic off and how to move it (that is,
> > > detect
> > > if the code causing it really fully went dead).
Interesting. Which diagnostics would you have in mind to defer in this way?
> >
> > Another (maybe only remotely related) aspect of this project might
> > be getting #pragma GCC diagnostic to work reliably with middle-end
> > warnings emitted for inlined code. That it doesn't work is one of
> > the frustrations for users who run into false positives with "late"
> > warnings like -Wstringop-overflow or -Wformat-overflow.
Thank you Martin for bringing this up!
>
> A similar issue is they are not carried along from compile-time to
> LTO link time. I'm not even sure how they are attached to anything
> right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION.
This is good to know too.
I know that there is only a week left to submit a proposal, but I am
thinking of a project proposal that can be summarized in one line as
"Improving the diagnostics infrastructure of GCC," which combines the
original proposal about a finer-grained
TREE_NO_WARNING/gimple_no_warning mechanism along with Richard's and
Martin's ideas of preserving diagnostic pragmas after inlining and for
LTO link time, and maybe Richard's idea of being able to defer
diagnostics until we know for sure that the code in question survives
DCE. Would such a proposal be well-defined and tractable enough for
GSoC? If so, would anyone volunteer to be a mentor for this project?
Regards,
Patrick
>
> > I'm sure there are bugs that track this but here's a test case
> > involving -Warray-bounds:
> >
> >int a[3];
> >
> >int f (int i)
> >{
> > return a[i];
> >}
> >
> >#pragma GCC diagnostic push
> >#pragma GCC diagnostic ignored "-Warray-bounds"
> >int g (void)
> >{
> > return f (7); // expect no -Warray-bounds
> >}
> >#pragma GCC diagnostic pop
> >
> >int h (void)
> >{
> > return f (7); // expect -Warray-bounds
> >}
> >
> > Martin
Re: GSoC Project Ideas
On Sun, Mar 3, 2019 at 5:16 PM Jeff Law wrote: > > On 3/3/19 4:06 PM, Patrick Palka wrote: > > Hi everyone, > > > > I am very interested in working on GCC as part of GSoC this year. A few > > years > > ago I was a somewhat active code contributor[1] and unfortunately my > > contributing waned once I went back to school, but I'm excited to > > potentially > > have the opportunity to work on GCC again this summer. My contributions > > were > > mainly to the C++ frontend and to the middle end, and I've been thinking > > about > > potential projects in these areas of the compiler. Here are some project > > ideas > > related to parts of the compiler that I've worked on in the past: > > > > * Extend VRP to track unions of intervals > > (inspired by comment #2 of PR72443 [2]) > > Value ranges tracked by VRP currently are represented as an interval > > or > > its complement: [a,b] and ~[a,b]. A natural extension of this is > > to support unions of intervals, e.g. [a,b]U[c,d]. Such an extension > > would make VRP more powerful and at the same time would subsume > > anti-ranges, potentially making the code less complex overall. > You should get in contact with Aldy and Andrew. I believe their work > already subsumes everything you've mentioned here. > > > > > > > * Make TREE_NO_WARNING more fine-grained > > (inspired by comment #7 of PR74762 [3]) > > TREE_NO_WARNING is currently used as a catch-all marker that inhibits > > all > > warnings related to the marked expression. The problem with this is > > that > > if some warning routine sets the flag for its own purpose, > > then that later may inhibit another unrelated warning from firing, > > see for > > example PR74762. Implementing a more fine-grained mechanism for > > inhibiting particular warnings would eliminate such issues. > Might be interesting. You'd probably need to discuss the details further. > > > > > > * Make -Wmaybe-uninitialized more robust > > (Inspired by the recent thread to move -Wmaybe-uninitialized to > > -Wextra [4]) > > Right now the pass generates too many false-positives, and hopefully > > that > > can be fixed somewhat. > > I think a distinction could be made between the following two > > scenarios in > > which a false-positive warning is emitted: > > 1. the pass incorrectly proves that there exists an execution path > > that > >results in VAR being used uninitialized due to a deficiency in > > the > >implementation, or > > 2. the pass gives up on exhaustively verifying that all execution > > paths > >use VAR initialized (e.g. because there are too many paths to > > check). > >The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently > > control > >when this happens. > > I'd guess that a significant fraction of false-positives occur due to > > the > > second case, so maybe it would be worthwhile to allow the user to > > suppress > > warnings of this second type by specifying a warning level argument, > > e.g. > > -Wmaybe-uninitialized=1|2. > > Still, false-positives are generated in the first case too, see e.g. > > PR61112. These can be fixed by improving the pass to understand such > > control flow. > I'd suggest you look at my proposal from 2005 if you want to improve > some of this stuff. > > You might also look at the proposal to distinguish between simple > scalars that are SSA_NAMEs and the addressable/aggregate cases. > > In general I'm not a fan of extending the predicate analysis as-is in > tree-ssa-uninit.c. I'd first like to see it broken into an independent > analysis module. The analysis it does has applications for other > warnings and optimizations. Uninit warnings would just be a client of > hte generic analysis pass. > > I'd love a way to annotate paths (or subpaths, or ssa-names) for cases > where the threaders identify a jump threading path, but don't actually > optimize it (often because it's a cold path or to avoid code bloat > problems). THese unexecutable paths that we leave in the CFG are often > a source of false positives when folks use -O1, -Os and profile directed > optimizations. Bodik has some thoughts in this space, but I haven't > really looked to see how feasible they are in the real world. Hi Jeff, I read your proposal from 2005 (I think the main part is https://gcc.gnu.org/ml/gcc/2005-11/msg00040.html) and I wonder how your position has changed since the uninit pass has been made predicate-aware. I see what you mean about breaking the predicate analysis out from the rest of the uninit pass. Would that be a good start of a project on improving the uninit pass? If so, I have in mind a project proposal that would consist of: 1. breaking out the predicate analysis from the rest of the uninit pass, 2. enhancing the uninit pass to detect uninitia
